javascript charset <> page charset

[optimistx]

I try to develope a bookmarklet in javascript. The charset of the
bookmarklet is UTF-8, but it is supposed to work within pages, whose
character set is not UTF-8, but e.g. ISO-8859-1 or WINDOWS-1252. The
bookmarklet loads other javascript files with the attribute charset="UTF-8".

Mostly everything works nicely, but at least alert-boxes seem to show
different characters depending on the browser (Firefox 3 , Opera 9.02, ie6
has been compared this far: Opera uses the page character set, ff and ie
js-charset.).

'Feature testing' is a fascinating idea, but how can it be used in this case
or otherwise solv this problem?

[Bart Van der Donck]

Re: javascript charset &lt;&gt; page charset

optimistx wrote:

I try to develope a bookmarklet in javascript. The charset of the
bookmarklet is UTF-8, but it is supposed to work within pages, whose
character set is not UTF-8, but e.g. ISO-8859-1 or WINDOWS-1252.  The
bookmarklet loads other javascript files with the attribute charset="UTF-8".
>
Mostly everything works nicely, but at least alert-boxes seem to show
different characters depending on the browser (Firefox 3 , Opera 9.02, ie6
has been compared this far: Opera uses the page character set, ff and ie
js-charset.).

Two ideas: It might be an issue for Opera whether the remote js-file
was saved under UTF-8 or not. It might also matter whether that file
has a charset-header from itself.

When the 'charset'-argument is used for an external script-call, then
this should only indicate how the main caller file will (try to) treat
non-ASCII characters in the remote file (except when UTF-7). And this
should normally stand apart from the encoding that is used in the
caller file.

Hope this helps,

--
Bart

[optimistx]

Re: javascript charset &lt;&gt; page charset

Bart Van der Donck wrote:

Two ideas: It might be an issue for Opera whether the remote js-file
was saved under UTF-8 or not. It might also matter whether that file
has a charset-header from itself.
>
When the 'charset'-argument is used for an external script-call, then
this should only indicate how the main caller file will (try to) treat
non-ASCII characters in the remote file (except when UTF-7). And this
should normally stand apart from the encoding that is used in the
caller file.
>
Hope this helps,

Thanks, your advice helped. After all, there was no discrepancy between
browsers. When the original files really have the character sets which their
http-headers claim they have, and the files are without any 'BOM'- marks,
then the Apache-servers and browsers do their work as expected. The final
alertbox is shown correctly in 3 browsers at least provided that the
entities like &auml; are programmaticall y replaced by appropriate character
codes.