文章关键字 ‘AscW’

AscW函数返回负数的问题

2010年09月29日，星期三

其实这个问题在以前写《VBS实现PHP的urlencode函数》的时候就碰到了，但是当时没有记下来，造成写前面一篇文章《VBS实现Unicode转UTF-8》的时候重蹈覆辙。还是记录下来吧，免得以后又忘记。

MSDN文档对AscW的说明是：AscW是为使用Unicode字符的32位平台提供的。它返回Unicode（宽型）字符代码，因此可以避免从ANSI到Unicode的代码转换。

按照参考手册的定义，AscW函数应该返回一个字符的Unicode字符编码，但是直接拿返回的结果来用的话会有潜在的BUG，正如我碰到的。

“魔”字的Unicode编码是39764，测试如下代码

c = AscW("魔")
If c > 127 Then
	WScript.Echo "Not ASCII"
Else
	WScript.Echo "ASCII"
End If

你认为返回的结果是什么？"Not ASCII"？错！返回的结果是"ASCII"。

这就是潜在的BUG，对某些中文（当然还有其他字符）AscW函数返回的值是负数！如果你的代码拿这个值与一个正数比较大小，逻辑值将是False！

为什么呢？因为AscW的返回值的子类型是Integer，而VBS中Integer的取值范围是从-32768到32767。39764 > 32767，造成了溢出，所以返回负数。

怎样才能得到正确的结果呢？答案把子类型是转化成Long，Long的取值范围是-2,147,483,648到2,147,483,647，不会造成溢出。

WScript.Echo CLng("&H" & Hex(AscW("魔")))

先用Hex函数把AscW的返回值转化成十六进制的字符串，加上VBS中十六进制前缀&H，最后用CLng函数把子类型转化成Long。这样就能得到39764这个正确的Unicode编码值了。

标签：, , ,
发布在 程序设计 | 3 条评论 »

Asc/AscB/AscW和Chr/ChrB/ChrW函数之间的区别

2010年06月15日，星期二

翻译自微软帮助和支持，感谢公子的大力协助。http://support.microsoft.com/kb/145745/en-us/

概要：多年来，BASIC程序员一直使用Asc和Chr函数来访问和操作ASCII字符集。随着Unicode被主流操作系统和应用程序所接受，需要改进版本的Asc和Chr函数已经开发了。为了满足这种需求，针对Windows系统的Microsoft Visual Basic（4.0以及更高版本）包括了AscB、ChrB和AscW、ChrW函数。

更多信息：Unicode是一种为代替ANSI标准而设计的，把字符编码成数值形式的标准。因为ANSI标准只使用单个字节来代表每个字符，它受最大256个字符的限制。虽然这对于英语受众来说已经足够，但当考虑到全球软件市场时，它无法满足。使用Unicode标准，每个字符由两个字节表示，因此整个的Unicode字符集包括了65536个可能的位置。

微软的Windows NT, Windows 2000, and Microsoft OLE 2.0完全基于Unicode设计，而且Visual Basic（4.0以及更高版本）在内部使用Unicode格式来表示所有的字符串。AscW和ChrW函数允许对Unicode字符的全范围访问。这些函数和原始的Asc、Chr函数运行方式相同，唯一的区别在于新函数支持0到65536的参数，而原来的只能是0到255。许多Visual Basic对象（例如调试窗口、标签、文本框），当它们不知道怎样显示一个Unicode字符时，会返回一个“？”。

因为所有的字符串现在在内部由Unicode格式表示，它不像以前表示一个字符串里的二进制数据那样简单。使用Chr函数来分配数据给一个字符串的结果不再向以前一样。例如：

stringvar = Chr(65)

结果是一个两字节长的字符串，其中第一字节的值为65，第二字节的值为0（这是Unicode表示的字母“A”）。需要记住的是，从ANSI转换至Unicode并不总是意味着像这个例子里做的那样，仅仅添加一个值为0的第二字节。例如，大多数在130~159范围内的ANSI字符码拥有完全不同的Unicode值。尝试运行’Debug.Print AscW(Chr(130))’，然后一个8218的值会显示出来。

（更多…）

标签：, , , , , , , ,
发布在 程序设计 | 4 条评论 »