我尝试使用testdiskLinux 上的软件包从 exFAT 拇指驱动器恢复丢失的文件。它非常擅长查找已删除的文件。然而，当我浏览这些条目时，我看到了奇怪的条目。该程序声称有数十个存在和已删除的文件，其文件名不可读、文件大小巨大以及奇怪的时间戳。
例如，一项读取79862082558814991字节2-Apr-1911和文件名,~WM-*'? M-kxfM-'D^^Q謁懫䞭鵣ㄆ冚୩鳼묁쐚쵡૪댷腁濬。无效条目名称为乱码、外文、表情符号。有趣的是，一些时间戳是在 unix 纪元之前。
这些奇怪的条目不在驱动器的根目录上。它们只存在于某些文件夹中。仅包含字母数字字符的文件也可以正常显示。
我的问题是：
- 造成这种现象的原因是什么？ testdisk 是否错误地将随机剩余字节拾取为“已删除文件”？或者在 Windows 上创建的某些文件不适合 Linux？
- Linux 和 Windows 的文件名实际上使用不同的编码/规则集吗？如果是这样，如果名称在一个操作系统上有效但在另一个操作系统上无效的文件被发送到敌对操作系统，会发生什么情况？难道都变成这样胡言乱语了吗？
ps 所有文件的内容均以 UTF-8 编码。
答案1
(1) 文件清理者/雕刻者寻找看起来可能曾经是文件的模式。这是必要的，因为根据定义，这些文件不再正常可用。有时，不是文件的东西与某些启发式相匹配，并且您会得到这样的误报。
(2) 根据我的经验，大多数文件系统在任何地方都使用特定的编码，无论是作为规范的一部分，还是隐含的。
例如，许多早期的文件系统都隐含 ASCII，因为这就是全部。
NTFS 指定 Unicode 和 UCS-2 编码（16 位固定宽度字符）。
我不确定各种 Linux 扩展文件系统是否属于“隐式”或“显式”，但实际上，它是 Unicode 和 UTF-8，或者可能是非常旧的内核中的 ASCII。实际的文件名是没有解释的字节序列，超出了 NUL（零）。由显示例程将这些字节解释为字符。这些显示例程大部分位于用户空间中——例如，ls(1)实用程序和正在使用的终端仿真器。
当系统遇到无效字符时，系统会采取不同的措施。作为一个非常普遍的规则，从历史上看，Unix 派生系统试图让它工作，但/或一开始就没有注意到（可能会给用户带来非常混乱的结果），而 Microsoft 派生系统在注意到时会返回错误，或者如果他们不这样做就会表现得很奇怪。