日语 - 帧中的错误编码 [英] Japanese - wrong encoding in a frame
问题描述
这可能是个问题，但我的搜索没有带来任何结果......
我们有静态的HTML文件使用UTF-8编码的日文文本 - 这是我们的应用程序的
联机帮助，因此不涉及Web服务器，
只需.html和。 js在一个硬盘上。
..
帮助主题显示在框架集中（我知道，我知道，我个人已经
否想法:)）像这样（我做了一个例子）： http://RusWin.net/jindex .htm
在这个例子中看起来很好，每个涉及的文件都有
< HEAD>
< meta http-equiv =" content-type"含量=" text / html的; charset = utf-8">
但是在这个例子中，帧中使用的文件是硬编码的
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>
在一个真实的系统主框架中显示乱码而不是日文 -
尽管所有浏览器都显示（如果我将光标放在主框架上）并且
使用鼠标右键查看当前编码）当前选择
编码该片段_is_ UTF-8，文本使用Western显示
编码:(
你可以看到模拟的效果如果你去 http://RusWin.net/jindex.htm ，将光标放在主框架上并使用
右键单击选择 ; Western（Windows）" encoding - 它是我们在实际生产系统中看到的
！
与我的例子有什么不同实际系统？
在实际系统中，带FRAMESET标签的HTML文件有_pl aceholders_
（blank.htm）afrer SRC =这样：
< frame name ="" SRC =" pagenav.htm" scrolling =" no">
< frame name ="" SRC =" blank.htm" scrolling =" no">
< frame name ="" SRC =" blank.htm" scrolling =" auto">
和真实文件名是使用JavaScript动态准备的
（重新直接发生）：
WWHGetWWHFrame（ParamToBookDir）
........
location.replace（ParamToBookDir +
" wwhelp / wwhimpl / common / html / wwhelp.htm？context =" +
WWHBookData_Context（）+"& file =" + BaseFilename）;
* ****************************** *
所以有人知道为什么要重新指挥（location.replace）会导致这样的错误编码使用了什么奇怪的效果？
************** ***********************************
我们试图避免替换whic首先从帧中删除文件并且
尝试使用位置直接将文件分配给框架，
但它没有帮助：
newUrl = ParamToBookDir +
" wwhelp / wwhimpl / common / html / wwhelp.htm？context =" +
WWHBookData_Context（）+"& file =" + BaseFilename;
location = newUrl;
******************* ************************** *
谢谢，
保罗
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
推荐答案
2006年4月20日 pa ** ***@compuserve.com 写道：
On 20 Apr 2006 pa*****@compuserve.com wrote:
帮助主题显示在框架集中
不要使用框架。
http://RusWin.net/jindex.htm
|您的浏览器< B>不< / B>支持< I> FRAMES< / I>
首先不要使用框架。
特别是不要使用这种愚蠢的NOFRAMES文本。这就像
alt ="您的浏览器不支持图片。"
< meta http-equiv =" content-type" ;含量=" text / html的;字符集= UTF-8英寸;>
这只是vodoo。编码在HTTP标头中指定。
但是在这个例子中，框架中使用的文件是硬编码的。
jindex.htm：
不要使用框架。
与我的例子和真实系统有什么区别？
服务器发送的charset参数。你的< meta charset> vodoo
根本没有帮助：
http://www.w3.org/International/O-HTTP-charset.html
http://ppewww.ph.gla.ac.uk/~flavell/...t/ns-burp .html
在带有FRAMESET标签的真实系统HTML文件中有_placeholders_
不要使用框架。
所以有人知道为什么重定向（location.replace）会导致使用错误编码的奇怪效果吗？
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?
你有不同的服务器 - 一个发送charset = ISO-8859-1并且
另一个没有指定编码（charset）。确保你的服务器发送了charset = UTF-8的
并删除你的< meta charset>
ersatz。
我提到框架是邪恶的吗？
-
邪恶？是美国总统的注册商标。
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.
Andreas Prilop写道：
Andreas Prilop wrote:
< meta http-equiv =" content-type"含量=" text / html的; charset = utf-8">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
这只是vodoo。编码在HTTP标头中指定。
This is only vodoo. The encoding is specified in the HTTP header.
除了原始海报提到有问题的文件
显示为应用程序'帮助屏幕直接来自硬盘
-
Dan
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
Andreas Prilop写道：
Andreas Prilop wrote:
2006年4月20日< a href =mailto：pa ***** @ compuserve.com> pa ***** @ compuserve.com 写道：
On 20 Apr 2006 pa*****@compuserve.com wrote:
帮助主题显示在框架集中
不要使用框架。
Help topics are shown in a frameset
Don''t use frames.
为什么不在地球上？
我是否提到框架是邪恶的??
究竟在哪种情况下？
首先不要使用框架。特别是不要使用这种愚蠢的NOFRAMES文字。这就像
alt ="您的浏览器不支持图像。
不，不是。那个'alt''文字毫无意义;观众已经知道
他无法看到图像。它可能会产生误导;没有显示图像的事实
可能不是由于缺少浏览器支持而导致的。在框架的情况下，显示框架集的失败只能是由于缺乏浏览器支持而导致的，并且没有NOFRAMES
文本，你会有显示其他东西（也许这就是你的意思，
但是你说的不清楚）。
这只是vodoo。编码在HTTP标头中指定。
如果您碰巧有HTTP可用，那就太棒了。
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.
我的例子和真实系统有什么区别？
服务器发送的charset参数。
What is the difference with my example and the real system?
The charset parameter sent by the server.
什么服务器？
你有不同的服务器 - 一个发送&＃charset = ISO-8859-1"而
其他没有指定编码（charset）。确保您的服务器发送charset = UTF-8。并删除你的< meta charset> ersatz。
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.
这篇关于日语 - 帧中的错误编码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
