☰

非标准化 UTF-8 目录名称

tag-icon • tag-icon filesystems unicode character-encoding
非标准化 UTF-8 目录名称

我在我的一个目录中注意到一些有趣的事情：

$ ls -li
total 36
2625309 drwxrwxr-x 2 dotancohen dotancohen 4096 Jul  4  2022  Español
2625385 drwxrwxr-x 2 dotancohen dotancohen 4096 Jul  4  2022  Español
2625396 drwxrwxr-x 2 dotancohen dotancohen 4096 Jul  4  2022  Français
2625406 drwxrwxr-x 2 dotancohen dotancohen 4096 Jul  4  2022  Français

$ ls Espa<tab><tab>
Español/ Español/

$ echo Espa* | od -tx1 -c
0000000  45  73  70  61  6e  cc  83  6f  6c  20  45  73  70  61  c3  b1
          E   s   p   a   n 314 203   o   l       E   s   p   a 303 261
0000020  6f  6c  0a
          o   l  \n
0000023

请注意，这些是不同的目录 - 它们具有不同的索引节点号（第一列，这就是-i使用该标志的原因）。这两个西班牙语目录有不同的名称，其中一个的名称由以下内容组成七人物：E s p a ñ o l。另一个的名字由以下组成八人物：E s p a n COMBINING TILDE o l。从视觉上看，这两个文件名是无法区分的，任何软件都可以创建其中一个。这COMBINING TILDE打印在与其n前面的字符相同的“空间”中。

这些实际上是我几年前在 Android 设备（三星 Note 3）上做的笔记，然后通过 ADB 复制到我的 Linux 桌面上，直到最近才放在那里。这打开了一个充满问题的世界：

  1. 谁负责规范组合字符？我认为将这个责任委托给写入文件的程序（或者，令人震惊的是，委托给最终用户）只会加剧这个问题。我们应该建议文件系统标准化吗？

  2. 是否有任何工具可以处理文件系统中的规范化问题？例如查找不同标准化形式的同名目录，以及可能的重复数据删除和合并这些目录？也许还可以将整个文件系统引入标准规范化形式，而无需更新，例如 mtimes。

  3. 哪些程序可能会在这些问题上崩溃？ncdu似乎find没有问题，但我很想知道其他一些软件是否无法很好地处理不同规范化中具有相同名称的目录。例如，当用户打算写入另一个目录时，会覆盖一个目录的内容，因为软件规范化的文件名写入方式与打开的文件名不同。

  4. 还有什么是我没想到的？

相关内容