当前位置:天才代写 > tutorial > 大数据教程 > 全面分析Python与Unicode

全面分析Python与Unicode

2018-05-17 08:00 星期四 所属: 大数据教程 浏览:629

  您对大数据是否非常了解,您是否了解大数据的所有,您是否已经非常了解大数据呢?您知道大数据里的Python与Unicode,如果您觉得大数据非常重要,不管您是否真的非常了解大数据还是不了解大数据。请好好阅读本篇文章吧,本篇文章带你了解大数据中Python与Unicode。课课家教育提醒您:要仔细阅读哦~~

  unicode 与 utf8 的关系

  unicode 定义了统一的字符集, UTF8 则是一种编码 unicode 字符集的方式.

  在 python2 中, str 类型, unicode 类型都是 basestring 的子类, 其中 str 类型就好比 C 语言中的字符串, unicode 类型就好比 C 语言中的宽字符串.

  因为 utf8 的编码方式不使用 0x0 填充, 一串 utf8 字符流实际上也是一串合法的 c 字符流 (0x0 结尾) — 也就是合法的 str 类型的字符流.

  编程相关的编码问题

  关于编程语言的编码问题, 可能会涉及到这么几个内容:

  源文件自身的编码

  编辑器/IDE 所理解的源文件的编码方式

  编译器/解释器对源代码中字符常量的处理方式

  下文我们会一一说明.

  源文件自身的编码

  源文件自身的编码是由谁决定的呢? 实际是我们自己决定的, 还记得保存文件时弹出的对话框吗? 对话框中有一个选项就是文件的格式, 可能大部分人没有关注, 如果我们不去 touch 选项的话, 那文件就以操作系统的默认编码格式存储了. 这在 Linux, MacOS 上是 utf8, 某些 windows 上是 gbk.

  在 vim 中我们通过 set fileencoding=utf8 选项来告诉 vim 应该把文件保存成 utf8 格式 — 也就是将每个字符按照其 utf8 中定义的 code point 存到磁盘上.

  编辑器/IDE 所理解的源文件的编码方式

  纯文本文件是没有 header 或者叫 meta 信息的 (请忽略 BOM 这个异类), 编辑器打开文本文件的时候实际上不知道他是什么格式, 只能自己根据文本内容猜测一下它的格式, 但是大部分编辑器是不干这个活的, 只是跟随操作系统的默认格式, 比如 Linux, MacOS 上默认的文本格式都是 utf8, 所以 vim, emacs 这些编辑器打开文本文件时就认为文件内容是 utf8 格式的; 而以前中文 windows 系统默认的文本格式是 gbk, 所以在 windows 系统中创建的文本文件, 到 Linux 系统中用 vim 打开会发现是乱码, 我们不得不手动执行一下 :e ++enc=gbk 告诉 vim 用 gbk 编码重新渲染这个文件.

  我们刚刚用到了 “渲染” 这个词, 为什么这么说呢? 因为 vim 只是个编辑器, 他不负责文本在显示器上的显示, 负责将文本输出到显示器 (显卡) 的是你机器上的 X 服务程序, 而 vim 又是怎么和 X 服务程序通信的呢? 实际上这中间还有个 X 客户程序, X 客户程序是什么呢? 就是你打开 vim 的地方, 一般来说也就是 xterm, rxvt, Terminal 这些终端程序.

  在我们使用 vim 编辑文本的时候, 所看到的结果其实全都是 vim 将结果输出到标准输出的过程, vim 的标准输出是连着 xterm 的, 所以文本文件的编辑过程就在 xterm 中为我们展现出来.

  另外要注意的是, :e ++enc=gbk 只是告诉 vim, 这个文件的格式是 gbk, 这样一来 vim 才能够正确的理解该文件的格式, 但是在 vim 内部对字符的处理, vim 输出到标准输出 xterm, 以及 xterm 到 X 服务程序之间的通信, 全部无一例外走的是 utf8 格式, 这是 Linux 生态传统. 我们当然可以配置 xterm 的字符格式, 也可以更改 vim 内部处理字符的方式 (这两件事我没试过, 我猜是可以的, 至少通过改它们源码一定是可以的), 但这当然是强烈不推荐的.

  也就是说, :e ++enc=gbk 之后, 只是告诉 vim, 在读入文件的时候按照 gbk 的编码来理解这些字符, 然后这每个被理解的字符在 vim 内部都会转换成对应的 utf8 编码的字符, 后续输出到标准输出 (xterm) 时输出的就是这些 utf8 字符, 接着 xterm 这边只要你没有闲的蛋疼改配置那它一定也是默认理解 utf8 字符的, xterm 会将这些字符, 字符的编码方式 (这里是 utf8), 以及采用的字体, 字号大小等信息拼成一张指令单, 告诉 X 服务程序, 让 X 服务程序按照这个指令单渲染这些字符到显示器上, X 服务程序就会解析出每个字符的 code point, 字号等信息, 然后到字库中找对应这个 code point 的 glyph, 正确的输出到显示器上.

  如果你没有 :e ++enc=gbk , vim 自然会以为文本格式就是 utf8, 按照 utf8 的编码方式来理解文本内容, 结果巧了 gbk 的编码方式被解读城 utf8 的话, code point 正好落入了 utf8 编码的乱码区, 于是这些乱码信息就被 vim 传给了 xterm 进而传给了 X 服务程序.

  上面是输出过程, 下面我们看一看输入过程.

  明白了输出过程, 输入过程就很好理解了, 你在 XIM 软件 (输入法软件) 里打字, 一般会有选字框的对吧, 选好字 (这个过程在写输入法的人口中被称作 “上屏幕”) 之后, 这些字的 code point 就被发送给 xterm, 还记得吗 Linux 生态系统 utf8 是官定编码格式, XIM 软件也是 X 客户程序之一, 所以发给 xterm 的 code point 也是 utf8 格式. xterm 收到这些 code point 之后给谁呢? 当然是经由标准输入给到了 vim, 然后后面的事情就和上面一样了: vim 将这些字符通过标准输出给回到 xterm, 进而给到 X 服务程序渲染到显示器上.

#p#分页标题#e#

  可以看到, 只要你不要闲的没事瞎折腾 X 系统的编码, 那么输入过程是很难出现乱子的, 这也是为什么你可能打开一个文件是乱码, 但是你继续在这个文件中输入内容却并不是乱码的原因:

  编译器/解释器对源代码中字符常量的处理方式

  (以下内容针对 python2)

  前面说的纯文本文件是不包含 meta 信息的, 几乎所有编程语言的源代码文件都是纯文本文件, .py 文件当然也不例外, 连 vim 这样的专业编辑器都没法知道源文件的编码格式, python 解释器肯定也是不知道的, 所以 python 也是选用了一种默认的编码方式来解释 .py 源文件, 与编辑器程序不同的是, python 默认认为源文件是 ascii 编码的, 因为程序代码一般都是英文字符嘛, 所以你如果写了这么一个 python 源文件:

  #!/usr/bin/env python

  a = '你好, 世界'

  print a

  并保存为 utf8 格式, 然后执行, 会发生下面的错误:

  $ ls

  test.py

  $ python test.py

  File “test.py”, line 3

  SyntaxError: Non-ASCII character 'xe4' in file test.py on line 3, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details

  这就是因为 python 解释器按照 ascii 的编码方式解读源文件, 结果突然读到一个字节 xe4发现这个字节并不在 ascii 范围内, 与就报错退出了. 这个过程和 vim 其实是类似的, 只不过 vim 不会报错退出, 而是 “将错就错”, 把乱码呈现给我们.

全面分析Python与Unicode_大数据_存储_数据_课课家教育

  那么如何解决这个问题呢? 很简单, 上面错误信息里已经给出了, 让我们参考 pep0263 就好了. 看过 pep0263 之后我们就知道了, 原来 python 是采用了在源文件中写明文件格式的办法, 所以我们只要在 shell-bang 下面一行加上如下内容就行了:

  #!/usr/bin/env python

  # -*- coding: utf-8 -*-

  a = '你好, 世界'

  print a

  然后再执行就能够正确输出 “你好, 世界” 了.

  误区

  经过上文, 我们应该知道要在程序源代码中使用 utf8 字符, 首先源文件顶部得有这么一行了:# -*- coding: utf-8 -* , 否则解释器直接报错.

  然后看这么一个问题, 当我们写下这么一段程序时:

  #!/usr/bin/env python

  # -*- coding: utf-8 -*-

  a = '你好, 世界'

  b = u' => hello, world'

  print a + b

  我们会得到这么一个错误:

  Traceback (most recent call last):

  File “test.py”, line 6, in

  print a + b

  UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 0: ordinal not in range(128)

  这个错误是由于没有分清 “unicode 对象” 和 “包含 unicode 序列的 str 对象” 的区别导致的. 前面我们说了, 在 python 中, str 和 unicode 都是 basestring 的子类, str 对象就相当于 C 语言的字符串类型, unicode 则相当于 C 语言中的宽字符序列.

  在上面的代码中, 虽然 a 的值是 ‘你好, 世界’, 但是 a 实际上是 str 对象, ‘你好, 世界’ 之所以能够显示出来, 是因为源文件格式是 utf8 而且编辑器和 X 服务程序也都支持 utf8 字符集. 但是变量 a 中存储的实际上是 ‘xe4xbdxa0xe5xa5xbd, xe4xb8x96xe7x95x8c’ (使用 a.encode(‘string_escape’) 或者 a.encode(‘hex_codec’) 方法查看).

  由于 b 是 unicode 类型而 a 是 str 类型, 而 python 又是强类型, 所以上面的 a + b 的时候, 所以要先对 a 做一次 decode 目的是将其转化成 unicode 对象, 然后再将它和 b 相加. 然而对 str 类型 decode 实际上是没什么意义的, decode 时所选用的 encoding 默认就是 ‘ascii’ 或者是 sys.getdefaultencoding() 的返回值, 当然这个方法的返回值默认也是 ‘ascii’. 然而采用 ‘ascii’ 去 decode a 时, 自然就会因为 a 里面包含了 xe4 这样的非 ascii 字符而导致 decode 失败报错.

#p#分页标题#e#

 这样的非 ascii 字符而导致 decode 失败报错.

  Python3 的进步

  python2 时代对 unicode 的支持问题一直广为诟病, str , unicode , encode , decode 等概念也是十分混乱, 在 python3 中这些概念的清晰度有了很大的提升.

  比如在 python3 中 str 不再相当于 C 语言中的 char * , 而是像 C 语言的宽字符类型或者 java 的 String 类型那样, 本身就是支持宽字符的类型. 而且增加还增加了 bytes 类型, bytes类型这下才是相当于 C 语言的 char * 类型. 同时取消了 str 类型的 decode 方法, 以及取消了 bytes 类型的 encode 方法.

  小知识:

  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规范没有说你的应用程序应当死于火焰。

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

  因为 decode 就是讲字节流解析成对象, encode 就是讲对象编码成字节流, 所以对 bytes 进行 encode, 和对已经表示对象的 str 进行 decode, 都是没有意义的. pyton2 时代 str 类型作为字节流类型时, 存在 str.encode(), 以及 unicode.decode 这两个方法其实都是无意义的.

结尾:大家是否了解了吗?有仔细阅读了吗?嘻嘻~再给大家补充一点小知识:在Python3我们作为开发者需要好好使用Unicode。显然,我觉得这意味着所有的文本数据都是Unicode,所有非文本数据都是字节。大家如果有什么问题和想了解更多的知识,课课家平台欢迎您的咨询哦~~

 

    关键字:

天才代写-代写联系方式