Re: REWARD: chr() not working for Chinese "Locale"

From: John Cody (newsgroups_at_noospammmax-soft.com)
Date: 10/15/04 

Date: Fri, 15 Oct 2004 15:49:35 -0400

Hey Jon,

I will try your pobox email address for the "thank you" reward.

-JC

"Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message
news:MPG.1bd6ea1ab048bc98b6a1@msnews.microsoft.com...
> John Cody <newsgroups@noospammmax-soft.com> wrote:
> > Basically, I have a routine that encrypts a string. Each character of
the
> > resulting string can have a value of 0-255. It seems that with a "Latin"
> > based character set, characters 128 to 255 are all unique, so no matter
what
> > value the encryption routine generated for each character, it was
> > reversible - meaning the original string could be de-crypted back to its
> > original value.
>
> Urgh. That's a nasty idea. It may well work, but it's not at all nice.
> Base64 is a much better way to convert what is essentially binary data
> into a string which is likely to survive whatever you throw at it.
>
> Actually, ISO-8859-1 sort of has a hole between 128 and 140 (or 160 -
> can't remember now). (I used to disagree with this based on the Unicode
> spec stating that the first 256 values of Unicode were the same as ISO-
> 8859-1, but now I'm not so sure. It's a shame that the spec itself
> costs money...) What you're probably referring to is something like
> Code Page 1252, which is the same as ISO-8859-1 for every value other
> than the "hole".
>
> > However, it appears that when a "cero" character set is used, there are
a
> > lot of invalid/duplicate characters in the 128-255 range, so when the
> > encryption routine tries to set a character to a value in this range,
say
> > 213 using CHR(213), it would get transposed to some default character
code
> > like 63, which obviously would corrupt the string so it could not be
> > de-crypted using ASC(x), because it would not be the same value as the
> > original character it is suppose to be.
> >
> > But, by using chrw(x) and Ascw(x), proper unique character are
> > generated.
>
> It's still basically a bad idea to keep binary data as a string like
> that though. Base64 encoding is easy and doesn't add *very* much bulk
> to the data.
>
> --
> Jon Skeet - <skeet@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too