unicode是萬能編碼，包含了所有符號的編碼，它規定了所有符號在計算機底層的二進位制的表示順序。有關unicode為什麼會出現就不敘述了，unicode是針對所有計算機的使用者定義一套統一的編碼規範，這樣計算機使用者就避免了編碼轉換的問題。unicode定義了所有符號的二進位制形式，也就是符號如何在計算機內部儲存的，而且每個符號規定都必須使用兩個位元組來表示，也就是用16位二進位制去代表乙個符號，這樣就導致了乙個問題，英文編碼的空間浪費，因為在ansi中的符號都是乙個位元組來表示的，而使用了unicode編碼就白白浪費了乙個位元組。也就代表著unicode需要使用兩倍的空間去儲存相應的ansi編碼下的符號。雖然現在硬碟或者記憶體都很廉價，但是在網路傳輸中，這個問題就凸顯出來了，你可以這樣想想，本來1m的頻寬在ansi下可以代表1024*1024個字元，但是在unicode下卻只能代表1024*1024/2個字元。也就是1mb/s的頻寬只能等價於512kb/s，這個很可怕啊。所以為了解決符號在網路中傳輸的浪費問題，就出現了utf-8編碼，unicode transfer format -8 ，後面的8代表是以8位二進位制為單位來傳輸符號的，但是這樣又導致了乙個問題，雖然utf-8可以使用乙個位元組來表示ansi下的符號，但是對於其它類似漢語的符號，得需要兩個位元組來表示，所以計算機不知道如何去擷取乙個符號，也就是乙個符號對應的二進位制的擷取開始位置和擷取結束位置。所以為了解決unicode下的ansi符號的空間浪費和網路傳輸下如何擷取字元的問題，utf規定：如果乙個符號只佔乙個位元組，那麼這個8位位元組的第一位就為0。如果為兩個位元組，那麼規定第乙個位元組的前兩位都為1，然後第乙個位元組的第三位為0，第二個位元組的前兩位為10，然後如果是三個位元組的話，那麼第乙個位元組的前三位為111，第四位為0，剩餘的兩個位元組的前兩位都為10。按照這樣的演算法去思考乙個中文字元的utf-8是怎麼表示的：乙個中文字元需要兩個位元組來表示，兩個位元組一共是16位，那麼utf-8下，兩個位元組是不夠的，因為兩個位元組下，第乙個位元組已經佔據了三位：110，然後剩餘的乙個位元組佔據了兩位：10，現在就只剩下11位，與unicode下的兩個位元組，16位去表示任意乙個字元是相悖的。所以就使用三個位元組去表示非ansi字元：三個位元組下，一共是24位，第乙個位元組頭四位是：1110，後兩個位元組的前兩位都是：10，那麼24位-8位=16位，剛好兩個位元組去表示unicode下的任意乙個非ansi字元。這也就是為什麼utf-8需要使用三個位元組去表示乙個非ansi字元的原因了！
題外話：
然，中國的漢字多達10多萬，常用的漢字3500左右[08年統計]，如果用3個位元組來表示，一共只有2^16(65535)種可能，不足以表示10多萬的漢字。所以中日韓的超大字符集是採用的4個位元組來表示的，多達6萬多個。但是平時使用超大字符集的概率0.01%都不到。所以我們一般認為日常的中文在utf-8中佔三個位元組 即可！
多個位元組提供的位數超過了所需要的，多餘的位以0補全到編碼前面
UTF 8 編碼裡，乙個漢字占用多少個位元組 轉
在查詢 utf 8 編碼資料時發現，很多的帖子說的 utf 8 編碼裡，乙個漢字占用3個位元組，有的還做了個證明，大概是這樣的，建立乙個沒有bom的utf 8編碼的文字檔案，裡面儲存了幾個漢字，然後檢視檔案的大小。我覺得這樣的證明沒有一點說服力，因為 utf 8 是變長的，1 6個位元組，少量的漢字...
Java生成乙個UTF 8檔案
生成utf 8檔案.如果檔案內容中沒有中文內容，則生成的檔案為ansi編碼格式 如果檔案內容中有中文內容，則生成的檔案為utf 8編碼格式。param filenametemp 待生成的檔名 含完整路徑 param str 檔案內容 private static void writetxtfile ...
MySQL為什麼需要乙個主鍵
主鍵 表中每一行都應該有可以唯一標識自己的一列 或一組列 乙個顧客可以使用顧客編號列，而訂單可以使用訂單id，雇員可以使用雇員id 或 雇員社會保險號。主鍵 primary key 一列 或一組列 其值能夠唯一區分表中的每個行。唯一標識表中每行的這個列 或這組列 稱為主鍵。沒有主鍵，更新或刪除表中特...