C++中文顯示問題(轉自 csdn dbzhang800)

原文網址 http://blog.csdn.net/dbzhang800/article/details/7540905html

長期以來,不少人都清楚,一旦C++源碼中直接使用了中文,這樣的源碼想要跨平臺(I18N)會很是困難。windows

隨着:ide

  • Windows下:MSVC2010成爲主流編碼

  • Linux下:GCC升級到4.6spa

C++中的中文問題 纔算有了一個比較優雅的、跨平臺的Workaround。.net

(本文討論編譯器範圍:GCC4.6+, MSVC2010sp1+ 。本文屬於QString系列,但暫不涉及QString)命令行

C++ 中文問題

要在C++中正確使用中文,必需要了解下面兩個概念:code

源碼字符集(the source character set)htm

源碼文件是使用何種編碼保存的blog

執行字符集(the execution character set)

可執行程序內保存的是何種編碼(程序執行時內存中字符串編碼)

C++98的問題: 既沒有規定源碼字符集,也沒有規定執行字符集

這個... 如何理解?不妨看個例子

例子

這個要求高麼?

  • 一個簡單的C++程序,只是但願它能在簡體中文Windows、正體中文Windows、英文版Windows、Linux、MAC OS...下的結果一致。

//main.cppint main(){    char mystr[] = "老老實實的學問,來不得半點馬虎";    return sizeof mystr;}

能夠試着反問本身兩個問題

  • 這個源碼文件是何種編碼保存的?(有肯定答案麼?)

  • mystr中是什麼內容?(有肯定答案麼?)

對C++來講,這兩個都不肯定。

  • 固定平臺的話,還能忍忍

  • 要跨平臺的話,這種東西...

GCC

在GCC下,這兩個均可以使用你本身喜愛的編碼(若是不指定,默認都是UTF8)

-finput-charset=charset-fexec-charset=charset

除了前兩個選項外,還有一個:

-fwide-exec-charset=charset

wide? 不妨先猜一下它是幹嗎的

MSVC

MSVC沒有相似前面的選項。

源碼字符集如何解決?

有BOM麼,有則按BOM解釋,無則使用本地Locale字符集(隨系統設置而變)

執行字符集如何解決?

使用本地Locale字符集(隨系統設置而變)

挺霸道哈(固然,源碼中可使用#pragma setlocale("..."),但功能頗有限,好比Windows沒有utf8的locale,因此...)。

另外,和GCC對應的wide-exec-charset呢?

寬執行字符集如何解決?

不妨先考慮一下

怎麼辦?

這才兩個編譯器,看起來就這麼複雜了。而C++編譯器的數目遠大於2.

要想跨平臺,必須確保這兩個字符集都是「肯定」的,而能勝任該任務的字符集,彷佛理想的也只能是...

UTF-8方案

  • 若是咱們將源碼保存成utf8,執行字符集也選爲utf8,那麼天下將太平了。使用非ASCII字符的源碼文件也就能夠在不一樣國家的用戶間無障礙流通了 ;-).

源碼保存成UTF-8沒有什麼困難,可是,執行字符集須要是UTF-8。沒那麼簡單

對GCC來講,這個問題很簡單(默認的編碼選項足夠了):

  • 只要源碼文件保存成utf8便可(帶或不帶BOM都可)

  • 早期的gcc不接收帶BOM的utf8源碼文件,如今,至少在GCC4.6中,這一限制再也不存在。

對MSVC來講,這個問題異常複雜:

  • 對MSVC2003來講,只要源碼保存成不帶BOM的utf8便可

  • 對MSVC200五、(沒在SP1基礎上裝熱補丁的)MSVC2008來講。徹底沒辦法

  • 直到MSVC2010sp1,纔算提供了一個解決方案。源碼保存成帶BOM的utf8,utf16,...,而後添加

#pragma execution_character_set("utf-8")

要想跨GCC4.6+和MSVC2010sp1+,咱們須要取它們的交集:也就是

  • 源碼保存成帶BOM的utf8

  • 爲MSVC添加#pragma

//main.cpp#if _MSC_VER >= 1600#pragma execution_character_set("utf-8")#endifint main(){    char mystr[] = "老老實實的學問,來不得半點馬虎";    return sizeof mystr;}

C++11

等到MSVC支持C++11的String Literals之時,咱們就不必用那個蹩腳的pragma了,直接

    char mystr[] = u8"老老實實的學問,來不得半點馬虎";

便可(儘管如今在GCC下沒問題,但要跨平臺,估計要等到Visual C++ 12了)。

有個問題?

C++98中不是有個wchar_t麼,它不是用來表示unicode字符的麼?

Unicode 4.0標準的5.2節是如何說的:

The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compilershould not use wchar_t for storing Unicode text. The wchar_t type is intended forstoring compiler-defined wide characters, which may be Unicode characters in some compilers.

在回頭看看GCC的選項

-fwide-exec-charset=charset

儘管GCC爲其提供的默認編碼是UTF16或UTF32(取決於wchar_t的寬度),但該編碼是能夠隨意設置的。

儘管這個東西不保證跨平臺,也很很差玩, 可是,因爲在windows下面wchar_t用來表示utf16字符,並且直接對應系統API接口,因此在類型char16_t普及以前,仍是很重要的。

C++11執行字符集

前面提到的u8就是C++11爲「執行字符集」所作的努力之一。

新明確規定了utf八、utf16和utf32這3種執行字符集。

char*

u8"中文"

char16_t*

u"中文"

char32_t*

U"中文"

但是C++11並無規定源碼字符集

const char* mystr=u8"中文";

C++標準對編譯器說,我無論這個文件的具體編碼是什麼,但你必須給我生成對應utf8編碼的字節流。

編譯器彷佛有點傻了吧?不知道源文件的編碼,我如何轉換

因而:

MSVC說:源碼文件必須有BOM,否則我就認爲你是本地locale的編碼

GCC說:我認爲你就是utf8編碼,除非經過命令行通知我其餘編碼

在C++11標準下,對源碼編碼 簡單的處理辦法仍是,使用帶BOM的UTF8保存。

參考

相關文章
相關標籤/搜索