【问题标题】:Is the Unicode Byte Order Mark allowed at the start of a UNIX script file?UNIX 脚本文件的开头是否允许使用 Unicode 字节顺序标记?
【发布时间】:2016-01-02 14:30:37
【问题描述】:

可执行文件开头的#! 告诉 Unix/Linux shell 将该文件视为脚本,并且该脚本的解释器路径紧跟在 #! 之后。

Unicode 字节顺序标记出现在此类脚本文件的开头 #! 之前是否合法?

我了解脚本将被传递到的特定解释器需要理解字节顺序标记并正确处理它。我的问题是#! 部分是否仍被认为位于文件的开头?

当然,我可以出去测试特定操作系统上的特定 shell 的作用,但我对一个更普遍的问题感兴趣,即这是否合法。如果有人可以链接或指向一个很棒的文档!

【问题讨论】:

  • 如果你在文件开头放了一个 BOM,内核将无法识别#! shebang。此外,BOM 没有任何意义。如果文件是 UTF-8,则 BOM 毫无意义,而且我知道没有任何内核可以使用 UTF-16(或 UTF-32)作为 Unicode 表示,而那些是 BOM 可能相关的地方。所以,总而言之——不要在 Unix 上将 BOM 放在文件的开头;它不会有帮助,而且可能会阻碍事情。
  • 谢谢你,乔纳森。 BOM 将有利于最终运行脚本的解释器。
  • 如果脚本文件中的数据确实是UTF-16(UTF-16LE或UTF-16BE),那么BOM可以出现在开头,可以通知脚本的解释器,但是内核不会为您启动解释器;您应该使用interpreter script.name 而不是只输入script.name(而且您可能还必须处理脚本的路径位置)。这很好,只要你认识到这就是会发生的事情。如果您只想运行 script.name,则文件必须以 #! 开头,这排除了 BOM 作为替代开始。

标签: linux unix unicode byte-order-mark


【解决方案1】:

将 cmets 转换为答案。

如果您将 BOM 放在文件的开头,内核将无法识别 #! shebang。此外,BOM 没有任何意义。如果文件是 UTF-8,则 BOM 毫无意义,而且我知道没有内核可以使用 UTF-16(或 UTF-32)作为 Unicode 表示,而这些编码可能与 BOM 相关。所以,总而言之——不要在 Unix 上将 BOM 放在文件的开头;这无济于事,而且可能会阻碍事情的发展。

BOM 将有利于最终运行脚本的解释器。

如果脚本文件中的数据确实是 UTF-16(UTF-16LE 或 UTF-16BE),那么 BOM 可以出现在开始并可以通知脚本的解释器,但内核不会启动为您翻译;你会用的:

interpreter script.name

而不仅仅是打字

script.name

(您可能还必须处理脚本的路径位置)。这很好,只要你认识到这就是会发生的事情。如果您只想运行 script.name,则文件必须以 #! 开头,这排除了 BOM 作为替代开始。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2010-09-17
    • 2016-05-10
    • 2014-07-08
    • 1970-01-01
    • 2017-04-16
    • 2015-07-07
    • 2010-11-05
    • 1970-01-01
    相关资源
    最近更新 更多