软件国际化的思考

　　元旦这几天都在睡梦中度过了，只正经地思考了一件事，就是软件国际化的问题。

　　国际化（Internationalization，这个又长又丑的单词，＝ ＝＃），也被称为I18n，技术一点来讲就是准备让软件支持多个区域文化（语言）的活动。这个问题在过去的一年也曾思考过，在国内这是一个非常头痛的问题。对于一般软件来说，软件支持中文，这是一个很不错的亮点。但对于一些高端的产品来说，特别是同类产品都没有支持中文的时候，我们就很担心，一旦支持了中文，会不会对未来用户对我们的产品的印象带来不好的影响。

　　这几天云风在他的博客中就提到这个问题，当然，他们已经不是思考要不要用进行国际化的问题了，而是总结在使用 Unicode 过程中的一些经验。

　　于是，这两天重新对国际化这个问题进行思考，想想如果不国际化的时候应该注意哪些问题，如果产品要国际化的时候要注意哪些问题。

　　事实上，国际化要考虑地问题很多，包括大量的状态提示、帮助信息、错误信息，等等。这就要估算这些 String 所用到的资源，如何组织不同的语言，何时确定使用哪种语言，还有使用何种字符集（Unicode、ISO8859、GBK、GB18030，等等），一旦有了改变，以前的数据怎么办些都是非常复杂的问题，都得从架构层次上来考虑。因此，很认为云风所讲的，VC 提倡的所谓为软件维护 UNICODE 和 非 UNICODE 两个版本是件巨傻 X 的事情。

　　以下是翻阅了《代码大全》之后思考的总结：

1. 如果你知道只需要支持一种文字的语言，请考虑使用 ISO8859 字符集。
2. 如果你需要支持多种语言，请使用 Unicode。
3. 采用某种一致的字符串类型转换策略。也就是字符串在程序内部统一使用一种字符集，同时尽可能地靠近输入和输出操作的位置转换成其他格式。

　　其实，我个人的看法，软件应该从架构上支持国际化，现在很多国际化的方案都是把本地化跟编程分离开来的，比如 GNU Gettext，对开发不会有多大的影响。同时，担心上了中文会影响用户的印象，其实是对自己的不自信。综观发展，其实中文程序是未来一段时候一个不小的市场，有谁愿意用起软件来，在手旁还要放块字典来的。然而，也只有中国人才能了解中国人，自己都不做，心里觉得怪怪的。

　　ASCII to Unicode：

1. 添加 UNICODE,_UNICODE 预处理定义：Project Settings -> C/C++ -> Preprocessor definitions
2. 将 Project Settings -> Link -> CateGory:Output -> Entry Point 设为 wWinMainCRTStartup
3. 对字符串常量使用前缀L： L”String”
4. 使用宽字符相关类型，如：char -> TCHAR、char * -> LPTSTR、const char * -> LPCTSTR
5. 替换C库中的中字符串操作函数，如 strlen -> _tcslen、strcmp -> _tcscmp 等
   类似的还有C库中字符串与数字的转换函数，如 atoi -> _ttoi、itoa -> _itot 等
6. 对于仍需使用ANSI字符串的地方，如第三方类库的接口，仍可继续使用；如需进行Unicode字符串和ANSI字符串的互转换，可使用 MultiByteToWideChar 和 WideCharToMultiByte

　　相当参考：
　　　　Unicode and Multibyte Character Set (MBCS) Support