我的讀者知道我是一個喜歡痛罵Python3 unicode的人。這次也不例外。我將會告訴你用unicode有多痛苦和為什么我不能閉嘴。我花了兩周時間研究Python3，我需要發(fā)泄我的失望。在這些責(zé)罵中，仍然有有用的信息，因?yàn)樗涛覀內(nèi)绾蝸硖幚鞵ython3。如果沒有被我煩到，就讀一讀吧。

這次吐槽的內(nèi)容會不一樣。不會關(guān)聯(lián)到WSGI或者HTTP及與其相關(guān)的東西。通常，我被告知我應(yīng)該停止抱怨Python3 Unicode系統(tǒng)，因?yàn)槲也粚憚e人經(jīng)常寫的代碼（HTTP庫之類的東西），所以我這次準(zhǔn)備寫點(diǎn)別的東西：一個命令行應(yīng)用程序。我寫了一個很方便的庫叫click來讓編寫它更加簡單。

注意，我做的是每一個新手Python程序員做的事情：寫一個命令行應(yīng)用程序。Hello World程序。但是不同以往，我想要確保應(yīng)用程序是穩(wěn)定的并且對于Python2和Python3的Unicode都是支持的，還能夠進(jìn)行單元測試。所以接下來的就是如何來實(shí)現(xiàn)它。

我們想做什么

在Python3我們作為開發(fā)者需要好好使用Unicode。顯然，我覺得這意味著所有的文本數(shù)據(jù)都是Unicode，所有非文本數(shù)據(jù)都是字節(jié)。在這么美妙的世界里所有的東西只有黑與白，Hello World的例子非常直截了當(dāng)。所以讓我們來寫一些shell工具吧。

這是用Python2形式實(shí)現(xiàn)的應(yīng)用程序：

import sys
import shutil
 
for filename in sys.argv[1:]:
  f = sys.stdin
  if filename != '-':
    try:
      f = open(filename, 'rb')
    except IOError as err:
      print >> sys.stderr, 'cat.py: %s: %s' % (filename, err)
      continue
  with f:
    shutil.copyfileobj(f, sys.stdout)

顯然，命令在處理任何命令行選項(xiàng)的時候也不是特別好，不過至少能夠用。所以我們開始碼代碼吧。

UNIX里的UNICODE

上面的代碼在Python2是不行的，因?yàn)槟惆抵刑幚碜止?jié)。命令行參數(shù)是字節(jié)，文件名是字節(jié)，文件內(nèi)容也是字節(jié)。語言衛(wèi)道士會指出這是不對的，這樣會引發(fā)問題，但如果你開始更多考慮它，你會發(fā)現(xiàn)這是個不固定的問題。

UNIX是字節(jié)，已經(jīng)被定義成了這樣，并且一直會是這樣。為了理解為什么你需要觀察數(shù)據(jù)傳輸?shù)牟煌瑘鼍啊?/p>

• 終端
• 命令行參數(shù)
• 操作系統(tǒng)輸入輸出層
• 文件系統(tǒng)驅(qū)動

順便提一下，這不是數(shù)據(jù)可能通過的唯一東西，但是我們來了解一下，在多少場景下我們能了解一個編碼。答案是一個也沒有。至少我們需要理解一個編碼是終端輸出區(qū)域信息。這個信息可以用來展現(xiàn)轉(zhuǎn)換，也能夠理解文本信息所擁有的編碼。

舉個例子，如果LC_CTYPE的值為en_US.utf-8告訴應(yīng)用程序系統(tǒng)使用US English，并且大部分文本數(shù)據(jù)是utf-8編碼。實(shí)際上還有很多別的變量，不過我們假定這是我們唯一需要看的。注意LC_CTYPE并不代表所有的數(shù)據(jù)都是utf-8編碼的。它代替通知應(yīng)用程序如何分類文本特性并且什么時候需要應(yīng)用轉(zhuǎn)換。

這很重要，原因是因?yàn)閏 locale。c locale是POSIX唯一指定的現(xiàn)場，它說所有ASCII編碼和來自命令行工具的回復(fù)會按照POSIX spec里定義的來對待。

在我們上面的cat工具里，如果它是比特，沒有別的方法來對待這些數(shù)據(jù)。原因是shell里沒有指定這數(shù)據(jù)是什么。例如你調(diào)用cat hello.txt，終端會在對應(yīng)用程序編碼的時候?qū)ello.txt進(jìn)行編碼。

但是現(xiàn)在想想這個例子echo *。Shell會把目前目錄的所有文件名傳遞給你的應(yīng)用程序。那它們是什么編碼？文件名沒有編碼！

UNICODE瘋狂

現(xiàn)在一個用Windows的人看到這里會說：弄UNIX的人在搞什么呢。但這還不算悲慘。產(chǎn)生這些工作的原因是一些聰明的人設(shè)計得這個系統(tǒng)能夠向后兼容。不像Windows把每個API都定義兩次，在POSIX上，最好的處理方法是為了顯示的目的將其假定為字節(jié)，用默認(rèn)的編碼方式來編碼。

用上面的cat命令來舉例。比如有一個關(guān)于文件無法打開的錯誤信息，原始是因?yàn)樗鼈儾淮嬖诨蛘咚鼈兪鞘鼙Ｗo(hù)的，或者其他任何的原因。我們假定文件是用latin1編碼的，因?yàn)樗莵碜?995年外部驅(qū)動。終端會獲取標(biāo)準(zhǔn)輸出，它將會試著把它用utf-8編碼，因?yàn)檫@是它認(rèn)為的編碼。因?yàn)樽址莑atin1編碼的，因?yàn)樗鼰o法順利得解碼。但是不怕，不會有什么崩潰，因?yàn)槟愕慕K端在無法處理它的時候會無視它。

它在圖形界面上怎樣？每種有兩個版本。在一個像Nautilus 這樣的圖形界面上列出所有的文件。它把文件名和圖標(biāo)關(guān)聯(lián)起來，能夠雙擊并且試著使文件名能夠顯示出來，因而把它解碼。例如它會嘗試用utf-8解碼，錯誤的地方用問題記號來替代。你的文件名可能不是完全可讀的但那是你仍能打開文件。

UNIX上的unicode只在你強(qiáng)制所有東西用它的時候會很瘋狂。但那不是unicode在UNIX上工作的方式。UNIX沒有區(qū)別unicode和字節(jié)的API。它們是相同的，使其更容易處理。

C Locale

C Locale在這里出現(xiàn)的次數(shù)非常多。C Locale是避免POSIX的規(guī)格被強(qiáng)行應(yīng)用到任何地方的一種手段。POSIX服從操作系統(tǒng)需要支持設(shè)置LC_CTYPE，來讓一切使用ASCII編碼。

這個locale是在不同的情況下挑選的。你主要發(fā)現(xiàn)這個locale為所有從cron啟動的程序，你的初始化程序和子進(jìn)程提供一個空的環(huán)境。C Locale在環(huán)境里復(fù)原了一個健全的ASCII地帶，否則你無法信任任何東西。

但是ASCII這個詞指出它是7bit編碼。這不是問題，因?yàn)椴僮飨到y(tǒng)是能處理字節(jié)的！任何基于8bit的內(nèi)容能正常處理，但你與操作系統(tǒng)遵循約定，那么字符處理會限制在前7bit。任何你的工具生成的信息它會用ASCII編碼并且使用英語。

注意POSIX規(guī)范沒有說你的應(yīng)用程序應(yīng)當(dāng)死于火焰。

Python3死于火焰

Python3在unicode上選擇了與UNIX不同的立場。Python3說：任何東西是Unicode（默認(rèn)情況下，除非是在某些情況下，除非我們發(fā)送重復(fù)編碼的數(shù)據(jù)，可即使如此，有時候它仍然是Unicode，雖然是錯誤的Unicode）。文件名是Unicode，終端是Unicode，stdin和stdout是Unicode，有如此多的Unicode。因?yàn)閁NIX不是Unicode，Python3現(xiàn)在的立場是它是對的UNIX是錯的，人們也應(yīng)該修改POSIX的定義來添加Unicode。那么這樣的話，文件名就是Unicode了，終端也是Unicode了，這樣也就不會看到一些由于字節(jié)導(dǎo)致的錯誤了。

不是僅僅我這樣說。這些是Python關(guān)于Unicode的腦殘想法導(dǎo)致的bug：

• ASCII是很槽糕的文件名編碼
• 用surrogateescape作為默認(rèn)error handler
• Python3在C locale下拋出Unicode錯誤
• LC CTYPE=C，pydoc給終端留下一個不能使用的狀態(tài)

如果你Google一下，你就能發(fā)現(xiàn)如此多的吐槽?？纯从卸嗌偃税惭bpip模塊失敗，原因是changelog里的一些字符，或者是因?yàn)閔ome文件夾的原因又，或者是因?yàn)镾SH session是用ASCII的，或者是因?yàn)樗麄兪鞘褂肞utty連接的。

Python3 cat

現(xiàn)在開始為Python3修復(fù)cat。我們?nèi)绾巫?？首先，我們需要處理字?jié)，因?yàn)橛行〇|西可能會顯示一些不符合shell編碼的東西。所以無論如何，文件內(nèi)容需要是字節(jié)。但我們也需要打開基本輸出來讓它支持字節(jié)，而它默認(rèn)是不支持的。我們也需要分別處理一些情況比如Unicode API失敗，因?yàn)榫幋a是C。那么這就是，Python3特性的cat。

import sys
import shutil
 
def _is_binary_reader(stream, default=False):
  try:
    return isinstance(stream.read(0), bytes)
  except Exception:
    return default
 
def _is_binary_writer(stream, default=False):
  try:
    stream.write(b'')
  except Exception:
    try:
      stream.write('')
      return False
    except Exception:
      pass
    return default
  return True
 
def get_binary_stdin():
  # sys.stdin might or might not be binary in some extra cases. By
  # default it's obviously non binary which is the core of the
  # problem but the docs recomend changing it to binary for such
  # cases so we need to deal with it. Also someone might put
  # StringIO there for testing.
  is_binary = _is_binary_reader(sys.stdin, False)
  if is_binary:
    return sys.stdin
  buf = getattr(sys.stdin, 'buffer', None)
  if buf is not None and _is_binary_reader(buf, True):
    return buf
  raise RuntimeError('Did not manage to get binary stdin')
 
def get_binary_stdout():
  if _is_binary_writer(sys.stdout, False):
    return sys.stdout
  buf = getattr(sys.stdout, 'buffer', None)
  if buf is not None and _is_binary_writer(buf, True):
    return buf
  raise RuntimeError('Did not manage to get binary stdout')
 
def filename_to_ui(value):
  # The bytes branch is unecessary for *this* script but otherwise
  # necessary as python 3 still supports addressing files by bytes
  # through separate APIs.
  if isinstance(value, bytes):
    value = value.decode(sys.getfilesystemencoding(), 'replace')
  else:
    value = value.encode('utf-8', 'surrogateescape') \
      .decode('utf-8', 'replace')
  return value
 
binary_stdout = get_binary_stdout()
for filename in sys.argv[1:]:
  if filename != '-':
    try:
      f = open(filename, 'rb')
    except IOError as err:
      print('cat.py: %s: %s' % (
        filename_to_ui(filename),
        err
      ), file=sys.stderr)
      continue
  else:
    f = get_binary_stdin()
 
  with f:
    shutil.copyfileobj(f, binary_stdout)

這不是最差的版本。不是因?yàn)槲蚁胱屖虑楦訌?fù)雜，它現(xiàn)在就是有這么復(fù)雜。例如在例子里沒有做的是在讀取一個二進(jìn)制的東西是強(qiáng)制清理文本stdout。在這個例子里沒有必要，是因?yàn)檫@里的print調(diào)用去了stderr而不是stdout，但如果你想打印一些stdout，你就必須清理。為什么？因?yàn)閟tdout是別的緩沖區(qū)之上的緩沖區(qū)，如果你不強(qiáng)制清理它，你的輸出順序可能會出錯。

不僅僅是我，例如看： ，會發(fā)現(xiàn)相同的麻煩。

最新評論