By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,212 Members | 2,209 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,212 IT Pros & Developers. It's quick & easy.

Japanese - wrong encoding in a frame

P: n/a
Hi,

May be it's a know issue but my search brought nothing...

We have static HTML files with Japanese text in UTF-8 encoding - it's
on-line Help for our application, so there are no Web servers involved,
just .html and .js on a hard drive.
..
Help topics are shown in a frameset (I know, I know, I personally had
no idea :)) like this (I made an example): http://RusWin.net/jindex.htm

Looks Ok in this example, each file involved has
<HEAD>
<meta http-equiv="content-type" content="text/html; charset=utf-8">

But in this example the filese used in frames are hard-coded in
jindex.htm:

<FRAMESET ROWS="14%,76%,*">
<FRAME SRC="jheader.htm">
<FRAMESET COLS="29%,71%">
<FRAME SRC="jleft.htm">
<FRAME SRC="jmain.htm" NAME="page">
</FRAMESET>
<FRAME SRC="jfoot.htm">
</FRAMESET>

In a real system main frame shows gibberish instead of Japanese -
eventhough all browsers show (if I place cursor to the main frame and
use right mouse button to see current encoding) that currently selected
encoding for that piece _is_ UTF-8, the text is shown using "Western"
encoding :(

You can see that bad effect simulated if you go to
http://RusWin.net/jindex.htm, place cursor to the main frame and using
right mouse click choose "Western(Windows)" encoding - it's what we see
in real production system!

What is the difference with my example and the real system?

In real system HTML file with FRAMESET tag has _placeholders_
(blank.htm) afrer SRC= like this:

<frame name="" src="pagenav.htm" scrolling="no">
<frame name="" src="blank.htm" scrolling="no">
<frame name="" src="blank.htm" scrolling="auto">
and real file names are dynamically prepared using JavaScript
(re-direct happens):

WWHGetWWHFrame(ParamToBookDir)
........
location.replace(ParamToBookDir +
"wwhelp/wwhimpl/common/html/wwhelp.htm?context=" +
WWHBookData_Context() + "&file=" + BaseFilename);

*******************************

So does anyone know why re-direct (location.replace) can cause such
strange effect of a wrong encoding used?

*********************************************
We tried to avoid replacing whic removes file from frame first and
tried instead to use location to directly assign a file to the frame,
but it did not help:

newUrl = ParamToBookDir +
"wwhelp/wwhimpl/common/html/wwhelp.htm?context=" +
WWHBookData_Context() + "&file=" + BaseFilename;

location = newUrl;

*********************************************

Thanks,
Paul

Apr 21 '06 #1
Share this Question
Share on Google+
12 Replies


P: n/a
On 20 Apr 2006 pa*****@compuserve.com wrote:
Help topics are shown in a frameset
Don't use frames.
http://RusWin.net/jindex.htm | Your browser does <B>not</B> support <I>FRAMES</I>

Don't use frames in the first place.
Especially do not use such silly NOFRAMES text. That's like

alt="Your browser does not support images."
<meta http-equiv="content-type" content="text/html; charset=utf-8">
This is only vodoo. The encoding is specified in the HTTP header.
But in this example the filese used in frames are hard-coded in
jindex.htm:
Don't use frames.
What is the difference with my example and the real system?
The charset parameter sent by the server. Your <meta charset> vodoo
doesn't help at all:
http://www.w3.org/International/O-HTTP-charset.html
http://ppewww.ph.gla.ac.uk/~flavell/...t/ns-burp.html
In real system HTML file with FRAMESET tag has _placeholders_
Don't use frames.
So does anyone know why re-direct (location.replace) can cause such
strange effect of a wrong encoding used?


You have different servers - one sends "charset=ISO-8859-1" and
the other does not specify an encoding (charset). Make sure that
your server sends "charset=UTF-8" and remove your <meta charset>
ersatz.

Did I mention that frames are evil?

--
Evil is a registered trademark of the President of the United States.

Apr 21 '06 #2

P: n/a
Dan

Andreas Prilop wrote:
<meta http-equiv="content-type" content="text/html; charset=utf-8">


This is only vodoo. The encoding is specified in the HTTP header.


Except that the original poster mentioned that the files in question
were displayed as an application's help screens, directly from a hard
drive, with no HTTP server involved. This probably technically makes
it off-topic for this WWW authoring group, since it's not actually on
the Web.

--
Dan

Apr 21 '06 #3

P: n/a
Andreas Prilop wrote:
On 20 Apr 2006 pa*****@compuserve.com wrote:
Help topics are shown in a frameset
Don't use frames.


Why on earth not?
Did I mention that frames are evil?
Under which circumstances, exactly?
Don't use frames in the first place. Especially do not use such silly
NOFRAMES text. That's like

alt="Your browser does not support images."
No, it's not. That 'alt' text is pointless; the viewer already knows
that he cannot see the image. And it's potentially misleading; the fact
that the image isn't displayed may not be caused by lack of browser
support. In the case of frames, the failure to display a frameset can
only be caused by a lack of browser support, and absent the NOFRAMES
text, you'd have to display something else (perhaps that's your point,
but it's not clear from what you said).
This is only vodoo. The encoding is specified in the HTTP header.
That's great, if you happen to have HTTP available.
What is the difference with my example and the real system?
The charset parameter sent by the server.


What server?
You have different servers - one sends "charset=ISO-8859-1" and the
other does not specify an encoding (charset). Make sure that your
server sends "charset=UTF-8" and remove your <meta charset> ersatz.


How's he supposed to do that, when the 'server' is a hard disk?

--
Jack.
Apr 21 '06 #4

P: n/a
Hello!

Andreas Prilop wrote:
On 20 Apr 2006 pa*****@compuserve.com wrote:
Help topics are shown in a frameset


Don't use frames.


It's why I wrote in my post, "I know, I know" and that I have nothing
to do with
the product - I saw the product first time yesterday -
at this stage it's too late for me to tell them do drop
the frames - their shipping time is close :)
So it's not an option to have no-frames product at this time...
--
Regards,
Paul

Apr 21 '06 #5

P: n/a

Hi,

It looks like a JavaScript issue - no problem without JavaScript,
issue appears only when we change a file name of HTML to be shown
in the main frame from a spaceholder Blank.htm to a needed one
dynamically using JavaScript function
location.replace()
or location = newUrl

with the same result - Japanese UTF-8 text is shown using "Western"
encoding (by both Firefox and Internet Explorer).

Anyone heard about such issue?

--
Regards,
Paul
Apr 21 '06 #6

P: n/a
VK

pa*****@compuserve.com wrote:
Hi,

May be it's a know issue but my search brought nothing...

We have static HTML files with Japanese text in UTF-8 encoding - it's
on-line Help for our application, so there are no Web servers involved,
just .html and .js on a hard drive.
.
Help topics are shown in a frameset (I know, I know, I personally had
no idea :)) like this (I made an example): http://RusWin.net/jindex.htm

Looks Ok in this example, each file involved has
<HEAD>
<meta http-equiv="content-type" content="text/html; charset=utf-8">

But in this example the filese used in frames are hard-coded in
jindex.htm:

<FRAMESET ROWS="14%,76%,*">
<FRAME SRC="jheader.htm">
<FRAMESET COLS="29%,71%">
<FRAME SRC="jleft.htm">
<FRAME SRC="jmain.htm" NAME="page">
</FRAMESET>
<FRAME SRC="jfoot.htm">
</FRAMESET>

In a real system main frame shows gibberish instead of Japanese -
eventhough all browsers show (if I place cursor to the main frame and
use right mouse button to see current encoding) that currently selected
encoding for that piece _is_ UTF-8, the text is shown using "Western"
encoding :(

You can see that bad effect simulated if you go to
http://RusWin.net/jindex.htm, place cursor to the main frame and using
right mouse click choose "Western(Windows)" encoding - it's what we see
in real production system!

What is the difference with my example and the real system?

In real system HTML file with FRAMESET tag has _placeholders_
(blank.htm) afrer SRC= like this:

<frame name="" src="pagenav.htm" scrolling="no">
<frame name="" src="blank.htm" scrolling="no">
<frame name="" src="blank.htm" scrolling="auto">
and real file names are dynamically prepared using JavaScript
(re-direct happens):

WWHGetWWHFrame(ParamToBookDir)
.......
location.replace(ParamToBookDir +
"wwhelp/wwhimpl/common/html/wwhelp.htm?context=" +
WWHBookData_Context() + "&file=" + BaseFilename);

*******************************

So does anyone know why re-direct (location.replace) can cause such
strange effect of a wrong encoding used?


Is it with any language or with Japanese only?
Japanese part of Unicode is severely screwed by the Unicode Consortium.
Everyone (uncluding Japanese) uses Shift_JIS instead. They (Unicode)
happened to make Japanese tables while they were still trying to stay
in the original two-byte format, so they implemented only the own
Japanese characters, and whatever they could - they referenced in
Chinese tables. Holly mess...

Any way, try to use Shift_JIS instead and make sure that your server
sends the proper Content-Type with charset indicated. In serious things
like Eastern alphabets meta cheat-chat is not trustful :-)

Apr 21 '06 #7

P: n/a
Paul Gorodyansky wrote:
Hi,

It looks like a JavaScript issue - no problem without JavaScript,
issue appears only when we change a file name of HTML to be shown in
the main frame from a spaceholder Blank.htm to a needed one
dynamically using JavaScript function location.replace() or location
= newUrl

with the same result - Japanese UTF-8 text is shown using "Western"
encoding (by both Firefox and Internet Explorer).

Anyone heard about such issue?

This works correctly in both IE and Firefox.

I have created a page "frameset.html", with two frames, the second one
being named "hebrew" and loading a blank file, with the first frame
loading "western.html". I have created a page "western.html" thus:
<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=iso-8859-1">
</head>
<body>
<p>This is the first frame.</p>
<p><input type="button" value="Replace"
onclick="parent.hebrew.location.replace('hebrew.ht ml');"></p>
<p> ל×� × ×™×ª×Ÿ ליצור ×�ת</p>
<p>That was hebrew</p>
</body>
</html>

That page is actually UTF-8 encoded, and the meta-tag lies. The garbled
characters are UTF-8, from the Hebrew alphabet.

I have a second file "hebrew.html" thus:
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hebrew text follows</p>
<p>
ל×� × ×™×ª×Ÿ ליצור×�ת
</p>
<p>That was hebrew</p>
</body>
</html>

When I load "frameset.html" into a bruiser from the filesystem, the
garbage in the first appears to be garbage, as expected, and the second
frame displays nothing. When I click on the "Replace" button in the
first frame, the Hebrew text is loaded, and is correctly rendered as
Hebrew, as you would expect.

This behaviour is observed both with IE6 and Firefox. If I dick around
with the meta tag in either the frameset document or in "western.html",
the only change is that the Hebrew text is correctly rendered in the
latter when I change it to UTF-8. The display of "hebrew.html" is always
correct.

I initially tested all this without using framesets, because they just
complicate things. I can't read or write Hebrew; the Hebrew text was
found on a UTF-8-encoded webpage, and copied/pasted into a UTF-8-aware
text-editor.

Anyway, I conclude that there is nothing wrong with the handling by
location.replace() either of my meta-tags, or of UTF-8, in either of the
two bruisers that I tested.

Are you sure that your Japanese help-text is still correctly encoded in
UTF-8, and hasn't been damaged by some non-UTF-8-aware editor?

Are you perhaps using some more primitive bruiser? You haven't said
anything about your platform; these tests were carried out on a Win2K
machine configured to use ISO-8859-1 by default.

--
Jack.
Apr 21 '06 #8

P: n/a
VK wrote:

Any way, try to use Shift_JIS instead and make sure that your server
sends the proper Content-Type with charset indicated. In serious
things like Eastern alphabets meta cheat-chat is not trustful :-)


Which operating system has the ability to return a Content-Type (with
charset) when you open a file?

--
Jack.
Apr 22 '06 #9

P: n/a
On Sat, 22 Apr 2006, Jack wrote:
Which operating system has the ability to return a Content-Type
(with charset) when you open a file?


Well, if your file system is based on http and conforms to rfc2616
then you should have no problem.

Installing Apache was easy enough, on any OS that I've worked with in
the last few years, and would be one recommendable way of getting
anywhere near on-topic for comp.infosystems.www.authoring.html

Browsing local files directly in the filesystem is a kludge, and
really has little or nothing of relevance to tell us about the World
Wild Web, other than by accident.

bye
Apr 22 '06 #10

P: n/a
Alan J. Flavell wrote:

Browsing local files directly in the filesystem is a kludge, and
really has little or nothing of relevance to tell us about the World
Wild Web, other than by accident.


Can you recommend to the OP a more appropriate group, suitable for
discusing non-WWW uses of HTML? It seems a little anal to treat his
question as OT, simply because he's not technically using the web.

--
Jack.
Apr 22 '06 #11

P: n/a
On Sat, 22 Apr 2006, Jack wrote:
Alan J. Flavell wrote:

Browsing local files directly in the filesystem is a kludge, and
really has little or nothing of relevance to tell us about the
World Wild Web, other than by accident.


Can you recommend to the OP a more appropriate group, suitable for
discusing non-WWW uses of HTML?


I can't personally predict how it would be received on alt.html, but
that's a somewhat broader church than a big-8 group which has got WWW
right there in its name.

I haven't examined the original problem in detail (neither frames nor
javascript really tempted me), but it might be that the real problem
lies with the javascript rather than with the HTML. In which case, no
HTML group would seem more on-topic than a javascript group, AFAICS.

My general advice (which indeed I follow myself, as best I can) in any
complex situation is to break a problem into its component parts and
get each one working in isolation, before fitting them together to
make a working whole. In that sense, a problem which includes both
frames and javascript seems to me to be in need of subdivision in
order to isolate the problem. If the problem hasn't already been
located while doing that, at least it would be clearer whether it was
an HTML issue, a javascript issue, or even a browser anomaly, and thus
indicate an appropriate forum for raising it. BICBW and YMMV.

regards
Apr 22 '06 #12

P: n/a
Thanks, Jack!

We will look further, your tests will help.
--
Regards,
Paul
Apr 22 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.