precise range of ascw()

[Xandy]

I shift chars in unicode with ascw(). I need to be able to decode the data by shifting back to the origin. It becomes crucial that I know the max integer value ever returned by ascw() so that when I shift to a value greater I can subtract the max. Completely reversible. I am having trouble writing a test to find the max because of my character font set.

So far I am thinking ascw() returns 65536 values. Implying the range produced is 0..65535 is that correct?

edit:

opps nevermind, I'm thinking of this wrong. I get to makeup my own range, provided I don't go beyond the scope of an integer.

I would still like to know the max range however, if someone knows.

Edited February 19, 2012 by Xandy

[jchd]

I can only give you my educated guess answer (which I believe is correct anyway) since I'm not in the Dev team.

Despite what you can read here and there, current AutoIt doesn't support Unicode, strictly speaking. Rather it supports only a part of it, and the most needed part. To make a long story short, AutoIt supports the UCS-2 part of Unicode (approximately: codepoints which use a single 16-bit encoding unit in UTF-16 encoding). Hence you'll run into issues if you need to use codepoints needing more than 16 bits.

AscW() is the inverse function of ChrW(), which clearly says (see help) that the allowable range is 0..65535 just as you correctly guessed. It's already a strong hint that AscW() will not work for codepoints outside this range.

Fortunately, Unicode codepoints > 65535 are of very rare use: you find there old Babylonian musical symbols, cuneiforms, hieroglyphs, specialized maths symbols, a huge range of remapped asian ideograms, and such highly special symbols or letters.

So unless you're doing work on ancient Aegypt or similar, you're unlikely to need those ranges at all.

That's why limiting AutoIt characters to those whose codepoint are below 65536 is still "good enough for most practical purposes, if not all."

As a funny (or not: I find it's a drama) sidenote, you can see that AutoIt isn't by far the only program having issues with Unicode beyond UCS-2. While composing this post, I downloaded a set of cuneiform TT fonts (from this page) and installed them on my Vista x86 machine (I know it's a pile of shit, don't bother).

The accompanying PDF file discussing those fonts displayed perfectly but guess what: Windows own CharMap applet does NOT show the codepoints correctly and remaps > 16-bit codepoints into their lower 16-bit part (it does Mod(codepoint, 65536)). So when even own MS apps designed to show Unicode charset fails it, you can argue that it isn't such a big problem if AutoIt doesn't allow for the full Unicode range.

[Xandy]

lol, thank you very much.