我想将Unicode支持添加到我正在维护的C库中。目前，它希望所有字符串都以utf8编码传递。根据反馈，似乎Windows通常提供3个功能版本。
是否有一种简单的方法来添加此支持而无需自己编写大量的包装函数？一些功能可以从库和用户调用，这使情况稍微复杂化。
我想继续支持utf8字符串，因为该库可以在多个操作系统上使用。
答案 0 :(得分：4)
没有后缀的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的POSIX接口使用UTF-8，其他所有东西使用UTF-16（Carbon，Cocoa）。
关于术语的一些注意事项：Microsoft文档中使用的“ANSI”和“Unicode”字样与国际标准所说的不符。当Microsoft说“Unicode”或“宽字符”时，它们表示“UTF-16”或（历史上）其BMP子集（每个代码点具有一个代码单元）。用于Microsoft术语的“ANSI”意味着一些依赖于区域设置的遗留编码，这在所有现代版本的Windows中都已完全过时。
如果您需要明确的建议，请选择UTF-16和ICU库。
答案 1 :(得分：1)
由于您的库已经需要UTF-8编码的字符串，因此它已经完全支持Unicode，因为UTF-8是一种无损Unicode编码。如果您想在通常使用UTF-16甚至UTF-32字符串的环境中使用您的库，那么在与您的库交谈时，它可以简单地编码到UTF-8并从中解码。否则，您的库必须公开额外的UTF-16/32函数，这些函数在内部执行那些编码/解码操作。