2011-06-11 77 views
7

我正在修改一些非常陳舊的(10年)C代碼。代碼在Unix/Mac上使用GCC編譯,並與MinGW交叉編譯Windows。目前在整個TCHAR字符串中。我想擺脫TCHAR並改爲使用C++字符串。是否仍然需要使用Windows寬泛的函數,或者我現在可以使用Unicode和UTF-8來做所有事情嗎?我應該從Windows代碼中刪除TCHAR嗎?

+0

相關:http://stackoverflow.com/questions/234365/is-tchar-still-relevant/ – dan04 2011-06-11 15:42:32

+3

使用C++的std :: wstring的C代碼是不可取的。 – 2011-06-11 17:23:13

+0

我已經成功地使用'TCHAR'得到一些短小的工具到Windows,Linux和Solaris下編譯,分別使用其原生Unicode格式(UTF-16或UTF-8)。但它確實涉及爲* nix平臺創建自己的'tchar.h'。 – hippietrail 2011-08-10 10:38:49

回答

9

Windows仍然使用UTF16,而且很可能總是會這樣。因此,您需要使用wstring而不是string。 Windows API直接不提供對UTF8的支持,主要是因爲Windows在UTF8發明之前支持Unicode。

因此編寫可在Windows和Unix平臺上編譯的Unicode代碼是相當痛苦的。

+2

Windows使用'UCS-2'和'UTF-16'的可怕混合。在BMP之外使用字符有點難以置信。 – 2011-06-11 14:03:57

+1

@Ben我認爲UCS-2的東西大多侷限於控制檯APIS。比這更廣泛嗎? – 2011-06-11 14:20:12

+0

@大衛:也許這是一個文檔錯誤,但如果您信任的文檔,甚至'WideCharToMultiByte'和'MultiByteToWideChar'只處理'UCS-2'(返回的'UTF-16'字符數是無用的緩衝區分配)。 'GetWindowTextLength'同樣打破,返回的字符數(有這個暗示多字節字符集的註腳,但指出,混合ANSI和Unicode時,這個特殊的行爲只發生)。 – 2011-06-11 14:44:53

0

是的,現在編寫非unicode應用程序正在拍攝自己的腳。只要在任何地方使用廣泛的API,你就不用再哭了。如果您不需要平臺之間的(網絡)通信(或將wchar_t與Win32 API轉換爲UTF-8),那麼仍然可以在UNIX上使用UTF8,在Windows上使用wchar_t,或者在硬編碼方式中使用UTF-8並轉換到wchar_t的時候你使用Win32 API函數(這就是我所做的)。

0

直接回答你的問題:

是否仍然需要使用Windows廣泛的功能,或者我現在可以做的一切使用Unicode和UTF-8?

不,絕大多數Windows API函數都不接受(非ASCII)UTF-8。您仍然必須使用廣泛的API。

有人可能會同樣嘆息其他操作系統仍然不支持wchar_t。所以你也必須支持UTF-8。

其他答案提供了一些關於如何在跨平臺代碼庫中管理這些問題的好建議,但聽起來好像您已經有支持不同字符類型的實現。如果想要簡化代碼,可能聽起來不錯。

4

是它仍然需要使用 窗戶大功能,還是現在我所能做的一切 使用Unicode和UTF-8?

是的。不幸的是,Windows不支持UTF-8。如果您需要適當的Unicode支持,則需要使用版本的Windows API函數wchar_t,而不是版本char

我應該從Windows代碼中刪除TCHAR嗎?

是的,你應該。 TCHAR存在的原因是爲了支持Windows的Unicode和非Unicode版本。非Unicode支持可能在2001年Windows 98仍然流行時受到關注,但不是今天。

而且任何非Windows特定庫都會有相同類型的char/wchar_t超載,這使得TCHAR可用。

所以繼續,用wchar_t s代替您所有的TCHAR s。

代碼在Unix/Mac上用GCC編譯,並用MinGW爲Windows交叉編譯。

我收到編寫跨平臺的C++代碼。 (現在我的工作是編寫跨平臺的C#代碼。)當Windows不支持UTF-8並且Un * x不支持UTF-16時,字符編碼相當痛苦。我最終使用UTF-8作爲我們的主要編碼,並在Windows上根據需要進行轉換。

+1

[UTF-8 Everywhere](http://www.utf8everywhere.org/)也建議在任何地方使用UTF-8並根據需要進行轉換 – 2014-03-28 15:09:42

0

我預測總有一天,儘管可能不會在2020年之前,Windows會添加UTF-8支持,只需添加所有API函數的U版本,以及A和W以及相同類型的鏈接程序黑客。 8位A函數只是本地W(UTF-16)函數的翻譯層。我敢打賭,他們可以從A層半自動生成一個U層。

一旦他們被戲弄夠了,足夠長的時間,他們的「20世紀的Unicode支持...

他們仍然會設法讓它尷尬寫的,醜陋的閱讀和非便攜式的默認情況下,通過使用仔細選擇的宏和默認的Visual Studio設置。

相關問題