[Greasemonkey] Javascript character encoding problem

[Jonas Lundberg]

> So let's say you're on a page served as iso-8859-1. You pull utf-8
> data from your server via GM_xmlhttpRequest. You insert the data into
> the DOM. Then I'm not sure what is happening. The user modifies the
> data, and you take it out of the DOM. You send it back to your server,
> and it turns out to be iso-8859-1.
>
> > Also, different pages will have different encodings, and this should
> > not affect my form.
> > So, it is good that the text encoding in the Ajax call does not vary.
> > But it is BAD that XMLHttprequest does not use utf-8.
>
> XMLHttpRequest does look at encoding of data it pulls in, and no
> matter what encoding it is it will be converted to Unicode, because
> that's what the Javascript string type is. I'm not sure when this
> happens, but the unicode string has to be converted to bytes of a
> particular charset before it is sent over the wire, and it seems that
> it takes the charset from the page.
>
> If the page charset includes the international characters you need,
> then you can specify
>
> headers: { 'Content-type': 'multipart/form-data; boundary=shapecms;
> charset=' + document.characterSet }
>
> and assuming that your web service looks at Content-Type, it will know
> to decode from the right charset.
>
> At least I think it should work that way.

I agree that it should work like this, but it does not. The ajax call
uses a different character set than the page encoding (the same
character set each time). Since my international characters can be
displayed using the alert() function, they seem to be inside the
script all right. But when I send them through the ajax request they
are scrambled - thus surprisingly NOT sent in UTF-8. To find out what
the caracters "look like" in transit, I use the live HTTP headers
extension. The encoding stated in the "headers" part only seems to be
information for the receiving server - it does not affect the actual
encoding used.

So, is it a bug then?

Regards
Hans