字符編碼

字符編碼

啓動應用程序：

1.雙擊qq

2.操做系統接收指令，而後把該操做轉化爲0和1發送給CPU

3.CPU接收指令而後把指令發送給內存

4.內存接收指令把指令發送給硬盤獲取數據

5.qq在內存運行

寫文本的流程

1.在記事本中按下鍵盤中j的時候

2.記事本和操做系統交互，把這個按下j的指令轉化爲0和1

3.操做系統發送指令給CPU

4.CPU說吧這個0和1的指令轉化爲j

5.而後再由顯示器顯示

• 期間發送的轉化過程咱們稱之爲字符編碼

j--->0和1 #存儲

0和1---> j #取

統稱爲字符編碼

python解釋器的原理

1.啓動python解釋器，python解釋器至關於一個文本編輯器00000

2.打開文件，讀出文件內容，python解釋器至關於一個文本編輯器，--->發生了字符編碼，name='nick'

3.python解釋器解釋name ='nick',而後纔有了語法的概念--->發生了字符編碼00000

001001101001000101010（硬盤中）---->name ='nick'（內存）--->開闢一塊內存空間--->0000001010101001010

python解釋器和文本編輯器的區別

1.都能幹什麼：

​ A.把硬盤中躺着的數據讀入到內存中，並顯示

2.不一樣：

​ A.python解釋器還會執行解釋的步驟

字符編碼發生在哪三個階段

1.存 內存到硬盤

2.取 硬盤到內存

3.python3解釋器的解釋

最先的電腦只認識英文，

00001-a 00002-b 00003-中

256個足夠他們用了

0 1

00 a 01 b 10 c 11 d

8位二進制位做爲一個對應表，稱爲ASCII表

unicode的轉換

中 0000111100001111 a 00001111

內存 unicode轉換 硬盤

0000111100001111000011110 - a - 00001111
0000111100001111000111111 - 中 - 000011110000111

utf8的出現只是爲了節省空間，把這個00000000 01000001改爲01000001存到內存中

1.電腦是美國創造出來的，電腦只認識0和1，可是美國人想輸入一個a字符進去，因此必須得創建一套字符編碼，讓00001111表示a，創建一套ascii碼錶

2.可是其餘國家也開始使用電腦了，ascii碼錶不能知足需求了，因此各個國家創建了本身的字符編碼表

3.中國的是gbk，日本的是ift，韓國的是uck，因此各個國家的碼農都用本身國家的編碼表寫了各類各樣的代碼

4.忽然某個韓國人想說某個日本人的代碼是本身寫的，可是把日本人的代碼放到本身的電腦上運行會報錯，一下就被揭穿了，因此這個韓國人站出來講，我要弄一套編碼表，這個編碼表不只能兼容日本，還能兼容世界的，而後最終沒能實現

5.忽然有一個超級英雄站出來講，我來幫你吧，而後unicode橫空出世，unicode能認識全部國家的字符

6.而後可使用unicode的編碼保存到硬盤中取，可是發現unicode編碼太浪費內存了，而後作出了一套精簡的utf8編碼

7.等哪一天硬盤中躺着的全是utf8的編碼的代碼，那麼unicode就下崗了

• 上述說到的報錯其實就是亂碼，怎樣才能解決亂碼

存的時候用什麼編碼，取的時候用什麼編碼（必考）

內存中的編碼格式統一就是unicode

從內存到硬盤的過程，即unicode--->gbk稱爲encode

從硬盤到內存的過程，即gbk--->unicode稱爲解碼decode

python2與python3解釋器編碼的區別

python2（瞭解）

解釋語法的時候，生成變量時會把這個字符丟入到內存中，這個時候會有兩種狀況，一種是str編碼，一種是unicode編碼

str

直接編碼成gbk的形式

unicode

直接編碼成unicode的形式

python3

pycharm右下角控制的是你寫入的代碼字符以什麼編碼格式保存

coding：utf-8控制的是python3做爲文本編輯器的時候，以什麼編碼格式讀取文本內容，python3默認是utf-8的形式讀取字符

python解釋器的語法

解釋定義變量的語法，會新開闢一塊內存空間放入這個變量，而後這個變量在python3中以unicode的形式存儲，如字符x='中'，被python3解釋後在內存中會變成x=1010101010101100，理論上print(x)至關於輸出1010101010101100，可是1010101010101100對於程序員來說看不懂，因此python3創始人龜叔做了這個操做，把1010101010101100編碼按終端的編碼格式輸出到編碼後的結果上，如上.

解釋定義變量的語法，會新開闢一塊內存空間放入這個變量，而後假設這個變量在python3中以utf-8的形式存儲，如字符x=中,被python3解釋後在內存中會變成x=000001101010.理論上print（x）至關於輸出000001101010，可是這個000001101010對於程序員來說看不懂，因此pyhon3創始人龜叔做了這個操做-把000001101010編碼按終端的編碼格式輸出編碼後的結果，如上,若是終端的編碼格式是gbk，終端沒法識別000001101010，因此新開闢空間放入變量的時候，就用unicode轉換，則終端不管是什麼編碼格式，都可以識別打印。

亂碼分析

亂碼的兩種狀況：

• 亂碼一：存文件時就已經亂碼

存文件時，因爲文件內容有各個國家的文字，咱們單以shiftjis去存，本質上其餘國家的文字因爲在shiftjis中沒有找到對應關係而致使存儲失敗。但當咱們硬要存的時候，編輯並不會報錯（難道你的編碼錯誤，編譯器這個軟件就跟着崩潰了嗎？？？），但毫無疑問，不能存而硬存，確定是亂存了，即文件階段就已經發生亂碼，而當咱們用shiftjis打開文件時，日文能夠正常顯示，而中文就亂碼了。

總結

一、保證不亂碼的核心法則就是，字符按照什麼標準編碼的，就要按照什麼標準解碼，此處的標準指的就是字符編碼

二、在內存中寫的全部字符，一視同仁，都是unicode編碼，好比咱們打開編譯器，輸入一個「你」，咱們並不能說「你」就是一個漢字，此時它僅僅只是一個符號，該符號可能不少國家都在使用，根據咱們使用的輸入法不一樣這個字的樣式可能也不太同樣。只有咱們往硬盤保存或者是基於網絡傳輸時，才能肯定「你」究竟是一個漢字，仍是一個日本字，這就是unicode轉換成其餘編碼格式的過程了。簡而言之，就是內存中固定使用使用的就是unicode編碼，咱們惟一能改變的就是存儲到硬盤時使用的編碼。

• Unicode---------->encode(編碼)---------->gbk
• Unicode---------->decode(解碼)----------->gbk