«

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?

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

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 ä are programmatically replaced by appropriate character
codes.