開發這些年，一直有遇到字元編碼這些問題，能一直在解決，但始終沒有做到通透的水平，現在想嘗試做一下歸納與總結。嘗試從乙個完全不懂的小白的角度，把問題講清楚。
最開始的時候，只是英文世界裡面存在計算機。對於計算機而言，他只認識一些基本的位元組，不認識所謂的英文。為了顯示26個字母，出現了最早的ascii碼。可以簡單的理解為，當某個位元組如果被解釋成字元的時候，那麼，就參考ascii碼的對映關係。例如：值為0x41的時候，就顯示字元」a「。英文本元，加上一些其他的運算子，基本上ascii碼表就能解決問題了。
然而，其他國家也加入了網際網路世界。每個國家有自己的文字，需要一套從位元組，轉換成顯示的一套對映規則。所以就出現各種字元編碼。
像我國，由於歷史原因，先後推出了幾個編碼標準，有gbk，gb18030等。為了資料資訊方便的在全世界交換，出現了乙個統一的標準，unicode。unicode是乙個字元編碼表，可以簡單的理解為是乙個大表。key是乙個數值，value是對應的乙個字元。所有語言的任何字元，都能在unicode中找到乙個唯一的值與其對應。那麼，傳輸文字的時候，如果使用unicode方案，那就非常簡單和清晰了。
有了unicode，那麼傳輸的時候，其實就是傳輸對應的unicode的key的值。而unicode中，總共需要4個位元組。如果全部是英文的話，理論上只需要1個位元組就足夠表達了。因此，就出現了utf-8等將unicode字符集轉換成數值的一種對映演算法機制，我們稱之為utf-8編碼。utf-8、utf-16、utf-32等本質上都是如何把unicode字符集轉成數值，達到用更少的空間來表達的目的。具體轉換演算法，可以參考網際網路上的解讀。
從儲存資料的角度，確實無須儲存什麼編碼。如果拿到資料的解釋程式知道是什麼編碼，直接存即可。然而，從mysql的客戶端角度，更友好的做法，應該是我給你一段資料的同時，我告訴你這段資料採用的是什麼編碼，你才能正確解發布來，這就是mysql需要儲存編碼資訊的原因了。
對於常見的如utf-8檔案，其開頭有乙個固定的頭，efbbbf，其他的尚未求證是否存在。待補充。
我對字元裝置驅動的理解
實驗要求 編寫簡單的字元裝置驅動模組，能夠支援建立和刪除節點，節點進行讀寫操作時分別列印 you are reading 和 you are writing 思想整理 1.本實驗需要我們編寫乙個驅動程式,如mymodule.c 2.該驅動程式經編譯後生成.ko檔案,使用makefile檔案生成mym...
對字元編碼的一些理解
記住 unicode是乙個字符集，不是具體的編碼方案，而utf 8 utf 16才是編碼。unicode字符集和ascii是乙個型別的概念。字符集可以說是乙個抽象的概念，就是所有文字的集合，然後每個字都有乙個獨一無二的編號。而到具體的實現 就是這個編號到底是用幾個位元組去存放，就是utf x們要幹的...
對Python中字串編碼的理解
字串，作為python中基本資料型別中的一種，也是使用最頻繁的資料型別。這裡對字串的編碼格式做乙個總結。在python中字串有兩種形式 一種是bytes型別，一種是str型別。str bytes encode編碼 bytes str decode解碼 可以使用下圖這種理解方式 1.1引數 1.2示例...