文件编码中 BOM 标记的对齐方式 [关闭]

Question

我想确信，出于以下原因，绝对需要对文件使用 BOM 标记进行文件编码。

• 文件的信息必须是自包含的。我们没有找到一个明确的算法来确定哪种编码适合文件。
• 对于 shebang 行的兼容性问题，这个问题需要在脚本语言内部进行纠正，因为编码比 shebang 行更高的概念。

对于第一个声明，我很难确定哪种编码适合或不适合文件。因此，对文件应用不同的编码时常出现，我想大多数新开发者都会遇到这种情况，并且由于编码策略不同而忽略了文件中的怪异字符。

我已经认识到兼容性是软件维护的一个重要方面。但是，我认为让系统混乱的旧规则在以后的步骤中有所改变。

是否有任何想法或任何动作将添加BOM标记作为官方？或者有什么重要的理由不能引入 BOM 标记？ （例如，存在识别编码文件的清晰算法。）

我的理解来自下面的链接，所以额外的链接来改变我的观点将是一个很大的乐趣。

• What's the difference between UTF-8 and UTF-8 without BOM?

谢谢，

Answer 1

你的第一个假设是错误的。我们有协议来定义文件（或数据包）包含的内容以及如何解释包含的内容。我们应该始终将元数据与数据分开。您实际上是在推动将 BOM 作为描述以下字节的元数据，但这还不够。文本数据并不是那么有用的信息：我们仍然需要理解和解释它是什么意思的文本数据。更明显的部分是将 U+0020（空白）解释为 打印字符 或 控制数据。 HTML 解释为第二个（两个空格不是那么特殊，或者一个空格和一个新行，但在<pre> 中）。而且：我们有邮件、邮箱、markdown 文件、HTML 等。BOM 不能单独提供帮助。但是，对于您的第一点，我们需要添加更多信息，等等。但是我们有一个通用的容器格式（元数据，带有一个或多个数据），所以它不是更多的文本，也不是 BOM 对我们有帮助。

如果你需要BOM，你已经输了，你可以拥有一个BOM，它不是真正的BOM，而是其他编码的真实数据。使用 2 个字节或 3 个字节是不够的（shebang，它是旧的，使用了 4 个字节，#! /，现在不再需要空间，但无论如何它是一个旧协议，当文件没有大量交换时，并且路径是相关的（没有人执行随机文件，如果不是 shebang，它就是一个 a.out 文件）。

你正在讨论一个旧的东西。现在一切都是 UTF-8。无需BOM。微软只是让事情变得更复杂：Unix、Linux、macos 做了一个短暂的过渡，没有太大的伤害（也没有“标志日”）。还有网络：默认情况下是 UTF-8。您的问题是关于编程语言的，但是 UTF-8 很好：它们在语法中使用 ASCII，而字符串中的内容并不重要：将字符串和 Unicode 视为不透明对象是标准的，但对于少数情况下，否则您会错过 Unicode 中的某些内容（例如，拆分组合字符、拆分表情符号，例如使用 UTF16 代码单元的语言等）。

UTF-16 不是你会写程序的东西。它可能被 API 使用（固定长度可能/看起来更好），或者 ev。用于数据，但通常不用于编码。

如果您不修改所有脚本/程序，BOM 也无济于事（但是，让我们将其作为“全部为 UTF-8”）：在多种编码中找到程序源的情况并不罕见（并且在同一个文件上）：您可能已经使用简单的编辑器（并且使用一种编码）复制粘贴了版权（以及作者姓名），然后字符串可能使用其他编码，并且很少有 cmets（和提交者姓名）可能在不同的。而 git（和其他工具）只是检查行，因此它可能会插入编码错误的行：git 的信息很少，用户经常有错误的配置。因此，您可能会破坏可以正常运行的来源（只是因为编码问题只是在 cmets 中）。

然后是对第二个假设的简短评论，这也是困难。

您想拆分图层，但这很成问题：我们的脚本末尾包含二进制数据，因此操作系统不应尝试对脚本进行转码（然后删除 BOM），因为第一部分可能是只是文本，但某些部分可能需要准确的正确字节。 （而且有些Unicode测试文件也属于这一类，而且是文本，可能带有一些无效代码）。

只需使用没有 BOM 的 UTF-8，一切都会变得简单得多。