代碼頁

代碼頁是字符集編碼的別名，也有人稱"內碼錶"。早期，代碼頁是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 <windows.h>

#include <stdio.h>

int main( void )

SetConsoleOutputCP(936);

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

return 0;

輸出：

簡體中文

如果將代碼頁設置為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"是否相同。另外還定義排序規則是否區分重音，例如"á"和"&auml;"是否相同。

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

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

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