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

发布时间：2020-12-16 07:34:30 所属栏目：百科来源：网络整理

导读：希望问题标题能很好地描述我的问题. 平台：OSX 10.8,带有clang编译器的llvm 我有一个日文或西里尔字符文件名的目录.这些文件名在iTerm2中使用en_EN.UTF-8语言环境和Monaco 10字体正确显示(例如通过ls)(不确定语言环境/字体是否有所不同,但似乎应该这样).但是

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

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

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

这是实际问题：

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

>由于日文文件名的字节大小不等于该数字
显示的字符,我大胆地假设,dirent.h函数工作
使用UTF-8字符串.是否有可能是所有的OSX C-Library
这样工作？
>因此,例如它是安全的.改变struct dirent.d_name或
strcpy它并使用更改的字符串创建一个新文件？是否有可能介入导致’?????’的陷阱文件名是写而不是汉字？
>会设置不同的区域设置,例如“C”,搞砸了(没有
在使用setlocale(LC_ALL,“C”)时看起来那样.

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

解决方法

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

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

setlocale将影响certain operations,主要与处理字符类型,排序和格式有关.

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!