在最近的question中，有人注意到OSX在非ascii文件上运行sed会产生奇怪的结果。例如，如果你这样做（/ usr / bin / cal是一个随机二进制文件）
sed 's/[^A-Z]//' /usr/bin/cal
sed将删除除A-Z以外的所有可打印字符，但仍保留许多不可打印的字符。但是，如果你做了
LANG='' sed 's/[^A-Z]//' /usr/bin/cal
仅输出A-Z（和换行符）。为什么呢？
通常LANG=en-US.UTF-8发生了什么事？无论如何，我无法看到在UTF-8中可以认为sed的输出是正确的。它是否破碎，或者是否存在一些我不理解的工作概念？
我知道OSX sed符合POSIX，因此与心爱的GNU sed不同。
答案 0 :(得分：3)
二进制数据，例如/ usr / bin / cal的内容，不是UTF-8，因此会混淆任何读取它的代码，就像它一样。具体地，具有高位设置（例如，> = 128）的任何字节将被解释为表示单个字符的多字节序列的一部分，并且因此将从输出中省略。并非所有具有高位设置的字节序列都是有效的UTF-8，因此事情会变得非常混乱，但这可能解释了为什么某些不可打印的字符仍然存在但（可能）不存在其他字符。
简而言之：如果您想在二进制数据上使用面向文本的工具，请不要。