Unicode环境下的字符差异

Posted 2020-09-20 Autumn の Box

　　我总是对我的字符串使用_T()宏，这是为了让我的代码至少有Unicode的意识，当然，关于Unicode的话题不在这篇文章的讨论范围。_T()宏在8位字符环境下是如下定义的：

　　　　#define _T(x) x // 非Unicode版本（non-Unicode version）

　　而在Unicode环境下是如下定义的：

　　　　#define _T(x) L##x // Unicode版本（Unicode version）

　　所以在Unicode环境下，它的效果就相当于：

　　　　s.Format(L"%d", total);

　　如果你认为你的程序可能在Unicode的环境下运行，那么开始在意用 Unicode 编码。比如说，不要用 sizeof() 操作符来获得字符串的长度，因为在Unicode环境下就会有2倍的误差。我们可以用一些方法来隐藏Unicode的一些细节，比如在我需要获得字符长度的时候，我会用一个叫做DIM的宏，这个宏是在我的dim.h文件中定义的，我会在我写的所有程序中都包含这个文件：

　　　　#define DIM(x) ( sizeof((x)) / sizeof((x)[0]) )

　　这个宏不仅可以用来解决Unicode的字符串长度的问题，也可以用在编译时定义的表格上，它可以获得表格的项数，如下：

　　　　class Whatever { ... };

　　　　Whatever data[] = {

  　　　　 { ... },

   　　　　 　...

  　　　　 { ... },

　　　　};

　　　　for(int i = 0; i < DIM(data); i++) // 扫描表格寻找匹配项。

　　这里要提醒你的就是一定要注意那些在参数中需要真实字节数的API函数调用，如果你传递字符个数给它，它将不能正常工作。如下：

　　　　TCHAR data[20];

　　　　lstrcpyn(data, longstring, sizeof(data) - 1); // WRONG!

　　　　lstrcpyn(data, longstring, DIM(data) - 1); // RIGHT

　　　　WriteFile(f, data, DIM(data), &bytesWritten, NULL); // WRONG!

　　　　WriteFile(f, data, sizeof(data), &bytesWritten, NULL); // RIGHT

　　造成以上原因是因为lstrcpyn需要一个字符个数作为参数，但是WriteFile却需要字节数作为参数。

　　同样需要注意的是有时候需要写出数据的所有内容。如果你仅仅只想写出数据的真实长度，你可能会认为你应该这样做：

　　　　WriteFile(f, data, lstrlen(data), &bytesWritten, NULL); // WRONG

　　但是在Unicode环境下，它不会正常工作。正确的做法应该是这样：

　　　　WriteFile(f, data, lstrlen(data) * sizeof(TCHAR), &bytesWritten, NULL); // RIGHT

　　因为WriteFile需要的是一个以字节为单位的长度。（可能有些人会想“在非Unicode的环境下运行这行代码，就意味着总是在做一个多余的乘1操作，这样不会降低程序的效率吗？”这种想法是多余的，你必须要了解编译器实际上做了什么，没有哪一个C或C++编译器会把这种无聊的乘1操作留在代码中。在Unicode环境下运行的时候，你也不必担心那个乘2操作会降低程序的效率，记住，这只是一个左移一位的操作而已，编译器也很乐意为你做这种替换。）

　　使用_T宏并不是意味着你已经创建了一个Unicode的程序，你只是创建了一个有Unicode意识的程序而已。如果你在默认的8-bit模式下编译你的程序的话，得到的将是一个普通的8-bit的应用程序（这里的8-bit指的只是8位的字符编码，并不是指8位的计算机系统）；当你在Unicode环境下编译你的程序时，你才会得到一个Unicode的程序。记住，CString 在 Unicode 环境下，里面包含的可都是16位的字符哦。