附加到结尾时文件中间的python utf-8-sig BOM

ast*_*aut 7 python byte-order-mark utf-8

我最近注意到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')
Run Code Online (Sandbox Code Playgroud)

以下文本以文件结尾:

<BOM>123
<BOM>123
Run Code Online (Sandbox Code Playgroud)

这不是一个bug吗?这是不合逻辑的.任何人都可以向我解释为什么会这样做?为什么不在文件不存在且需要创建时才设置BOM?

Mar*_*ers 9

不,这不是一个bug; 这是完全正常的,预期的行为.编解码器无法检测已经写入文件的数量; 例如,您可以使用它附加到预先创建但空的文件.该文件不是新文件,但也不包含BOM.

然后还有其他用例,其中编解码器用于流或字节串(例如,没有codecs.open()),其中根本没有文件要测试,或者开发人员想要在输出开始时强制执行BOM.

只使用utf-8-sig一个新的文件; 编解码器将始终在您使用时写出BOM.

如果您直接使用文件,您可以自己测试一下; utf-8改为使用并手动编写BOM,这只是一个编码的U + FEFF ZERO WIDTH NO-BREAK SPACE:

import io

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

我用的是新的io.open()而不是codecs.open(); io是根据codecs我的经验,为Python 3开发的新I/O框架,并且比处理编码文件更强大.

请注意,UTF-8 BOM实际上是无用的.UTF-8 没有可变字节顺序,因此只有一个字节顺序标记.另一方面,UTF-16或UTF-32可以用两个不同的字节顺序之一写入,这就是需要BOM的原因.

Microsoft产品主要使用UTF-8 BOM来自动检测文件的编码(例如,不是遗留代码页之一).