欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

关于你不想知道的所有Python3 unicode特性

程序员文章站 2022-06-08 09:54:00
我的读者知道我是一个喜欢痛骂python3 unicode的人。这次也不例外。我将会告诉你用unicode有多痛苦和为什么我不能闭嘴。我花了两周时间研究python3,我需...

我的读者知道我是一个喜欢痛骂python3 unicode的人。这次也不例外。我将会告诉你用unicode有多痛苦和为什么我不能闭嘴。我花了两周时间研究python3,我需要发泄我的失望。在这些责骂中,仍然有有用的信息,因为它教我们如何来处理python3。如果没有被我烦到,就读一读吧。

这次吐槽的内容会不一样。不会关联到wsgi或者http及与其相关的东西。通常,我被告知我应该停止抱怨python3 unicode系统,因为我不写别人经常写的代码(http库之类的东西),所以我这次准备写点别的东西:一个命令行应用程序。我写了一个很方便的库叫click来让编写它更加简单。

注意,我做的是每一个新手python程序员做的事情:写一个命令行应用程序。hello world程序。但是不同以往,我想要确保应用程序是稳定的并且对于python2和python3的unicode都是支持的,还能够进行单元测试。所以接下来的就是如何来实现它。

我们想做什么

在python3我们作为开发者需要好好使用unicode。显然,我觉得这意味着所有的文本数据都是unicode,所有非文本数据都是字节。在这么美妙的世界里所有的东西只有黑与白,hello world的例子非常直截了当。所以让我们来写一些shell工具吧。

这是用python2形式实现的应用程序:

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)

显然,命令在处理任何命令行选项的时候也不是特别好,不过至少能够用。所以我们开始码代码吧。

unix里的unicode

上面的代码在python2是不行的,因为你暗中处理字节。命令行参数是字节,文件名是字节,文件内容也是字节。语言卫道士会指出这是不对的,这样会引发问题,但如果你开始更多考虑它,你会发现这是个不固定的问题。

unix是字节,已经被定义成了这样,并且一直会是这样。为了理解为什么你需要观察数据传输的不同场景。

  • 终端
  • 命令行参数
  • 操作系统输入输出层
  • 文件系统驱动

顺便提一下,这不是数据可能通过的唯一东西,但是我们来了解一下,在多少场景下我们能了解一个编码。答案是一个也没有。至少我们需要理解一个编码是终端输出区域信息。这个信息可以用来展现转换,也能够理解文本信息所拥有的编码。

举个例子,如果lc_ctype的值为en_us.utf-8告诉应用程序系统使用us english,并且大部分文本数据是utf-8编码。实际上还有很多别的变量,不过我们假定这是我们唯一需要看的。注意lc_ctype并不代表所有的数据都是utf-8编码的。它代替通知应用程序如何分类文本特性并且什么时候需要应用转换。

这很重要,原因是因为c locale。c locale是posix唯一指定的现场,它说所有ascii编码和来自命令行工具的回复会按照posix spec里定义的来对待。

在我们上面的cat工具里,如果它是比特,没有别的方法来对待这些数据。原因是shell里没有指定这数据是什么。例如你调用cat hello.txt,终端会在对应用程序编码的时候对hello.txt进行编码。

但是现在想想这个例子echo *。shell会把目前目录的所有文件名传递给你的应用程序。那它们是什么编码?文件名没有编码!

unicode疯狂

现在一个用windows的人看到这里会说:弄unix的人在搞什么呢。但这还不算悲惨。产生这些工作的原因是一些聪明的人设计得这个系统能够向后兼容。不像windows把每个api都定义两次,在posix上,最好的处理方法是为了显示的目的将其假定为字节,用默认的编码方式来编码。

用上面的cat命令来举例。比如有一个关于文件无法打开的错误信息,原始是因为它们不存在或者它们是受保护的,或者其他任何的原因。我们假定文件是用latin1编码的,因为它是来自1995年外部驱动。终端会获取标准输出,它将会试着把它用utf-8编码,因为这是它认为的编码。因为字符串是latin1编码的,因为它无法顺利得解码。但是不怕,不会有什么崩溃,因为你的终端在无法处理它的时候会无视它。

它在图形界面上怎样?每种有两个版本。在一个像nautilus 这样的图形界面上列出所有的文件。它把文件名和图标关联起来,能够双击并且试着使文件名能够显示出来,因而把它解码。例如它会尝试用utf-8解码,错误的地方用问题记号来替代。你的文件名可能不是完全可读的但那是你仍能打开文件。

unix上的unicode只在你强制所有东西用它的时候会很疯狂。但那不是unicode在unix上工作的方式。unix没有区别unicode和字节的api。它们是相同的,使其更容易处理。

c locale

c locale在这里出现的次数非常多。c locale是避免posix的规格被强行应用到任何地方的一种手段。posix服从操作系统需要支持设置lc_ctype,来让一切使用ascii编码。

这个locale是在不同的情况下挑选的。你主要发现这个locale为所有从cron启动的程序,你的初始化程序和子进程提供一个空的环境。c locale在环境里复原了一个健全的ascii地带,否则你无法信任任何东西。

但是ascii这个词指出它是7bit编码。这不是问题,因为操作系统是能处理字节的!任何基于8bit的内容能正常处理,但你与操作系统遵循约定,那么字符处理会限制在前7bit。任何你的工具生成的信息它会用ascii编码并且使用英语。

注意posix规范没有说你的应用程序应当死于火焰。

python3死于火焰

python3在unicode上选择了与unix不同的立场。python3说:任何东西是unicode(默认情况下,除非是在某些情况下,除非我们发送重复编码的数据,可即使如此,有时候它仍然是unicode,虽然是错误的unicode)。文件名是unicode,终端是unicode,stdin和stdout是unicode,有如此多的unicode。因为unix不是unicode,python3现在的立场是它是对的unix是错的,人们也应该修改posix的定义来添加unicode。那么这样的话,文件名就是unicode了,终端也是unicode了,这样也就不会看到一些由于字节导致的错误了。

不是仅仅我这样说。这些是python关于unicode的脑残想法导致的bug:

如果你google一下,你就能发现如此多的吐槽。看看有多少人安装pip模块失败,原因是changelog里的一些字符,或者是因为home文件夹的原因又,或者是因为ssh session是用ascii的,或者是因为他们是使用putty连接的。

python3 cat

现在开始为python3修复cat。我们如何做?首先,我们需要处理字节,因为有些东西可能会显示一些不符合shell编码的东西。所以无论如何,文件内容需要是字节。但我们也需要打开基本输出来让它支持字节,而它默认是不支持的。我们也需要分别处理一些情况比如unicode api失败,因为编码是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)

这不是最差的版本。不是因为我想让事情更加复杂,它现在就是有这么复杂。例如在例子里没有做的是在读取一个二进制的东西是强制清理文本stdout。在这个例子里没有必要,是因为这里的print调用去了stderr而不是stdout,但如果你想打印一些stdout,你就必须清理。为什么?因为stdout是别的缓冲区之上的缓冲区,如果你不强制清理它,你的输出顺序可能会出错。

不仅仅是我,例如看: ,会发现相同的麻烦。

跳起编码舞蹈

为了理解shell里的命令行参数,顺便说一些python3里最糟糕的情况:

  1. shell把文件名以字节传给脚本
  2. 字节在命中你的代码前被python以预期的解码方式解码。因为这是有损好的过程,python3使用一个特别的错误处理器来处理解码错误。
  3. python代码处理一个没有错误的文件,并且需要格式化一个错误信息。因为我们写文本流的时候如果它不是非法的unicode,是不会写替代的。
  4. 将包含替代的unicode串编码为utf-8,然后告诉它处理替代转义。
  5. 然后我们从utf-8解码并告诉他忽略错误
  6. 结果字符串回到只有文本的流里
  7. 之后终端会解码我们的字符串来进行显示

以下是python2里的情况:

  1. shell把文件名作为字节传给脚本
  2. shell解码字符串来进行显示

因为python2版本里的字符串处理只是在出错的时候进行纠正,因为shell在显示文件名时能做得更好。

注意这没有让脚本更不对。如果你需要对输入数据进行实际的字符串处理,你就要在2.x和3.x里面切换到unicode处理。但在那种情况,你也想让你的脚本支持一个—charset参数,那么在2.x和3.x上做的工作差不多。只是在3.x上会更加糟糕,你需要构建在2.x上不需要的二进制标准输出。

但你是错误的

很显然我错了,我被人告诉这些:

  • 我感到痛苦是因为我不像初学者那样思考,新的unicode系统会对初学者更友好
  • 我不考虑windows用户和新的文本模型对windows用户是多么大的改进
  • 问题不在于python,问题在posix规范
  • linux发行版需要开始支持c.utf-8,因为它们被过去一直阻碍着
  • 问题是ssh发送了错误的编码。ssh需要修复这个问题。
  • python3里一大堆unicode错误的真正问题是人们不传递明确的编码而假设python3作出了正确的决定。
  • 我与分解代码工作,显然这在python3里会更难。
  • 我应该去改进python3而不是在twitter和博客上抱怨
  • 你在没有问题的地方制造问题。让每个人修复他们的环境和对任何东西进行编码就很好。这是用户的问题。
  • java有这个问题好多年了,这对开发者来说没问题。

你知道吗?我在做http方面的工作的时候就停止了抱怨,因为我接受了这个主意,就是http/wsgi的一大堆问题对人们来说很平常。但你知道什么?在hello world这样的情况下也有相同的问题。可能我应该放弃获得一个高质量的unicode支持的库,就这么将就了。

我可以对以上观点进行反驳,但最终也没关系了。如果python3是我唯一使用的python语言,我会解决所有的问题并且使用它开发。有一个完美的另一个语言叫python2,它有更大的用户基础,并且用户基础是很牢固的。这时我是非常沮丧的。

python3可能足够强大,会开始让unix走windows走过的路:在很多地方使用unicode,但我很怀疑这样的做法。

更可能的事情是人们仍旧使用python2,并且用python3做一些很烂的东西。或者他们会用go。这门语言使用了与python2很相似的模型:任何东西都是字节串。并且假设其编码是utf-8。到此结束。