⑴ 请求在linux下C语言如何将汉字转换成UTF
试试这个四个函数，C 里面的，Linux 可用：
mbtowc
wctomb
mbstowcs
wcstombs
在 Linux 下试试看吧：
#include <stdio.h>
#include <stdlib.h>
#include <locale.h>
int main(void)
{
size_t cch;
char psz[1024];
wchar_t pwsz[] = { 0x52B3, 0x788C, 0x788C, 0 };
setlocale(LC_ALL, "");
cch = wcstombs(psz, pwsz, 1024);
if (cch != 0 && cch != -1) {
printf("%s", psz);
}
return 0;
}
zdl_361 说的 "utf8 劳碌碌" 不对，因为我也输出 "劳碌碌"，而我是用 Unicode 编码的。在 Windows 上，char 是 ANSI，Unicode (wchar_t) 是 UTF-16；在 Linux 上，char 是 UTF-8，Unicode (wchar_t) 是 UTF-32。不过对于这个函数来说，在哪个平台上都不会因为字符编码而影响使用。
⑵ 如何查看和修改Oracle数据库服务器端的字符集
A、oracle server 端字符集查询
select userenv（'language'） from al
其中NLS_CHARACTERSET 为server端字符集
NLS_LANGUAGE 为 server端字符显示形式
B、查询oracle client端的字符集
$echo $NLS_LANG
如果发现你select 出来的数据是乱码，请把client端的字符集配置成与linux操作系统相同的字符集。如果还是有乱码，则有可能是数据库中的数据存在问题，或者是oracle服务端的配置存在问题。
C、server端字符集修改
将数据库启动到RESTRICTED模式下做字符集更改：
SQL> conn /as sysdba Connected.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
如果发现你select 出来的数据是乱码，请把client端的字符集配置成与linux操作系统相同的字符集。如果还是有乱码，则有可能是数据库中的数据存在问题，或者是oracle服务端的配置存在问题。
.1.oracle server端字符集查询 复制代码代码如下: select userenv（'language'） from al; server字符集修改： 将数据库启动到RESTRICTED模式下做字符集更改：&……
oracle10g服务器端是安装在AIX 6.0系统上，客户端是安装在windows server 2008 系统上，客户端与服务器已成功连接，但是数据库表里的中文字无法显示，显示为“？”，用SQLPLUS查得服务器端的字符集为AL16uTF16,如何修改该字符集使之支持中文呢？另外oracle10G客户端的字符集需不需要设置，如何查看和设置呢？
⑶ linux系统下WPS缺失字体导致文件乱码该怎么办
真的很正常，linux下经常出现乱码问题，这个跟编辑器的编码有关，至于wps，，你进wps的官方论坛，他们说这个问题很多次:
一下是官方的说明：
看涛哥讲故事讲的起兴，正好周末，我也上来讲讲故事哈。
随便挑了个主题，就讲“无尽混乱的编码吧”。
我想只要是玩linux的人，多多少少都遇到过乱码的问题吧，否则还真不能叫linux党。
wps运行时用的是什么编码？
wps运行时采用的是utf16编码，我相信在windows这是很多程序的选择。
但是坑爹的gcc竟然，它竟然只支持utf32编码？？？？？gcc的wchar_t竟然是4字节的，4字节的！！！！
幸亏那个坑爹的c++0x新标准被我们赶上了，支持了所谓u"str"和U"str"新格式。u就是utf16，U就是utf32。
so，我们只能选用了gcc4.5作为我们的编译器，并且编写了一个宏__X(str)，在windows展开为L #str，linux下展开为u #str。 （这也是很多朋友抱怨libstdc++版本过高的罪恶根源）
然后我们把工程里所有的L"xxx"改为了__X("xxx")，把工程里的所有wchar_t改为WCHAR// 囧，改的我们手脚发麻啊。
但是好景不长，没过两天就让我们知道，c++标准委员会绝对不是吃素的。这帮天煞的家伙不把c++搞的反人类就不爽。
strcmp是单字节的，wcscmp是4字节的，那两字节的是啥？？？？？没有！上帝啊： c++0x是的，c++0x不是c0x。。。。。so，char16_t是没有c库支持的。这叫神马utf16支持啊。
一不做二不休，我们再把所有的字符串c标函数又实现了一遍，于是乎有了xstrcmp，xstricmp，xstrncmp....。然后继续改到手发麻。。。。
但是c艹还是觉得我们太悠闲了，so，下一句台词是： c++0x不是c0x，也不是c++。。。。是的，我们目前发现char16_t除了std::basic_string<char16_t>能链接通过以外没有发现系统库例子。
连正则表达式都不能用，// 朋友你想用？不好意思，我们还没实现，你再等等吧。。。。。
。。。。我感觉我们只剩下半管血了。c++标准委员会还是觉得意犹未尽啊。
在不和c兼容 & 半成品实现上， c++0x下一个坑我们的是char16_t，这个类型本身。对，他是一个类型，不是typedef unsigned short chart16_t。
so，工程里充斥满了QString::fromUtf16((WCHAR *)__X("what a bad day!!!"));
到最后我们终于受不了了，把__X的定义改成了 ((unsigned short *)(u #str))。
then....__X('x') 和 __X("adsf") __X("asdf") 和 WCHAR str[] = __X("asdf") 都顺利歇菜了。阿门
然后我们血条红了。。。
wps的源代码用的是什么编码？
这个不用想都知道，wps是从vc6年代过来的工程，vc6又不支持utf8，当然是ansi编码（GBK）的了。
移植到linux的时候，没多久我们就碰到了编码问题。
主要是2种情况。
1 gcc按照utf-8编码解释gbk文件，导致\n回车被吞。这个时候一旦使用\\形式的备注，编译就悲剧了。（/**/形式只要在*/前加入足量的空格就没问题）
2 字符串中本身存在非ascii字符。这种情况虽然不多，却是更加棘手。
于是在linux分支上，我们就将一部分文件转为了utf8。
但这是做了几天后我们就发现不对劲了。去vc上做了个实验，果然vc罢工了。
最后我们根据实验结果得出以下结论： vc支持ansi、utf8+bom、utf16+bom，gcc支持utf8、utf8+bom
于是我们经过商议后，得出结论： 把所有工作代码转为utf8+bom，以适应将来跨平台
步骤如下：
1 编写svn钩子，以进行强制编码检查
2 将主干转为utf8+bom
3 改写svn客户端，使得支持跨编码代码合并
4 所有的分支和主干合并后，重新拉取分支后变为utf8分支。
于是乎我很happy的将主干转为了utf8+bom，结果，结果编不过去了。~_~
然后才发现，天煞的windows资源编译器只支持ansi、utf16+bom
我勒个去啊，一交集，发现没答案了。
幸亏那部分文件，没包含非中文不行的字符，俺直接给那部分文件中文备注全给删除了，改成了英文备注，OK，过了
看了这个计划，大家就知道最头大的在3和4两个步骤。
其他分支还好，文件编码基本都是ansi的，合并的时候基本没压力。
linux分支的文件有很多都是utf8没bom的。
然后俺又做了搓事啊，悲剧svn客户端没改好，编码猜测部分代码除了BUG。然后。。。。。
然后俺就拉着一帮小弟，人肉fixup啊。。。。。。。。。。