Preserving japanese characters with document.open()

[websmith99]

I've run across a problem with Netscape 4.x handling the
"shift_jis" encoding when you re-create a document using
document.open() in JavaScript.

I have a Web application that uses a JavaScript menu tree for
navigation to pages in a dynamically created course. The course
can be offered in Japanse (Kanji) and the menu is originally
loaded with the correct encoding (done on the server side).

However, when you use the menu to navigate throughout the
course, the menu will expand and collapse like the windows
explorer menu by redrawing the page and highlighting the correct
node the user has chosen using document.open() and
document.write(). This is because it would be a huge
performance hit to reload the page from the server every time
you clicked on a node in the tree.

The problem is, that with Netscape 4.x when the tree is redrawn
using document.open() and document.write() it loses the
"shift_jis" encoding for the Kanji character set, as Netscape 4.x
by default reverts to iso-8859-1 encoding where IE retains the
encoding used before.

I have tried adding the following within the document.write()
to the new document, but it didn't work:

<META HTTP-EQUIV="content-type" CONTENT="text/html; charset=shift_jis">

Any ideas?

[Waldo2k2]

well, you say that you don't want to go back and forth to the server...so, include a .js file that has a variable in it that is encoded in shift_jis (how do you do that by the way? same as the meta tag below?) anyhow, you should be able to include that file on both pages (the original and the one opened with document.open()) then just document.write() the variable.
The way that ie works, is that it encodes text when the page is first loaded, scripting for some reason can't call the encoding process dynamically. I ran into something similar earlier on someone elses post, and i think this may be the same thing. So give it a try, if you don't know what i mean get back to me and i'll try to formulate an example.