我有一个 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，这对我来说听起来有点像浏览器约定...
非常感谢您的高度赞赏的帮助！
编辑：感谢sideshowbarker的回答，我找到了一种解决方法，通过在内容前面添加两个BOM，这样在浏览器删除第一个BOM后，就会剩下一个BOM。
解决方法（来自评论）：由于仅读取前三个字节，因此您可以在源前面添加两个 BOM，这将导致下载的文件为带有 BOM 的有效 UTF-8。
具体就 Excel 而言：根据 https://stackoverflow.com/a/16766198/1143392 的答案，较新版本的 Excel（来自 Office 365）现在支持 UTF-8。
就问题中描述的行为原因而言：原因是，相关规范要求去掉BOM，而浏览器就是这样做的。即浏览器符合编码规范中的UTF-8解码算法的要求，就是这样的：
要对字节流 stream 进行 UTF-8 解码，请运行以下步骤：
令 buffer 为空字节序列。
从stream读取三个字节到buffer。
如果 buffer 与 0xEF 0xBB 0xBF 不匹配，请将 buffer 添加到 stream。
令 output 为代码点流。
使用 stream 和 output 运行 UTF-8 解码器。
返回输出。
第 3 步导致 BOM 被剥离。
考虑到编码规范的要求，我认为没有办法告诉浏览器保留 BOM。
还有另一种解决方法：如果将 mime 类型更改为
application/octet-streamtext/csv