我想向我正在维护的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