BOM标记在文件编码中的合理性
Justification of BOM mark in file encoding
我想确信使用 BOM 标记进行文件编码对于文件来说是绝对必要的，原因如下。
- 一个文件的信息必须是独立的。我们没有想出一个明确的算法来识别哪种编码适合文件。
- 关于 shebang 行的兼容性问题，这个问题需要在脚本语言内部修正，因为编码比 shebang 行更高级的概念。
对于第一个声明，我很难确定文件的编码正确与否。因此，对一个文件应用不同编码的情况经常出现，我猜大部分新手开发者都遇到过这种情况，并且由于不同的编码策略而忽略了文件中的奇怪字符。
我已经认识到兼容性是软件维护的一个重要方面。但是，我认为让系统混淆的旧规则已更改以供将来使用。
是否有任何想法或行动将添加 BOM 标记视为正式？还是有什么关键原因不能引入BOM标记？ （例如，存在识别编码文件的明确算法。）
我的理解来自于下面的link，所以补充link来改变我的观点将是一件非常愉快的事情。
- What's the difference between UTF-8 and UTF-8 without BOM?
谢谢，
你的第一个假设是错误的。我们有协议来定义文件（或数据包）包含什么以及如何解释包含的内容。我们应该始终将元数据与数据分开。您实际上是在推动将 BOM 作为元数据，它描述了以下字节，但这还不够。文本数据并不是那么有用的信息：我们仍然需要理解和解释文本数据的含义。更明显的部分是关于将 U+0020（白色 space）解释为 印刷字符 或 控制数据 。 HTML解释为第二个（两个白色space并没有那么特别，或者一个白色space和一个新行，但是在<pre>中）。而且：我们有一封邮件、一个邮箱、一个 markdown 文件、一个 HTML 等。单独使用 BOM 是无济于事的。但是，对于你的第一点，我们需要添加更多信息，等等。但是后来我们有一个通用的容器格式（元数据，有一个或多个数据），所以不是更多的文本，也不是BOM帮助我们。
如果你需要BOM，你已经输了，你可以有一个BOM，它不是真正的BOM，而是其他编码的真实数据。使用 2 个字节或 3 个字节是不够的（shebang，它是旧的，使用 4 个字节，#! /，现在不再需要 space，但无论如何它是一个旧协议，当文件没有大量交换，路径是相关的（没有人执行随机文件，如果不是 shebang，它是一个 a.out 文件）。
而且你在讨论一个老东西。现在一切都是UTF-8。无需 BOM。 Microsoft 只是让事情变得更复杂：Unix、Linux、macos 进行了短暂的过渡，没有造成太大伤害（也没有“卖旗日”）。还有 web: 默认是 UTF-8。您的问题是关于编程语言的，但是 UTF-8 很好：它们在语法中使用 ASCII，而它在字符串中是什么并不重要：将字符串和 Unicode 视为不透明对象是标准的，但对于少数在某些情况下，否则您会错过 Unicode 中的某些内容（例如拆分组合字符、拆分表情符号，例如使用与 UTF16 代码单元一起使用的语言等）。
UTF-16 不是你编写程序的一回事。它可能被 API（固定长度可能 be/seem 更好）或 ev 使用。用于数据，但通常不用于编码。
BOM 也没有用，如果你不修改所有 scripts/programs（但是，让我们把它当作“全部是 UTF-8”）：在中找到程序源并不少见多重编码（并且在同一个文件上）：您可能已经使用简单的编辑器（以及一种编码）复制粘贴了版权（以及作者姓名），然后字符串可能使用其他编码，并且很少有评论（和提交者姓名) 也许在不同的。而 git （和其他工具）只是检查行，因此它可能会插入编码错误的行： git 的信息很少，用户经常有错误的配置。所以你可能会破坏源代码（只是因为编码问题只是在评论中）。
然后对第二个假设做一个简短的评论，这也是困难。
你想拆分层，但这很成问题：我们的脚本最后包含二进制数据，所以操作系统不应该尝试对脚本进行转码（然后删除 BOM），因为第一部分可能只是文本，但某些部分可能需要准确的正确字节。 （还有一些Unicode测试文件也属于这一类，而且是文本，可能带有一些无效代码）。
只要使用没有 BOM 的 UTF-8，一切都会变得简单得多。
我想确信使用 BOM 标记进行文件编码对于文件来说是绝对必要的，原因如下。
- 一个文件的信息必须是独立的。我们没有想出一个明确的算法来识别哪种编码适合文件。
- 关于 shebang 行的兼容性问题，这个问题需要在脚本语言内部修正，因为编码比 shebang 行更高级的概念。
对于第一个声明，我很难确定文件的编码正确与否。因此，对一个文件应用不同编码的情况经常出现，我猜大部分新手开发者都遇到过这种情况，并且由于不同的编码策略而忽略了文件中的奇怪字符。
我已经认识到兼容性是软件维护的一个重要方面。但是，我认为让系统混淆的旧规则已更改以供将来使用。
是否有任何想法或行动将添加 BOM 标记视为正式？还是有什么关键原因不能引入BOM标记？ （例如，存在识别编码文件的明确算法。）
我的理解来自于下面的link，所以补充link来改变我的观点将是一件非常愉快的事情。
- What's the difference between UTF-8 and UTF-8 without BOM?
谢谢，
你的第一个假设是错误的。我们有协议来定义文件（或数据包）包含什么以及如何解释包含的内容。我们应该始终将元数据与数据分开。您实际上是在推动将 BOM 作为元数据，它描述了以下字节，但这还不够。文本数据并不是那么有用的信息：我们仍然需要理解和解释文本数据的含义。更明显的部分是关于将 U+0020（白色 space）解释为 印刷字符 或 控制数据 。 HTML解释为第二个（两个白色space并没有那么特别，或者一个白色space和一个新行，但是在<pre>中）。而且：我们有一封邮件、一个邮箱、一个 markdown 文件、一个 HTML 等。单独使用 BOM 是无济于事的。但是，对于你的第一点，我们需要添加更多信息，等等。但是后来我们有一个通用的容器格式（元数据，有一个或多个数据），所以不是更多的文本，也不是BOM帮助我们。
如果你需要BOM，你已经输了，你可以有一个BOM，它不是真正的BOM，而是其他编码的真实数据。使用 2 个字节或 3 个字节是不够的（shebang，它是旧的，使用 4 个字节，#! /，现在不再需要 space，但无论如何它是一个旧协议，当文件没有大量交换，路径是相关的（没有人执行随机文件，如果不是 shebang，它是一个 a.out 文件）。
而且你在讨论一个老东西。现在一切都是UTF-8。无需 BOM。 Microsoft 只是让事情变得更复杂：Unix、Linux、macos 进行了短暂的过渡，没有造成太大伤害（也没有“卖旗日”）。还有 web: 默认是 UTF-8。您的问题是关于编程语言的，但是 UTF-8 很好：它们在语法中使用 ASCII，而它在字符串中是什么并不重要：将字符串和 Unicode 视为不透明对象是标准的，但对于少数在某些情况下，否则您会错过 Unicode 中的某些内容（例如拆分组合字符、拆分表情符号，例如使用与 UTF16 代码单元一起使用的语言等）。
UTF-16 不是你编写程序的一回事。它可能被 API（固定长度可能 be/seem 更好）或 ev 使用。用于数据，但通常不用于编码。
BOM 也没有用，如果你不修改所有 scripts/programs（但是，让我们把它当作“全部是 UTF-8”）：在中找到程序源并不少见多重编码（并且在同一个文件上）：您可能已经使用简单的编辑器（以及一种编码）复制粘贴了版权（以及作者姓名），然后字符串可能使用其他编码，并且很少有评论（和提交者姓名) 也许在不同的。而 git （和其他工具）只是检查行，因此它可能会插入编码错误的行： git 的信息很少，用户经常有错误的配置。所以你可能会破坏源代码（只是因为编码问题只是在评论中）。
然后对第二个假设做一个简短的评论，这也是困难。
你想拆分层，但这很成问题：我们的脚本最后包含二进制数据，所以操作系统不应该尝试对脚本进行转码（然后删除 BOM），因为第一部分可能只是文本，但某些部分可能需要准确的正确字节。 （还有一些Unicode测试文件也属于这一类，而且是文本，可能带有一些无效代码）。
只要使用没有 BOM 的 UTF-8，一切都会变得简单得多。