⑴ 請求在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啊。。。。。。。。。。