在代码审查中，我遇到了以下代码:
# Python bug that renders the unicode identifier (0xEF 0xBB 0xBF)
# as a character.
# If untreated, it can prevent the page from validating or rendering
# properly.
bom = unicode( codecs.BOM_UTF8, "utf8" )
r = r.replace(bom, '')
这是在将字符串传递给Response对象(Django或Flask)的函数中。
这仍然是需要在python 2.7或3中进行此修复的bug吗？有人告诉我不是，但是我想问一下，因为我不太清楚这个问题。
我不确定这是从哪里来的，但是我已经在Internet上看到了它，有时与Jinja2(我们正在使用)一起引用。
谢谢阅读。
最佳答案
字符\ufeff的Unicode standard states具有两个不同的含义。在数据流开始时，应将其用作字节顺序和/或编码签名，但在其他地方，应将其解释为零宽度的不间断空间。
所以代码
bom = unicode(codecs.BOM_UTF8, "utf8" )
r = r.replace(bom, '')
不仅删除了utf-8编码签名(又名BOM)，还删除了任何嵌入式零宽度不间断空格。
某些早期的python版本没有“utf-8”编解码器的变体，该变体在读取数据流时会跳过BOM。由于这与其他其他unicode编解码器不一致，因此version 2.5引入了“utf-8-sig”编解码器，它确实跳过了BOM。
因此，代码注释中提到的“Python错误”可能与此有关。
但是，“错误”似乎更可能与嵌入的
\ufeff字符有关。但是，由于Unicode标准明确规定可以将它们解释为合法字符，因此，数据消费者实际上要决定如何对待它们-因此，这不是python中的错误。