作者：zyl910

　　将Windows程序移植到Linux等平台时，经常会遇到tchar.h问题与字符串的格式控制字符问题（char串、wchar_t串、TCHAR串混合输出）。本文探讨如何解决这些问题。

一、背景

1.1 历史

　　传统的C程序使用char字符串，采用ANSI+DBCS方案来支持当地语言，不能实现多国语言同时显示。

　　当年微软在设计Windows NT时考虑到国际化，决定内核支持Unicode，对应wchar_t类型。那时的Unicode只有16位，于是Windows中的wchar_t是16位的。
　　为了兼容老程序，与字符串有关的API一般有两套——A结尾的表示是ANSI版，使用char字符串；W结尾的是Unicode版，使用wchar_t字符串。
　　两套API用起来不方便，于是微软设计了tchar.h，定义了TCHAR类型，使用宏来切换。只需编写一份代码，就可分别编译为ANSI版与Unicode版，分别兼容老系统（win9X）和新系统（winNT）。

　　Linux等平台较晚才支持Unicode，那时已经有成熟的UTF-8编码方案，兼容传统的char类型。于是Linux等平台将UTF-8作为默认编码，这样不仅支持Unicode多国语言，而且传统的C标准库、POSIX等API均能正常工作。两全其美，不再需要搞两套API，自然也不需要tchar.h。
　　UTF-8是变长编码，一个字符可能是1至4字节，处理起来不太方便。于是Linux等平台也提供了wchar_t类型，只不过它是32位的。

　　为什么是32位的的呢，这与Unicode的发展有关。由于Unicode需要收录的东西太多，16位早就不够用了。
　　UCS-4 提倡31位的编码空间，并提出了UTF-32和6字节UTF-8等编码方案。可是该方案的成本很高。
　　进过折衷考虑，Unicode组织将编码空间由16位的0至FFFF，升级至21位的0至10FFFF。将传统16位Unicode编码称为utf-8，并提供代理对（surrogate）方案，用两个utf-8字符单元来编码超过16位的字符。
　　也就是说，如果wchar_t类型是16位的话，那它实际上代表utf-8编码——对于在U+0000至U+FFFF之间的字符，每个字符占1个wchar_t；对于在U+10000至U+10FFFF之间的字符，每个字符占2个wchar_t。
　　为了确保每个字符都只占1个wchar_t，那就得将wchar_t定义为32位。这也就是UTF-32编码。

　　虽然UTF-8编码方案本身能表达很大的编码空间（例如6字节UTF-8可编码31位），但为了规范化，RFC 3629规定UTF-8最长为4字节，即最高21位编码，超过10FFFF的编码点是无效的。

1.2 为什么需要让Linux等平台也支持tchar.h？

　　很多人认为Linux等平台没必要支持tchar.h，这主要是因为wchar_t的一些问题——
1. UTF-8编码的char类型能满足Unicode国际化需求。
2. char类型更容易跨平台。而wchar_t是C95修订中加入的，到C99标准才有比较完善的支持，故某些旧编译器对wchar_t支持性不佳、甚至完全不支持。
3. wchar_t的位数不固定。在Windows平台中它是16位，而在Linux等平台中它是32位的。C99标准并没有严格规定wchar_t的位数。
4. wchar_t版函数与char版函数不对称。在C99的C标准库中，只有部分字符串函数有wchar_t版。虽然Windows平台上有A、W两套对称的API，但其他平台只有一套API。

　　以前我也赞同上述观点，但是现在我觉得有一个tchar.h会方便很多，理由有——
1. 方便Windows程序移植。很多控制台程序只进行了一些很简单的字符串操作，不会遇到wchar_t的缺陷。如果仅因缺少tchar.h问题而改动代码的话，那就成本太高了。
2. 无副作用。对于Linux等只有一套API的平台，可以取消UNICODE宏，这样tchar.h会将TCHAR映射为char，使用传统的窄字符串版函数。
3. 避免printf/wprintf混用时的Bug。printf与wprintf内部使用的是不同的缓冲区，混用会造成Bug。统一使用TCHAR能避免该bug。

1.3 字符串的格式控制字符问题

　　除了tchar.h问题外，在跨平台操作字符串时还会遇到格式控制问题。例如这些问题——
1. 在printf中使用哪种格式控制字符来输出 char字符/字符串？
2. 在printf中使用哪种格式控制字符来输出 wchar_t字符/字符串？
3. 在printf中使用哪种格式控制字符来输出 TCHAR字符/字符串？
4. 在wprintf中使用哪种格式控制字符来输出 char字符/字符串？
5. 在wprintf中使用哪种格式控制字符来输出 wchar_t字符/字符串？
6. 在wprintf中使用哪种格式控制字符来输出 TCHAR字符/字符串？

　　C99标准比较保守，不能完全解决上述问题。C99标准中对c、s仅存在“l”长度修正——没“l”的是char字符串，有“l”的是wchar_t字符串。详见C99标准的“7.24.2.1 The fwprintf function”。

　　VC++因为需要处理两套字符串API，所以它对该问题的支持非常完善。VC++中上述6个问题的答案是——
1. hc/hs。
2. lc/ls。
3. c/s。
4. hc/hs。
5. lc/ls。
6. c/s。

　　对于BCB、MingGW等Windows平台上的编译器，它们也兼容VC++的做法，支持这些格式控制字符。

　　而对于Linux等平台的gcc，它紧跟C99标准，不支持那么多格式控制字符。

　　我以前做过测试，详见——
http://www.cnblogs.com/zyl910/archive/2012/07/30/wcharfmt.html
[C] wchar_t的格式控制字符（VC、BCB、GCC、C99标准）》

1.4 _tmain入口函数问题

　　标准C使用main函数作为程序入口，其格式为——
int main(int argc, char* argv[])

　　VC++考虑到到TCHAR类型的命令行参数，于是又定义_tmain程序入口，其格式为——
int _tmain(int argc, TCHAR* argv[])

　　目前VC++对_tmain的支持较好，而MinGW等编译器对_tmain较差，有些只支持C标准的main。

二、解决方案

2.1 auto_tchar.h：使各种编译器兼容tchar.h

　　我编写了auto_tchar.h，它根据编译预处理判断该编译器是否支持tchar.h。若支持，便包含编译器的tchar.h；若不支持，则自己实现tchar.h，参考了 MinGW 的 tchar.h. http://www.mingw.org/。

　　在测试时发现，BCB6的tchar.h中没有定义TCHAR，只定义了_TCHAR。TCHAR是在winnt.h中定义的。于是做了如下修正——

　　使用方法——
1. 将“auto_tchar.h”放在项目的include目录中。
2. 将原来的“#include <tchar.h>”改为“#include "auto_tchar.h"”。

2.2 prichar.h：解决字符串的格式控制字符问题

　　怎么解决各个编译器对格式控制字符的差异呢？
　　我从C99标准的inttypes.h找到了灵感。inttypes.h定义了一系列PRI开头的宏，解决了各种整数的格式控制字符问题。
　　我们也可以这样做，编写一个头文件，里面定义了一系列字符串的PRI宏。同时利用编译预处理判断各种编译器，定义合适的常量。

　　我编写了prichar.h，定义了这些宏——
SCNcA
SCNsA
SCNcW
SCNsW
SCNcT
SCNsT
PRIcA
PRIsA
PRIcW
PRIsW
PRIcT
PRIsT

　　前缀含义——
PRI: print, 输出.
SCN: scan, 输入.

　　中缀含义——
c: char, 字符.
s: string, 字符串.

　　后缀含义——
A: char, 窄字符版.
W: wchar_t, 宽字符版.
T: TCHAR, TCHAR版.

　　使用方法——
1. 将“prichar.h”放在项目的include目录中。
2. 包含该头文件（#include "prichar.h"）。
3. 代码示例——