什么可能导致 Linux 中的 file 命令将文本文件报告为二进制数据？

Question

我有几个 C++ 源文件（一个 .cpp 和一个 .h），它们被Linux 中的命令报告为类型数据file。当我file -bi对这些文件运行命令时，我得到了这个输出（每个文件的输出相同）：

application/octet-stream; charset=binary

每个文件都是纯文本文件（我可以在 中查看它们vi）。是什么导致file误报这些文件的类型？它可能是某种Unicode的东西吗？这两个文件都是在 Windows 环境中创建的（使用 Visual Studio 2005），但它们是在 Linux 中编译的（它是一个跨平台应用程序）。

任何想法，将不胜感激。

更新：我在两个文件中都没有看到任何空字符。我在 .cpp 文件（在注释块中）中发现了一些扩展字符，将它们删除，但file仍然报告相同的编码。我试过在 SlickEdit 中强制编码，但这似乎没有效果。当我在 中打开文件时vim，我一[converted]打开文件就会看到一行。也许我可以让 vim 强制编码？

Answer 1

Vim 非常努力地理解你扔给它的任何东西，而不会抱怨。这使其成为用于诊断file输出的相对较差的工具。

Vim 的 "[converted]" 通知表明文件中有一些东西是 vim 不希望在您的区域设置（LANG 等）建议的文本编码中看到的。

其他人已经建议

• cat -v
• xxd

您可以尝试对非 ASCII 字符进行 grepping。

• grep -P '[\x7f-\xff]' filename

另一种可能性是平台的非标准行尾（即 CRLF 或 CR），但我希望file能够应对并报告“DOS 文本文件”或类似内容。

Answer 2

我使用二分搜索来找到有问题的行，发现了这个问题。

head -n {1/2 line count} file.cpp > a.txt
tail -n {1/2 line count} file.cpp > b.txt

对阵file每一半场并重复这个过程，帮助我找到了违规的线路。我发现其中嵌入了一个Control+ P( ) 字符。^P删除它解决了问题。将来我将为自己编写一个 Perl 脚本来搜索这些字符（以及其他扩展字符）。

非常感谢为所有提示提供答案的所有人！

Answer 3

如果运行file -D filename，则file显示调试信息，包括它执行的测试。接近尾声时，它将显示成功确定文件类型的测试。

对于常规文本文件，它看起来像这样：

[31> 0 regex,=^package[ \t]+[0-9A-Za-z_:]+ *;,""]
1 == 0 = 0
ascmagic 1
filename.txt: ISO-8859 text, with CRLF line terminators

这将告诉您它发现了什么以确定它是那种 mime 类型。