如何在OSX上的C程序中处理（可能的）UTF-8字符串

Question

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

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

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

以下是实际问题：

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

• 由于日文文件名的字节大小不等于该数字 显示的字符，我大胆地假设，struct dirent.d_name函数有效 使用UTF-8字符串。是否有可能是所有的OSX C-Library 是这样的吗？

• 因此，例如，它是安全的改变strcpy或 setlocale(LC_ALL,"C")它并使用更改的字符串创建一个新文件？是否有可能介入导致'?????'的陷阱文件名是写而不是汉字？

• 设置不同的区域设置，例如“C”，搞砸了（没有 在使用{{1}}）时会出现这种情况。

注意：我对dirent.h的第三方替代品不感兴趣。我编写的程序仅仅是为了阐明OSX如何处理区域设置和字符编码。

Answer 1

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

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

^{*只要你不干涉字符串中的个别字符。}

Answer 2

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

处理char*的大多数API都不知道并且不关心编码，所以它们应该是安全的。

setlocale会影响certain operations，主要与处理字符类型，排序和格式有关。

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