Python之路3【知識點】白話Python編碼和文件操做

Python文件頭部模板

先說個小知識點：如何在建立文件的時候自動添加文件的頭部信息！

經過：file--settings 每次都經過file--setings打開設置頁面太麻煩了！能夠經過：View--選中Toolbar工具條

修改後的效果：

1、Python Script 模板第一行

這個很簡單告訴系統用什麼解釋去解釋，若是你直接用python python_file_name.py的話這個沒什麼影響能夠不加。

可是若是想直接經過./python_file_name.py去運行的話就得加上！

爲何？

拿Linux和Windows來舉例子，默認Linux有本身的可執行文件的解釋器的是什麼？SHELL若是你不告訴系統用Python去解釋就會默認使用shell去解釋。徹底不認識就會出問題

Windows也是有本身的解釋器的powershell....同理，so 明白了吧

2、Python Script模板第三行

這個不須要特別解釋就是文件的做者註釋

 

我們單獨看下第二行

Python編碼詳解--嘔心瀝血

在2.7環境中我們要寫上這一行#-*- coding:utf-8 -*-  爲何咱們要加這一行呢？這同樣的意思是置頂編碼類型爲utf-8編碼！

首先在看這個問題以前，我們是否曾想過一個問題？

爲何咱們能夠在顯示器上能看到這些文字、數字、圖片、字符、等等信息呢？你們都知道計算機自己只能識別 0  1 的組合，他們是怎麼展現這些內容的呢？咱們怎麼和計算機去溝通呢？

若是咱們使用0 1 的組合和計算機溝通你還能看到這些內容嗎？還有一個問題就是01的組合對於我們說幾乎看不懂對吧！

那怎麼辦？如何讓計算機理解咱們的語言，而且咱們能理解計算機的語言呢？

舉個比較形象的例子，中英文詞典對照表，這樣咱們就能夠把中英文進行互相的翻譯了呢？對不對！同理計算機也是這樣的他須要一個標準的對照關係，那麼這個標準最先叫什麼呢？ASCII表

ASCII（American Standard Code for Information Interchange，美國信息交換標準代碼）是基於拉丁字母的一套電腦編碼系統，主要用於顯示現代英語和其餘西歐語言。它是現今最通用的單字節編碼系統，並等同於國際標準ISO/IEC 646。

 

我們看下這張表：

有特殊符號、大寫字母、小寫字母、數字（這裏注意下0~9的數字是字符），在這些字符左邊都有一個10進制的數字。可是對於10進制來講計算機他也是不能理解的，由於他只能理解0 1 ，可是10進制和2進制的轉換就很是容易了！

點擊我以前寫過的一篇文章來查看：十進制&二進制轉換

舉例來講：若是我在鍵盤上按一個A字母的時候那麼實際是給計算機傳輸了一個數字65，經過這樣的機制和計算機溝通，有了這個ASCII碼錶就能夠和任何計算機進行溝通了。NICE

 

這裏在看個知識點：計算機中最小的單位是什麼？bit   bit就我們常說一位二進制，一位二進制要麼是0 要麼是 1

可是bit這個單位過小了，咱們用字節（byte）來表示。他們是有換算的規則的(看下面的規則我想你們都不是很陌生對吧)：

'''
8b = 1B  #小b=bit ； 大B=byte
1024B = 1KB
1024KB = 1M
1024M = 1G
1024G = 1T 
'''

在存儲英文的時候咱們至少須要1個字節（一個字母），就是8位(bit),看下ASCII表中1個字節就能夠表示全部的英文所須要的字符，是不很是高效！

爲何呢？早期的計算機的空間是很是寶貴的！

那你會發現1個字節8位，他能存儲的最大數據是2的8次方-1 = 255，一個字節最多能表示255個字符 那西方國家他們使用了127個字符，那麼剩下字符是作什麼的呢？就是用來作擴展的，西方人考慮到還有其餘國家。因此留下了擴展位。

 

可是呢有問題，計算機是西方人發明的，若是僅僅支持英文的話，這127個字符徹底就能夠表示全部英文中能用的的內容了。可是他沒有考慮我們大中國啊！ASCII到了中國以後發現：我們中國最經常使用的中文都有6000多個徹底不夠用啊！

可是怎們辦？中國人很是聰明：就在原有的擴展位中，擴展出本身的gbk、gb23十二、gb2318字符編碼。

他是怎麼擴展的呢？好比說在ASCII碼中的128這個位置，這個位置又指定一張單獨表，聰明吧！ 其餘國家也是這樣設計的！

中國東亞大國是吧，咱們國家比較NB，我要兼容其餘國家的經常使用的編碼！好比韓國日本，由於韓國和日本人家都有本身的編碼，人家根本就不鳥你，舉個例子來講，好比韓國的遊戲，在中國下載安裝以後會出現亂碼的狀況？什麼鬼？

這種亂碼的出現基本上就兩種狀況：

一、字符編碼沒有

二、字符編碼衝突了，人家在寫這個程序的時候指定的字符集和我們使用的字符集的位置不對。 0 0 ！

你想一想不光是亞洲國家這樣，歐洲國家，非洲國家都會存在這個問題，基於這個亂象國際互聯網組織就說大家各個國家都別搞了，咱們給大家搞一個統一的，這個統一的是什麼呢Unicode「萬國編碼」，

 

Unicode（統一碼、萬國碼、單一碼）是一種在計算機上使用的字符編碼。Unicode 是爲了解決傳統的字符編碼方案的侷限而產生的，它爲每種語言中的每一個字符設定了統一而且惟一的二進制編碼，

規定雖有的字符和符號最少由 16 位來表示（2個字節），即：2 **16 = 65536， 注：此處說的的是最少2個字節，可能更多。

 

這裏還有個問題：使用的字節增長了，那麼形成的直接影響就是使用的空間就直接翻倍了！舉例還說：一樣是ABCD這些字符存儲一篇相同的文章，使用ASCII碼若是是1M的話，那麼Unicode存儲至少2M可能還會更多。

爲了解決個問題就出現了:UTF-8編碼

UTF-8編碼：是對Unicode編碼的壓縮和優化，他再也不使用最少使用2個字節，而是將全部的字符和符號進行分類：ascii碼中的內容用1個字節保存、歐洲的字符用2個字節保存，東亞的字符用3個字節保存...

經過這種可擴展的方式來存儲。

OK 上面瞭解了：

一、什麼ASCII編碼

二、什麼Unicode編碼

三、什麼UTF-8編碼

回顧下亂碼的出現緣由：一、沒有字符集 二、字符集衝突

 

回過頭來看下爲何須要在第二行加上指定編碼呢？在2.x版本的Python中Pyton在解釋.py文件的時候，默認是給他一個編碼的就是ASCII碼，so若是在2.7版本中若是你不指定編碼而且在.py文件中寫了一個ASCII碼中沒有的字符就會顯示亂碼 0 0 ！

不過這個問題在Python3中就不存在了，由於在Python3中默認就是Unicode編碼。。。。。

Python編碼轉換

有一個問題，既然有統一的Unicode編碼了，爲毛還須要編碼轉換？你們都統一一個編碼不就能夠了嗎？

一、

不要問我爲何，我問大家個問題，若是世界上出了一種世界語言，你會放棄中文嗎？去使用這個世界通用語言嗎？這就是個坑，是個遺留問題。

可是雖然之後可能世界語言會慢慢替代我們經常使用的語言，你們之後溝通就使用世界語言就不會有溝通障礙了對吧。（就是舉個例子）

二、

還有一個狀況是什麼呢？韓國的遊戲到中國來以後，是亂碼？結合上一個回答我們能夠猜出：編寫這個遊戲的人在編寫遊戲的時候可能根本就沒有考慮出口其餘國家。那若是沒有這個Unicode編碼的話，到我們這裏來顯示確定是亂碼是吧。

那就得須要經過轉碼把他們編碼集，轉換爲Unicode（utf-8）編碼集。這樣他們就能夠正常顯示韓文了！（這裏只是轉編碼集並非翻譯成中文不要弄混了~~！）

 

1、Python3中的編碼轉換

#由於在Python3中默認就是unicode編碼

#!/usr/bin/env python
#-*- coding:utf-8 -*-
#author luotianshuai

tim = '天帥'
#轉爲UTF-8編碼
print(tim.encode('UTF-8'))
#轉爲GBK編碼
print(tim.encode('GBK'))
#轉爲ASCII編碼(報錯爲何?由於ASCII碼錶中沒有‘天帥’這個字符集~~)
print(tim.encode('ASCII'))

2、Python2.X中的編碼轉換

#由於在python2.X中默認是ASCII編碼，你在文件中指定編碼爲UTF-8，可是UTF-8若是你想轉GBK的話是不能直接轉的，的須要Unicode作一個轉接站點。

#!/usr/bin/env python
#-*- coding:utf-8 -*-
#author luotianshuai

import chardet
tim = '你好'
print chardet.detect(tim)
#先解碼爲Unicode編碼，而後在從Unicode編碼爲GBK
new_tim = tim.decode('UTF-8').encode('GBK')
print chardet.detect(new_tim)

#結果
'''
{'confidence': 0.75249999999999995, 'encoding': 'utf-8'}
{'confidence': 0.35982121203616341, 'encoding': 'TIS-620'}
'''