正确放置具有 http-equiv 属性的 META 标记？

发布于 2024-09-09 07:59:12 字数 830 浏览 4 评论 0原文

我正在页面上实现 Bing 地图（我更喜欢 Google 地图，但这不是我的选择）。我正在遵循 MS 在这里提供的教程：http://msdn.microsoft。 com/en-us/library/bb412551.aspx

使用 MS 的代码，一切正常。用我自己的一些 jQuery 代码充实它，我发现每次运行 $.get(); 时都会收到“权限被拒绝”错误。我认为这是某种“同源”冲突，但经过多次检查，我确定我没有向任何其他主机请求任何内容（甚至不是 www.example.com 与 example.com - 一切都在相同的主机上）主持人）。

经过一番挫败之后，我最终将原因归结为 MS 代码中的 META 标签：

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

这位于我的 HEAD 部分的底部。在阅读规范时。对于 META 标签（我不太熟悉），我发现有些服务器可能会将 http-equiv 标签直接翻译成 HTTP 标头，而其他服务器可能只是按原样发送它们。由于我相信标头必须在任何内容之前发送，因此我将 META 标记移至 HEAD 部分的开头，一切正常。

另一个细节：我只在 IE7 中遇到问题。我在FF测试的时候完全没有问题。

所以这是我的问题：带有 http-equiv 属性的 META 标签是否应该位于 HEAD 部分的开头？ IE 是不是很奇怪？还是FF只是特别宽容？

谢谢！

原文

I'm implementing Bing Maps on a page (I'd prefer Google Maps, but it's not my choice). I'm following the tutorial MS provides here: http://msdn.microsoft.com/en-us/library/bb412551.aspx

Using MS's code, everything worked just fine. Fleshing it out with some of my own jQuery code, I found that I was getting a "Permission Denied" error every time I ran $.get(); I assumed this was some sort of "Same Origin" conflict, but after much checking, I determined that I wasn't requesting anything from any other host (not even www.example.com vs. example.com - everything was on the SAME host).

After much frustration, I finally whittled the cause down to the META tag in MS's code:

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

This was towards the bottom of my HEAD section. In reading the spec. for the META tag (which I wasn't very familiar with), I found that some servers may translate http-equiv tags directly into HTTP headers, while others may just send them as-is. Since I believe headers must be sent before any content, I moved the META tag to the BEGINING of the HEAD section, and everything worked fine.

Another detail: I only had problems in IE7. When I tested in FF, I had no problems at all.

So here's my question: Are META tags with the http-equiv attribute SUPPOSED to be at the begining of the HEAD section? Was IE just being weird? Or was FF just being particularly forgiving?

Thanks!

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

小伙你站住 2024-09-16 07:59:12

来自 HTML5 草案规范 (http://dev.w3.org/html5/规范/semantics.html#charset）：

4.2.5 元元素
[截图]
4.2.5.5 指定文档的字符编码
状态：最后一次征求意见
字符编码声明是一种指定用于存储或传输文档的字符编码的机制。
以下限制适用于
字符编码声明：
* 给定的字符编码名称必须是字符编码的名称 
  用于序列化文件。
* 该值必须是有效的字符编码名称，并且必须是 ASCII
  该编码的首选 MIME 名称的不区分大小写的匹配。 
  [IANA 字符集]
* 字符编码声明必须序列化，不使用 
  任何类型的字符引用或字符转义。
* 包含字符编码声明的元素必须被序列化
  完全在文档的前 512 字节内。
* 文档中只能有一个字符编码声明。

注意第四个要点。我相信 512 字节规则是传统浏览器之间的妥协，这些浏览器过去选择了不同的限制，但我认为所有浏览器都有一定长度的字节限制。这可能是原因，但我不知道为什么它会导致“权限被拒绝”错误。

From the HTML5 draft spec (http://dev.w3.org/html5/spec/semantics.html#charset):

4.2.5 The meta element
[snip]
4.2.5.5 Specifying the document's character encoding
Status: Last call for comments
A character encoding declaration is a mechanism by which the character encoding used to store or transmit a document is specified.
The following restrictions apply to
character encoding declarations:
* The character encoding name given must be the name of the character encoding 
  used to serialize the file.
* The value must be a valid character encoding name, and must be an ASCII
  case-insensitive match for the preferred MIME name for that encoding. 
  [IANACHARSET]
* The character encoding declaration must be serialized without the use of 
  character references or character escapes of any kind.
* The element containing the character encoding declaration must be serialized
  completely within the first 512 bytes of the document.
* There can only be one character encoding declaration in the document.

Note the fourth bullet point. I believe that the 512 byte rule was a compromise between the legacy browsers which have in the past chosen different limits, but all, I think, had a byte limit of some length. This may be the reason, though why it should cause a "Permission Denied" error, I've no idea.

回复收藏 0 原文

~没有更多了~