VÆLG COLLATIONPROPERTY('Chinese_PRC_Stroke_CI_AI_KS_WS', 'CodePage')
Her er forespørgselsresultaterne:
936 kinesisk forenklet GBK
950 Kinesisk Traditionel BIG5
437 US/canadisk engelsk
932 japanere
949 Koreansk
866 Russisk
65001 unicode UFT-8
Da vi installerede SQL SERVER 2008, fordi vi valgte standardinstallationen, oprettede vi denNår det er database, er den standard sorteringsregel, som serveren vælger, en SQL_Latin1_General_CP1_CI_AS sorteringsregel, så når tekst indsættes i datatabellen, vises den ikke normalt, alt sammen med "? I stedet.
Når vi så opretter en database, skal vi manuelt specificere en kollationsregel, som kan vælges som Chinese_PRC_CI_AS kollation, som vist i figuren nedenfor
Sorteringsregler:
De sorteringsregler, der bruges i SQLSEVER2005, er SQL_Latin1_General_CP1_CI_AS, ikke de tre sorteringsregler, der kan vise forenklede kinesiske tegn korrekt:
Chinese_PRC_BIN,
Chinese_PRC_CI_AS,
Chinese_PRC_CS_AS。
Tag et kig på MS's forklaring af kollation: Collation Rules Control Physical Storage of Strings in SQL Server 2005. Kollationsregler specificerer bitmønsteret, der repræsenterer hvert tegn, samt reglerne for lagring og sammenligning af tegnbrug.
Det vil sige, i SQLSERVER er sammensætningen faktisk tegnkodningen.
Ved at køre følgende sætning i forespørgselsanalysatoren kan du få alle de samlingsregler, der understøttes af SQL SERVER.
Vælg * fra ::fn_helpcollations()
Kollationsnavnet består af to dele, hvor den første del refererer til det tegnsæt, som denne kollation understøtter.
For eksempel: Chinese_PRC_CS_AI_WS
Den første halvdel refererer til UNICODE-tegnsættet og Chinese_PRC_refers til sorteringsreglerne for det forenklede kinesiske tegn UNICODE.
Den anden halvdel af kollationen er betydningen af suffikset:
_BIN Binær sortering
_CI(CS) Uanset om det er kasusfølsomt, er CI ikke følsomt, og CS er følsomt
_AI (AS) Om man skal skelne mellem accenter, skelner AI ikke, AS skelner mellem accenter
_KI(KS) Om man skal skelne mellem pseudonymtyper, gør KI ikke, KS skelner
_WI(WS) er ikke bredde-differentieret, WS er ikke differentieret
Følsomt for store bogstaver: Vælg denne mulighed, hvis du vil have sammenligninger for at behandle store og små bogstaver som ulige.
Skeln mellem accenter: Vælg denne mulighed, hvis du vil have sammenligninger for at behandle accentuerede og utrykte bogstaver som ulige. Hvis du vælger den mulighed, behandler sammenligningen også bogstaver med forskellige accenter som ulige.
Skeln Kana: Vælg denne mulighed, hvis du vil have sammenligningen til at behandle Katakana- og Hiraka-dagstavelser som ulige.
Breddedifferentiering: Vælg denne mulighed, hvis du vil have sammenligningen til at behandle halv- og fuldbredde-tegn som ulige.
Efter at have forstået samlingsreglerne i SQLSERVER kan følgende konklusioner drages for ovenstående problem:
1. Modificere SQLSERVER-brugerdatabasen til at understøtte sammenstilling af kinesiske tegnsæt.
2: For visning af kinesiske tegn??, men man ikke ønsker at ændre sorteringsreglerne i databasen og ønsker at vise kinesiske tegn korrekt, anbefales det at bruge alle Unicode-typer i designet, altså de felttyper, der starter med N, såsom nChar, nVarchar, for at vise kinesiske tegn korrekt.
3: Hvis du ikke vil ændre kollationsreglen eller felttypen, skal du ændre SQL-udsagnet, og for alle kinesiske tegn skal du også tilføje N foran for at vise det korrekt. Se venligst følgende to udsagn for specifikke metoder:
Forespørgsel: vælg * fra tb_Cust hvor FirstName=N'Wang'
Indsæt: indsæt tb_Cust(Fornavn, Efternavn, Køn) værdier(N'Wang', N'Xinhao', N'Mand')
Bemærk: For fremtiden vil det være mere besværligt at ændre serverniveau-kollationsreglen efter SQLSERVER2000, og det er nødvendigt at genopbygge masterdatabasen.
I øjeblikket kan vi for databaser, der allerede er oprettet, også ændre sorteringsmetoden på optionssiden i databasens egenskabsvindue, så der ikke vil komme fejlmeddelelser, når tekst indsættes i datatabellen!
|
Opslået på 27/10/2016 12.50.16
|
|
|
|
