摘要：關(guān)于的參考知乎上的一個(gè)回答傳送門以我自己的理解就是首先得分清楚編碼問題在不同的環(huán)境中，編碼是不同的。但是如果換成的是知乎的話，則表示的是將這個(gè)漢字用編碼的形式存放。

cnblogs

阮一峰

知乎

note from wiki:

從維基百科上得到的一些理解，一個(gè)字符的unicode編碼是確定的，但是在傳輸過程中，由于不同系統(tǒng)平臺(tái)的設(shè)計(jì)不一致，所以對(duì)unicode編碼的實(shí)現(xiàn)方式是有所不同的。unicode的實(shí)現(xiàn)方式成為unicode轉(zhuǎn)換格式(簡稱UTF)例如對(duì)于一個(gè)包含基本7位ASCII字符的unicode文件，如果都使用2字節(jié)的原unicode編碼傳輸，會(huì)造成浪費(fèi)。對(duì)于這種情況可以使用UTF-8編碼，它是一種變長編碼，對(duì)于基本ASCII字符仍然采用7位編碼表示，占用一個(gè)字節(jié)。
意思其實(shí)就是，unicode規(guī)定了符號(hào)的二進(jìn)制代碼的符號(hào)集，但是并沒有規(guī)定二進(jìn)制代碼應(yīng)該如何存儲(chǔ)。也就是說，在計(jì)算機(jī)的存儲(chǔ)中，一個(gè)字符的存放方式并不一定會(huì)與它的unicode編碼一致。這是因?yàn)椴捎昧瞬煌木幋a方式所導(dǎo)致的。

編碼一開始是使用ASCII碼來進(jìn)行編碼的，但是這個(gè)編碼方式是針對(duì)英文為基礎(chǔ)的國家的。后來，各個(gè)地區(qū)因?yàn)楦髯缘男枰?，開始使用127位以后的擴(kuò)展位。比如中國，因?yàn)閹兹f個(gè)漢字，所以單靠單個(gè)127位是根本不夠的，所以就規(guī)定，使用高于127位的兩個(gè)字節(jié)來表示漢字。當(dāng)然也就順便把原來的一些其他擴(kuò)展西方字符給出重新編碼了。即，全角字符（半角字符可類推）GB2312。
后來標(biāo)準(zhǔn)隨著發(fā)展，GBK變成了GB18030，即，只要第一個(gè)字節(jié)表示的十六進(jìn)制數(shù)大于127，就表示漢字的開始。（DBCS，雙字節(jié)字符。臺(tái)灣地區(qū)的BIG5）。
后來unicode開始制定了，它的制定標(biāo)準(zhǔn)在上面的引用中可以看到，使用的是兩個(gè)字節(jié)來表示字符。因此在unicode標(biāo)準(zhǔn)里，無論是漢字的全角字符還是英語的半角字符，都是一個(gè)字符，兩個(gè)字節(jié)。但是unicode如何在網(wǎng)絡(luò)上傳播也是一個(gè)問題。于是，便有了UTF。UTF與unicode的轉(zhuǎn)換關(guān)系如下：

note:
    0000 0000-0000 007F | 0xxxxxxx
    0000 0080-0000 07FF | 110xxxxx 10xxxxxx
    0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
    0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

其中的x是要用左邊的十六進(jìn)制碼轉(zhuǎn)化為二進(jìn)制碼后，代替相關(guān)的位。UTF-8的編碼規(guī)則很簡單，只有二條：

    1）對(duì)于單字節(jié)的符號(hào)，字節(jié)的第一位設(shè)為0，后面7位為這個(gè)符號(hào)的unicode碼。因此對(duì)于英語字母，UTF-8編碼和ASCII碼是相同的。
    2）對(duì)于n字節(jié)的符號(hào)（n>1），第一個(gè)字節(jié)的前n位都設(shè)為1，第n+1位設(shè)為0，后面字節(jié)的前兩位一律設(shè)為10。剩下的沒有提及的二進(jìn)制位，全部為這個(gè)符號(hào)的unicode碼。

在查閱了幾篇blog后，舉個(gè)例子：比如說你現(xiàn)在的file用的是編輯器等(比如說是windows上的記事本，且設(shè)置它為ASCII，unicode（其實(shí)是帶BOM的utf-8）)默認(rèn)的編碼方式，那么存儲(chǔ)的時(shí)候用的就是這種編碼方式對(duì)應(yīng)的在硬盤中的存儲(chǔ)方式。比如說，此刻我用sublime 3打開，而且我的sublime 3 中只有utf系列和一些西文字體的編碼方式，那么如果打開的文件用的是ASCII保存的文件，則此時(shí)會(huì)顯示的亂碼；而如果使用的是unicode的編碼方式，也是能打開的，而且不會(huì)出現(xiàn)亂碼的情況。
在終端或者編輯器中，如果沒有進(jìn)行特殊聲明的話，就會(huì)使用它們默認(rèn)的編碼格式進(jìn)行編碼，或者是GBK或者是UTF，如果是ascii的話，漢字字符是無法存儲(chǔ)的，因?yàn)闆]有配套的編碼。所以一般能顯示漢字的地方，使用的是GBK等等編碼格式，要轉(zhuǎn)碼的話，先轉(zhuǎn)換為unicode，然后再轉(zhuǎn)換為其他東西。

參考知乎上的一個(gè)回答傳送門

以我自己的理解就是:

首先得分清楚編碼問題,在不同的環(huán)境中，編碼是不同的。在終端的情況下，（windows 中是cmd，ubuntu 下的terminal，遠(yuǎn)程登錄是xshell），所以他們的編碼是不同的。shell環(huán)境下，windows的編碼是GBK,ubuntu一般是utf-8。-------在文本編輯的情況下，與上面的情況類似，是根據(jù)編輯器的情況決定的.

在python中的情況是，unicode(A,B)的意思是用B的編碼方案將A解碼，并將結(jié)果返回為unicode字符串。所以一般在出現(xiàn)UnicodeDecodeError時(shí)候，錯(cuò)誤的來源應(yīng)該就是：

文件保存時(shí)的編碼方式是編輯器默認(rèn)的保存方式，而在運(yùn)行環(huán)境中默認(rèn)的編碼方式與該文件方式并不相同，很有可能是有非ANIS的字符出現(xiàn)所致。因?yàn)榄h(huán)境無法編碼該文件。

在文件保存的時(shí)候，帶有BOM 。BOM（byte order mark）是為 UTF-16 和 UTF-32 準(zhǔn)備的，用于標(biāo)記字節(jié)序（byte order）。微軟在 UTF-8 中使用 BOM 是因?yàn)檫@樣可以把 UTF-8 和 ASCII 等編碼明確區(qū)分開，但這樣的文件在 Windows 之外的操作系統(tǒng)里會(huì)帶來問題。
所以啊，最后在文件的頭里面需要加入utf-8的說明，最好不要用BOM。

# 環(huán)境是sublime 3
    1 >>> u"知乎".encode("utf-8")
    2 "xe7x9fxa5xe4xb9x8e"
    3 >>> u"知乎".encode("gb2312")
    4 "xd6xaaxbaxf5"
    5 >>> "知乎".encode("utf-8")
    Traceback (most recent call last):
        File "", line 1, in 
    UnicodeDecodeError: "ascii" codec can"t decode byte 0xe7 in position 0: ordinal not in range(128)
   7 >>> "知乎"
     "xe7x9fxa5xe4xb9x8e"
   8 >>> u"知乎"
     u"u77e5u4e4e"
   9 >>> u"知乎".encode("utf-8").decode("utf-8")
     u"u77e5u4e4e"    
   
# 環(huán)境是windows：
    >>>"知乎"
    "xd6xaaxbaxf5"
    >>>u"知乎"
    u"u77e5u4e4e"
    >>> u"知乎".encode("utf-8")
    "xe7x9fxa5xe4xb9x8e"
    >>> u"知乎".encode("gb2312")
    "xd6xaaxbaxf5"
    
    #還是補(bǔ)充一下舉這個(gè)例子的本意：
    #從第七行（數(shù)字標(biāo)出的，以下也是一樣）以及第一二行中可以看出，兩個(gè)輸出結(jié)果是相同的，第一行說明  將    u"知乎"  unicode字符串按照utf-8的編碼方式進(jìn)行編碼，并以字節(jié)串的形式輸出來。
    #但是如果換成的是 u"知乎" 的話，則表示的是將這個(gè)漢字用unicode編碼的形式存放。（猜測是自動(dòng)調(diào)用了encode方法）。所以呢，第九行意思是將utf-8編碼的字符串用utf-8解碼出來。
    #下面又在windows上補(bǔ)充了下，可以看出在不同的終端下，使用的編碼方式可能是不同的，比如在windows上就有可能是，當(dāng)輸入漢字的時(shí)候，終端用gbk的編碼方式將漢字編碼。

最后再貼一個(gè)鏈接參考blog

在這兩天的調(diào)試過程中，開始將unicode的相關(guān)知識(shí)模塊化，所以在此也特地寫下這些東西，作為一個(gè)總結(jié)。在寫代碼的時(shí)候，如果一個(gè)文件中有超過ascii的字符的話，那么需要在py文件的第一行加以聲明。這是因?yàn)椴煌沫h(huán)境，不同的編譯器所默認(rèn)的編碼字符的格式是不同的。最好能夠統(tǒng)一以u(píng)nicode字符串為基礎(chǔ)進(jìn)行轉(zhuǎn)換。

這是一個(gè)在segmentfault網(wǎng)站上回答過的一個(gè)東西的鏈接。鏈接1