我有一个可能很天真的问题，但我觉得有必要问，因为我真的不知道发生了什么。我在Ubuntu上。
假设我
echo "t" > test.txt
如果我那么
file test.txt
我得到test.txt:ASCII text
如果我那么做
echo "å" > test.txt
然后我得到
test.txt: UTF-8 Unicode text
这是怎么发生的？文件如何“知道”编码，或者，它是如何猜测的？
感谢。
答案 0 :(得分：4)
来自file manpage：
如果文件与任何文件都不匹配 魔术文件中的条目，它是 检查看它是否是一个 文本文件。 ASCII，ISO-8859-x，非ISO 8位扩展ASCII字符集 （例如在Macintosh和 IBM PC系统），UTF-8编码 Unicode，UTF-16编码的Unicode和 EBCDIC字符集可以是 以不同的范围区分 和构成的字节序列 每组中的可打印文本。如果是文件 通过任何这些测试，它 报告字符集。 ASCII， ISO-8859-x，UTF-8和扩展ASCII 文件被标识为“文本” 因为它们几乎是可读的 几乎任何终端; UTF-16和 EBCDIC只是''字符数据'' 因为，虽然它们包含文本，但它 是需要翻译的文本 在它可以阅读之前。此外， 文件将尝试确定其他 文本类型文件的特征。如果 文件的行被终止 CR，CRLF或NEL，而不是 Unix标准LF，这将是 报道。包含嵌入的文件 逃避序列或重击意志 也可以确定。
答案 1 :(得分：4)
某些字节序列建议可能正在使用UTF-8编码（请参阅Wikipedia）。如果file找到其中一个或多个并且没有找到UTF-8中不会出现的任何内容，那么可以合理地猜测该文件是以UTF-8编码的。但同样，只是一个猜测。对于基本的ASCII字符集（普通字符，如't'），二进制表示在大多数常见编码（包括UTF-8）中是相同的，因此如果文件只包含基本的ASCII字符，file具有无法分辨出许多与ASCII兼容的编码中的哪一个是有意的。它默认使用ASCII。
要注意的另一件事是你的shell设置为使用UTF-8，这就是为什么文件首先用UTF-8编写的原因。可以想象，您可以将shell设置为使用其他编码（如UTF-16），然后使用命令
echo "å" > test.txt
会使用UTF-16写一个文件。
答案 2 :(得分：3)
UTF-8是“ASCII友好的”，因为只有ASCII字符组成的文本文件才会完全相同，无论是用ASCII还是UTF-8编码。
注意：有些人认为有256个ASCII字符。只有128. ISO-8859-x是一系列编码，其前128个字符是ASCII，其余是其他字符。
此外，UTF-8设计得非常好，并为您提供了几个属性，例如，一些字符用1字节编码，有些字符用2,3或4编码 - 但是4字节字符永远不会包含任何较短字符的字节，也不是3或2字节字符。所有1字节字符都使用字节0到127进行编码，而所有较长字符都编码为128到255范围内的字节序列。
非UTF-8字节流（例如，二进制文件或UTF-16文件）通常可以排除为UTF-8，因为它可能违反这些属性。唯一的例外是纯ASCII文件，无论如何当然可以无害地解释为UTF-8。
简而言之，UTF-8文件可以被检测到，因为大多数“随机”字节序列在UTF-8中是非法的，因此不违反任何规则的东西很可能是UTF-8。
答案 3 :(得分：2)
它在文件的最开头插入BOM。
BOM（Byte-Oder Mark）告诉编辑器文件的编码（以及大/小端编码等其他内容）
您可以找出BOM的存在，检查文件大小。它超过2个字节（我猜它是4或5个字节）。
维基百科中的This Article about BOMs可以提供很多帮助。
是的，我错了。
即使有UTF-8的BOM，但大多数编辑在开始时都会 NOT 插入BOM，因为BOM代码与ASCII不兼容，并且UTF-8设计的目标之一是ASCII兼容性。因此，为UTF-8插入BOM非常糟糕！
因此，如果文件以UTF-8编码，编辑员真的猜测。
所以另一个问题！：
似乎编辑可能会猜错文件的实际编码。这种情况难得吗？很明显，较小的文本有更多的机会来应对这种情况。