wchar_t vs char用于创建API
我正在创建一个C ++库，用于与不同语言编写的不同应用程序，如Java，C＃，Delphi等。
我偶尔会遇到wstrings，strings，char *，wchar_t *之间的转换。 例如，我坚持使用wchar_t，但必须使用正则表达式库来接受其他类似问题。
我希望坚持使用w或普通字符串。 我的库主要处理ASCII字符，但也可以有非ASCII字符，如名称等。所以，我可以永久切换到char而不是wchar_t和字符串而不是wstring。 我可以使用unicode支持，并且会影响不同平台和语言的可扩展性和可移植性。
请指教。
您需要决定使用哪种编码。 一些考虑：
-
如果您可以使用非ASCII字符，那么选择ASCII或8位ANSI是没有意义的。 这种方式会导致失望并导致数据丢失。
-
选择一种编码并坚持下去是有道理的。 到处。 Windows API在支持ANSI和Unicode方面不常见，但这是由于旧软件的向后兼容性。 如果微软从头开始，那么只会有一个编码。
-
Unicode编码最常见的选择是UTF-8和UTF-16。 任何体面的环境都将支持两者。 任何一种选择都是合理的。
-
Java，VB，C＃和Delphi都对UTF-16有很好的支持，并且所有这些都使用UTF-16作为其原生字符串类型（在Delphi的情况下，本机字符串类型仅在Delphi 2009及更高版本中为UTF-16）对于早期版本，您可以使用
WideString字符串类型）。 -
大多数操作系统平台本身都是UTF-16（* Nix系统，如Linux，而不是UTF-8），所以最简单的方法就是使用UTF-16。
-
另一方面，UTF-8可能是技术上更好的选择，面向字节，向后兼容8位ASCII。 很可能，如果从头开始发明Unicode，就没有UTF-16和UTF-8将是可变长度编码。
你已经把这个问题作为char和wchar_t之间的选择。 我认为真正的选择是您的首选编码应该是什么。 您还必须注意wchar_t在某些系统上是16位（UTF-16），而在其他系统上是32位（UTF-32）。 它不是便携式数据类型。 这就是为什么C ++ 11引入了新的char16_t和char32_t`数据类型来纠正这种歧义。
Unicode和简单char之间的主要区别是代码页。 只有一个char*指针不足以理解字符串的含义。 它可以是某种特定的编码，也可以是多字节等。宽字符串没有这些警告。
在许多情况下，国际方面并不重要。 在这种情况下，这两种表示之间的差异是最小的。 您需要回答的主要问题是：国际化是否对您的图书馆很重要？
现代Windows编程应该倾向于定义UNICODE构建，因此使用宽字符和宽字符API。 这对于提高性能（Windows API层后面的转换次数较少或没有），改进的function（有时ANSI包装器不公开宽函数的所有function）是理想的，并且通常它避免了无法表示字符的问题不在系统的当前代码页上（因此实际上无法表示非ASCII字符）。
当你不得不与不使用宽字符的东西进行交互时，这可能很困难。 例如，虽然Windows API具有宽字符文件名，但Linux文件系统通常使用字节串。 虽然这些字节串按常规通常是UTF-8，但实施起来很少。 如果所讨论的语言不能理解API级别的宽字符，则与其他语言的接口也很困难。 理想情况下，此类语言选择了特定的编码，例如UTF-8，允许您在边界处进行转换。
这是一个一般性建议：在内部使用Unicode进行所有处理，并在边界处根据需要进行转换。 如果您还不熟悉这一点，那么引用Joel关于Unicode的文章是很好的 。