saint_monkey (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
saint_monkey) wrote2004-01-26 08:22 pm
saint_monkey) wrote2004-01-26 08:22 pm
(no subject)
i am post-happy today. post-happy!
this is geek heavy, so beware.
just had to add this, i got the strangest escalated mac call. the user was entering a payment amount in our website on an XML form, when he would type a value with a leading 2, he'd get an instant error fromthe "onchange" event, saying that invalid data has been entered. this happens normally on the site when a hard space is typed in. sometimes, other mac users using safari will get an error from the site that tells them that the "&" character isn't supported when they are typing only numbers. so i took a look at the page source, which says:
< ?xml version="1.0" encoding="UTF-16"? ><tr class="row0"><td class="rows_sched_pmts">PHILADELPHIA ELECTRIC CO<br />26-01-38-300835</td><input type="hidden" name="Payee2911947" value="PHILADELPHIA ELECTRIC CO" /><input type="hidden" name="UserPayeeID2911947" value="2911947" /><td class="rows_sched_pmts" align="right">
see that header declaration, utf-16...? that refers to multi-lingual unicode 16 bit standard. it is telling the form which characterset (language) to accept the entry with. older macs with the old motorola processor (pre g-3) support ASCII charactersets, or at the most, utf-8, the 8-bit unicode standard. what happens when utf-8 input meets a utf-16 form that doesn't know how to properly fall back? the data gets re-interpreted as ASCII. the utf characterset for the number two (the decimal number 50) is hex 0032, transmitted as   by ASCII. (see the ampersand... explains safari's ampersand problem, but what about the "invalid entry...?") well, either the xml, or ie, or the server, is converting   into the decimal value 32. and tries to make a characer out of it. if you convert 32 back into hex, you get... 0020. 0020 is utf-16's hex code for the hard space character. trippy.
this is geek heavy, so beware.
just had to add this, i got the strangest escalated mac call. the user was entering a payment amount in our website on an XML form, when he would type a value with a leading 2, he'd get an instant error fromthe "onchange" event, saying that invalid data has been entered. this happens normally on the site when a hard space is typed in. sometimes, other mac users using safari will get an error from the site that tells them that the "&" character isn't supported when they are typing only numbers. so i took a look at the page source, which says:
< ?xml version="1.0" encoding="UTF-16"? ><tr class="row0"><td class="rows_sched_pmts">PHILADELPHIA ELECTRIC CO<br />26-01-38-300835</td><input type="hidden" name="Payee2911947" value="PHILADELPHIA ELECTRIC CO" /><input type="hidden" name="UserPayeeID2911947" value="2911947" /><td class="rows_sched_pmts" align="right">
see that header declaration, utf-16...? that refers to multi-lingual unicode 16 bit standard. it is telling the form which characterset (language) to accept the entry with. older macs with the old motorola processor (pre g-3) support ASCII charactersets, or at the most, utf-8, the 8-bit unicode standard. what happens when utf-8 input meets a utf-16 form that doesn't know how to properly fall back? the data gets re-interpreted as ASCII. the utf characterset for the number two (the decimal number 50) is hex 0032, transmitted as   by ASCII. (see the ampersand... explains safari's ampersand problem, but what about the "invalid entry...?") well, either the xml, or ie, or the server, is converting   into the decimal value 32. and tries to make a characer out of it. if you convert 32 back into hex, you get... 0020. 0020 is utf-16's hex code for the hard space character. trippy.