非常固执己见，但基于经验答案

我开始之前，让我声明我已经在C++软件上工作了五年，在全球拥有数百万用户 - 在此过程中，我学到了很多关于现实世界中事物如何运作的知识。

首先要了解的是Windows固有地使用它（最初是土生土长的）UTF-16标准（又名宽字符）。这样做会让你的生活变得更加艰难。（几乎）所有其他操作系统都使用 UTF-8。我的意思是;OS X，*NIX，Android，ios，几乎任何你可以扔C++编译器的东西。

因此，您是否打算在Windows之外使用您的代码？如果你不这样做，没有理由不以"窗口方式"来做，std::wstring成为你最好的朋友。您可以轻松地使用 .c_str() 来获取const wchar_t *（并且隐式转换为 LPCWSTR）。许多这些窗口类型（如LPCWSTR和TCHAR）实际上是宏（又名#define）你可以在这里阅读更多。

您是否应该为 UTF-16 宽字符而烦恼？思考"如果我忽略不使用拉丁字母的语言怎么办"是非常非常非常的，当我说，不要时，请相信我。是的，您可以仅使用多字节字符，也可以仅隐式调用 API 函数的 A 变体。但是，虽然这有效（并且非常好），但如果您支持拉丁语类型以外的任何语言，则会遇到问题。即使您不这样做，用户也会期望用他们的母语输入。

博士

只有英语，跨平台？-简而言之，在Windows编程中仅使用Ansi 8位字符串本身并没有错 - 它不会使互联网崩溃，如果您编写的内容肯定只会被跨平台的英语使用者使用（美国软件？），那么我实际上建议您将项目更改为Multi-Byte，并将std::string用于所有内容， 只是不要指望打开具有国际文件名的单个文件.
请记住，如果您的用户群数以千计，则为数以万计，人们会因无法加载汉字文件名而感到轻微的愤怒。

国际，仅限视窗 -如果你的软件甚至接近瑞典的互联网边界（在那里它需要加载一个用Goa'uld写的文件名），使用std::wstring，使用UTF-16，并在仅限Windows的软件中感到高兴。老实说，这是当今大多数Windows软件的状态。

国际，Mac很酷吗？您的项目经理昨天想要跨平台软件，它需要在 Mac 和 PC 上运行 - 因为它被部署到的用户是 16% 的 mac 用户（根据营销），并且它需要对阿拉伯语和日语提供 IME 支持><。告诉你的项目经理你要为你所有的API调用写一个包装器，这将需要一周的时间，但如果他不同意，可以防止任何跨平台语言的废话 - 退出。

然后这样做，在引擎盖下使用 UTF-8，并使用您自己编写的包装类处理对 Windows/mac 系统的任何 API 调用。是的，这将需要一些努力和维护，但从长远来看，它可以节省大量时间。

额外链接

如果您需要非常复杂的 unicode 支持，请查看 ICU 库，OSX 在后台使用它！学习使用 BOOST - 仅文件系统支持就使跨平台C++开发速度更快

那么，总是使用TCHAR？

不是真的推荐，因为这是窗口唯一的宏。但是，如果您打算在其他平台上使用它，那么定义自己的TCHAR很容易。就我个人而言，我总是使用TCHAR - 因为我工作的应用程序是作为仅限Windows的项目开始的。

唱Unicode，一个wchar_t。那么，总是使用TCHAR？但随后你会发现这样的问题，比如 TCHAR 仍然相关吗？ 好吧，让我们用别的东西...？

默认情况下，Visual Studio 将创建定义 UNICODE 宏的项目，这意味着所有 Win API 函数都将接受 WCHAR 字符串，这也意味着 TCHAR 将解析为 WCHAR -> wchar_t。因此，如果您严格只使用Windows UI，那么最好使用wchar_t和std：：wstring。

如果我正在编写一个不会被翻译成其他语言的程序，我应该使用什么？ 如果我正在编写一个将被翻译成其他语言的程序，我应该使用什么？ ...

你为什么认为它不会？我建议你为最糟糕的场景准备代码，你的代码必须接受中国符号。因此，如果某些资源中有文本，请将它们保留在 UTF8 中，然后在 c++ 代码中使用 char 字符串来管理它们。当您需要使用某些Windows API显示它们时，请将它们转换为wchar_t。编写可移植代码，即。一个不使用任何TCHAR，WCHAR的后端 - 以及将与MFC或WinAPI或QT等平台API通信的前端。