[po] auto sync bot

zhsj · zhsj · commit b667b5a67559 · 2019-08-05T12:14:21.000+08:00
diff --git a/library/codecs.po b/library/codecs.po
@@ -1336,6 +1336,19 @@ msgid ""
 "sequence has been decoded into a string; as a ``ZERO WIDTH NO-BREAK SPACE`` "
 "it's a normal character that will be decoded like any other."
 msgstr ""
+"所有这些编码格式只能对 Unicode 所定义的 1114112 个码位中的 256 个进行编码。 一种能够存储每个 Unicode "
+"码位的简单而直接的办法就是将每个码位存储为四个连续的字节。 存在两种不同的可能性：以大端序存储或以小端序存储。 这两种编码格式分别被称为 "
+"``UTF-32-BE`` 和 ``UTF-32-LE``。 它们的缺点可以举例说明：如果你在一台小端序的机器上使用 ``UTF-32-BE`` "
+"则你将必须在编码和解码时翻转字节。 ``UTF-32`` 避免了这个问题：字节的排列将总是使用自然顺序。 当这些字节被具有不同字节顺序的 CPU "
+"读取时，则必须进行字节翻转。 为了能够检测 ``UTF-16`` 或 ``UTF-32`` 字节序列的大小端序，可以使用所谓的 BOM "
+"(\"字节顺序标记\")。 这对应于 Unicode 字符 ``U+FEFF``。 此字符可添加到每个 ``UTF-16`` 或 ``UTF-32`` "
+"字节序列的开头。 此字符的字节翻转版本 (``0xFFFE``) 是一个不可出现于 Unicode 文本中的非法字符。 因此当发现一个 "
+"``UTF-16`` 或 ``UTF-32`` 字节序列的首个字符是 ``U+FFFE`` 时，就必须在解码时进行字节翻转。 不幸的是字符 "
+"``U+FEFF`` 还有第二个含义 ``ZERO WIDTH NO-BREAK SPACE``: 即宽度为零并且不允许用来拆分单词的字符。 "
+"它可以被用来为语言分析算法提供提示。 在 Unicode 4.0 中用 ``U+FEFF`` 表示 ``ZERO WIDTH NO-BREAK "
+"SPACE`` 已被弃用（改用 ``U+2060`` (``WORD JOINER``) 负责此任务）。  然而 Unicode 软件仍然必须能够处理 "
+"``U+FEFF`` 的两个含义：作为 BOM 它被用来确定已编码字节的存储布局，并在字节序列被解码为字符串后将其去除；作为 ``ZERO WIDTH "
+"NO-BREAK SPACE`` 它是一个普通字符，将像其他字符一样被解码。"
 
 #: ../../library/codecs.rst:919
 msgid ""
