linux - UNIX 脚本文件的开头是否允许使用 Unicode 字节顺序标记?

标签 linux unix unicode byte-order-mark

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

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

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

当然,我可以出去测试特定操作系统上的特定 shell 的功能,但我对更一般的问题感兴趣,即这是否合法。如果有人可以链接或指向一份文档,那就太棒了!

最佳答案

将评论转化为答案。

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

The BOM would be for the benefit of the interpreter that eventually runs the script.

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

interpreter script.name

不仅仅是打字

script.name

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

关于linux - UNIX 脚本文件的开头是否允许使用 Unicode 字节顺序标记?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/34566980/

相关文章:

delphi - 编码非常大的文件时如何解决此 EOutOfMemory 异常?

java - 从文件中删除重复行

C-传递参数以在新的 Xterm 窗口中执行程序

PHP-ODBC 驱动程序安装问题

r - 为什么h2o.saveModel卡在R v3.3.2和H2O v3.10.4.2中

linux - 查看列表中出现的每个文件名的文件内容

C99 标准 - fprintf - s 精确转换

perl - SPLIT 1000 文件限制的解决方法?

database - 如何使用 AWK 附加文本

Perl 新手初体验 Unicode(在文件名、-e 运算符、打开运算符和 cmd 窗口中)