閱讀目錄
上節拾遺
變量的建立與id
例1:name = 'oldboy'
首先，當咱們定義了一個變量name = ‘oldboy’的時候，在內存中實際上是作了這樣一件事：python
程序開闢了一塊內存空間，將‘oldboy’存儲進去，再讓變量名name指向‘oldboy’所在的內存地址。以下圖所示：git
例2:兩個變量名一個值
提問：當我執行下面這段代碼的時候，程序是怎麼處理的呢？程序員
咱們猜測會有兩種可能:編程
第一種狀況:程序分別在內存中開闢了兩塊兒空間來存儲‘oldboy’這個值，而且讓name1和name2指向這兩個值。以下左圖編程語言
第二種狀況:因爲兩個值內容一致，因此程序只開闢一起空間存儲‘oldboy’，並讓name1和name2只想着個值。以下右圖ide
提問：你們來猜想一下會是哪一種狀況？post
其實上面的兩種猜測都是對的。正常狀況下字符串在內存裏就是如咱們猜測的第一種狀況同樣，每一次建立一個變量都會在內存中申請一起空間。學習
可是，python認爲一些「看起來像python標識符的字符」和小整數字在開發中是經常使用的，所以出於節省內存的角度思考，對於這部分字符串和數字作出了優化[-5,257)，python解釋器會因爲要定義的新變量內容與以前定義過的變量內容相同而不讓這部份內容佔用新的內存空間。優化
咱們如何證實咱們的想法呢？this
python爲咱們提供了一個id()方法，能夠查看一個變量的內存地址。
>>> name1 = 'oldboy' >>> name2 = 'oldboy' >>> name1_id = id(name1) >>> name2_id = id(name2) >>> print(name1_id,name2_id) (4459387232, 4459387232)
執行完這段代碼就基本驗證了咱們的思想，因爲‘oldboy’是一個簡單的字符串，所以python解釋器作了優化，內存裏只有一個‘oldboy’，name1和name2都指向同一起內存地址。
若是是長字符串呢？就米有優化機制啦！
>>> a = 'this is a very long sentence' >>> b = 'this is a very long sentence' >>> id(a) 4394464720 >>> id(b) 4394464640
對於[-5,257)範圍內的數字也有優化機制：
>>> a = 256 >>> b = 256 >>> id(a) 4297546112 >>> id(b) 4297546112 >>> a = -5 >>> b = -5 >>> id(a) 4297537760 >>> id(b) 4297537760
可是超過這個範圍可就不太行了：
>>> a=257 >>> b=257 >>> id(a) 4402490032 >>> id(b) 4403650768 >> a = -6 >>> b=-6 >>> id(a) 4402490032 >>> id(b) 4403650768
例3:一個變量名2個值
提問：若是像下面這樣寫本身的代碼，最終打印name會獲得什麼結果？
name = 'oldboy' name = 'alex' print(name)
我想你們的答案是一致的，name此時應該是‘alex’，當咱們在程序中對變量進行重複賦值時，就是對一個變量進行修改.
代碼解讀：
程序先申請了一塊內存空間來存儲‘oldboy’，讓name變量名指向這塊內存空間
讀到name=‘alex’以後又申請了另外一塊內存空間來存儲‘alex’，並讓本來指向‘oldboy’內存的連接斷開，讓name再指向‘alex’。
以下圖所示：
例4:變量的賦值與修改
提問：若是像下面這樣寫本身的代碼，最終打印name1和name2會分別獲得什麼結果？
name1 = 'oldboy' name2 = name1 name1 = 'alex' print(name1,name2)
這裏你們就會產生一些爭論了，先執行一下給你們看。
要想知道上面問題的結果是爲何，首先要了解在內存中兩個變量的存儲狀況。
從上面的示意圖中咱們能夠知道，當執行name2=name1這句話的時候，事實上是讓name2指向了‘oldboy’所在的內存地址。
修改name1的值，至關於斷開了name1到‘oldboy’的連接，從新創建name1和‘alex’之間的連接。在這個過程當中，始終沒有影響到name2和‘oldboy‘之間的關係，所以name2仍是‘oldboy’，而name1變成了‘alex’。
身份運算
二進制
首先，計算機一共就能作兩件事：計算和通訊
那在講計算機以前，咱們先來說一個故事，你們知道古時候的中國是如何通訊的麼？
假如，戰國時期兩個國家要打仗了，咱們壘了城牆，每隔一段就有兵鎮守，如今有人來攻打咱們了，而後咱們是否是得通知其餘人有人來打咱們來了？怎麼通知？
字符編碼
經過上一節講的二進制的知識，你們已經知道計算機只認識二進制，生活中的數字要想讓計算機理解就必須轉換成二進制。十進制到二進制的轉換隻能解決計算機理解數字的問題，那麼文字要怎麼讓計算機理解呢？
因而咱們就選擇了一種曲線救國的方式，既然數字能夠轉換成十進制，咱們只要想辦法把文字轉換成數字，這樣文字不就能夠表示成二進制了麼？
但是文字應該怎麼轉換成數字呢？就是強制轉換
咱們本身強行約定了一個表，把文字和數字對應上，這張表就至關於翻譯，咱們能夠拿着一個數字來對比對應表找到相應的文字，反之亦然。
ASCII碼
能夠先讓學生看圖片，而後再介紹ascii碼
假如咱們就已經有這麼一張表了
ASCII（American Standard Code for Information Interchange，美國信息交換標準代碼）是基於拉丁字母的一套電腦編碼系統，主要用於顯示現代英語和其餘西歐語言。它是現今最通用的單字節編碼系統，並等同於國際標準ISO/IEC 646。
因爲計算機是美國人發明的，所以，最先只有127個字母被編碼到計算機裏，也就是大小寫英文字母、數字和一些符號，這個編碼表被稱爲ASCII編碼，好比大寫字母 A的編碼是65，小寫字母 z的編碼是122。後128個稱爲擴展ASCII碼。
那如今咱們就知道了上面的字母符號和數字對應的表是早就存在的。那麼根據如今有的一些十進制，咱們就能夠轉換成二進制的編碼串。
好比
提問：假如咱們要打印兩個空格一個對勾 寫做二進制就應該是 0011111011可是 可是問題來了，咱們怎麼知道從哪兒到哪兒是一個字符呢？
正是因爲這些字符串長的長，短的短，寫在一塊兒讓咱們難以分清每個字符的起止位置，因此聰明的人類就想出了一個解決辦法，既然一共就這255個字符，那最長的也不過是11111111八位，不如咱們就把全部的二進制都轉換成8位的，不足的用0來替換。
這樣一來，剛剛的兩個空格一個對勾就寫做000000000000000011111011，讀取的時候只要每次讀8個字符就能知道每一個字符的二進制值啦。
在這裏，每一位0或者1所佔的空間單位爲bit(比特)，這是計算機中最小的表示單位
每8個bit組成一個字符，這是計算機中最小的存儲單位(畢竟你是沒有辦法存儲半個字符的)orz～
要不要舉例子說單位？就像咱們形容長度會有釐米、分米、米之分，在計算機裏也有本身的計量數據大小的單位
人民幣的例子：給了你好多錢，假如沒有萬-十萬
bit 位，計算機中最小的表示單位 8bit = 1bytes 字節，最小的存儲單位，1bytes縮寫爲1B 1KB=1024B 1MB=1024KB 1GB=1024MB 1TB=1024GB 1PB=1024TB 1EB=1024PB 1ZB=1024EB 1YB=1024ZB 1BB=1024YB
提問：學完ascii碼，做爲一個英文程序員來講，基本圓滿了。可是做爲一箇中國程序員，你是否是以爲少了點兒什麼？（再給學生看一下ascii碼錶）
GBK和GB2312
顯然，對於咱們來講能在計算機中顯示中文字符是相當重要的，然而剛學習的ASCII表裏連一個偏旁部首也沒有。因此咱們還須要一張關於中文和數字對應的關係表。以前咱們已經看到了，一個字節只能最多表示256個字符，要處理中文顯然一個字節是不夠的，因此咱們須要採用兩個字節來表示，並且還不能和ASCII編碼衝突，因此，中國製定了GB2312編碼，用來把中文編進去。
你能夠想獲得的是，全世界有上百種語言，日本把日文編到Shift_JIS裏，韓國把韓文編到Euc-kr裏，
各國有各國的標準，就會不可避免地出現衝突，結果就是，在多語言混合的文本中，顯示出來會有亂碼。
Unicode
所以，Unicode應運而生。Unicode把全部語言都統一到一套編碼裏，這樣就不會再有亂碼問題了。
Unicode標準也在不斷髮展，但最經常使用的是用兩個字節表示一個字符（若是要用到很是偏僻的字符，就須要4個字節）。現代操做系統和大多數編程語言都直接支持Unicode。
如今，捋一捋ASCII編碼和Unicode編碼的區別：
ASCII編碼是1個字節，而Unicode編碼一般是2個字節。
字母A用ASCII編碼是十進制的65，二進制的01000001；
字符0用ASCII編碼是十進制的48，二進制的00110000；
漢字「中」已經超出了ASCII編碼的範圍，用Unicode編碼是十進制的20013，二進制的01001110 00101101。
你能夠猜想，若是把ASCII編碼的A用Unicode編碼，只須要在前面補0就能夠，所以，A的Unicode編碼是00000000 01000001。
新的問題又出現了：若是統一成Unicode編碼，亂碼問題今後消失了。可是，若是你寫的文本基本上所有是英文的話，用Unicode編碼比ASCII編碼須要多一倍的存儲空間，在存儲和傳輸上就十分不划算。
UTF-8
因此，本着節約的精神，又出現了把Unicode編碼轉化爲「可變長編碼」的UTF-8編碼。UTF-8編碼把一個Unicode字符根據不一樣的數字大小編碼成1-6個字節，經常使用的英文字母被編碼成1個字節，漢字一般是3個字節，只有很生僻的字符纔會被編碼成4-6個字節。若是你要傳輸的文本包含大量英文字符，用UTF-8編碼就能節省空間：
| 字符 | ASCII | Unicode | UTF-8 |
| A | 01000001 | 00000000 01000001 | 01000001 |
| 中 | x | 01001110 00101101 | 11100100 10111000 10101101 |
從上面的表格還能夠發現，UTF-8編碼有一個額外的好處，就是ASCII編碼實際上能夠被當作是UTF-8編碼的一部分，因此，大量只支持ASCII編碼的歷史遺留軟件能夠在UTF-8編碼下繼續工做。
搞清楚了ASCII、Unicode和UTF-8的關係，咱們就能夠總結一下如今計算機系統通用的字符編碼工做方式：
在計算機內存中，統一使用Unicode編碼，當須要保存到硬盤或者須要傳輸的時候，就轉換爲UTF-8編碼。
用記事本編輯的時候，從文件讀取的UTF-8字符被轉換爲Unicode字符到內存裏，編輯完成後，保存的時候再把Unicode轉換爲UTF-8保存到文件。
文件存取編碼轉換圖
經常使用編碼介紹一覽表
| 編碼 | 制定時間 | 做用 | 所佔字節數 |
| ASCII | 1967年 | 表示英語及西歐語言 | 8bit/1bytes |
| GB2312 | 1980年 | 國家簡體中文字符集，兼容ASCII | 2bytes |
| Unicode | 1991年 | 國際標準組織統一標準字符集 | 2bytes |
| GBK | 1995年 | GB2312的擴展字符集，支持繁體字，兼容GB2312 | 2bytes |
| UTF-8 | 1992年 | 不定長編碼 | 1-3bytes |