IE 在 iframe 表单目标中丢失自动 UTF-8 编码
我在 IE 中遇到一个奇怪的问题。它与 IE 如何根据其父内容检测 iframe 的编码有关。我的应用程序将页面的内容包装在 iframe 中，并通过 Content-Type 标头将父窗口的编码设置为 UTF-8。 iframe 的内容不通过 Content-Type 设置编码，并在初始加载时选取父窗口的编码。这是期望的行为 - 内容窗口需要对某些语言内容进行 UTF-8 编码，但由于我无法控制的复杂原因，它无法强制设置自己的编码，因此它依赖于父窗口的编码。
当内容页面是表单操作的目标时，就会出现问题。当表单提交并且页面加载到内容窗口中时，它会自动选择西欧 (Windows) 编码。有谁知道为什么？我尝试过搜索有关相关行为的任何类型的文档，但是谷歌，他们什么也没做。任何类型的线索（除了发送内容类型标头或内容中的字节顺序标记之外）都是最有帮助的。
遗憾的是，我没有公共场所来托管此内容，但将这些代码示例复制粘贴到本地文件并使用 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>回顾一下示例，如果您加载页面并检查父级和 iframe 的编码，您应该看到“自动选择选中“并在两者中选择“UTF-8”。如果您在 iframe 中点击“提交”，框架将重新加载，并且输入文本将出现乱码。检查 iframe 的编码仍应显示已选中“自动选择”，但现在将选择“西欧 (Windows)”而不是“UTF-8”。我需要知道是否还有其他方法可以使其在表单操作完成时自动保留 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.
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.
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.
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.
Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当您说无法添加 Content-Type 标头/BOM 时，您是否可以将 Content-Type 添加为元标记？比如：
最近我遇到了非常类似的问题 - IE 始终自动检测西欧，除非某个弹出窗口导航到该页面，这导致 IE 选择 UTF-8。我始终无法准确地找出导致该问题的原因（生成的页面是相同的，只有链接到它的页面不同！），因此我们最终通过在整个页面强制使用 UTF-8 来修复它。整个应用程序（带标题）。
如果您确实无法以任何方式修改内部页面，您是否可以用您自己的页面“替换”此页面，然后通过 API 或 HTTP POST 将内容发送到您不需要的“其他”服务器无需担心 IE 的“自动检测”？
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:
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).
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"?