Det kan være nemt at glemme, at T-SQL FORMAT() funktion giver lokalitetsbevidst formatering. Lokalitetsbevidst betyder, at lokaliteten kan påvirke resultaterne. Med andre ord vil det nøjagtige output, du får, afhænge af lokaliteten.
Som standard bruger funktionen sproget for den aktuelle session til at bestemme lokaliteten. Dette kan dog tilsidesættes ved at sende et "kultur"-argument til funktionen. Ved at gøre dette kan du give resultater for en bestemt lokalitet uden at skulle ændre sproget for den aktuelle session.
Denne artikel indeholder eksempler på, hvordan lokalitet kan påvirke resultaterne, når du bruger FORMAT() funktion i SQL Server.
Eksempel 1 – Valutaer
Her er et hurtigt eksempel til at demonstrere, hvordan sprog/kultur kan påvirke dine resultater, når du formaterer tal.
DECLARE @num decimal(6,2) =1234,56;SELECT FORMAT(@num, 'C', 'en-us') 'en-us', FORMAT(@num, 'C', 'en-gb ') 'en-gb', FORMAT(@num, 'C', 'th-th') 'th-th', FORMAT(@num, 'C', 'nl-nl') 'nl-nl', FORMAT(@num, 'C', 'ne-np') 'ne-np', FORMAT(@num, 'C', 'fa-ir') 'fa-ir';
Resultater:
+-------+--------------------- --+------------+--------------+| en-us | da-dk | th-th | nl-nl | ne-np | fa-ir ||-------------------------------- ---+------------+--------------|| $1.234,56 | £1.234,56 | ฿1.234,56 | € 1.234,56 | रु 1.234,56 | 1.234/56ريال |+------------------------------ ---+------------+--------------+
C i dette eksempel er en standard numerisk formatangivelse. Dette enkelte tegn angiver, at værdien skal formateres på en bestemt måde (i dette tilfælde som en valuta). Heldigvis er SQL Server smart nok til at vide, at ikke alle kulturer bruger det samme format, og det præsenterer automatisk et andet format afhængigt af kulturen.
I ovenstående eksempel, hver gang jeg kalder FORMAT() , sender jeg den samme værdi og formatstreng. Den eneste forskel er værdien af kulturargumentet. Dette får resultaterne til at være forskellige, afhængigt af den anvendte kultur. Valutasymbolet og dets placering bestemmes af kulturen. Tegnet, der bruges til decimalseparatorer og gruppeseparatorer, bestemmes også af kulturen.
Eksempel 2 – Negative værdier
Formatering kan også afhænge af, om værdien er positiv eller negativ. Hvis vi bruger en negativ værdi, sker der her:
DECLARE @num decimal(3,2) =-1,23;SELECT FORMAT(@num, 'C', 'en-us') 'en-us', FORMAT(@num, 'C', 'en- gb') 'en-gb', FORMAT(@num, 'C', 'th-th') 'th-th', FORMAT(@num, 'C', 'nl-nl') 'nl-nl' , FORMAT(@num, 'C', 'ne-np') 'ne-np', FORMAT(@num, 'C', 'fa-ir') 'fa-ir';
Resultater:
+--------+---------+---------+--------+------ ---+-----------+| en-us | da-dk | th-th | nl-nl | ne-np | fa-ir ||--------+--------+--------+--------+--------+----- ----+-----------|| ($1,23) | -£1,23 | -฿1,23 | € -1,23 | -रु 1,23 | 1/23-ريال |+--------+--------+--------+--------+---- ------+-----------+
I nogle kulturer vises minustegnet før valutategnet, i andre vises det efter det. Men i andre kulturer er der slet ikke noget minustegn - det er erstattet med parenteser, der omgiver hele resultatet, inklusive valutategnet.
Vi bør dog ikke antage, at de samme regler anvendes på tværs af alle formatstrenge. For eksempel, hvis vi formaterer det som et tal i stedet for en valuta, får vi ingen parenteser:
DECLARE @num decimal(3,2) =-1,23;SELECT FORMAT(@num, 'N', 'en-us') 'en-us', FORMAT(@num, 'N', 'en- gb') 'en-gb', FORMAT(@num, 'N', 'th-th') 'th-th', FORMAT(@num, 'N', 'nl-nl') 'nl-nl' , FORMAT(@num, 'N', 'ne-np') 'ne-np', FORMAT(@num, 'N', 'fa-ir') 'fa-ir';
Resultater:
+--------+---------+---------+--------+------ ---+---------+| en-us | da-dk | th-th | nl-nl | ne-np | fa-ir ||--------+--------+--------+--------+--------+----- ----+---------|| -1,23 | -1,23 | -1,23 | -1,23 | -1,23 | 1/23- |+---------+--------+--------+--------+---- -----+---------+
Eksempel 3 – Datoer og tidspunkter
Talformatering er ikke det eneste, der påvirkes af kultur. Datoer og tidspunkter vil for eksempel også blive formateret forskelligt afhængigt af kulturen.
DECLARE @date datetime2(0) ='2019-06-15 13:45:30';SELECT FORMAT(@date, 'G', 'en-us') 'en-us', FORMAT(@date , 'G', 'en-gb') 'en-gb', FORMAT(@date, 'G', 'th-th') 'th-th', FORMAT(@date, 'G', 'nl- nl') 'nl-nl', FORMAT(@date, 'G', 'ne-np') 'ne-np', FORMAT(@date, 'G', 'fa-ir') 'fa-ir';
Resultater (ved hjælp af lodret output):
da-us | 15/6/2019 13:45:30Men-gb | 15/06/2019 13:45:30th-th | 15/6/2562 13:45:30nl-nl | 15-6-2019 13:45:30ne-np | 15/6/2019 1:45:30 अपराह्नfa-ir | 25/03/1398 01:45:30 ب.ظ
Dette eksempel bruger et generelt dato/langtidsformat (opnået ved at bruge G). – en af standardformaterne for dato og klokkeslæt), og forskellene mellem kulturer er indlysende.
Men vi kan også se forskelle, selv når vi bruger et langt datoformat:
DECLARE @date datetime2(0) ='2019-06-15 13:45:30';SELECT FORMAT(@date, 'F', 'en-us') 'en-us', FORMAT(@date , 'F', 'en-gb') 'en-gb', FORMAT(@date, 'F', 'th-th') 'th-th', FORMAT(@date, 'F', 'nl- nl') 'nl-nl', FORMAT(@date, 'F', 'ne-np') 'ne-np', FORMAT(@date, 'F', 'fa-ir') 'fa-ir';
Resultater (ved hjælp af lodret output):
da-us | Lørdag den 15. juni 2019 13:45:30 PMen-gb | 15. juni 2019 13:45:30-th | 15 มิถุนายน 2562 13:45:30nl-nl | lørdag 15. juni 2019 13:45:30ne-np | maj, 15. maj 2019 1:45:30 kl. fa-ir | søndag, 25. maj 1398 01:45:30 ب.ظ
Eksempel 4 – Hvad med strenge til tilpasset format?
De foregående eksempler bruger standardformatstrenge, som stort set gør formateringen for dig. Det er som en kortfattet måde at specificere en brugerdefineret formatstreng. En brugerdefineret formatspecifikation giver dig på den anden side mulighed for at specificere præcis, hvilke tegn der skal vises i outputtet, og hvor de skal hen. Dette betyder dog typisk, at du skal bruge flere formatspecifikationer i din formatstreng.
Men selv når du bruger brugerdefinerede formatspecifikationer, kan det nøjagtige output også afhænge af lokaliteten. Hvis vi ville bruge en tilpasset dato- og tidsformatstreng til at efterligne det forrige eksempel, kunne vi gøre noget som dette:
DECLARE @date datetime2(0) ='2019-06-15 13:45:30';SELECT FORMAT(@date, 'dddd, dd MMMM yyyy tt:mm:ss tt', 'en-us') 'en-us', FORMAT(@date, 'dddd, dd MMMM åååå tt:mm:ss tt', 'en-gb') 'en-gb', FORMAT(@dato, 'dddd, dd MMMM åååå tt:mm:ss tt', 'th-th') 'th-th', FORMAT(@date, 'dddd, dd MMMM åååå tt:mm:ss tt', 'nl-nl') 'nl-nl', FORMAT (@date, 'dddd, dd MMMM åååå tt:mm:ss tt', 'ne-np') 'ne-np', FORMAT(@date, 'dddd, dd MMMM åååå tt:mm:ss tt', ' fa-ir') 'fa-ir';
Resultater (ved hjælp af lodret output):
da-us | Lørdag 15. juni 2019 01:45:30 PMen-gb | Lørdag, 15. juni 2019 01:45:30 PMth-th | เสาร์, 15 มิถุนายน 2562 01:45:30 PMnl-nl | lørdag, 15 juni 2019 01:45:30 ne-np | maj, 15. marts 2019 01:45:30 kl. fa-ir | søndag, 25. maj 1398 01:45:30 ب.ظ
Den nok mest åbenlyse observation er, at resultatet er formateret ved hjælp af sproget i den angivne lokalitet. Men hvis vi ser nøje efter, kan vi se, at den også ignorerer AM/PM-designatoren (tt ) for nl-nl kultur, sandsynligvis fordi den kultur typisk bruger 24 timers uret. Vi kan også se, at selv vores positionering kan ignoreres i nogle tilfælde (f.eks. fa-ir ).
Det er dog ikke alt, der ignoreres, og derfor ender vi med en kombination af vores eksplicitte specifikationer og dem, der bestemmes af lokaliteten.
Find/ændre dit nuværende sprog
Som nævnt, hvis du ikke angiver "kultur"-argumentet, vil sproget for din nuværende session blive brugt til at bestemme lokaliteten.
Der er flere måder at finde sproget for din aktuelle session på.
Du kan også ændre lokaliteten for din nuværende forbindelse.
Alternativt kan du bare bruge SET LANGUAGE sætning for at skifte det aktuelle sprog efter behov.
Her er et hurtigt eksempel med SET LANGUAGE for at vise, at dine egne sprogindstillinger kan påvirke formateringsresultaterne på samme måde, som når du bruger "kultur"-argumentet, som i de foregående eksempler.
DECLARE @num decimal(3,2) =-1.23;SET LANGUAGE British;SELECT FORMAT(@num, 'C') Resultat;SET LANGUAGE US_English;SELECT FORMAT(@num, 'C') Resultat;Resultater:
+----------+| Resultat ||--------|| -£1,23 |+----------++----------+| Resultat ||--------|| ($1,23) |+----------+