纠结vc中的string table资源的使用

来源:互联网 发布:威廉玛丽学院 知乎 编辑:程序博客网 时间:2024/04/27 19:01

以下为从网上搜集到得资料,本人太菜,关于具体的使用暂时还未搞明白,暂且把下文粘贴如此,进一步的使用方法搞明白后示于此。

VC++2005 StringTable资源类型研究

May 21, 2007 at 23:32 · Filed under Windows by zhangdi

 

在来到新公司之前,对于Windows编程实在不熟悉,更别说VC++中的Resource的实现了。工作的时候,同事提到了StringTable实现本地化的问题。当时我也很模糊,说不出个准确答案。周末回家研究了两天,算是搞明白了。

先说说我之前比较困惑的几个问题:

  • 在编译完成的二进制文件中,StringTable到底是按照什么方式存储的,简单说,就是按照什么编码方式存储的?
  • Windows已经支持了Unicode,为什么在VC++的StringTable Editor中,还要选择语言?
  • 如果使用了Unicode,怎么有的时候,应用程序还会出现乱码?
  • 如果是Unicode编码,那么是按照什么格式存储的,UTF-8,UTF-16?

 

当然,对于这些问题,可能对于一些牛人来说不算什么,都是很简单的问题。不过,对于我来说,还是很麻烦的,因为网上没有很直接解释这些问题的文章,最终还是自己一点一点研究出来的。

首先,需要复习和学习一些知识:

在计算机诞生的初期,操作系统只支持最多256个字符,就是著名的ASCII字符集。但是随着计算机在世界上各个国家的发展,本地化的需求越来越多,256个字符明显不够,就有一些国家发明了自己的字符集,也可以说是编码标准,不过这些编码方式都是只考虑自己国家的语言(当然不会有一个国家为了发展自己的科技,还要替别人着想),比如,ISO-8859-1,GB2312等等,在Windows里面,这类编码的体现就是我们熟悉的Code Page。在VC++中,Code Page是使用数字来代表的,比如:936是简体中文Code Page,1256是阿拉伯语言的Code Page。这样显然不爽,随着计算机的普及,Code Page会越来越多,并且很多Code Page可能相差不多,但是为了支持相应的用户,应用程序(包括操作系统)就不得不对之提供支持,这大大提高了软件的成本。终于,一些软件业的巨头决定做一件一劳永逸的事情,就是创造一个字符编码方式,能支持世界上所有的字符,这个字符集编码叫做Unicode。它设计可以支持11万多的字符,被认为足够放下世界上已知的所有字符(其中,中文字符占了2万多,英文只占52个)。而我们经常看到的UTF-8,UTF-16,UTF-32都是Unicode的一种存储方式。

言归正传,回答自己的四个问题:

  • 从Windows2000开始,Windows已经完全支持了Unicode,所以StringTable在二进制文件(*.dll、*.exe)中确实是以Unicode编码存储的。
  • 在StringTable Editor中,之所以要为StringTable选择相应的语言,是因为StringTable Editor中不是以Unicode存储的,而是基于Code Page编码存储的。所以必须对自己的StringTable选择正确的Code Page,否则系统将不能正确处理。因为在编译的时候,VC++的Resource Compiler会自动调用MultiByteToWideChar这个API,将字符串从Code Page编码方式转化为Unicode,如果Code Page选择不正确,那么转换也就必然不正确了。
  • 出现乱码一个原因是操作系统不支持Unicode,比如Windows98之前的版本。或者是没有将默认编码设置为Unicode。
  • 在Windows中都是使用UTF-16来存储Unicode的。UTF-16正好是两个字节,也就是我们使用的WCHAR类型。

 

需要说的是,StringTable Editor不是使用Unicode来存储,是因为历史原因。早期的VC++是不支持Unicode的