dbcs

DBCS,最初的128個代碼是ASCII,較高的128個代碼中的某些總是跟隨著第二個位元組。這兩個位元組一起(稱作首位元組和跟隨位元組)定義一個字元,通常是一個複雜的象形文字。

簡介

DBCS:double-byte character set
最初的128個代碼是ASCII,較高的128個代碼中的某些總是跟隨著第二個位元組。這兩個位元組一起(稱作首位元組和跟隨位元組)定義一個字元,通常是一個複雜的象形文字。
雖然中文、日文和韓文共用一些相同的象形文字,但顯然這三種語言是不同的,而且經常是同一個象形文字在三種不同的語言中代表三件不同的事。Windows支援四個不同的雙位元組字元集:內碼錶932(日文)、936(簡體中文)、949(韓語)和950(繁體漢字)。只有為這些國家(地區)生產的Windows版本才支持DBCS。明白Unicode和DBCS之間的區別很重要。Unicode使用(特別在C程式設計語言環境裡)寬字元集。Unicode中的每個字元都是16位元寬而不是8位元寬。在Unicode中,沒有單單使用8位元數值的意義存在。相比之下,在雙位元組字元集中我們仍然處理8位元數值。有些位元組自身定義字元,而某些位元組則顯示需要和另一個位元組共同定義一個字元。

產生的問題

當計算機傳到亞洲等國家時,ASCII編碼也還是不夠用了,像我們中國,常用的漢子估計也得3000+吧。所以老美在設計像我們國家的作業系統時就加入了DBCS編碼,取2個位元組代表一個字元,總計65535個字元,這樣對我們國家也就夠用了。
不過DBCS編碼有一個問題:漢字是兩個位元組,而英文仍舊是一個位元組。這樣問題就來,按正常情況,程式是如A我是程式設計師的編碼是途中的第二行和第三行,但如果程式出錯等原因,最後讀取的編碼就變成了第四行了,這樣就會產生亂碼了,這也是我們使用的系統動不動就有亂碼的真正原因了。因為每當涉及到DBCS字元串的處理時,總是要判斷當中的一個位元組到底表示的是一個字元還是半個字元,如果是半個字元,那是前一半還是後一半?由此可見DBCS並不是一種非常好的解決方案。

處理方法

處理DBCS字串非常雜亂,但是處理Unicode文字則像處理有秩序的文字。您也許會高興地知道前128個Unicode字元(16位元代碼從0x0000到0x007F)就是ASCII字元,而接下來的128個Unicode字元(代碼從0x0080到0x00FF)是ISO 8859-1對ASCII的擴展。Unicode中不同部分的字元都同樣基於現有的標準。這是為了便於轉換。希臘字母表使用從0x0370到0x03FF的代碼,斯拉夫語使用從0x0400到0x04FF的代碼,美國使用從0x0530到0x058F的代碼,希伯來語使用從0x0590到0x05FF的代碼。中國、日本和韓國的象形文字(總稱為CJK)占用了從0x3000到0x9FFF的代碼。

相關詞條

相關搜尋

熱門詞條

聯絡我們