我想向我正在維護的C庫添加Unicode支持。目前它期望所有的字符串都以utf8編碼傳遞。根據反饋，似乎windows通常提供3個功能版本。將Unicode支持添加到Windows的庫中
有一種簡單的方法來添加這種支持不自己寫了很多封裝函數？一些功能可以從庫和用戶調用，這使情況變得複雜一點。
我想繼續支持utf8字符串，因爲這個庫可以在多個操作系統上使用。
foo沒有後綴的函數實際上是宏。 fooA功能已過時，並且只是簡單的圍繞fooW函數的包裝，它們是實際執行工作的唯一功能。 Windows對所有內容使用UTF-16字符串，因此如果要繼續使用UTF-8字符串，則必須將它們轉換爲每個API調用（例如使用MultiByteToWideChar）。
對於您的庫的公共接口，請嚴格遵循一種編碼，即UTF-16，UTF-32或UTF-8。其他所有內容（取決於語言環境或取決於操作系統的編碼）對於調用者來說太複雜。您不需要UTF-8與其他操作系統兼容：許多獨立於平臺的庫（如ICU，Qt或Java標準庫）在所有系統上使用UTF-16。我認爲這三種Unicode編碼之間的選擇取決於您期望該庫最常用的操作系統：如果它主要在Windows上使用，請使用UTF-16，以避免所有字符串轉換。在Linux上，UTF-8是文件系統或終端編碼的常用選擇（因爲它是唯一一個具有8位寬字符單位的Unicode編碼），但請參閱上面有關庫的註釋。 OS X使用UTF-8作爲其POSIX接口，UTF-16使用其他所有內容（Carbon，Cocoa）。
關於術語的一些說明：Microsoft文檔中使用的「ANSI」和「Unicode」一詞不符合國際標準的說法。當Microsoft提到「Unicode」或「寬字符」時，它們表示「UTF-16」或（歷史上）其BMP子集（每個代碼點具有一個代碼單元）。 Microsoft術語中的「ANSI」表示一些現代版本的Windows中完全過時的某些與區域相關的傳統編碼。
如果你想要一個明確的建議，去UTF-16和ICU庫。
由於您的庫已經需要UTF-8編碼的字符串，因此它已經完全支持Unicode，因爲UTF-8是一種無損Unicode編碼。如果您想在通常使用UTF-16或甚至UTF-32字符串的環境中使用您的庫，那麼在與庫進行交談時，它可以簡單地編碼爲UTF-8並從中解碼。否則，你的庫將不得不公開額外的UTF-16/32函數來進行內部的編碼/解碼操作。
很久以前我曾經這樣做過。要求是，唉，編寫一個轉換層，所以我最終不得不復制結構並用轉換代碼包裝函數，以便在字符串轉換之間在結構之間複製數據。不要這樣做。我會嘗試並公開一個純粹的unicode接口，並儘可能在Unicode中對字符串進行操作，並且只有在其他地方的互操作性需要時才轉換爲UTF8。但我不知道如何建議你以簡單的可維護方式來做到這一點。在任何情況下，我建議你忽略ANSI並只顯示Unicode或UTF8，如果你絕對必須的話。 – Rup 2010-06-30 11:47:24