4

希望问题标题能很好地描述我的问题。

平台：OSX 10.8，带有 clang++ 编译器的 llvm

我有一个文件名是日文或西里尔字符的目录。这些文件名ls在 iTerm2 中使用 en_EN.UTF-8 语言环境和 Monaco 10 字体正确显示（例如 via ）（不确定语言环境/字体是否有所不同，但似乎应该如此）。但是，不支持 UTF-8 的 vanilla xterm 会打印乱码或“？” 非 ASCII 字符的字符。

这是实际的问题：

在 C++ 程序中，我使用readdir()fromdirent.h列出包含日文或西里尔字符文件名的目录的内容。打印结果的d_name属性会在 Xcode 终端中显示正确的字符。也就是说，例如，日本汉字真的是这样显示的。从 iTerm2 执行程序时也是如此。同样，非 UFT-8 xterm 中的字符乱码。struct direntreaddir()

  • 由于日文文件名的字节大小不等于显示的字符数，我大胆假设，这些dirent.h函数适用于 UTF-8 字符串。是否有可能所有的 OSX C-Library 都以这种方式工作？

  • 因此，例如更改struct dirent.d_nameor strcpyit 并使用更改后的字符串创建新文件是否安全？是否有可能踏入一些导致“？？？？？？”的陷阱 文件名被写而不是汉字？

  • 设置不同的语言环境，例如“C”，会搞砸（使用时似乎不是这样setlocale(LC_ALL,"C")）。

注意：我对 dirent.h 可能的第 3 方替代方案不感兴趣。我编写这个程序只是为了阐明 OSX 如何处理语言环境和字符编码。

4

2 回答 2

1

从遗留字符串处理代码的角度来看，UTF-8 旨在向后兼容 ASCII。这包括strcpy()和朋友。

所以是的，在您的代码中，处理这些字符串通常是安全的，就像处理任何其他字符串*一样；只有在展示时间才会发生聪明的事情。

* 只要您不干预字符串中的单个字符。

于 2013-01-15T12:39:56.590 回答
1

有效的 UTF8 字符串不包含任何空字符，因此任何字符串操作都应该适用于 UTF8 编码的字符串。您可能不想获取它的子字符串或修改其中的字节，因为某些字符被编码为多个字节。

大多数处理的 APIchar*不知道也不关心编码，因此它们应该可以安全使用。

setlocale 会影响某些操作，主要与处理字符类型、排序和格式有关。

当您打印字符串时，它会以一串字节的形式输出。终端模拟器将其解释为 UTF8 并选择正确的字符。xterm 不知道 unicode，当然不能正确解释它并显示正确的字符。

于 2013-01-15T12:41:58.933 回答