例如：
// This will become either SomeMethodA or SomeMethodW,
// depending on whether _UNICODE is defined.
SomeMethod( _T( "My String Literal" ) );
// Becomes either AnotherMethodA or AnotherMethodW.
AnotherMethod( _TEXT( "My Text" ) );
两个我都见过。_T 似乎是为了简洁而 _TEXT 是为了清楚起见。这仅仅是程序员的主观偏好还是比这更具技术性？例如，如果我使用一个而不是另一个，我的代码不会针对特定系统或某些旧版本的头文件编译吗？
SDK 的一个简单的 grep 向我们展示了答案是没关系——它们是相同的。他们都变成了__T(x)。
C:\...\Visual Studio 8\VC>findstr /spin /c:"#define _T(" *.h
crt\src\tchar.h:2439:#define _T(x) __T(x)
包括\tchar.h:2390:#define _T(x) __T(x)
C:\...\Visual Studio 8\VC>findstr /spin /c:"#define _TEXT(" *.h
crt\src\tchar.h:2440:#define _TEXT(x) __T(x)
包括\tchar.h:2391:#define _TEXT(x) __T(x)
为了完整性：
C:\...\Visual Studio 8\VC>findstr /spin /c:"#define __T(" *.h
crt\src\tchar.h:210:#define __T(x) L ## x
crt\src\tchar.h:889:#define __T(x) x
包括\tchar.h:210:#define __T(x) L ## x
包括\tchar.h:858:#define __T(x) x
但是，从技术上讲，对于 C++，您应该使用TEXT()而不是_TEXT()，但它（最终）也会扩展到相同的东西。
提交 Unicode 并使用L"My String Literal".
来自雷蒙德陈：
TEXT 与 _TEXT 与 _T，以及 UNICODE 与 _UNICODE
没有下划线的普通版本会影响 Windows 头文件视为默认的字符集。因此，如果您定义 UNICODE，例如，GetWindowText 将映射到 GetWindowTextW 而不是 GetWindowTextA。同样，TEXT 宏将映射到 L"..." 而不是 "..."。
带有下划线的版本会影响 C 运行时头文件视为默认的字符集。因此，如果您定义 _UNICODE，则 _tcslen 将映射到 wcslen 而不是 strlen，例如。同样，_TEXT 宏将映射到 L"..." 而不是 "..."。
_T呢？好吧，我不知道那个。也许只是为了节省一些打字时间。
短版：_T()是懒人的_TEXT()
注意：您需要了解源代码文本编辑器在编写时使用的代码页：
_TEXT("Some string containing Çontaining");
TEXT("€xtended characters.");
编译器看到的字节取决于编辑器的代码页。
这是来自知名且受人尊敬的来源的有趣读物。
同样，_TEXT 宏将映射到 L"..." 而不是 "..."。
_T呢？好吧，我不知道那个。也许只是为了节省一些打字时间。
我从未见过有人_TEXT()用_T().
这些宏是从应用程序可能实际上想要同时编译 unicode 和 ANSI 版本的时候开始的。
今天没有理由这样做——这都是退化的。微软一直坚持永远支持所有可能的配置，但你不是。如果您没有同时编译为 ANSI 和 Unicode（说实话，没有人编译），只需使用 L“text”。
是的，如果现在还不清楚：_T == _TEXT
两者都不。根据我的经验，有两种基本类型的字符串文字，一种是不变的，另一种是在您的代码本地化时需要翻译的。
在编写代码时区分两者很重要，这样您就不必稍后再找出哪个是哪个。
所以我使用_UT()不可翻译的字符串，和ZZT()（或其他容易搜索的东西）需要翻译的字符串。_T()代码或代码中的实例是_TEXT()尚未正确分类的字符串文字的证据。
_UT并且ZZT都是 #defined 到 _TEXT
两者都不使用，也请不要使用 L"..." 废话。对所有字符串使用 UTF-8，并在传递给 Microsoft API 之前对其进行转换。