ИЗБЕРЕТЕ COLLATIONPROPERTY('Chinese_PRC_Stroke_CI_AI_KS_WS', 'CodePage')
Ето резултатите от заявката:
936 Китайски опростен GBK
950 Китайски традиционен BIG5
437 американски и канадски английски
932 японски
949 корейски
866 руски
65001 Unicode UFT-8
Когато инсталирахме SQL SERVER 2008, тъй като избрахме стандартната инсталация, я създадохмеКогато е в база данни, стандартното правило за сортиране, избрано от сървъра, е правило за SQL_Latin1_General_CP1_CI_AS събиране, така че при вмъкване на текст в таблицата с данни той няма да се показва нормално, всичко с "? вместо това.
След това, когато създаваме база данни, трябва ръчно да зададем правило за събиране, което може да бъде избрано като Chinese_PRC_CI_AS колиране, както е показано на фигурата по-долу
Правила за сортиране:
Правилата за сортиране, използвани в SQLSEVER2005, са SQL_Latin1_General_CP1_CI_AS, а не трите правила за сортиране, които могат правилно да показват опростените китайски знаци:
Chinese_PRC_BIN,
Chinese_PRC_CI_AS,
Chinese_PRC_CS_AS。
Вижте обяснението на MS за колирането: Контрол на правилата за колиране физическо съхранение на низове в SQL Server 2005. Правилата за сравняване определят битовия модел, който представя всеки знак, както и правилата за съхранение и сравнение на използването на символи.
Тоест, в SQLSERVER колацията всъщност е кодирането на символи.
Като изпълните следното изявление в анализатора на заявки, можете да получите всички правила за събиране, поддържани от SQL SERVER.
изберете * от ::fn_helpcollations()
Името на колекцията се състои от две части, първата част се отнася до набора от знаци, поддържан от тази колация.
Например: Chinese_PRC_CS_AI_WS
Първата половина се отнася до набора от символи UNICODE, а Chinese_PRC_refers към правилата за сортиране на опростения китайски знак UNICODE.
Втората половина на колекцията е значението на наставката:
_BIN Бинарно сортиране
_CI(CS) Независимо дали е чувствителна към капетър, CI не е чувствителна, а CS е чувствителна
_AI (AS) Дали да се различават акценти, AI не прави разлика, AS прави разлика
_KI(KS) Дали да се различават типове псевдоними, KI не го прави, KS прави разлика
_WI(WS) не се различава по ширина, WS не е диференцирана
Чувствителна към регистр: Изберете тази опция, ако искате сравнения да третират главните и малките букви като неравни.
Разграничавайте акцентите: Изберете тази опция, ако искате сравнения, които да третират акцентираните и неударените букви като неравни. Ако изберете тази опция, сравнението третира и буквите с различни акценти като неравни.
Разграничавайте Кана: Изберете тази опция, ако искате сравнението да третира сричките на Катакана и Деня на Хирака като неравни.
Диференциация на ширината: Изберете тази опция, ако искате сравнението да третира символите с половинна ширина и пълна ширина като неравни.
След разбиране на правилата за колиране в SQLSERVER, могат да се направят следните изводи за горния проблем:
1. Модифициране на потребителската база данни на SQLSERVER, за да поддържа събиране на китайски знаци.
2: За показване на китайски йероглифи??, но не искате да променяте правилата за сортиране в базата данни и искате да показвате китайските йероглифи правилно, препоръчва се да се използват всички Unicode типове полета в дизайна, тоест тези типове, започващи с N, като nChar, nVarchar, за да се показват правилно китайските знаци.
3: Ако не искате да променяте правилото за колиране или типа на полето, трябва да промените SQL оператора, а за всички китайски знаци трябва да добавите и N отпред, за да го покажете правилно. Моля, вижте следните две твърдения за конкретни методи:
Заявка: изберете * от tb_Cust, където FirstName=N'Wang'
Вмъкнете: вмъкнете стойности tb_Cust(Име, Фамилия, Пол) (N'Wang', N'Xinhao', N'Male')
Забележка: В бъдеще ще бъде по-трудно да се модифицира правилото за събиране на сървърно ниво след SQLSERVER2000 и е необходимо да се възстанови главната база данни.
В момента, за вече създадени бази данни, можем също да променим метода на събиране в страницата с опции в прозореца за свойства на базата данни, така че при вмъкване на текст в таблицата с данни да няма съобщения за грешка!
|
Публикувано в 27.10.2016 г. 12:50:16 ч.
|
|
|
|
