Ⅰ 如何在linux系統實現字元編碼轉換
Linux下提供了iconv實現這一功能，在Linux
的
shell
環境下，iconv用法如下：
iconv
-f
fromconde
-t
tocode
-f：
指定需要轉換的文本編碼
-t：
指定目標文本編碼
我們也可以用
-l
列舉出所有已知的字元編碼集合
iconv
-l
具體用法可以通過幫助函數
iconv
--help來詳細了解
另外，我們也可以在程序中直接使用該函數實現文本的編碼轉換
#ifndef
__CODE_CONVERTER
#define
__CODE_CONVERTER
#ifdef
WIN32
#include
<windows.h>
#else
#include
<iconv.h>
#endif
class
CodeConverter
{
private:
#ifndef
WIN32
iconv_t
m_cd;
#endif
const
char*
m_pszFromCode;
const
char*
m_pszToCode;
public:
CodeConverter()
{
m_pszFromCode
=
NULL;
m_pszToCode
=
NULL;
#ifndef
WIN32
m_cd
=
0;
#endif
}
~CodeConverter()
{
#ifndef
WIN32
iconv_close(m_cd);
#endif
}
bool
Initialize(const
char
*pszToCode,
const
char
*pszFromCode);
size_t
Convert(char*
inBuf,
size_t
inBytesLeft,
char*
outBuf,
size_t
outBytesLen);
};
#endif
#include
<string.h>
#include
<stdlib.h>
#include
<stdio.h>
#include
"code_converter.h"
#include
<errno.h>
bool
CodeConverter::Initialize(const
char*
pszToCode,
const
char*
pszFromCode)
{
if(pszFromCode
==
NULL
||
pszToCode
==
NULL)
return
false;
m_pszFromCode
=
pszFromCode;
m_pszToCode
=
pszToCode;
#ifndef
WIN32
m_cd
=
iconv_open(m_pszToCode,m_pszFromCode);
if(m_cd
==
(iconv_t)-1)
{
printf("cannot
open
iconv
descripter\n");
return
false;
}
#endif
return
true;
}
size_t
CodeConverter::
Convert(char*
inBuf,
size_t
inBytesLeft,
char*
outBuf,
size_t
outBytesLen)
{
int
nRealLen
=
0;
#ifdef
WIN32
if(stricmp(m_pszFromCode,"UNICODE")
==
0)
{
nRealLen
=
WideCharToMultiByte(CP_ACP,0,(PWCHAR)inBuf,
inBytesLeft,
(PCHAR)outBuf,
outBytesLen,NULL,NULL);
}
if(stricmp(m_pszFromCode,"gb2312")
==
0)
{
nRealLen
=
MultiByteToWideChar(CP_ACP,0,(PCHAR)inBuf,inBytesLeft,(PWCHAR)outBuf,
outBytesLen);
}
#else
size_t
outBytesLeft
=
outBytesLen;
size_t
ret
=
0;
while
(1)
{
ret
=
iconv(m_cd,
&inBuf,
&inBytesLeft,
&outBuf,
&outBytesLeft);
if
(ret
==
0)
break;
if
(ret
==
(size_t)-1)
{
printf("iconv
error
aaa:
%s\n",strerror(errno));
return
-1;
}
inBuf++;
inBytesLeft--;
}
nRealLen
=
outBytesLen-outBytesLeft;
outBuf[nRealLen]=0;
#endif
return
nRealLen;
}
Ⅱ 用MultiByteToWideChar將char轉換為wchar就代表將ansi轉換為utf-8了嗎那在linux下用wcstombs轉回來
在linux下用iconv
Ⅲ Linux下寬字元串輸出問題,求解...
setlocale( LC_ALL, "chs " );
看看是不是沒有調用這個函數
for example
char str[1024] = "abc123故障短路切換";
wchar_t array[1024]={0};
setlocale(LC_ALL,"zh_CN.GB2312");
/*from chinese to Unicode*/
if((ret=mbstowcs(array, str, strlen(str)))==-1)
{
printf("error\n");
}
goodluck
Ⅳ Linux下LPCWSTR與BSTR區別
字元串轉換_BSTR/LPSTR/LPWSTR/Char
一、BSTR、LPSTR和LPWSTR
在Visual C++.NET的所有編程方式中，我們常常要用到這樣的一些基本字元串類型，如BSTR、LPSTR和LPWSTR等。之所以出現類似上述的這些數據類型，是因為不同編程語言之間的數據交換以及對ANSI、Unicode和多位元組字元集(MBCS)的支持。
那麼什麼是BSTR、LPSTR以及LPWSTR呢？
BSTR(Basic STRing，Basic字元串)是一個OLECHAR*類型的Unicode字元串。它被描述成一個與自動化相兼容的類型。由於操作系統提供相應的API函數(如SysAllocString)來管理它以及一些默認的調度代碼，因此BSTR實際上就是一個COM字元串，但它卻在自動化技術以外的多種場合下得到廣泛使用。圖1描述了BSTR的結構，其中DWORD值是字元串中實際所佔用的位元組數，且它的值是字元串中Unicode字元的兩倍。
LPSTR和LPWSTR是Win32和VC++所使用的一種字元串數據類型。LPSTR被定義成是一個指向以NULL(『\0』)結尾的8位ANSI字元數組指針，而LPWSTR是一個指向以NULL結尾的16位雙位元組字元數組指針。在VC++中，還有類似的字元串類型，如LPTSTR、LPCTSTR等
Ⅳ 有宏 -t 就屬於windows編程嗎windows編程的入口函數也可以是 -tmain（）嗎
_t 或 _T 這樣的前綴或後綴在有些情況下並沒有什麼意義，如 size_t、uint_t 等。在有些情況下則只是一個宏，表示一個通用名稱，這個名稱在編譯的時候才能確定，並不是 Windows 專用的。早期的 Windows 系統使用 ANSI 編碼，在不同語言編碼的系統上運行會出現亂碼。而從 2000 開始，Windows 支持 ANSI 和 Unicode 編碼，因此所有的與字元有關的 Windows API 均有兩個不同的版本，如 SetWindowText 這個 API，事實上是不存在的，只有 SetWindowTextA（用於 char 類型）和 SetWindowTextW（用於 wchar_t 類型）。Linux 系統雖然也用 char 類型，但其 char 是 UTF-8 編碼的，不會亂碼，因此你很少看到 Linux 上使用 _t。但是 Linux 也有 char 和 wchar_t 數據類型，這點與 Windows 是一致的。即不管在哪個平台，C 語言中的字元類型都有 char 和 wchar_t 兩種類型。如 _tprintf 這個宏，本身不是一個函數名，它可能被替換為代表 printf（用於 char 類型）或者 wprintf（用於 wchar_t 類型），取決於是否定義了 UNICODE。同樣的 Windows 控制台程序的入口有 main 和 wmain，但是它被定義為 _tmain，這個宏在定義 Unicode 時等於 wmain，未定義是等於 main。Windows GUI 程序入口有 WinMain 和 wWinMain，它被定義為宏 _tWinMain。同樣地，上面提到的 SetWindowText，當定義 UNICODE 時，SetWindowText 被定義為 SetWindowTextW，未定義時代表 SetWindowTextA。在 C 語言中，wchar_t 類型的寬字元在聲明時，字元或字元串串前需要加 L 以便編譯器知道這是寬字元。所以針對字元串也定義了宏 _T，其 Windows 版名稱為 TEXT。_tprintf 和 _T 這樣的宏都是 C 標准，定義在 tchar.h 中。現以一個簡單的命令行程序說明一下這些宏的意義。假如有這樣的代碼：
#include <stdio.h>
#include <stdlib.h>
#include <tchar.h>
#include <windows.h>
int _tmain(int argc, TCHAR *argv[])
{
TCHAR szText[] = TEXT("Sample string.");
_tprintf(TEXT("%s"), szText)
SetWindowText(GetDesktopWindow(), szText);
return 0;
}
定義 UNICODE 時，等同於：
int wmain(int argc, wchar_t *argv[])
{
wchar_t szText[] = L"Sample string.";
wprintf(L"%s", szText)
SetWindowTextW(GetDesktopWindow(), szText);
return 0;
}
未定義 UNICODE 時，等同於：
int main(int argc, char *argv[])
{
char szText[] = "Sample string.";
printf("%s", szText)
SetWindowTextA(GetDesktopWindow(), szText);
return 0;
}
不過 wmain、WinMain、wWinMain 這幾個入口是 Windows 特有的。
Ⅵ 100財富給牛逼之人！就沒人知道在linux下用c語言如何將漢字的unicode編碼轉化為漢字嗎
除了iconv命令，我們在linux系統下的man page的第三節還可以看到一組iconv函數。它們分別是
iconv_t iconv_open(const char *tocode, const char *fromcode);
size_ticonv(iconv_t cd, char **inbuf, size_t *inbytesleft, char **outbuf, size_t *outbytesleft);
int iconv_close(iconv_t cd);
iconv_open函數用來打開一個編碼轉換的流，iconv函數的作用是實際進行轉換，iconv_close函數的作用就是關閉這個流。實際用法參見下面的例子，下面是一個將UTF-8碼轉換成GBK碼的例子，我們假設已經有了一個uft8編碼的輸入緩沖區inbuf以及這個緩沖區的長度inlen。
iconv_t cd = iconv_open( "GBK", "UTF-8");
char *outbuf = (char *)malloc(inlen * 4 );
bzero( outbuf, inlen * 4);
char *in = inbuf;
char *out = outbuf;
size_t outlen = inlen *4;
iconv（cd, &in, (size_t *)&inlen, &out,&outlen）;
outlen = strlen(outbuf);
printf("%s\n",outbuf);
free(outbuf);
iconv_close(cd);
Ⅶ Linux下怎麼將wchar
在<WCHAR.h>頭文件中有定義
typedef unsigned short wchar_t;
就是 wide character type 的意思
在 美國資訊交換標准碼(ASCII: American Standard Code for Information Interchange)
開發過程中 為了節約成本(排除8位, 當時每位元的存儲空間成本很昂貴) 最終由美國國家標准協會發布了7位版本的方案 記錄在ANSI X3.4-1986 中
該標准在美國及拉丁字母國家使用方便 但在遠東 西歐南部 會遇到拉丁字母中不存在的字母
比如俄語(斯拉夫) 希臘語 希伯來語 阿拉伯語 以及 漢字 日語 韓語
為了解決的字元集不同的惡心問題(內碼轉換) 誕生了Unicode字元集 它比ASCII多了一倍空間
這個wchar_t 就是Unicode對應的資料結構 它是16位的 可以裝得下漢字哦
wchar_t *p = L"ooxx!"; 這個L告訴編譯器, 把字母擴展為寬字元
你也會見到 _T(ooxx) 或者 TEXT(之類的寫法) 他們都是為了讓你的代碼能在美歐以外運行
#ifdef UNICODE //UNICODE版
#define __T(x) L##x //這##字元串連接符 你應該知道滴
#else //ASCII版
#define __T(x) (x)
#endif
#define _T(x) __T(x)
#define _TEXT(x) __T(x)
因此他們都是一樣的
在windows的編程中 更普遍的寫法是用WCHAR取代wchar_t
因為符合微軟的命名規則 當然你如果喜歡Linux的話...
typedef char CHAR
typedef wchar_t WCHAR
如果你的代碼是國際版本(多語言版)
你也可以用TCHAR.. 它是一個依賴識別字的宏 可以是char 也可以是wchar_t...
Ⅷ 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啊。。。。。。。。。。