2006年6月的最新版本的 Unicode 是 2005年3月31日推出的Unicode 4.1.0 。另外，5.0 Beta已於2005年12月12日推出，以供各會員評價。
Unicode 的編碼和實現
大概來說，Unicode 編碼系統可分為編碼方式和實現方式兩個層次。
1.編碼方式
Unicode 的編碼方式與 ISO 10646 的通用字元集(亦稱[通用字符集])（Universal Character Set，UCS）概念相對應，目前的用於實用的 Unicode 版本對應於 UCS-2，使用16位的編碼空間。也就是每個字符占用2個字節。這樣理論上壹***最多可以表示 216 個字符。基本滿足各種語言的使用。實際上目前版本的 Unicode 尚未填充滿這16位編碼，保留了大量空間作為特殊使用或將來擴展。
上述16位 Unicode 字符構成基本多文種平面（Basic Multilingual Plane, 簡稱 BMP）。最新（但未實際廣泛使用）的 Unicode 版本定義了16個輔助平面，兩者合起來至少需要占據21位的編碼空間，比3字節略少。但事實上輔助平面字符仍然占用4字節編碼空間，與 UCS-4 保持壹致。未來版本會擴充到 ISO 10646-1 實現級別3，即涵蓋 UCS-4 的所有字符。UCS-4 是壹個更大的尚未填充完全的31位字符集，加上恒為0的首位，***需占據32位，即4字節。理論上最多能表示 231 個字符，完全可以涵蓋壹切語言所用的符號。
BMP 字符的 Unicode 編碼表示為 U+hhhh，其中每個 h 代表壹個十六進制數位。與 UCS-2 編碼完全相同。對應的4字節 UCS-4 編碼後兩個字節壹致，前兩個字節的所有位均為0。
2.實現方式
Unicode 的實現方式不同於編碼方式。壹個字符的 Unicode 編碼是確定的。但是在實際傳輸過程中，由於不同系統平臺的設計不壹定壹致，以及出於節省空間的目的，對 Unicode 編碼的實現方式有所不同。Unicode 的實現方式稱為Unicode轉換格式（Unicode Translation Format，簡稱為 UTF）。
例如，如果壹個僅包含基本7位ASCII字符的 Unicode 文件，如果每個字符都使用2字節的原 Unicode 編碼傳輸，其第壹字節的8位始終為0。這就造成了比較大的浪費。對於這種情況，可以使用 UTF-8 編碼，這是壹種變長編碼，它將基本7位ASCII字符仍用7位編碼表示，占用壹個字節（首位補0）。而遇到與其他 Unicode 字符混合的情況，將按壹定算法轉換，每個字符使用1-3個字節編碼，並利用首位為0或1進行識別。這樣對以7位ASCII字符為主的西文文檔就大大節省了編碼長度（具體方案參見UTF-8）。類似的，對未來會出現的需要4個字節的輔助平面字符和其他 UCS-4 擴充字符，2字節編碼的 UTF-16 也需要通過壹定的算法進行轉換。
再如，如果直接使用與 Unicode 編碼壹致（僅限於 BMP 字符）的 UTF-16 編碼，由於每個址 加昧肆礁鱟紙冢贛acintosh機和PC機上對字節順序的理解是不壹致的。這時同壹字節流可能會被解釋為不同內容，如編碼為 U+594E 的字符“奎”同編碼為 U+4E59 的“乙”就可能發生混淆。於是在 UTF-16 編碼實現方式中使用了大尾序（big-endian）、小尾序（little-endian）的概念，以及BOM（Byte Order Mark）解決方案。（具體方案參見UTF-16）
此外 Unicode 的實現方式還包括 UTF-7、Punycode、CESU-8、SCSU、UTF-32等，這些實現方式有些僅在壹定的國家和地區使用，有些則屬於未來的規劃方式。目前通用的實現方式是 UTF-16小尾序（BOM）、UTF-16大尾序（BOM）和 UTF-8。在微軟公司Windows XP操作系統附帶的記事本中，“另存為”對話框可以選擇的四種編碼方式除去非 Unicode 編碼的 ANSI 外，其余三種“Unicode”、“Unicode big endian”和“UTF-8”即分別對應這三種實現方式。
目前輔助平面的工作主要集中在第二和第三平面的中日韓統壹表意文字中，因此包括GBK、GB18030、Big5等簡體中文、正體中文、日文、韓語以及越南字喃的各種編碼與 Unicode 的協調性被重點關註。考慮到 Unicode 最終要涵蓋所有的字符，從某種意義而言，這些編碼方式也可視作 Unicode 的出現於其之前的既成事實的實現方式，如同ASCII及其擴展Latin-1壹樣，後兩者的字符在16位 Unicode 編碼空間中的編碼第壹字節各位全為0，第二字節編碼與原編碼完全壹致。但上述東亞語言編碼與 Unicode 編碼的對應關系要復雜得多。
非 Unicode 環境
在非 Unicode 環境下，由於不同國家和地區采用的字符集不壹致，很可能出現無法正常顯示所有字符的情況。微軟公司使用了代碼頁（Codepage）轉換表的技術來過渡性的部分解決這壹問題，即通過指定的轉換表將非 Unicode 的字符編碼轉換為同壹字符對應的系統內部使用的 Unicode 編碼。可以在“語言與區域設置”中選擇壹個代碼頁作為非 Unicode 編碼所采用的默認編碼方式，如936為簡體中文GBK，950為正體中文Big5（皆指PC上使用的）。在這種情況下，壹些非英語的歐洲語言編寫的軟件和文檔很可能出現亂碼。而將代碼頁設置為相應語言中文處理又會出現問題，這壹情況無法避免。從根本上說，完全采用統壹編碼才是解決之道，但目前上無法做到這壹點。
代碼頁技術現在廣泛為各種平臺所采用。UTF-7 的代碼頁是65000，UTF-8 的代碼頁是65001。
XML 和 Unicode
XML及其子集HTML采用UTF-8作為標準字集，理論上我們可以在各種支持XML標準的瀏覽器上顯示任何地區文字的網頁，只要電腦本身安裝有合適的字體即可。可以利用nnn;的格式顯示特定的字符。nnn代表該字符的十進制 Unicode 代碼。如果采用十六進制代碼，在編碼之前加上x字符即可。但部分舊版本的瀏覽器可能無法識別十六進制代碼。
然而部分由於 Unicode 版本發展原因，很多瀏覽器只能顯示 UCS-2 完整字符集也即現在使用的 Unicode 版本中的壹個小子集。下表可以檢驗您的瀏覽器怎樣顯示各種各樣的 Unicode 代碼：
代碼 字符標準名稱 (英語) 在瀏覽器上的顯示
A 大寫拉丁字母"A" A
小寫拉丁字母"Sharp S" ? 小寫拉丁字母"Thorn" ?Δ 大寫希臘字母"Delta" Δ
Й 大寫斯拉夫字母"Short I" Й
希伯來字母"Qof" ? 阿拉伯字母 "Meem" ? 泰文數字 7 ? 埃塞俄比亞音節文字"Qha" ?あ 日語平假名 "A" あ
ア 日語片假名 "A" ア
葉 簡體漢字 "葉" 葉
葉 繁體漢字 "葉" 葉
韓國音節文字 " Yeob" ?輸入Unicode
除了輸入法外，操作系統會提供幾種方法輸入Unicode。像是Windows 2000之後的Windows系統就提供壹個可點擊的表。例如在Microsoft Word之下，按下 Alt 鍵不放，輸入 0 和某個字符的 Unicode 編碼（十進制），再松開 Alt 鍵即可得到該字符，如Alt + 033865會得到Unicode字符葉。另外按Alt + X 組合鍵，MS Word 也會將光標前面的字符同其十六進制的四位 Unicode 編碼進行互相轉換。
Unicode 編碼表
0000-0FFF 8000-8FFF 10000-10FFF 20000-20FFF 28000-28FFF
1000-1FFF 9000-9FFF 21000-21FFF 29000-29FFF
2000-2FFF A000-AFFF 22000-22FFF 2A000-2AFFF
3000-3FFF B000-BFFF 23000-23FFF
4000-4FFF C000-CFFF 1D000-1DFFF 24000-24FFF 2F000-2FFFF
5000-5FFF D000-DFFF 25000-25FFF
6000-6FFF E000-EFFF 26000-26FFF
7000-7FFF F000-FFFF 27000-27FFF E0000-E0FFF
Unicode 目前已經有5.0版本。世界上有壹大批計算機、語言學等科學家專門研究Unicode，到了現在Unicode標準已經不單是壹個編碼標準，還是記錄人類語言文字資料的壹個巨大的數據庫，同時從事人類文化遺產的發掘和保護工作。
對於中文而言，Unicode 16編碼裏面已經包含了GB18030裏面的所有漢字（27484個字），目前Unicode標準準備把康熙字典的所有漢字放入到Unicode 32bit編碼中。
簡單地說，Unicode擴展自ASCII字元集。在嚴格的ASCII中，每個字元用7位元表示，或者電腦上普遍使用的每字元有8位元寬；而 Unicode使用全16位元字元集。這使得Unicode能夠表示世界上所有的書寫語言中可能用於電腦通訊的字元、象形文字和其他符號。Unicode 最初打算作為ASCII的補充，可能的話，最終將代替它。考慮到ASCII是電腦中最具支配地位的標準，所以這的確是壹個很高的目標。
Unicode影響到了電腦工業的每個部分，但也許會對作業系統和程式設計語言的影響最大。從這方面來看，我們已經上路了。Windows NT從底層支援Unicode（不幸的是，Windows 98只是小部分支援Unicode）。先天即被ANSI束縛的C程式設計語言通過對寬字元集的支援來支援Unicode。
自然，作為程式寫作者，我們通常會面對許多繁重的工作。我已試圖透過使本書中的所有程式「Unicode化」來減輕負擔。其含義會隨著本章對Unicode的討論而清晰起來。