我有一个 JAX-RS REST-Service，它生成 CSV 文件并将其流回浏览器。一切都设置为 UTF-8，所以我通过浏览器下载的文件也是一个有效的 UTF-8 文件（没有 BOM），它在 Notepad++、Sublime 等中向我显示有效、可读的 UTF-8 变音符号等。
在 Excel 中打开这样的文件会导致不可读的元音变音等，因为 Excel 显然尝试使用另一个字符集（我猜是 CP-1252，但这并不重要）打开它。
通过 Notepad++ 保存带有 BOM 的文件并在 Excel 中重新打开它效果很好。似乎 BOM 检测是 Excel 用于检测 UTF-8 的唯一方法。无论如何 - 我认为添加 BOM 可以有所帮助......
做过某事。相同的结果。一段时间后，我发现 BOM 在某些情况下会被删除：如果我在 BOM 之前添加任何字符，我可以在我的十六进制编辑器中看到 BOM。删除该字符后，BOM 将不再存在。
当我继续通过 cURL 下载该文件时，我真的很惊讶。 BOM 就在那里！在此之前，我认为这可能与我的应用程序、内容类型、编码、HTTP 标头等有关 - 但所有这些似乎都很好。
现在，经过几个小时的尝试不同的事情后，我对如何告诉浏览器保留 BOM 有什么想法吗？我可以设置任何 HTTP 标头吗？由于 Chrome、Internet Explorer、Edge、Firefox 都删除了 BOM，这对我来说听起来有点像浏览器约定......
非常感谢您的高度赞赏的帮助！
EDIT:感谢 sideshowbarker 的回答，我找到了一种解决方法，即在内容前面添加两个 BOM，这样在浏览器删除第一个 BOM 后，还会剩下一个 BOM。
解决方法（来自注释）：由于仅读取前三个字节，因此您可以在源中添加两个 BOM，这将导致下载的文件为带有 BOM 的有效 UTF-8 文件。
具体就 Excel 而言：根据答案https://stackoverflow.com/a/16766198/1143392，较新版本的 Excel（来自 Office 365）现在支持 UTF-8。
至于问题中描述的行为原因：原因是，相关规范要求删除 BOM，而这就是浏览器所做的。也就是说，浏览器符合以下要求编码规范中的 UTF-8 解码算法，就是这样：
对字节流进行 UTF-8 解码stream，运行以下步骤：
-
Let buffer是一个空字节序列。
-
从中读取三个字节stream into buffer.
-
If buffer与 0xEF 0xBB 0xBF 不匹配，前置buffer to stream.
-
Let output是一个码点流。
-
运行 UTF-8 解码器stream and output.
-
Return output.
步骤 3 导致 BOM 被剥离。
鉴于编码规范的要求，我认为没有办法告诉浏览器保留 BOM。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
