代碼頁

早期，代碼頁是IBM稱呼電腦BIOS本身支持的字符集編碼的名稱。當時通用的操作系統都是命令行界面系統，這些操作系統直接使用BIOS供應的VGA功能來顯示字元，操作系統的編碼支持也就依靠BIOS的編碼。現在這BIOS代碼頁被稱為 OEM代碼頁。圖形操作系統解決了此問題，圖形操作系統使用自己字元呈現引擎可以支持很多不同的字符集編碼。

早期IBM和微軟內部使用特別數字來標記這些編碼，其實大多的這些編碼已經有自己的名稱了。雖然圖形操作系統可以支持很多編碼，很多微軟程序還使用這些數字來點名某編碼。

對於字元和Unicode數據的位模式的定義，此模式代表特定字母、數字或符號（例如 0x20 代表一個空格，而 0x74 代表字元“t”）。一些數據類型每個字元使用一個位元組；每個位元組可以具有 256 個不同的位模式中的一個模式。

在計算機中，字元由不同的位模式（ON 或 OFF）表示。每個位元組有 8 位，這 8 位可以有 256 種不同的 ON 和 OFF 組合模式。對於使用 1 個位元組存儲每個字元的程序，通過給每個位模式指派字元可表示最多 256 個不同的字元。2 個位元組有 16 位，這 16 位可以有 65,536 種唯一的 ON 和 OFF 組合模式。使用 2 個位元組表示每個字元的程序可表示最多 65,536 個字元。

單位元組代碼頁是字元定義，這些字元映射到每個位元組可能有的 256 種位模式中的每一種。代碼頁定義大小寫字元、數字、符號以及 !、@、#、% 等特殊字元的位模式。每種歐洲語言（如德語和西班牙語）都有各自的單位元組代碼頁。雖然用於表示 A 到 Z 拉丁字母表字元的位模式在所有的代碼頁中都相同，但用於表示重音字元（如"é"和"á"）的位模式在不同的代碼頁中卻不同。如果在運行不同代碼頁的計算機間交換數據，必須將所有字元數據由發送計算機的代碼頁轉換為接收計算機的代碼頁。如果源數據中的擴展字元在接收計算機的代碼頁中未定義，那麼數據將丟失。如果某個資料庫為來自許多不同國家的客戶端提供服務，則很難為該資料庫選擇這樣一種代碼頁，使其包括所有客戶端計算機所需的全部擴展字元。而且，在代碼頁間不停地轉換需要花費大量的處理時間。

僅靠單位元組字符集存儲許多語言所使用的字元也是不夠的。例如，一些亞洲語言包含上千個字元，所以每個字元必須使用雙位元組。雙位元組字符集正是為這些語言定義的。但是，這些語言都有各自的代碼頁，在運行不同雙位元組代碼頁的計算機之間傳輸數據也存在困難。

1258 越南語

1257 波羅的語

1256 阿拉伯語

1255 希伯來語

1254 土耳其語

1253 希臘語

1252 拉丁 1 字元 (ANSI)

1251 西里爾語

1250 中歐語言

950 繁體中文

949 朝鮮語

936 簡體中文

932 日語

874 泰國語

850 多語種 (MS-DOS Latin1)

437 MS-DOS 美國英語

為解決在網路中支持多種代碼頁時出現的字元轉換和解釋問題，ISO 標準化組織和稱為 Unicode Consortium 的團體定義了 Unicode 標準。Unicode 使用四個位元組存儲每個字元。由於 4,294,967,296 個字元足以涵蓋世界上所有語言常用的字元，因此 Unicode 標準適用於所有的主要語言。如果網路中的所有計算機和程序都使用 Unicode，則無需進行任何字元轉換，每個用戶與所有其它用戶看到的字元完全相同，並且不會丟失任何字元。

在運行 Microsoft Windows 操作系統的計算機上，操作系統和 Windows 應用程序使用的代碼頁由 Windows 區域設置定義。區域設置是在安裝操作系統時選擇的。Windows 應用程序使用由 Windows 區域設置定義的代碼頁來解釋數據。Windows 應用程序還支持寬字元數據，即 Unicode 數據。

支持兩類字元數據類型：

Unicode 數據類型

nchar、nvarchar 和 ntext。這些數據類型使用 Unicode 字元表示法。代碼頁不適用於這些數據類型。

非 Unicode 字元數據類型

char、varchar 和 text。這些數據類型使用單位元組或雙位元組代碼頁中定義的字元表示法。

有關字元數據的存儲方式以及代碼頁、Unicode 和排序次序操作的更多信息，請參見在 MSDN 頁中的 Developing International Software for Windows 95 and Windows NT 4.0。

國際化數據和 Unicode

當只使用字元數據和代碼頁時，在一個資料庫內很難以多種語言存儲數據。很難為資料庫找到一種代碼頁，能夠存儲所需全部語言特有的字元。對於運行各種代碼頁的不同客戶端所讀取和更新的特殊字元，要確保正確地轉換也很困難。支持國際化客戶端的資料庫應始終使用 Unicode 數據，而不應使用非 Unicode 數據類型。

例如，北美洲客戶的資料庫必須處理三種主要語言：

墨西哥使用的西班牙文名稱和地址。

魁北克使用的法文名稱和地址。

加拿大的其餘地區和美國使用的英文名稱和地址。

當只使用字元列和代碼頁時須小心，以確保資料庫所安裝的代碼頁能夠處理這三種語言的字元。當其中一種語言的字元由運行另一種語言的代碼頁的客戶端讀取時，必須更加小心以確保能夠正確轉換字元。

在DOS下可以通過mode命令來設置代碼頁。

選定代碼頁: MODE CON[:] CP SELECT=yyy

代碼頁狀態: MODE CON[:] CP [/STATUS]

按Windows+R組合鍵，然後輸入cmd或者command打開命令提示符。

比如輸入：mode con cp select=936，則表示顯示簡體中文。如果輸入mode con cp select=437，則表示顯示MS-DOS 美國英語，而中文顯示將會是?。

方法一：

通過system函數調用dos命令，該函數的頭文件是stdlib.h。

例：system("mode con cp select=936");

方法二：

通過API函數SetConsoleOutputCP來實現

程序例：

#include

#include

int main( void )

{

SetConsoleOutputCP(936);

printf("簡體中文\n");

return 0;

}

輸出：

簡簡體體中中文文

Press any key to continue

如果將代碼頁設置為437，那麼無法正常輸出簡體中文：

╝≥╠σ╓╨╬─

Press any key to continue

隨著 Internet 的發展，支持眾多運行不同區域設置的客戶端計算機變得日益重要。很難選擇這樣一種代碼頁，使其包含的字元數據類型能夠支持全球範圍用戶所需的全部字元。

管理國際化資料庫中的字元數據的最簡單方法是始終使用 Unicode nchar、nvarchar 和 ntext 數據類型，代替對應的非 Unicode 數據類型（char、varchar 和 text）。如果所有使用國際化資料庫的應用程序也採用 Unicode 變數而不是非 Unicode 變數，那麼在系統中的任何地方都無須進行字元轉換。每個客戶端與所有其它客戶端看見的字元數據都完全相同。

對於可使用單位元組代碼頁的系統，Unicode 數據需要的存儲空間是非 Unicode 字元數據的兩倍，但卻消除了在代碼頁間轉換擴展字元的必要，因此至少部分彌補了上面的不足。使用雙位元組代碼頁的系統沒有這個問題。

SQL Server 2000 將所有的文本化系統目錄數據都存儲在包含 Unicode 數據類型的列中。資料庫對象（如表、視圖和存儲過程）的名稱存儲在 Unicode 列中。這樣就可以只使用 Unicode 開發應用程序，從而避免了所有的代碼頁轉換問題。

排序次序

排序次序指定 SQL Server 解釋、排序、比較和顯示字元數據所使用的規則。例如，排序次序定義"a"是小於、等於還是大於"b"。排序次序定義排序規則是否區分大小寫，例如"m"和"M"是否相同。另外還定義排序規則是否區分重音，例如"á"和"ä"是否相同。

SQL Server 2000 對每種排序規則使用兩種排序次序，一種用於 Unicode 數據，另一種用於字元代碼頁。

許多 SQL Server 排序規則使用相同的代碼頁，但是代碼頁的排序次序不同。這使站點得以選擇：

是否僅根據位模式所表示的數字值來排序字元。二進位排序的速度最快，這是因為 SQL Server 不用做任何調整並可使用快速、簡單的排序演演算法。二進位排序次序始終區分大小寫。由於代碼頁中的位模式可能不按照特定語言的字典規則所定義的序列排列，二進位排序有時並不按照使用該語言的用戶所期待的序列對字元進行排序。