关于Linux上文件系统字符编码的几个问题

由于Windows（GBK编码）和Linux（UTF-8编码）之间有很多文件交换工作，因此它很容易遇到字符编码问题，例如：

• 在Windows系统上其名称包含中文字符的zip / tar文件，在Linux系统上将其解压缩/取消存储。
• 运行迁移的旧版Java Web应用程序（在Windows系统上设计，使用JSP中的GBK编码），该应用程序将以GBK编码的文件写入磁盘。
• ftp在Windows FTP服务器和Linux客户端之间获取/输入以GBK编码的文件。
• 在Linux中切换LANG环境。

前面提到的常见问题是文件定位/命名。谷歌搜索后，我收到了一篇文章《在Linux中使用Unicode》 http://www.linux.com/archive/feed/39912，它说：

操作系统和许多实用程序都没有意识到文件名中的字节代表什么字符。

因此，可能会有2个使用不同编码的English.txt文件：

[root@fedora test]# ls
????  中文
[root@fedora test]# ls | iconv -f GBK
中文
涓iconv: illegal input sequence at position 7
[root@fedora test]# ls 中文 && ls $'\xd6\xd0\xce\xc4'|iconv -f gbk
中文
中文

问题：

1. 是否可以配置linux文件系统使用固定字符编码（例如NTFS内部使用UTF-16）来存储文件名，而不管LANG / LC_ALL环境如何？
2. 或者，我真正想问的是：是否可以让$'\xe4\xb8\xad\xe6\x96\x87.txt'zh_CN.UTF-8环境中的文件名中文.txt（$'\xd6\xd0\xce\xc4.txt'）和zh_CN.GBK环境中的文件名中文.txt（）引用同一文件？
3. 如果它不是可配置的，那么是否有可能修补内核以在文件系统和当前环境之间转换字符编码（只是一个问题，不是请求实现）？并在可能的情况下影响多少性能？

我对您的问题做了一些重新表述，原因是当您按顺序阅读它们时，这些原因应该显而易见。

1.不管LANG / LC_ALL环境如何，都可以配置linux文件系统使用固定字符编码来存储文件名？

不，这是不可能的：正如您在问题中提到的那样，UNIX文件名只是一个字节序列。内核对编码一无所知，而编码完全是用户空间（即应用程序级）的概念。

换句话说，内核对LANG/ 一无所知LC_*，因此无法翻译。

2.是否可以让不同的文件名引用同一文件？

您可以有多个目录条目引用同一文件。您可以通过硬链接或符号链接来实现。

但是请注意，在当前编码中无效的文件名（例如，当您在UTF-8语言环境中工作时，您的GBK字符串）将显示得不好，甚至根本无法显示。

3.是否可以修补内核以在文件系统和当前环境之间转换字符编码？

您无法修补内核来执行此操作（请参见1.），但是理论上可以修补C库（例如glibc）以执行此转换，并始终在调用内核时将文件名转换为UTF-8，并从内核读取文件名时将它们转换回当前的编码。

一种更简单的方法是使用FUSE编写覆盖文件系统，该文件系统在将文件名转换为UTF-8或从UTF-8转换文件名后，仅将任何文件系统请求重定向到另一个位置。理想情况下，您可以将该文件系统挂载到其中~/trans，并且在~/trans/a/GBK/encoded/path对FUSE文件系统进行访问时才 真正对其进行访问 /a/UTF-8/encoded/path。

但是，这些方法的问题是：您如何处理文件系统上已经存在且未采用UTF-8编码的文件？您不能只是简单地将它们传递不翻译，因为那样您就不知道如何转换它们。您不能通过将无效字符序列转换为来处理它们，?因为这可能会产生冲突...

您可以做的就是将受支持的语言环境的数量限制为仅UTF-8语言环境。

http://www.fifi.org/cgi-bin/man2html/usr/share/man/man5/locale.gen.5