近期用Python讀取txt 文件時遇到一些小坑，涉及到文件編碼問題。
因此梳理編碼中Unicode與常見的UTF-8編碼的區別。
先貼總結：
Unicode：
全稱Universal Multiple-Octet Coded Character Set”，簡稱 UCS, 俗稱 “unicode“，由國際標準化組織ISO制定，目的是標準化一個字符集：爲地球上每一個「字符」分配一個唯一的 ID（學名爲碼位 / 碼點 / Code Point
廣義的 Unicode 是一個標準，定義了一個字符集以及一系列的編碼規則，即 Unicode 字符集和 UTF-8、UTF-16、UTF-32 等等編碼……
UTF-8:
爲解決unicode如何在網絡上傳輸的問題，於是面向傳輸的衆多UTF（UCS Transfer Format）標準，即可變長度編碼方式出現了，顧名思義，UTF-8就是每次8個位傳輸數據，而UTF-16就是每次16個位。設計的出發點是：節省網絡傳輸的代價，如果unicode統一規定，每個符號用三個或四個字節表示，那麼每個英文字母前都必然有二到三個字節是0，這對於存儲空間來說是極大的浪費，文本文件的大小會因此大出二三倍，這是難以接受的。
有一個形象的比喻；
用通信理論的思路可以理解爲:
unicode是信源編碼，對字符集數字化;
utf8是信道編碼，爲更好的存儲和傳輸。
例子：（來自知乎，侵權刪..
I 0049
t 0074
' 0027
s 0073
0020
知 77e5
乎 4e4e
日 65e5
報 62a5
每一個字符對應一個十六進制數字。
計算機只懂二進制，因此，嚴格按照unicode的方式(UCS-2)，應該這樣存儲：I 00000000 01001001
t 00000000 01110100
' 00000000 00100111
s 00000000 01110011
00000000 00100000
知 01110111 11100101
乎 01001110 01001110
日 01100101 11100101
報 01100010 10100101
這個字符串總共佔用了18個字節，但是對比中英文的二進制碼，可以發現，英文前9位都是0！浪費啊，浪費硬盤，浪費流量。
怎麼辦？
UTF。
UTF-8是這樣做的：
1. 單字節的字符，字節的第一位設爲0，對於英語文本，UTF-8碼只佔用一個字節，和ASCII碼完全相同；
2. n個字節的字符(n>1)，第一個字節的前n位設爲1，第n+1位設爲0，後面字節的前兩位都設爲10，這n個字節的其餘空位填充該字符unicode碼，高位用0補足。
這樣就形成了如下的UTF-8標記位：
0xxxxxxx
110xxxxx 10xxxxxx
1110xxxx 10xxxxxx 10xxxxxx
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
... ...
I 01001001
t 01110100
' 00100111
s 01110011
00100000
知 11100111 10011111 10100101
乎 11100100 10111001 10001110
日 11100110 10010111 10100101
報 11100110 10001010 10100101
和上邊的方案對比一下，英文短了，每個中文字符卻多用了一個字節。但是整個字符串只用了17個字節，比上邊的18個短了一點點。
此外，除了UTF-8 通用的傳輸編碼方式外，還有計算機歷史原因而存在的一些其他編碼方式；
最早計算機在美國使用，因此有ANSI的”Ascii”編碼（American Standard Code for Information Interchange，美國信息互換標準代碼。用於表示英文文字。
後來，加入了很多畫表格時需要用下到的橫線、豎線、交叉等形狀，一直把序號編到了最後一個狀態255。從128 到255這一頁的字符集被稱”擴展字符集。
後來，加入漢字編碼的“GB2312“。GB2312 是對 ASCII 的中文擴展。
後來，擴展了近20000個新的漢字（包括繁體字）和符號的GBK標準。
再擴展，又加了幾千個新的少數民族的字，GBK擴成了GB18030。