Python 防止自动将BOM添加到bytearray

这件事让我毛骨悚然

我有一张便条：

output = bytearray()

我有一个memoryview，映射在从文件读取的bytearray上：

ba = bytearray(os.path.getsize(filename))
with open(filename, 'rb') as fin:
    fin.readinto(ba)
mv = memoryview(ba)

现在，我这样做：

output += mv[pos:pos + length]

但是。。。这会在bytearray的开头添加一个3字节的BOM表

我已经尝试了我能想到的一切，例如，

output=bytearray（“”，encoding='cp437'）

，但那该死的BOM表仍然出现

---

我怎么能阻止自动添加BOM表呢

好的，首先，我想向所有参与这场追逐的人道歉。这个错误是我的，而不是Python的

让我解释一下：

我们有两个目录，

STAGING

和

DEV

。前者表示运行良好的代码（并且适合移交给QA），后者包含开发中的代码，可能有bug。只有通过一系列测试后，代码才会从开发人员“毕业”到登台

STAGING中的代码使用了我在对问题的评论中提到的

io.BytesIO

机制。DEV中的代码将BytesIO替换为

bytearray

团队中有人无意中替换了一对测试文件，我们称它们为

testinput

和

testreference

。因此，我们现在有两对测试文件：

STAGING/test input

，

STAGING/test reference

，

DEV/test input

，以及

DEV/test reference

现在，错误喜剧开始了

暂存中的

test-

对是纯二进制文件。当@user2357112在上面的评论中询问时，我正在检查STAGING中的

test-

文件。所以，没有物料清单

但是，DEV中的

测试-

对是完全不同的。输入是二进制的，但输出是XML。团队成员使用第三方工具提取XML文件，该工具剥离了BOM表

当我在STAGING和DEV之间发现

test-

文件对的大小不同时，我发现了这一点

因此，我劫持了STAGING中经过验证的正确函数，以正确地解压缩

DEV\test输入

文件。。。你知道什么！它有BOM

（为了保护团队成员，较新的

test-

文件对更大，大约是“原始”

test-

文件对的3倍，因此最好抓住边缘案例）

---

由于这个愚蠢的错误>，我们损失了一天的生产效率。听起来这个文件的开头有一个BOM表，Python正在正确地从文件中读取BOM表。不。二进制文件以\x50\xFB开头。在[pos]的位置，其值为\x01。我看不到BOM表。您如何知道BOM表正在添加到

输出+=mv[pos:pos+length]

中的bytearray，以及如何知道文件没有BOM表？您是否已经确定了您的程序在什么时候从任何数据结构中都没有BOM表变成在某个地方有BOM表？您能否显示产生错误的最小脚本和文件？在比较处理后输出的总长度时，我注意到这种行为，长度比引用长3字节。通过迭代检查前3个字节得到了\xEF\xBB\xBF。遗憾的是，我已经将代码还原为使用BytesIO，而BytesIO并没有表现出这种令人恼火的行为。我投票将这个问题作为离题来结束，因为尽管这个问题是可再现的，但它是由外部因素造成的（在本例中，是用于测试的错误参考文件）。这是我的错误，所以请结束这个问题，以防止其他人在这个问题上浪费时间。