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]

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,

 

[optimistx]

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