Det kan vara lätt att glömma att T-SQL FORMAT() funktionen ger språkmedveten formatering. Platsmedveten betyder att lokalen kan påverka resultaten. Med andra ord kommer den exakta utdata du får att bero på platsen.
Som standard använder funktionen språket för den aktuella sessionen för att bestämma språket. Detta kan dock åsidosättas genom att skicka ett "kultur"-argument till funktionen. Genom att göra detta kan du tillhandahålla resultat för en viss plats utan att behöva ändra språket för den aktuella sessionen.
Den här artikeln innehåller exempel på hur lokalitet kan påverka resultaten när du använder FORMAT() funktion i SQL Server.
Exempel 1 – Valutor
Här är ett snabbt exempel för att visa hur språk/kultur kan påverka dina resultat när du formaterar siffror.
DECLARE @num decimal(6,2) =1234,56;VÄLJ 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';
Resultat:
+-------+---------------------- --+------------+--------------+| sv-us | sv-gb | th-th | nl-nl | ne-np | fa-ir ||--------------------------------- ---+------------+-------------|| 1 234,56 USD | £1 234,56 | ฿1 234,56 | 1 234,56 € | रु 1 234,56 | 1,234/56ريال |+------------------------------- ---+------------+--------------+
C i detta exempel är en standard numerisk formatspecifikation. Detta enstaka tecken anger att värdet ska formateras på ett visst sätt (i det här fallet som en valuta). Som tur är är SQL Server smart nog att veta att inte alla kulturer använder samma format, och den presenterar automatiskt ett annat format beroende på kultur.
I exemplet ovan, varje gång jag anropar FORMAT() , skickar jag samma värde och formatsträng. Den enda skillnaden är värdet av kulturargumentet. Detta gör att resultaten blir olika beroende på vilken kultur som används. Valutasymbolen och dess placering bestäms av kulturen. Tecknet som används för decimalavgränsare och gruppavgränsare bestäms också av kulturen.
Exempel 2 – Negativa värden
Formateringen kan också bero på om värdet är positivt eller negativt. Om vi använder ett negativt värde händer det här:
DECLARE @num decimal(3,2) =-1,23;VÄLJ 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';
Resultat:
+--------+---------+--------+--------+------ ---+-----------+| sv-us | sv-gb | th-th | nl-nl | ne-np | fa-ir ||--------+--------+--------+--------+--------+----- ----+-----------|| ($1,23) | -£1,23 | -฿1,23 | € -1,23 | -रु 1,23 | 1/23-ريال |+---------+--------+--------+--------+---- ------+-----------+
I vissa kulturer visas minustecknet före valutatecknet, i andra förekommer det efter det. Men i andra kulturer finns det inget minustecken alls - det är ersatt med parenteser som omger hela resultatet, inklusive valutatecknet.
Vi bör dock inte anta att samma regler tillämpas på alla formatsträngar. Om vi till exempel formaterar det som ett tal istället för en valuta, får vi inga parenteser:
DECLARE @num decimal(3,2) =-1,23;VÄLJ 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';
Resultat:
+--------+---------+--------+--------+------ ---+---------+| sv-us | sv-gb | th-th | nl-nl | ne-np | fa-ir ||--------+--------+--------+--------+--------+----- ----+---------|| -1,23 | -1,23 | -1,23 | -1,23 | -1,23 | 1/23- |+---------+--------+---------+--------+---- -----+---------+
Exempel 3 – Datum och tider
Nummerformatering är inte det enda som påverkas av kultur. Datum och tider till exempel kommer också att formateras olika beroende på kultur.
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';
Resultat (med vertikal utdata):
sv-us | 15/6/2019 13:45:30Men-gb | 15/06/2019 13:45:30:e | 15/6/2562 13:45:30nl-nl | 15-6-2019 13:45:30ne-np | 6/15/2019 1:45:30 अपराह्नfa-ir | 25/03/1398 01:45:30 ب.ظ
Det här exemplet använder ett allmänt datum/långtidsformat (som uppnås genom att använda G – en av standardspecifikationerna för datum- och tidsformat), och skillnaderna mellan kulturer är uppenbara.
Men vi kan också se skillnader även när vi använder ett långt datumformat:
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';
Resultat (med vertikal utdata):
sv-us | Lördagen den 15 juni 2019 13:45:30 Men-gb | 15 juni 2019 13:45:30:e | 15 มิถุนายน 2562 13:45:30nl-nl | lördag 15 juni 2019 13:45:30ne-np | den 15 december 2019 1:45:30 अपराह्नfa-ir | söndag, 25 maj 1398 01:45:30 ب.ظ
Exempel 4 – Hur är det med anpassade formatsträngar?
De tidigare exemplen använder standardformatsträngar, som i stort sett gör formateringen åt dig. Det är som ett kortfattat sätt att ange en anpassad formatsträng. En anpassad formatspecifikator å andra sidan låter dig specificera exakt vilka tecken som ska visas i utdata och vart de går. Detta innebär dock vanligtvis att du behöver använda fler formatspecifikationer i din formatsträng.
Men även när du använder anpassade formatspecifikationer kan den exakta utdatan också bero på språket. Om vi ville använda en anpassad datum- och tidsformatsträng för att efterlikna föregående exempel, kan vi göra något så här:
DECLARE @date datetime2(0) ='2019-06-15 13:45:30';SELECT FORMAT(@date, 'dddd, dd MMMM yyyy hh:mm:ss tt', 'en-us') 'en-us', FORMAT(@date, 'dddd, dd MMMM åååå hh:mm:ss tt', 'en-gb') 'en-gb', FORMAT(@date, 'dddd, dd MMMM åååå hh:mm:ss tt', 'th-th') 'th-th', FORMAT(@date, 'dddd, dd MMMM åååå hh:mm:ss tt', 'nl-nl') 'nl-nl', FORMAT (@date, 'dddd, dd MMMM åååå hh:mm:ss tt', 'ne-np') 'ne-np', FORMAT(@date, 'dddd, dd MMMM åååå hh:mm:ss tt', ' fa-ir') 'fa-ir';
Resultat (med vertikal utdata):
sv-us | Lördag 15 juni 2019 13: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 maj 2019 01:45:30 अपराह्नfa-ir | söndag, 25 maj 1398 01:45:30 ب.ظ
Den förmodligen mest uppenbara observationen är att resultatet är formaterat med språket för den angivna lokalen. Men om vi tittar noga kan vi se att den också ignorerar AM/PM-beteckningen (tt ) för nl-nl kultur, förmodligen för att den kulturen vanligtvis använder 24-timmarsklockan. Vi kan också se att även vår positionering kan ignoreras i vissa fall (t.ex. fa-ir ).
Men allt ignoreras inte och vi slutar med en kombination av våra explicita specifikationer och de som bestäms av lokalen.
Hitta/ändra ditt nuvarande språk
Som nämnts, om du inte tillhandahåller "kultur"-argumentet, kommer språket för din nuvarande session att användas för att bestämma platsen.
Det finns flera sätt att hitta språket för din nuvarande session.
Du kan också ändra platsen för din nuvarande anslutning.
Alternativt kan du bara använda SET LANGUAGE för att byta aktuellt språk efter behov.
Här är ett snabbt exempel med SET LANGUAGE för att visa att dina egna språkinställningar kan påverka formateringsresultaten på samma sätt som när du använder argumentet "kultur", som i de tidigare exemplen.
DECLARE @num decimal(3,2) =-1.23;SET LANGUAGE British;SELECT FORMAT(@num, 'C') Resultat;SET LANGUAGE US_English;SELECT FORMAT(@num, 'C') Resultat;Resultat:
+----------+| Resultat ||--------|| -£1,23 |+----------++----------+| Resultat ||--------|| ($1,23) |+----------+