規格在MSVC++源字符集編碼的，像GCC「-finput-字符集=字符集」

我想創建與編碼處理的一些樣本程序，具體我想使用寬字符串等：規格在MSVC++源字符集編碼的，像GCC「-finput-字符集=字符集」

wstring a=L"grüßen"; 
wstring b=L"שלום עולם!"; 
wstring c=L"中文";

因爲這些都是示例程序。

這對於將源代碼視爲UTF-8編碼文本的gcc來說絕對是微不足道的。但是，直接編譯在MSVC下不起作用。我知道我可以使用轉義序列將它們編碼爲，但我寧願將它們保留爲可讀文本。

是否有任何選項可以指定爲「cl」的命令行開關，以便使這項工作成爲可能？有有任何命令行開關一樣gcc'c -finput-charset

感謝，

如果沒有你怎麼會建議讓文字自然的用戶？

注意：將BOM添加到UTF-8文件不是一個選項，因爲它不會被其他編譯器編譯。

注2：我需要它在MSVC版本工作> = 9 == VS 2008

真正的答案：有編碼組合無解

來源

2009-11-02 Artyom

這真是令人驚訝的MSVC++沒有這樣的編譯器的選項。真是太遺憾了...... – 2011-03-13 22:37:02

我問你這個問題的意思是*源文件** charset *的規範。 *源字符集*是用於編譯器內部使用的實現定義字符集的標準中的術語。 – 2011-03-14 20:20:08

@PiotrDobrogost有人猜測爲什麼微軟沒有通過本機支持編譯和SDK的UTF-8來滿足世界其他地區的需求，並且在必須國際化Windows應用程序的程序員的生活中增加了如此多的低效率，麻煩，混亂和痛苦在UTF-8世界。但我有一個猜測;它被稱爲*官僚主義*和*利潤動機*超過關心或質量的關注。 – 2015-01-10 02:16:33

對於那些訂閱座右銘「比從不遲到」更好的人來說，Visual Studio 2015（編譯器19版）現在支持這一點。

新的/source-charset命令行開關允許您指定用於解釋源文件的字符集編碼。它採用單個參數，其可以是所述IANA或ISO字符集名：

/source-charset:utf-8

或一個特定的代碼頁的十進制標識符（由點之前）：

/source-charset:.65001

官方文檔是here，在Visual C++團隊博客上也有a detailed article describing these new options。

還有一個補充/execution-charset switch，其工作方式完全相同，但控制可執行文件中生成的字符和字符串的範圍有多窄。最後，有一個快捷開關/utf-8，它設置了/source-charset:utf-8和/execution-charset:utf-8。

這些命令行選項不相容與老#pragma setlocale和#pragma execution-character-set指令，它們適用於全球所有的源文件。

對於停留在舊版本編譯器上的用戶，最好的選擇仍然是將源文件保存爲帶有BOM的UTF-8（如其他答案中所建議的，IDE可以在保存時執行此操作）。編譯器會自動檢測到這一點，並適當地運行。同樣，GCC也會在源文件開始時接受BOM而不會窒息而死，這使得這種方法在功能上是可移植的。

來源

2016-06-10 09:14:30

打開File->Advances Save Options... 選擇Unicode(UTF-8 with signature) - Codepage 65001。編譯器將自動使用選定的編碼。

根據微軟的答案here：

如果你想非ASCII字符
那麼「官方」和便攜的方式讓他們是使用\ u（或\ U）十六進制編碼（這是，我同意，只是簡單醜陋和容易出錯）。

編譯器遇到沒有BOM的源文件時，會提前讀取文件中的一定距離，看它是否能檢測到任何Unicode字符 - 它專門查找UTF-16和UTF-16BE - 如果它沒有找到，那麼它假定它有MBCS。我懷疑在這種情況下，它會回落到MBCS，這是導致問題的原因。

明確是最好的，所以雖然我知道這不是一個完美的解決方案我建議使用BOM。

Jonathan Caves
Visual C++編譯器團隊。

良好的解決方案將是把文本字符串中的資源文件。這是方便和便攜的方式。您可以使用本地化庫（例如gettext）來管理翻譯。

來源

2009-11-02 12:03:53

該文件已經以UTF-8編碼 – Artyom 2009-11-02 14:34:32

編譯器自動轉換文件中的字符串常量，因此字符串將使用UCS2編碼存儲在EXE中。 – 2009-11-02 15:20:34

好的，我明白了，你建議手動在UTF-8上添加「BOM」標記，它確實有效，但問題在於gcc和其他編譯器無法處理沒有意義的BOM。 – Artyom 2009-11-02 19:05:13

對於VS可以使用：

#pragma setlocale("[locale-string]")

的區域設置的默認ANSI代碼頁將被用作文件編碼。

但是，在代碼中硬編碼任何用戶可見的字符串通常是一個壞主意。將它們存儲在某種資源中。很好的本地化，易於拼寫檢查和更新等。

來源

2009-11-11 08:19:43

「但是，在代碼中硬編碼任何用戶可見的字符串通常是一個糟糕的主意」我知道，但這主要是用於這樣的事例，這些事情對用戶來說很重要，以便看到什麼是真正的發生。但是如何在locale字符串中指定UTF-8字符集呢？據我所知，Windows不支持UTF-8編碼的語言環境。 – Artyom 2009-11-11 09:37:53

短暫測試後，MSVC 2005未能接受'setlocale（「。65001」）'即UTF-8代碼頁。 – Artyom 2009-11-11 09:52:54

65001是一個代碼頁，編譯指示需要一個語言環境。沒有使用UTF-8作爲代碼頁的區域設置。如果你只需要它在VS中工作，你可以將它保存爲UTF-16 （從記事本「另存爲」和選擇編碼「Unicode」）否則唯一便攜的方法就是將其轉義爲Sherwood Hu建議。喜歡與否，這是唯一的方法。而正確的方法是不在你的c文件中硬編碼:-) – 2009-11-15 08:38:00

恕我直言，所有的C++源文件應嚴格的ASCII。如果編輯器支持，評論可以用UTF-8編寫。
這使得代碼可以在平臺，編輯器和源代碼控制系統之間移植。

您可以使用\u插入Unicode字符轉換爲一個寬字符串：

std::wstring str = L"\u20AC123,00"; //€123,00

來源

2009-11-12 14:34:11 cuteCAT

Thants我究竟**不想**想做什麼 – Artyom 2009-11-12 20:28:36

我們使用的流程：將文件保存爲UTF8-與BOM，共享Linux和Windows之間的相同的源，對於Linux：預處理編譯命令中的源文件爲了刪除BOM，在中間非BOM文件上運行g ++。

來源

2012-06-12 10:12:01

規格在MSVC++源字符集編碼的，像GCC「-finput-字符集=字符集」

回答

相關問題