簡介
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的代碼。
