[Greasemonkey] Javascript character encoding problem
Anton Berezin
tobez at tobez.org
Wed Apr 5 17:21:48 EDT 2006
On Wed, Apr 05, 2006 at 04:08:17PM +0200, Jonas Lundberg wrote:
> Thank's for the input!
>
> > Actually this is not so. Provided that the backend expects UTF-8 - and
> > I would like to hear about any reasons why it should not - and uses any
> > minimally competent CGI library, no decoding is necessary by nature of
> > application/x-www-form-urlencoded content type.
>
> I program the back-end in xQuery so I guess that the back-end
> competence bounces right back at me... I use multipart/form-data,
> since that will allow me to send images as well.
>
> > > The encoding headers seems to be identical in my two cases. It thus
> > > looks like that it is Javascript that serializes strings with
> > > international characters incorrectly.
> > Hmm. You are clearly getting UTF-8 in your GM_xmlhttpRequest() call,
> > and that is actually a more correct behavior in comparison to most
> > anything else, unless you would argue that international characters are
> > limited by 8869-1[5] charset.
>
> If I indeed get UTF-8 in my call, then I would prefer to get the
> correct UTF-8 characters in it. Since the alert(); mehtod works, I
> would guess that there is a bug in GM_xmlhttpRequest(). Is that
> possible? In the string, I have tried using the characters as they
> are, or an escape sequence, like \u00e5\u00e4\u00f6\u00c5\u00c4\u00d6.
> Nothing works.
But you are getting correct UTF-8 characters:
tobez at am2 ~> echo "öö"|iconv -f UTF-8 -t latin1
öö
tobez at am2 ~> echo "öö"|iconv -t UTF-8 -f latin1
öö
(assuming this mail arrives to you in 8859-1, you should see what I
see). :-)
\Anton.
--
An undefined problem has an infinite number of solutions.
-- Robert A. Humphrey
More information about the Greasemonkey
mailing list