Unicode 基本概念

更新： 2006 年 7 月 17 日

若某個資料庫中以多種語言儲存資料，則當您只使用字元資料和字碼頁時會使得管理更加困難。同時，也不容易針對可以儲存所有需要之語言特定字元的資料庫尋找某個字碼頁。此外，當執行各種字碼頁的不同用戶端讀取或更新特殊字元時，很難保證這些特殊字元能有正確的翻譯。支援國際用戶端的資料庫應該一律使用 Unicode 資料類型，而不使用非 Unicode 資料類型。

例如，考慮處理北美地區顧客的資料庫必須處理三種主要語言：

• 墨西哥的西班牙文姓名與地址
• 魁北克的法文姓名與地址
• 加拿大其他地區與美國的英文姓名與地址

只使用字元資料行與字碼頁時，必須小心確定安裝資料庫時，使用了可以處理這三種語言字元的字碼頁。您也必須小心確保由執行不同語言字碼頁的用戶端讀取資料時，會正確地翻譯其中一種語言的字元。

隨著網際網路的成長，要支援執行不同地區設定的許多用戶端電腦變得前所未有的重要。要對支援全球用戶需要的所有字元，選取字元資料類型的字碼頁則相當困難。

在國際性資料庫中管理字元資料，最容易的方式是使用 Unicode nchar、nvarchar 和 nvarchar(max) 資料類型，而不是相對的非 Unicode char、varchar 和 text。

Unicode 是將字碼指標對應到字元的標準用法。由於 Unicode 主要設計為涵蓋世界上所有語言的字元，因此不需要使用不同的字碼頁來處理不同的字元集。SQL Server 2005 支援 Unicode Standard 3.2 版。

如果處理國際性資料庫的所有應用程式也都使用 Unicode 變數，而不是非 Unicode 變數，系統的任何位置就都不必執行字元轉換。用戶端在資料中看到的字元，會和所有其他用戶端看到的一樣。

SQL Server 2005 將所有文字的系統目錄資料儲存在具有 Unicode 資料類型的資料行中。資料庫物件 (如資料表、檢視與預存程序) 的名稱都會儲存在 Unicode 資料行中。這樣就可以只使用 Unicode 開發應用程式，避免所有字碼頁轉換的問題。

請參閱

概念

使用 Unicode 資料
Unicode 的儲存和效能效果

說明及資訊

取得 SQL Server 2005 協助

變更歷程記錄