☰

为什么命令行 cat 与 BBEdit 不同？

tag-icon • tag-icon command-line audio notepad++
为什么命令行 cat 与 BBEdit 不同？

在电影行业中，WAV 音频文件在 iXML RIFF 块中包含元数据是很常见的。读取此元数据的一种简单方法是在文本编辑器中打开 WAV 文件，例如 BBEdit 或 Notepad++ 甚至 TextEdit。但使用命令行cat或tail它不起作用，我只看到乱码。我使用的是 macOS 10.13，如果有问题的话。为什么cat与这些文本编辑应用程序不同？

这是一个示例文件，其中 iXML 位于底部：http://www.gallery.co.uk/ixml/examples/usesEntireiXMLSpec.WAV

答案1

输出文件时cat，它会按原样逐字节输出，而不会替换空格或点或其他类型的替换字符。因此，当它在 .WAV 文件中较早地输出二进制音频样本数据时，其中一些字节恰好与旧式终端控制代码和“转义序列”（以“ESC”字符开头的字节序列，可用于执行诸如更改文本或背景颜色、清除终端屏幕以及在终端屏幕内重新定位光标等操作）相匹配。您的终端仿真器（Terminal.app 或 iTerm2 或其他）会尝试遵守这些控制代码和转义序列，这会破坏它通常显示文本的方式，并且以不可预测的方式进行。

许多基于终端的工具都有一些选项，可让您处理包含一些二进制数据和纯可打印 ASCII 文本的文件。例如，有cat一个-v选项可使其用可打印序列代替 ASCII 控制字符。还有vis(1)、、等。您还可以使用od(1)、和等工具尝试从文件中的二进制数据中提取 ASCII XML 数据。hexdump(1)strings(1)sed(1)grep(1)awk(1)

在这些选项中，我认为strings(1)对您来说可能是最有希望的。它会扫描整个文件，寻找中长不间断的可打印 ASCII 字符（字符串），并自动输出找到的任何此类字符串。因此，由于 XML 是纯可打印的 ASCII，因此strings(1)应该将其全部打印出来，同时跳过所有二进制音频数据。

相关内容