文本,他們通常指顯示在屏幕上的字符或者其他的記號;但是計算機不能直接處理這些字符和標記;它們只認識位(bit)和字節(byte)。實際上,從屏幕上的每一塊文本都是以某種字符編碼(character encoding)的方式保存的。粗略地說就是,字符編碼提供一種映射,使屏幕上顯示的內容和內存、磁盤內存儲的內容對應起來。有許多種不同的字符編碼,有一些是為特定的語言,比如俄語、中文或者英語,設計、優化的,另外一些則可以用於多種語言的編碼。
在實際操作中則會比上邊描述的更復雜一些。許多字符在幾種編碼裡是共用的,但是在實際的內存或者磁盤上,不同的編碼方式可能會使用不同的字節序列來存儲他們。所以,你可以把字符編碼當做一種解碼密鑰。當有人給你一個字節序列 -- 文件,網頁,或者別的什麼 -- 並且告訴你它們是文本時,就需要知道他們使用了何種編碼方式,然後才能將這些字節序列解碼成字符。如果他們給的是錯誤的密鑰或者根本沒有給你密鑰,那就得自己來破解這段編碼,這可是一個艱難的任務。有可能你使用了錯誤的解碼方式,然後出現一些莫名其妙的結果。
你所了解的關於字符串的知識都是錯的。
你肯定見過這樣的網頁,在撇號("
)該出現的地方被奇怪的像問號的字符替代了。這種情況通常意味著頁面的作者沒有正確的聲明其使用的編碼方式,浏覽器只能自己來猜測,結果就是一些正確的和意料之外的字符的混合體。如果原文是英語,那只是不方便閱讀而已;在其他的語言環境下,結果可能是完全不可讀的。
現有的字符編碼各類給世界上每種主要的語言都提供了編碼方案。由於每種語言的各不相同,而且在以前內存和硬盤都很昂貴,所以每種字符編碼都為特定的語言做了優化。上邊這句話的意思是,每種編碼都使用數字(0–255)來代表這種語言的字符。比如,你也許熟悉ASCII編碼,它將英語中的字符都當做從0–127的數字來存儲。(65表示大寫的A,97表示小寫的a,&c。)英語的字母表很簡單,所以它能用不到128個數字表達出來。如果你懂得2進制計數的話,它只使用了一個字節內的7位。
西歐的一些語言,比如法語,西班牙語和德語等,比英語有更多的字母。或者,更准確的說,這些語言含有與變音符號(diacritical marks)組合起來的字母,像西班牙語裡的ñ
。這些語言最常用的編碼方式是CP-1252,又叫做windows-1252,因為它在微軟的視窗操作系統上被廣泛使用。CP-1252和ASCII在0–127這個范圍內的字符是一樣的,但是CP-1252為ñ
(n-with-a-tilde-over-it, 241),Ü
(u-with-two-dots-over-it, 252)這類字符而擴展到了128–255這個范圍。然而,它仍然是一種單字節的編碼方式;可能的最大數字為255,這仍然可以用一個字節來表示。
然而,像中文,日語和韓語等語言,他們的字符如此之多而不得不需要多字節編碼的字符集。即,使用兩個字節的數字(0–255)代表每個字符。但是就跟不同的單字節編碼方式一樣,多字節編碼方式之間也有同樣的問題,即他們使用的數字是相同的,但是表達的內容卻不同。相對於單字節編碼方式它們只是使用的數字范圍更廣一些,因為有更多的字符需要表示。
在沒有網絡的時代,文本由自己輸入,偶爾才會打印出來,大多數情況下使用以上的編碼方案是可行的。那時沒有太多的純文本。源代碼使用ASCII編碼,其他人也都使用字處理器,這些字處理器定義了他們自己的格式(非文本的),這些格式會連同字符編碼信息和風格樣式一起記錄其中,&c。人們使用與原作者相同的字處理軟件讀取這些文檔,所以或多或少地能夠使用。
現在,我們考慮一下像email和web這樣的全球網絡的出現。大量的“純文本”文件在全球范圍內流轉,它們在一台電腦上被撰寫出來,通過第二台電腦進行傳輸,最後在另外一台電腦上顯示。計算機只能識別數字,但是這些數字可能表達的是其他的東西。Oh no! 怎麼辦呢。。好吧,那麼系統必須被設計成在每一段“純文本”上都搭載編碼信息。記住,編碼方式是將計算機可讀的數字映射成人類可讀的字符的解碼密鑰。失去解碼密鑰則意味著混亂不清的,莫名其妙的信息,或者更糟。
現在我們考慮嘗試把多段文本存儲在同一個地方,比如放置所有收到郵件的數據庫。這仍然需要對每段文本存儲其相關的字符編碼信息,只有這樣才能正確地顯示它們。這很困難嗎?試試搜索你的email數據庫,這意味著需要在運行時進行編碼之間的轉換。很有趣是吧…
現在我們來分析另外一種可能性,即多語言文檔,同一篇文檔裡來自幾種不同語言的字符混在一起。(提示:處理這樣文檔的程序通常使用轉義符在不同的模式(modes)之間切換。噗!現在是俄語 koi8-r 模式,所以241代表 Я;噗噗!現在到了Mac Greek模式,所以241代表 ώ。)當然,你也會想要搜索這些文檔。根本就沒有所謂的純文本。
--------------------------------------分割線 --------------------------------------
CentOS上源碼安裝Python3.4 http://www.linuxidc.com/Linux/2015-01/111870.htm
《Python核心編程 第二版》.(Wesley J. Chun ).[高清PDF中文版] http://www.linuxidc.com/Linux/2013-06/85425.htm
《Python開發技術詳解》.( 周偉,宗傑).[高清PDF掃描版+隨書視頻+代碼] http://www.linuxidc.com/Linux/2013-11/92693.htm
Python腳本獲取Linux系統信息 http://www.linuxidc.com/Linux/2013-08/88531.htm
在Ubuntu下用Python搭建桌面算法交易研究環境 http://www.linuxidc.com/Linux/2013-11/92534.htm
Python 語言的發展簡史 http://www.linuxidc.com/Linux/2014-09/107206.htm
Unicode編碼系統為表達任意語言的任意字符而設計。它使用4字節的數字來表達每個字母、符號,或者表意文字(ideograph)。每個數字代表唯一的至少在某種語言中使用的符號。(並不是所有的數字都用上了,但是總數已經超過了65535,所以2個字節的數字是不夠用的。)被幾種語言共用的字符通常使用相同的數字來編碼,除非存在一個在理的語源學(etymological)理由使不這樣做。不考慮這種情況的話,每個字符對應一個數字,每個數字對應一個字符。即不存在二義性。不再需要記錄模式了。U+0041
總是代表"A"
,即使這種語言沒有"A"
這個字符。
初次面對這個創想,它看起來似乎很偉大。一種編碼方式即可解決所有問題。文檔可包含多種語言。不再需要在各種編碼方式之間進行模式轉換。但是很快,一個明顯的問題跳到我們面前。4個字節?只為了單獨一個字符 這似乎太浪費了,特別是對像英語和西語這樣的語言,他們只需要不到1個字節即可以表達所需的字符。事實上,對於以象形為基礎的語言(比如中文)這種方法也有浪費,因為這些語言的字符也從來不需要超過2個字節即可表達。
有一種Unicode編碼方式每1個字符使用4個字節。它叫做UTF-32,因為32位 = 4字節。UTF-32是一種直觀的編碼方式;它收錄每一個Unicode字符(4字節數字)然後就以那個數字代表該字符。這種方法有其優點,最重要的一點就是可以在常數時間內定位字符串裡的第N個字符,因為第N個字符從第4×Nth個字節開始。另外,它也有其缺點,最明顯的就是它使用4個詭異的字節來存儲每個詭異的字符…
盡管有Unicode字符非常多,但是實際上大多數人不會用到超過前65535個以外的字符。因此,就有了另外一種Unicode編碼方式,叫做UTF-16(因為16位 = 2字節)。UTF-16將0–65535范圍內的字符編碼成2個字節,如果真的需要表達那些很少使用的星芒層(astral plane)內超過這65535范圍的Unicode字符,則需要使用一些詭異的技巧來實現。UTF-16編碼最明顯的優點是它在空間效率上比UTF-32高兩倍,因為每個字符只需要2個字節來存儲(除去65535范圍以外的),而不是UTF-32中的4個字節。並且,如果我們假設某個字符串不包含任何星芒層中的字符,那麼我們依然可以在常數時間內找到其中的第N個字符,直到它不成立為止這總是一個不錯的推斷…
但是對於UTF-32和UTF-16編碼方式還有一些其他不明顯的缺點。不同的計算機系統會以不同的順序保存字節。這意味著字符U+4E2D
在UTF-16編碼方式下可能被保存為4E 2D
或者2D 4E
,這取決於該系統使用的是大尾端(big-endian)還是小尾端(little-endian)。(對於UTF-32編碼方式,則有更多種可能的字節排列。)只要文檔沒有離開你的計算機,它還是安全的 -- 同一台電腦上的不同程序使用相同的字節順序(byte order)。但是當我們需要在系統之間傳輸這個文檔的時候,也許在萬維網中,我們就需要一種方法來指示當前我們的字節是怎樣存儲的。不然的話,接收文檔的計算機就無法知道這兩個字節4E 2D
表達的到底是U+4E2D
還是U+2D4E
。
為了解決這個問題,多字節的Unicode編碼方式定義了一個字節順序標記(Byte Order Mark),它是一個特殊的非打印字符,你可以把它包含在文檔的開頭來指示你所使用的字節順序。對於UTF-16,字節順序標記是U+FEFF
。如果收到一個以字節FF FE
開頭的UTF-16編碼的文檔,你就能確定它的字節順序是單向的(one way)的了;如果它以FE FF
開頭,則可以確定字節順序反向了。
不過,UTF-16還不夠完美,特別是要處理許多ASCII字符時。如果仔細想想的話,甚至一個中文網頁也會包含許多的ASCII字符 -- 所有包圍在可打印中文字符周圍的元素(element)和屬性(attribute)。能夠在常數時間內找到第Nth個字符當然非常好,但是依然存在著糾纏不休的星芒層字符的問題,這意味著你不能保證每個字符都是2個字節長,所以,除非你維護著另外一個索引,不然就不能真正意義上的在常數時間內定位第N個字符。另外,朋友,世界上肯定還存在很多的ASCII文本…
另外一些人琢磨著這些問題,他們找到了一種解決方法:
UTF-8
UTF-8是一種為Unicode設計的變長(variable-length)編碼系統。即,不同的字符可使用不同數量的字節編碼。對於ASCII字符(A-Z,&c.)UTF-8僅使用1個字節來編碼。事實上,UTF-8中前128個字符(0–127)使用的是跟ASCII一樣的編碼方式。像ñ和ö這樣的擴展拉丁字符(Extended Latin)則使用2個字節來編碼。(這裡的字節並不是像UTF-16中那樣簡單的Unicode編碼點(unicode code point);它使用了一些位變換(bit-twiddling)。)中文字符比如則占用了3個字節。很少使用的星芒層字符則占用4個字節。
缺點:因為每個字符使用不同數量的字節編碼,所以尋找串中第N個字符是一個O(N)復雜度的操作 -- 即,串越長,則需要更多的時間來定位特定的字符。同時,還需要位變換來把字符編碼成字節,把字節解碼成字符。
優點:在處理經常會用到的ASCII字符方面非常有效。在處理擴展的拉丁字符集方面也不比UTF-16差。對於中文字符來說,比UTF-32要好。同時,(在這一條上你得相信我,因為我不打算給你展示它的數學原理。)由位操作的天性使然,使用UTF-8不再存在字節順序的問題了。一份以UTF-8編碼的文檔在不同的計算機之間是一樣的比特流。
Python 3會假定我們的源碼 -- 即.py
文件 -- 使用的是UTF-8編碼方式。
Python 2裡,.py
文件默認的編碼方式為ASCII。Python 3的源碼的默認編碼方式為UTF-8
如果想使用一種不同的編碼方式來保存Python代碼,我們可以在每個文件的第一行放置編碼聲明(encoding declaration)。以下聲明定義.py
文件使用windows-1252編碼方式:
# -*- coding: windows-1252 -*-
從技術上說,字符編碼的重載聲明也可以放在第二行,如果第一行被類UNIX系統中的hash-bang命令占用了。
#!/usr/bin/python3 # -*- coding: windows-1252 -*-
了解更多信息,請參閱PEP263: 指定Python源碼的編碼方式。
在Python 3,所有的字符串都是使用Unicode編碼的字符序列。不再存在以UTF-8或者CP-1252編碼的情況。也就是說,這個字符串是以UTF-8編碼的嗎?不再是一個有效問題。UTF-8是一種將字符編碼成字節序列的方式。如果需要將字符串轉換成特定編碼的字節序列,Python 3可以為你做到。如果需要將一個字節序列轉換成字符串,Python 3也能為你做到。字節即字節,並非字符。字符在計算機內只是一種抽象。字符串則是一種抽象的序列。
>>> s = "深入 Python">>> len(s)9>>> s[0]"深">>> s + " 3""深入 Python 3"
為了創建一個字符串,將其用引號包圍。Python字符串可以通過單引號("
)或者雙引號("
)來定義。
內置函數len()
可返回字符串的長度,即字符的個數。這與獲得列表,元組,集合或者字典的長度的函數是同一個。Python中,字符串可以想像成由字符組成的元組。
Just like getting individual items out of a list, you can get individual characters out of a string using index notation.
與取得列表中的元素一樣,也可以通過下標記號取得字符串中的某個字符。
類似列表,可以使用+
操作符來連接(concatenate)字符串。
更多詳情見請繼續閱讀下一頁的精彩內容: http://www.linuxidc.com/Linux/2015-03/114726p2.htm