字串編碼和解碼

計算機底層通過二進位制儲存資料，字串的儲存和展示有這樣的關係：

字串<-->字元<-->二進位制儲存

在傳統的編碼方式中，如 ascii、iso-8859-1，是直接將字元與二進位制數進行了對映，形成乙個字元表。這樣，儲存字串時，查詢字元表，把其中每個字元都用對應的二進位制數進行表示。當展示資料時，同樣查詢字元表，把二進位制數轉化成對應的字元。

早期通過 ascii 編碼字串，但隨著計算機的發展，需要越來越多的字元要在計算機中進行表示，出現了各種編碼方式，如 iso-8859-1、gbk 等。使用同一種編碼不會出現問題，但國際間需要交流，雙方可能使用的是不同的編碼方式，這樣交流時就會出現問題，即 "亂碼"。

因此需要一種統一的編碼來解決這種問題，就出現了 unicode。

unicode 在 "字元" 和 "二進位制儲存" 之間引入了乙個抽象層，這樣的好處是在可以在不考慮具體的儲存時，表示更多的字元。此時字串的儲存和展示有這樣的關係：

字串<-->字元<-->十六進製制數描述<-->二進位制儲存

這個 "十六進製制數描述" 即所謂的 code point。它與具體的儲存無關，只用來進行字元到數字的對映。對於具體的儲存，可以採用各種符合需求的編碼方式。

當然可採用 "code point 直接轉換成二進位制數" 的方式進行儲存，但此時有這樣的問題：

當然也可以用之前常見的編碼方式，如 ascii、iso-8859-1 等，但若這些編碼中不包含 unicode 中對應的 code point，則展現的資料可能會是問號或 '-> ' 之類的，出現亂碼，因為缺少對應的對映關係。

當前國際上常用的編碼是 utf-8，它解決了上述提到的那些問題。

還有 utf-16、utf-32 之類的編碼，但由於是多位元組的字元表示，會有位元組序的問題，即是 "大端儲存還是小端儲存"，此時引入了 byte order mark，通過在文字開頭的幾個位元組表明當前的 utf-* 編碼是哪種位元組序。

python3 現在對字串的處理進行了統一和嚴格規定，把字串分成兩類：

通過上述的描述，可以清楚理解到，str 到 bytes 的轉換需要 encode，bytes 到 str 的轉換需要 decode。

解釋幾種場景下字串的形式：