在现代Bourne Shell解释器中使用UTF-8（而不仅仅是7位ASCII子集）是安全的，不论是在注释中（例如，使用框图字符），还是通过将参数传递给函数或程序？我正在考虑文件系统是否可以在这个问题范围之外的路径名中安全地处理Unicode。
我知道至少不会在我的shell脚本中放入BOM ...因为这会破坏内核的shebang行解析。
答案 0 :(得分：3)
关于UTF-8的事情是，任何只传递字符串数据并使用终止字符串和空字节的C字符串约定的旧代码都可以正常工作。这通常表示shell如何处理命令名称和参数。
即使shell对ascii字符进行了一些具有特殊含义的字符串处理，UTF-8仍然可以正常工作，因为ascii字符在UTF-8中编码完全相同。因此，例如，shell仍然能够识别其所有关键字和语法字符，如[]{}()<>/.?;'"$&*等。这表示应该如何处理脚本的字符串文字和其他语法位，例如。
您应该能够在注释，字符串文字，命令名称和命令参数中使用UTF-8。 （当然系统必须支持UTF-8文件名才能使用UTF-8命令，并且命令必须处理UTF-8命令行参数。）
您可能无法在函数名称或变量中使用UTF-8，因为shell可能在那里查找ascii字符串。虽然如果您的语言环境是UTF-8，那么在内部使用基于语言环境的字符分类函数的解释器也可以使用UTF-8标识符，但它可能不是可移植的。
答案 1 :(得分：2)
这实际上取决于你要做的事情......一般来说，普通的Bourne派生的shell无法处理脚本中的 字符串，这意味着你的脚本文本必须是纯粹的8位ASCII（+）如果您关心可移植性。同时，管道完全编码为中性，因此您可以使用a | b之类的内容，a输出UTF-8，b接收它。因此，假设find能够处理UTF-8路径并且您的处理工具可以使用UTF-8字符串，那么您应该没问题。
答案 2 :(得分：0)
1989年，Bourne Shell增加了多字节支持，鉴于UNICODE于1992年推出，你不能指望UTF-8来自比UNICODE更旧的外壳。 SunOS在可用时引入了UNICODE支持。
因此，从SVr4 Bourne Shell派生并编译并链接到现代库环境的任何Bourne Shell都应该在脚本中支持UTF-8。
如果您想验证这一点，您可以从schily-tools中的OpenSolaris Bourne Shell获取可移植版本：http://sourceforge.net/projects/schilytools/files/
osh是原始的Bourne Shell仅可移植。
sh是具有现代增强功能的Bourne Shell。