473,406 Members | 2,387 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,406 software developers and data experts.

Japanese - wrong encoding in a frame

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
12 5759
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
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
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
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

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
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
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
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
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
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
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
Thanks, Jack!

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

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: David Thomas | last post by:
Hi there, a while ago, I posted a question regarding reading japanese text from a text file. Well, since I solved the problem, I thought I'd post my solution for the benefit of other people with...
1
by: Sriv Chakravarthy | last post by:
I am trying to use xerces-c SAX parser to parse japanese characters. I have a <?xml... utf-8> line in the xml file. When the parser encounters the jap characters it throws a UTFDataFormatException....
2
by: Robert M. Gary | last post by:
I'm using JRE 1.5 on Solaris Japanese (Sparc). The JVM claims its default character set is EUC-JP I'm seeing two strange things when using Japanese character sets... 1) If I write a program that...
3
by: Benoit Martin | last post by:
in my windows app, I have some japanese text that I load from a text file and display on a label. No matter what type of encoding I try to use on the text file, the text always comes up as a bunch...
21
by: Doug Lerner | last post by:
I'm working on a client/server app that seems to work fine in OS Firefox and Windows IE and Firefox. However, in OS X Safari, although the UI/communications themselves work fine, if the...
11
by: prats | last post by:
I want to write a GUI application in PYTHON using QT. This application is supposed to take in Japanese characters. I am using PyQt as the wrapper for using QT from python. I am able to take input...
3
by: paulgor | last post by:
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...
2
by: phl | last post by:
Hello, I have aspx(say page.aspx) page which uses javascript to submit a form reload with some unicode characters,upon an button event e.g page.aspx?param=value I get this value in the...
1
by: PHP Wooer | last post by:
Can anybody there please help me out? I am having a problem with the display of Japanese character in the subject line of the mails sent in Japanese language. This problem is particularly with...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
0
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.