字符集和字元編碼的關係 ：
字符集是書寫系統字母與符號的集合，為每乙個「字元」分配乙個唯一的 id（學名為碼位 /碼點/ code point）；字符集種類較多，每個字符集包含的字元個數不同，常見的字符集名稱：ascii字符集、gb2312字符集、gb18030字符集、unicode字符集等。
字元編碼則是將字元對映為一特定的位元組或位元組序列，是一種規則，將「碼位」轉換為位元組序列的規則（編碼/解碼 可以理解為 加密/解密 的過程）。通常特定的字符集採用特定的編碼方式（即一種字符集對應一種字元編碼（例如：ascii、ios-8859-1、gb2312、gbk，都是即表示了字符集又表示了對應的字元編碼）），因此基本上可以將兩者視為同義詞。
unicode是乙個字元編碼的標準規範，而utf-8/utf-16/utf-32只是對這個標準規範的具體實現，可稱為unicode編碼。
unicode 目前規劃的總空間是17個平面（平面0至16，開頭是0x0-----0x10），0x0000 至 0x10ffff。每個平面有 65536 個碼點。2位元組：2^16=65536，4位元組：2^32=4,294,967,296
0平面是2位元組字元，1-16平面是4位元組字元。
bmp 的字元是 unicode 中最基礎和最常用的一部分，以 utf-16 編碼時使用2位元組，以 utf-8 編碼時使用1至3位元組。
超出 bmp（平面0） 的字元以 utf-16 或 utf-8 編碼都需要4位元組。
另外還有乙個比較少用的編碼形式，utf-32，它編碼任何 unicode 字元都需要4個位元組。
17*65536 = 1,114,112，32位可容納下所有的碼點
由於目前unicode的表的大小可以算到如果使用utf-32編碼的話，用32個bit就能完全容納下所有的碼點，所以utf-32的特點是每乙個字元編碼後都是4個位元組，是定長的，相對的utf-8和utf-16都是變長的
特殊的：
0-9是48-57
a-z 是65-90
a-z 是97-122
聯盟為每個字母中的每個柏拉圖字母分配了乙個魔幻數字，其寫法如下：u + 0639。這個幻數稱為**點。
在utf-8中，從0-127的每個**點都儲存在乙個位元組中【ascall碼】。實際上，只有**點128和更高的**點才使用2、3（最多6個位元組）儲存。相比於只使用英文本母的美國人使用utf-8比使用utf-16減少一半記憶體。
傳統的「兩位元組儲存」方法稱為ucs-2（因為它有兩個位元組）或utf-16（因為它有16位）
如果您在記憶體，檔案或電子郵件中有字串，則必須知道它的編碼格式，否則將無法解釋它或將其正確顯示給使用者。
如果字符集和字元編碼兩者之間的轉換規則不統一標準，就會亂碼現象。簡單的說亂碼的出現是因為：編碼和解碼時用了不同或者不相容的字符集。
字型檔就是字型庫（font library），其實計算機上顯示的每個字元（不管它是哪種語言的），都是乙個小的圖案。字型檔就是把這些小的圖案以的某種形式儲存起來，需要顯示的 時候還原出來就可以了。在windows作業系統裡的字庫存放在系統盤windows/fonts資料夾下，在linux作業系統中字庫存放在這/usr /share/fonts/資料夾下。
字符集 編碼和Unicode
部分來自 深入理解c 11 在計算機中，總是使用二進位制位組合來表示複雜的資訊。首當其衝需要被標識的就是字元。為了使二進位制組合標識字元的方法在不同設計的計算機間通用，就迫切需要統一的字元編碼方法。於是在20世紀60年代的時候，ascii字元編碼就出現了。在ansi頒布的標準中，基本ascii的字元...
Unicode以及字符集轉換
曾經碰到乙個問題，專案需要支援日文作業系統，但是沒有編譯成unicode程式。然後在乙個解析使用者輸入路徑的地方出問題了。原因是日文的 表 這個漢字，日文編碼格式下，低位元組和反斜槓 編碼一樣，解析的時候把它當成路徑的分隔符了。項 8d 80 shift jis 目 96 da shift jis ...
Unicode以及字符集轉換
曾經碰到乙個問題，專案需要支援日文作業系統，但是沒有編譯成unicode程式。然後在乙個解析使用者輸入路徑的地方出問題了。原因是日文的 表 這個漢字，日文編碼格式下，低位元組和反斜槓 編碼一樣，解析的時候把它當成路徑的分隔符了。項 8d 80 shift jis 目 96 da shift jis ...