Unicode — Werkzeug 文档
统一码
Werkzeug 在内部使用字符串,无论在何处假定文本数据,即使 HTTP 标准不支持 Unicode。 基本上所有传入的数据都是从字符集(默认为 UTF-8)解码的,因此您不能直接使用字节。 传出数据被编码到目标字符集中。
Python 中的 Unicode
假设您有德国元音变音 ö
。 在 ASCII 中你不能表示那个字符,但在 latin-1
和 utf-8
字符集中你可以表示它,但它们在编码时看起来不同:
ö
看起来不同取决于编码,这使得它很难作为字节使用。 相反,Python 将字符串视为 Unicode 文本,并以特定编码存储信息 LATIN SMALL LETTER O WITH DIAERESIS
而不是 ö
的字节。 具有 1 个字符的字符串的长度将为 1,其中字节的长度可能是其他值。
HTTP 中的 Unicode
但是,HTTP 规范是在 ASCII 字节是表示数据的常用方式的时代编写的。 为了在现代网络中解决这个问题,Werkzeug 自动解码和编码传入和传出的数据。 从浏览器发送到 Web 应用程序的数据从 UTF-8 字节解码为字符串。 从应用程序发送回浏览器的数据被编码回 UTF-8。
错误处理
执行内部编码或解码的函数接受传递给 str.decode()
和 str.encode()
的 errors
关键字参数。 默认值为 'replace'
,以便于发现错误。 将其设置为 'strict'
以捕获错误并向客户端报告错误数据可能很有用。
请求和响应对象
在大多数情况下,您应该坚持使用 Werkzeug 的默认 UTF-8 编码。 如果您有特定原因,您可以将 wrappers.Request
和 wrappers.Response
子类化以更改编码和错误处理。
只能针对请求更改错误处理。 在响应中编码为字节时,Werkzeug 将始终引发错误。 您有责任不创建目标字符集中不存在的数据。 这对于 UTF-8 来说不是问题。
文件系统
在 0.11 版中更改。
一些针对 Werkzeug 的错误报告表明,在传统 UNIX 系统下不能信任 sys.getfilesystemencoding()
的值。 通常发生这种情况是由于系统配置错误,其中未设置 LANG
和类似的环境变量。 在这种情况下,Python 默认使用 ASCII 作为文件系统编码,这是一个非常保守的默认值,通常是错误的,并且会导致比它避免的更多的问题。
如果 Werkzeug 检测到它在错误配置的环境中运行,它将假定文件系统编码为 UTF-8
并发出警告。