Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Difference between Asc and AscB 3

Status
Not open for further replies.

moonbase

Programmer
Nov 18, 2002
57
GB
Why does AscB(Chr(&H1B)) = 26 Correct
and AscB(Chr(&H82)) = 26 ???????

whereas Asc(Chr(&H1B)) = 26 Correct
and Asc(Chr(&H82)) = 130 Correct
 
From the help file:

"Note the AscB function is used with byte data contained in a string. In stead of returning the character code for the first character, AscB returns the first byte."

Roy-Vidar
 
So why does AscB(Chr(&H82)) = 26 when it should be 130
and AscB(Chr(&HFF)) = 255 which is correct?
 
> So why does AscB(Chr(&H82)) = 26 when it should be 130

nope - it shouldn't be 130. 130 is the character code for one character, but you ask for the first byte. How the number 26 is calculated, I do not know, but it probably has something to do with how strings are represented in memory (BSTR).

Here's a quicky to demonstrate the point - check out the help file for the Len and LenB functions (the first returns the length of the string (number of characters), the second returns the number of bytes used to represent the string)

[tt]? Len(Chr(&H82)), LenB(Chr(&H82))[/tt]

See - and through using the AscB function, you're just picking up the first byte.

Roy-Vidar
 
The issues are that

1) VB (more properly Windows) doesn't actually use ASCII character sets; ASCII, to all intents and purposes, was abandoned years ago.
2) ASCII was a 7-bit code, only giving specific codes to 127 characters (values 0 to 126), although there were several extensions that took this to 256 characters, the most predominant being ANSI. This in turn was superceded by ISO 8859
3) The VB documentation is vaguely misleading because it doesn't give the background

What Windows uses is Unicode, which is a huge character set (latest definition file here: which contains all the characters that exist in ASCII, in ANSI and in ISO 8859.

So what Windows and VB do for you is some lookup work to determine the correct Unicode character for a given ASCII character (and this is what they stick into the BSTR, the Unicode character, which is two bytes). Up to character 126 there is a direct 1 to 1 correlation (ASCII/ANSI/ISO 8859 character 32 is Unicode character 32). However above 126 there is no direct correlation (there's not really the time to go into explanations of code pages etc here). For example, under ISO 8851-1 (latin-1 or what Windows often calls Windows Western), ANSI character 128 is actually Unicode character 8364 (which in hex would be 20AC)

Now, in VB, when Using the Asc function we just get back the ANSI value of the character. When we use AscB what we actually get back is just the first byte of the stored Unicode value

In your specific case, ANSI character &H82 is mapped to Unicode value &H201A, which is stored lobyte hibyte in the string (1A 20), and AscB retrieves the first byte (&H1A), giving the result of 26 ...
 
(oops. Brain on weekend mode: ASCII is 128 characters, 0 to 127)
 
Yes, AscB() is usually used along with functions like MidB$() to address the bytes within a string variable in stead of the (Unicode) characters.

There is also AscW() as well of course.

On Win9x results can be different because of the lack of full Unicode support.
 
Thanks. It's clear now. In my simple mind I had thought that AscB would be correct to use with byte data. However what I really want is the Asc value to store in the byte.
 
Good post, strongm.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top