| 上一篇 |
SQL Server 处理多语言问题（原创） |
下一篇 |
有个简体，繁体，英文的系统，在搜寻时候，繁体成功，简体大部分不成功。
一查他们的默认排序方式不同。
production db用的是 Chinese_Taiwan_Stroke_CI_AS 排序，所以繁体搜寻ok。
简体不行。
查资料，发现，如果用nvarchar，一定要配合用sql 写法，前面加 ‘N ’。
例如 ：INSERT INTO MY_EMPLOYEES VALUES (N’中文’,N’中文’)
如果不加，就会默认用排序那个语言来比较了。
一下是一些资料。
介紹 SQL Server 處理多國語系的能力
儲存 Unicode 資料
SQL Server 2000 處理多國語系時，根據 SQL-92 規範使用 N 代表 National 資料型態，每個字元兩個 Bytes，不受單一定序(Collation)影響可同時支援儲存多國語言，透過下列資料型別，提供定義資料表進行 Unicode 字元資料處理。
NCHAR 固定長度的字元資料，不能超過 4,000 字元
NVARCHAR 變動長度的字元資料，不能超過 4,000 字元
NTEXT 長度可高達 2^30 - 1 (1,073,741,823)
在 SQL Server 2000 中字串函數的處理，可以搭配函數 DATALENGTH 計算出字串位元組數目，LEN 函數計算出字元數。當在 SQL Server 中處理 Unicode 資料時候，特別注意要使用 N 表示 Unicode 的處理，例如新增資料到定義成 NCHAR/NVARCAHR/NTEXT 的欄位時，必須使用以下的寫法
INSERT INTO MY_EMPLOYEES VALUES (N’中文’,N’中文’)
儲存 Non-Unicode 資料
SQL Server 2000 處理一般 Non-Unicode 字元時，每個字元所佔空間與所支援的語系有關，由定序的字碼頁決定。每個字元所佔空間為 1-2 個位元組，例如亞洲語系每個字元使用 2 個位元組，一般英文語系每個字元使用 1 個位元組。一般儲存 Non-Unicode 的字串時可以使用以下的資料型態
CHAR 固定長度的字元資料，不能超過 8,000 字元
VARCHAR 變動長度的字元資料，不能超過 8,000 字元
TEXT 長度可高達 231 - 1 (2,147,483,647 )
一般當 Unicode 資料透過一般字串，插入其中一個非 Unicode 資料型別資料行時，SQL Server 會將資料利用 Windows API 中的 WideCharToMultiByte 與 MultiByteToWideChar 等函數轉換資料型別與資料行定序相關的字碼頁。當字碼頁無法表示字元時，就會以問號 (?) 代替，表示資料已經遺失。資料中若有非預期的字元或問號出現，表示您的資料在某個層次已經從 Unicode 轉換成 Non-Unicode，而在轉換的過程中造成了字元的遺失。再者一般字碼頁決定所支援的語系，例如當字碼頁為 950 表示支援中文的語系，而有些地區僅能選用字碼頁為 0 的 Unicode 字碼支援方式，例如北印度語等。其他相關的字碼頁如下表所示：
語言
字碼頁
簡體中文
936
繁體中文
950
日文
932
韓文
949
Unicode 與 Non-Unicode 儲存方式與效能的比較
Unicode 每個字元使用 2 bytes 進行儲存，所以有以下的特點：
?
非雙位元組字元集 (DBCS) 仍使用 2 bytes 編碼，需要多一點空間
?
ODBC (3.6 版或更早的版本) 和資料程式庫 API 無法識別 Unicode
?
亞洲語言使用Unicode固定 2 位元組編碼，比特定字碼頁指定進行處理有效率，主要原因是字碼頁指定下的資料儲存會有混合長度差異
Non-Unicode字元視 Code Page 決定字元所佔為 1~ 2 bytes
?
中文、日文等亞洲語言使用 Non-Unicode 時，使用雙位元組字元集 (DBCS) 來儲存字元
?
亞洲語言使用 Non-Unicode 和 Unicode 間執行儲存作業幾乎沒有差別
?
非亞洲語言進行 Non-Unicode 排序比 Unicode 快 30%
Chinese_Taiwan_Stroke_CI_AS
Chinese_Taiwan_Stroke_CI_AS
Chinese_Taiwan_Stroke_CI_AS
Chinese_Taiwan_Stroke_CI_AS
INSERT INTO MY_EMPLOYEES VALUES (N’中文’,N’中文’)