Re: need help withXMLHTTPreq and parsing response

> > I just was looking for some rhyme or reason how
> > it's being converted, or why some bytes are converted to unicode, so
that I
> > can convert back to bytes (acutally ints < 255).
>
> Ah. Well, I mentioned that the data is apparently interpreted as
> windows-1252, did I not? Just translate it back.
>
I think that's where my question is going....I mean a \u201c character is a
\u201c, no matter what codepage is  used to view it, right?  So, then how do
I 'break out' the correct value?  I'm assuming the correct value comes in
the bytestream (e.g. 147), but is mistakenly(?) converted to a bigger
unicode char (e.g. \u201c, 8220 dec).  I've tried converting to Hex,
splitting, bitshifting, ANDing, ORing, etc. but can find no logic to it.

Here is some data I collected on the problem, maybe someone can see a
pattern:
charcodeat: (dec)       should be*: (dec)
8225                                135 (x87)
8220 (\u201C)                 147 (x93)
8216                                145 (x91)
339                                   156 (x96)

*Should be column is what the java version of the program, i.e.
InputStream.read() returns.

Also, in this case the server doesn't return a codepage suggestion in the
header, so I'm assuming that Mozilla xmlhttpreq is assuming everything is in
UTF-8.  All the other characters in the stream are interpreted correctly,
it's usually just 1 or 2 out of 30 or so that get turned to unicode -- go
out of range in other words.

To clarify one more point, I don't need to display the characters of the
response.  I have to get the charcodeat(), which should be ascii range
(<255), for further processing.  I therefore don't really care about the
codepage, unless it affects the bytestream.  Currently, no matter what I
specify in overrideMimeType, it has no effect on the processing of the
bytestream.

>
http://lxr.mozilla.org/seamonkey/source/extensions/xmlextras/base/src/nsXMLHttpRequest.cpp#520
> is where XMLHttpRequest converts the server data to unicode. Looks like
> all it does is get the charset from the HTTP response header, falling
> back to UTF-8.

Thanks for that link.  I will investigate this route further.

--Jason

P.S. I'm using readyState ==3 in my processReqChange function.  Moz is the
only one to do it as documented.  Good job.