Unicode又稱UCS(UnicodeCharacter Set)，是一種字符編碼方法，由一個字節表示(0x00-0xff),其即對應ASCII碼，如\u0041對應英文字符’A’,
Unicode爲全世界通用編碼，爲了能夠表示出兩個字節的中文字符，採用了兩個字節編碼，稱爲UCS-2，而UCS還有采用四個字節編碼的UCS-4。
UCS-2與GB2312編碼類似，使用兩組16進制的編碼合成一個字符，如漢字”啊”的UCS-2碼(一般直接稱爲Unicode)爲 \u554A，以此類推，其他中文字符在Unicode中的編碼亦用此種形式保存。UCS-4 爲32位二進制表示，而實際上最高位必須爲0，因此UCS-4可以表示2^31 個字符。UCS-4 的四個字節中根據最高字節分成2^7個group，每個group根據次高字節分爲2^8個plane，每個panel根據次低字節分爲2^8個rows，每個rows包含2^8個cells。而group和plane均爲0的碼稱爲BMP(Basic Multilingual Plane)，即是UCS-4中高兩個字節爲0的編碼爲BMP。目前UCS-4還未有分配在BMP範圍之外的字符。
中文字符常用的編碼爲GB2312，是ASCII碼的擴展。每個國家均從ASCII碼進行了擴展，擁有自己獨立的編碼。GB2312共收容中文字符7445個，其中漢字字符其高位字節爲B0-F7，低位字節爲A1-FE，D7FA-D7FE範圍爲空字符，如漢字字符”啊”的GB編碼爲B0A1，共6768個。後擴展漢字編碼爲GBK，共收容中文字符21886個，再後來又擴展爲GB18030，收容中文字符27484個。GB2312和GBk編碼均用兩個字符構成，ASCII碼由一個字符構成，而GB18030包括單字節、雙字節和四字節方式，四字節收錄包括CJK(China、Japan、Korea)等的編碼。
從ASCII—>GB2312—>GBK—>GB18030，其編碼依次擴展並且向下兼容。所謂向下兼容，就是前一種編碼字符的編碼值在後面的編碼相同，使用不同種編碼對應字符的編碼值一樣，就是後面的編碼範圍比前一種大。GB2312和GBK使用兩個字符，實現與單個字符的ASCII碼兼容，就是在前面補上個0值字節，以使編碼值相等。
GB還有一種碼爲GB13000.1，是ISO/IEC 10646-1的中文版。GB13000.1其實是GB2312的另一擴展，採用四字節編碼，其擴充了六個輔助集，收容的GB2312編碼稱爲基本集。其中第二、第四輔助集是簡體漢字集，第一、第三、第五輔助集是繁體漢字集，第一輔助集又稱GB12345，與GB2312 中的漢字一一對應，而第二與第三、第四與第五也是簡繁體的對應。另外沒有第六輔助集，而是有第七輔助集，收容的是在CJK統一使用的漢字部分，
中文字符也曾使用區位碼，由兩組十進制數字組成，高位組稱爲區，低位組稱爲位，區在1-9是中文字符(標點符號等)，16-55爲一級漢字區(漢字按拼音排序)，56-87爲二級漢字區(漢字按部首/筆畫排序)，由此組成的一個四位十進制的編碼即爲區位碼。區位碼與GB2312可以互相轉換，由區位碼轉爲GB2312方式爲轉化爲16進制的區位碼的區和位分別加上A0，由此得到的編碼即是GB2312碼，如中文字符”啊”的區位碼爲1601，轉化爲16進製爲1001,10和01分別加上A0爲B0A1，即是字符”啊”在GB2312上的編碼。區位最高爲94，10-15、88-94區未定義字符。
實際上，以上的編碼方式只是用於存放字符，並不能用於各個地方的傳輸。傳輸使用的是另外一種編碼——UTF(UCS Transformation Format)。UTF有UTF-8、UTF-16、UTF-32三種編碼，8、16、32的區分實際上就是對於UTF以多少位爲單元進行編碼，UTF-8是以8位二進制即一個字節爲單元，UTF-16以兩個字節爲單元，UTF-32以四個字節爲單元，通過編碼進行傳輸。
UTF-8的傳輸規則實際上是這樣的：
對於單字節的字符，字節碼第一位爲0，後7位爲該字符的Unicode碼，因此對於非擴展的ASCII碼，其編碼與UTF-8相同。
對於n個字節(n>1)的字符，字節碼的第一個字節前n位爲1，n+1位爲0，後面字節前兩位爲10，其餘位爲該字符的Unicode碼。
UCS-2與UTF-8的具體傳輸規則如下(左UCS-2 右UTF-8)：
0000– 007F—> 0xxx xxxx 1字節
0080– 07FF—>110x xxxx 10xx xxxx 2字節
0800– FFFF—>1110 xxxx 10xx xxxx 10xx xxxx 3字節
依據以上規則就可以進行Unicode與UTF-8的轉換。比如中文字符”啊”的Unicode碼爲\u554A，將其轉換爲二進制爲0101 0101 0100 1010，根據其Unicode碼所在區爲0800 – FFFF,將二進制碼依次從右往左代入x 得到 1110 0101 1001 0101 1000 1010 換爲16進制碼則爲E5 95 8A，此3字節碼即爲中文字符”啊”的UTF-8碼。
中文字符爲2字節，而在進行中文輸入法時有些字符如空格” ”依然只佔一個字節，或者需切換輸入法來代替，因此在進行某些中文字符串操作時對該字符應該採用兩個相同的1字節字符代替。如數據庫進行查詢操作時的查詢某個表中第二個字爲”啊”的內容:
SELECT value FROM tabel WHERE LIKE ‘__啊%’;
此中用了兩個單字節的'_'來表示一箇中文字符即是如此。
還有個小知識，編碼的存儲方式有兩種，分別爲Big Endian和Little Endian。此兩種存儲方式的區別在於，對於雙字節的編碼，其兩組16進制碼是誰前誰後問題，按照編碼方式正序存儲，則爲Big Endian，反序存儲則爲Little Endian。例如中文字符”啊”，其Unicode碼爲554A，如果採用Big Endian存儲則55在前，4A在後，如果採用Little Endian存儲，則4A在前，55在後。因此在計算機中，對於讀取文檔又有問題了，計算機並不知道文檔是採用哪種存儲方式，因此在一般的文件如文本文檔中，開頭加入了個”ZERO WIDTH NO-BREAK SPACE”的Unicode字符,其編碼爲FEFF，命名爲”零寬度非換行空格”。而實際上Unicode在FFFE上並沒有字符，因此計算機則可以根據這個對文檔進行編碼方式識別，如果讀取到FEFF，則爲Big Endian，讀到FFFE則爲Little Endian。
三種編碼GB、Unicode和UTF，Unicode與UTF的轉換已經知道，GB要轉換爲UTF，實際上是經過先轉換爲Unicode再轉爲UTF。GB轉爲Unicode，沒有什麼規律，是按GB與Unicode的映射表來轉換，計算機對其的轉換也是通過其映射來轉換，由此將GB轉化爲UTF碼。
Windows系統內核支持Unicode字符集，從而支持全世界的所有語言文字，而Windows內碼爲code page(代碼頁)，通過使用代碼頁來適應各個國家和地區。代碼頁只支持單字節和雙字節編碼。代碼頁包括了各個國家地區的語言，由此適應該地區的編碼。如中文(簡體，中國)對應的編碼爲GB編碼，在文本文檔的另存爲中有個編碼格式爲ANSI，其即指定編碼存儲格式爲缺省(Default)編碼，根據計算機系統的控制面板下的區域和語言選擇格式而定。
有時候當你打開一個文本文檔，你會發現裏面內容全是亂碼，其原理即是：寫文檔的時候使用了缺省編碼ANSI，根據地區環境編碼，而當你打開時文本讀取ANSI缺省爲你的區域，兩個不同區域編碼的不兼容，造成讀出來的內容全是亂碼。由此建議寫文檔時或者編程人員在編程時應在各種高級語言IDE編程環境下設爲國際通用的UTF-8或Unicode碼，由此進行文件/代碼遷移時就不會發生亂碼現象了。
到此爲止，對中文字符的排序有個想法，如果有哪種編碼是按拼音排序，則可採用獲得編碼的方式對一串字符串進行排序。根據測試結果，中文字符的Unicode碼並不是按拼音排序，而是像根據部首來排序，因此，並不能根據Unicode碼排拼音序。前面說過，中文字符區位碼一級漢字區爲按拼音排序，而區位碼實際上通過分別加上A0的操作成爲GB2312編碼，根據兼容原理，GB的排序規則也是按照拼音排序，並且通過測試結果確實如此，因此通過GB轉化爲Unicode轉化爲UTF，則就實現了中文字符的排序規則。如在java裏，字符串String的getBytes(Charset charset)方法可以得到字符串的字節數組，通過取8位二進制(&0xFF)得到指定組的16進制編碼。排序方法：通過實現Comparable接口，然後通過String.getBytes(“GBK”)得到byte數組，經過一系列的轉換對byte數組值進行比較就可以實現排序了。