当我们在 linux 中调用像 ' ' 这样的系统调用open或像 ' ' 这样的 stdio 函数时fopen，我们必须提供一个 ' const char * filename'。我的问题是这里使用的编码是什么？它是 utf-8 还是 ascii 或 iso8859-x？它取决于系统或环境设置吗？
我知道在 MS Windows 中有一个_wopen接受 utf-16。
问问题
5985 次
6 回答
8
它是一个字节字符串，解释取决于特定的文件系统。
于 2010-01-05T11:12:10.413 回答
4
Linux 上的文件系统调用与编码无关，即它们不需要（不需要）知道特定的编码。就他们而言，文件名参数指向的字节串按原样传递给文件系统。文件系统期望文件名采用正确的编码（通常是 UTF-8，如 Matthew Talbert 所述）。
这意味着您通常不需要做任何事情（文件名被视为不透明的字节字符串），但这实际上取决于您从哪里接收文件名，以及您是否需要以任何方式操作文件名。
于 2010-01-05T11:54:15.733 回答
4
这取决于系统区域设置。查看“locale”命令的输出。如果变量以 UTF-8 结尾，那么您的语言环境是 UTF-8。大多数现代 linux 将使用 UTF-8。虽然 Andrew 是正确的，从技术上讲它只是一个字节字符串，但如果您不匹配系统区域设置，某些程序可能无法正常运行，并且无法获得正确的用户输入等。最好坚持使用 UTF-8。
于 2010-01-05T11:14:44.923 回答
0
文件名是字节串；无论您使用的语言环境或任何其他关于文件名应如何编码的约定，您必须传递给fopen和传递给所有采用文件名/路径名的函数的字符串是文件命名方式的确切字节字符串。例如，如果您ö.txt在 NFC 中有一个以 UTF-8 命名的文件，并且您的语言环境是 UTF-8 编码并使用 NFC，您只需将名称写为ö.txt并将其传递给fopen. 但是，如果您的语言环境是基于 Latin-1 的，则您不能将ö.txt( "\xf6.txt") 的 Latin-1 形式传递给fopen并期望它成功；那是一个不同的字节字符串，因此是一个不同的文件名。您需要传递"\xc3\xb6.txt"（"ö.txt"如果您将其解释为 Latin-1），与实际名称相同的字节字符串。
这种情况与您似乎熟悉的 Windows 非常不同，其中文件名是解释为 UTF-16 的 16 位单元序列（尽管 AFAIK 它们实际上不需要是有效的 UTF-16）并且文件名传递给fopen等根据当前语言环境解释为 Unicode 字符，然后根据其 UTF-16 名称打开/访问文件。
于 2020-01-23T14:44:40.503 回答
0
正如上面已经提到的，这将是一个字节串，并且解释将对底层系统开放。更具体地说，想象一下 C 函数；一个在用户空间，一个在内核空间，它们char *作为参数。用户空间中的编码将取决于用户程序的执行字符集（例如，由-fexec-charset=charsetgcc 指定）。内核函数预期的编码取决于内核编译期间使用的执行字符集（不确定从哪里获取该信息）。
于 2020-01-22T06:03:49.813 回答
-1
我对这个主题做了一些进一步的调查，得出的结论是，unixoid 文件系统可以通过两种不同的方式处理文件名编码。
文件名在“系统语言环境”中编码，通常是，但不必与
locale命令反映的当前环境语言环境相同（但某些预设在全局配置文件中）。文件名以 UTF-8 编码，独立于任何区域设置。
GTK+ 通过假设 UTF-8 并允许通过当前的语言环境编码或用户提供的编码来覆盖它来解决这个问题。
Qt 通过假设语言环境编码（并且系统语言环境反映在当前语言环境中）并允许用用户提供的转换函数覆盖它来解决它。
所以底线是：使用 UTF-8 或 LC_ALL 或 LANG 默认告诉您的内容，并至少为其他替代方案提供覆盖设置。
于 2015-05-13T19:56:26.193 回答