IE在iframe表单目标中丢失自动UTF-8编码

I have an odd problem in IE. It has to do with how IE detects the encoding of an iframe based on its parent content. My application wraps the content of a page in an iframe, and sets the encoding of the parent window to UTF-8 through the Content-Type header. The content of the iframe does not set the encoding through the Content-Type, and picks up the parent window's encoding on its initial load. This is the desired behavior - the content window requires the UTF-8 encoding for some language content, but for complicated reasons beyond my control, it cannot forcibly set its own encoding, so it relies on the parent window's encoding.

我在IE中有一个奇怪的问题。它与IE如何根据其父内容检测iframe的编码有关。我的应用程序将页面内容包装在iframe中,并通过Content-Type标头将父窗口的编码设置为UTF-8。 iframe的内容不通过Content-Type设置编码,并在初始加载时选择父窗口的编码。这是所需的行为 - 内容窗口需要UTF-8编码用于某些语言内容,但由于我无法控制的复杂原因,它无法强制设置自己的编码,因此它依赖于父窗口的编码。

The problem arises when the content page is the target of a form action. When the form submits and the page loads in the content window, it auto-selects Western European (Windows) encoding. Does anyone know why? I've tried searching for any sort of documentation on related behavior, but the googles, they do nothing. Any sort of a lead (beyond sending a Content-Type header or a byte-order mark in the content) would be most helpful.

当内容页面是表单操作的目标时,会出现问题。当表单提交并在内容窗口中加载页面时,它会自动选择西欧(Windows)编码。有谁知道为什么?我曾尝试搜索有关相关行为的任何文档,但谷歌,他们什么都不做。任何类型的潜在客户(除了在内容中发送Content-Type标头或字节顺序标记)都将是最有帮助的。

I unfortunately don't have a public place to host this, but copy-pasting these code samples to local files and saving each with UTF-8 encoding without a byte-order mark should consistently reproduce the behavior in all versions of IE.

遗憾的是,我没有公共场所来托管这个,但是将这些代码示例复制粘贴到本地文件并使用UTF-8编码保存每个文件而没有字节顺序标记应该在所有版本的IE中一致地重现行为。

frame1.html

<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
<div>エンコード</div>
<iframe src="frame2.html"></iframe>

frame2.html

<form>
    <input value="エンコード">
    <input type="submit">
</form>

To recap with the example, if you load the page and check the encoding of both the parent and the iframe, you should see "Auto-Select" checked and "UTF-8" selected in both. If you hit Submit in the iframe, the frame will reload and the input text will be garbled. Checking the encoding of the iframe should still show "Auto-Select" checked, but now "Western European (Windows)" will be selected instead of "UTF-8". I need to know if there is anything else I can do to make it automatically preserve the UTF-8 encoding when the form action completes.

回顾一下这个例子,如果你加载页面并检查父和iframe的编码,你应该看到选中“自动选择”并选择“UTF-8”。如果您在iframe中点击提交,框架将重新加载,输入文本将出现乱码。检查iframe的编码仍应显示“自动选择”,但现在将选择“西欧(Windows)”而不是“UTF-8”。我需要知道在表单操作完成时是否还有其他任何操作可以使其自动保留UTF-8编码。

Thanks in advance!

提前致谢!

1 个解决方案

#1

When you say you cannot add a Content-Type header/BOM, are you able to add the Content-Type as a meta tag? Something like:

当您说无法添加Content-Type标题/ BOM时,您是否可以将Content-Type添加为元标记?就像是:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Recently I had very similar issues - IE auto-detecting Western European at all times, except when a certain popup window navigated to the page, which then caused IE to pick UTF-8. I was never able to track down exactly what caused it (the resulting page was identical, only the page that linked to it was different!), so we ended up fixing it by forcing UTF-8 across the entire application (with headers).

最近我有类似的问题 - IE自动检测西欧,除非某个弹出窗口导航到页面,然后导致IE选择UTF-8。我从来没有能够确切地追踪导致它的原因(结果页面是相同的,只有链接到它的页面是不同的!),所以我们最终通过在整个应用程序中强制使用UTF-8来修复它(带有标题)。

If you're really unable to modify the inner page in any way, is it possible you could "replace" this page with your own, and then send the content over to the "other" server via an API or HTTP POST where you wouldn't need to worry about IE's "auto-detecting"?

如果您真的无法以任何方式修改内部页面,是否可以用自己的“替换”此页面,然后通过API或HTTP POST将内容发送到“其他”服务器不用担心IE的“自动检测”?