关于linux下unicode编程的一个疑问

orclover

一直以来对字符编码问题都搞的不明不白的，最近时不时就这个问题写点小程序，但总会碰到无法理解的问题。比如linux下Unicode的实现方案为UTF-8，采用这种方案的好处时，原先各种库函数和系统调用（只要不是直接针对字符串进行操作的），都可以直接处理UTF-8字符串而不出错。

但问题是，虽然不会出错，但是显示出来的可能是乱码。如果我把linux环境系统默认语言设置为en_US.UTF-8，可以创建中文，日文文件夹（采用mkdir调用创建），且文件夹名称显示也正常。但如果我把系统默认语言环境设置为zh_CN.UTF-8，则创建日文文件夹时虽然可以创建成功，但是显示出来时并不是原先的日文字符了，很费解。

是不是我系统设置有问题，还是程序中需要做特殊处理？

prolj

iconv

orclover

刚刚重新配了下编程环境，又好了。。。会不会是和shell默认编码方式设置不同有关？

比如按照我的理解，linux下如果代码文件中直接包含字符串常量时，会默认保存为UTF-8格式，而我机器上当时没有日文输入法，为了方便输入日文，我直接从网页上进行了粘贴。但与此同时我的终端设置默认字符编码为中文GB2312（过去工作在伪终端下，且为英文环境，更改为中文环境后，顺便将终端默认编码改为中文了），这样贴日文是乱码，于是我就把默认编码改为日文。然后编译运行后，产生的文件夹名称为乱码，提示“无效的unicode”。

现在我把终端默认编码设置为UTF-8，然后重复上述过程，程序运行成功，显示也正常。

orclover

刚试着把系统默认语言设置为zh_CN.GBK（最初设置为zh_CN.UTF-8）了，然后字符显示为乱码，但由于编码依然是UTF-8编码，居然也能创建并显示成功（当前前提是系统支持这个语言）。但是在X系统下无法删除这个文件（并不是没有权限，提示文件路径无效），可见gnome无法处理路径中的特殊字符，看了下gnome的版本，是2.8.0了，比较古老了。