概況
代碼頁是
字元集編碼的別名,也有人稱"內碼錶"。早期,代碼頁是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 拉丁字母表字元的位模式在所有的代碼頁中都相同,但用於表示重音字元(如"é"和"á")的位模式在不同的代碼頁中卻不同。如果在運行不同代碼頁的計算機間交換數據,必須將所有字元數據由傳送計算機的代碼頁轉換為接收計算機的代碼頁。如果源數據中的擴展字元在接收計算機的代碼頁中未定義,那么數據將丟失。如果某個資料庫為來自許多不同國家的客戶端提供服務,則很難為該資料庫選擇這樣一種代碼頁,使其包括所有客戶端計算機所需的全部擴展
字元。而且,在代碼頁間不停地轉換需要花費大量的處理時間。
雙位元組
僅靠單
位元組字元集存儲許多語言所使用的字元也是不夠的。例如,一些亞洲語言包含上千個
字元,所以每個字元必須使用雙位元組。雙位元組字元集正是為這些語言定義的。但是,這些語言都有各自的代碼頁,在運行不同雙位元組代碼頁的計算機之間傳輸數據也存在困難。
描述
1257 波羅的語
1256 阿拉伯語
1255 希伯來語
1253 希臘語
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 數據。
SQL相關
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命令
在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 美國英語,而中文顯示將會是?。
通過C語言函式
方法一:
例:system("mode con cp select=936");
方法二:
程式例:
#include <windows.h>
#include <stdio.h>
int main( void )
{
SetConsoleOutputCP(936);
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 不用做任何調整並可使用快速、簡單的
排序算法。二進制排序次序始終區分大小寫。由於代碼頁中的位模式可能不按照特定語言的字典規則所定義的序列排列,二進制排序有時並不按照使用該語言的用戶所期待的序列對
字元進行排序。