附加到末尾时，python utf-8-sig BOM 位于文件中间

我最近注意到 Python 在使用以下命令附加到文件时的行为方式并不明显utf-8-sig编码。见下文：

>>> import codecs, os
>>> os.path.isfile('123')
False
>>> codecs.open('123', 'a', encoding='utf-8-sig').write('123\n')
>>> codecs.open('123', 'a', encoding='utf-8-sig').write('123\n')

文件中包含以下文本：

<BOM>123
<BOM>123

这不是一个错误吗？这太不符合逻辑了。 谁能向我解释为什么这样做？ 为什么他们不设法仅在文件不存在且需要创建时才添加 BOM？

不，这不是错误；而是错误。这是完全正常的、预期的行为。编解码器无法检测文件中已经写入了多少内容；你可以用它来附加到预先创建的但是empty例如文件。该文件不是新文件，但也不包含 BOM。

还有其他用例，其中编解码器用于流或字节串（例如，不与codecs.open()）哪里有根本没有文件进行测试，或者开发人员想要在输出开始时强制执行 BOM。

仅使用utf-8-sig on a new文件;编解码器将always每次使用时都将 BOM 写出来。

如果您直接使用文件，您可以自己开始测试；使用utf-8相反，手动编写 BOM，这只是一个编码的U+FEFF 零宽度不间断空格:

import io

with io.open(filename, 'a', encoding='utf8') as outfh:
    if outfh.tell() == 0:
        # start of file
        outfh.write(u'\ufeff')

我用的是较新的io.open()代替codecs.open(); io是为 Python 3 开发的新 I/O 框架，比codecs根据我的经验，用于处理编码文件。

请注意，UTF-8 BOM 确实几乎毫无用处。 UTF-8没有可变字节顺序，所以只有one字节顺序标记。另一方面，UTF-16 或 UTF-32 可以使用两种不同的字节顺序之一编写，这就是需要 BOM 的原因。

UTF-8 BOM 主要由 Microsoft 产品用来自动检测文件的编码（例如not遗留代码页之一）。