jQuery与XML名称空间和xhr的区别。Opera和Firefox之间的responseXML

Consider this:

考虑一下:

<!DOCTYPE HTML>
<html><head><title>XML-problem</title>

<script src="jquery-1.3.2.min.js" type="text/javascript"></script>

<script type="text/javascript">

$(function() {
    $('<p/>').load("text.xml", function(responseText, textStatus, xhr) {
        var xml = $(xhr.responseXML);
        var x_txt = xml.find('atom\\:x').text();
        $(this).text(x_txt).appendTo('#container');
    });
});

</script>

</head><body><div id="container" /></body></html>

This script should load text.xml when the document has been loaded. text.xml looks like this:

这个脚本应该加载文本。加载文档时的xml。文本。xml是这样的:

<xml xmlns:atom="http://www.w3.org/2005/Atom">
    <atom:x>Text</atom:x>
</xml>

When this file has been loaded, the text contents of the atom:x-node are appended to the document. I can see "Text" in my browser window.

当加载此文件时，atom:x-node的文本内容将附加到文档中。我可以在浏览器窗口中看到“文本”。

This works as expected in Firefox. However, it does not work in Opera unless I change the query from 'atom\\:x' to just 'x'. In this case it works in Opera, but not Firefox.

这在Firefox中可以正常工作。但是，除非我将查询从“atom\:x”更改为“x”，否则它在Opera中不能工作。在本例中，它可以在Opera中使用，但不能在Firefox中使用。

I have discovered a workaround, namely changing the query to 'atom\\:x, x', but I would rather like to get to the bottom of this.

我发现了一种变通方法，即将查询更改为“atom\:x, x”，但我更愿意深入了解这一点。

Now for the funny twist: I can inline the xml directly instead of getting it from XHR by changing

现在来看看有趣的变化:我可以直接内联xml，而不是通过更改来从XHR获得它。

var xml = $(xhr.responseXML);

into

成

var xml = $('<xml xmlns:atom="http://www.w3.org/2005/Atom"><atom:x>Text</atom:x></xml>');

In this case a query of 'atom\\:x' will give the desired result in both browsers and just 'x' will give no result in both browsers.

在这种情况下，对“atom\:x”的查询将在两个浏览器中给出所需的结果，而在两个浏览器中，仅使用“x”将不会产生任何结果。

The fact that this works differently in Opera leads me to conclude that the former behavior is a bug in Opera. Is this a reasonable conclusion? Where can I point to for the standard that describes how this is supposed to work?

这在歌剧中有不同的效果，这一事实使我得出这样的结论:前一种行为在歌剧中是一种缺陷。这是一个合理的结论吗?我在哪里可以找到标准来描述它是如何工作的呢?

In conclusion:

结论:

What are the alternative work-arounds for this problem? Any better than the one I have found?
解决这个问题的替代方法是什么?比我找到的更好吗?
Is this a bug in Opera? If yes, which standard says so?
这是歌剧中的bug吗?如果是，哪个标准是这么说的?

Hope you can help :)

希望你能帮忙:)

4 个解决方案

#1

It's not a bug in Opera. It's the correct behavior:

这不是歌剧中的错误。这是正确的行为:

In a namespace-aware client, the name part of element type selectors (the part after the namespace separator, if it is present) will only match against the local part of the element's qualified name.

在可识别名称空间的客户机中，元素类型选择器的名称部分(如果存在名称空间分隔符，则在名称空间分隔符之后)将只与元素限定名的本地部分匹配。

In your case local name is x, and atom:x isn't even a legal local name in XML.

在您的例子中，本地名称是x，而atom:x在XML中甚至不是合法的本地名称。

Moreover, namespace-prefixed type selector in CSS has different syntax that doesn't use colon at all:

此外，CSS中的名称空间前缀类型选择器具有完全不使用冒号的不同语法:

@namespace atom url(http://www.w3.org/2005/Atom);
atom|x { color: blue }

Your syntax seems to rely on a quirk introduced by HTML parsers in namespace-unaware user-agents.

您的语法似乎依赖于HTML解析器在没有名称空间的用户代理中引入的怪癖。

HTML parser "eats" the colon as part of tag name and you get atom:x element in default namespace, which would match atom\:x selector, but in XML that you get x element in http://www.w3.org/2005/Atom namespace.

HTML解析器将冒号作为标记名的一部分“吃”，并在默认名称空间中获得atom:x元素，该名称空间将与atom\:x选择器匹配，但在XML中，您将在http://www.w3.org/2005/Atom命名空间中获得x元素。

#2

I've already experienced this behavior in different versions of the same browser and as far as I remember at the time I was testing the problematic page with FF and IE, so I'd say it's not an Opera-specific bug.

我已经在同一浏览器的不同版本中经历过这种行为，据我所知，当时我用FF和IE测试有问题的页面，所以我要说这不是一个特定于操作数的bug。

I'd suggest that whenever you use jQuery for parsing XML tags with namespace prefixes, you query for the selector both with and without the prefix. That is, instead of using

我建议，每当您使用jQuery解析带有名称空间前缀的XML标记时，都要查询带有和不带有前缀的选择器。也就是说，不使用

var x_txt = xml.find('atom\\:x').text();

try

试一试

var x_txt = xml.find('atom\\:x, x').text();

I think this is an acceptable workaround for most situations and it will assure that your results are correct despite the misbehaviors...

我认为在大多数情况下，这是一个可以接受的变通方法，它将确保您的结果是正确的，尽管有错误的行为……

#3

I think you should say "atom:x" (without the backslashes), and be sure to have the xmlns:atom="http://www.w3.org/2005/Atom" declaration either on the html tag on the main html file, or in some other way known for the javascript.

我认为您应该说“atom:x”(不带反斜杠)，并确保在主html文件的html标记上或以某种javascript已知的方式拥有xmlns:atom=“http://www.w3.org/2005/Atom”声明。

#4

It is hard to say if this is a bug in opera or if this is a bug in jQuery that is Opera specific. From the sounds of it, Opera is not properly adding the namespace to the xhr document dom and this is why jQuery cannot query atom:x and also explains why, when you create your own jquery node, you do not get the same results.

很难说这是opera中的bug还是jQuery中特定于opera的bug。听起来，Opera没有将名称空间正确地添加到xhr文档dom中，这就是为什么jQuery不能查询atom:x，并解释了为什么在创建自己的jQuery节点时，不会得到相同的结果。

First thing I would do is to try and see if atom is a defined namspace in the xhr dom. It should return your atom ns as defined, If not, this is probably an opera bug. I'm not sure the best way to test this, but perhaps: xhr.getElementByTagNameNS( "x" "http://www.w3.org/2005/Atom" ); will work.

我要做的第一件事是尝试看看atom是否是xhr dom中定义的namspace。它应该按照定义返回您的atom ns，如果不是，这可能是一个opera bug。我不确定测试这个的最好方法，也许是:xhr。getElementByTagNameNS(“x”“http://www.w3.org/2005/Atom”);将工作。

Failing that, Opera claims to support XML namespaces fully however so, I would open a bug request with jQuery and see where that get's you.

如果做不到这一点，Opera声称完全支持XML名称空间，因此，我将用jQuery打开一个bug请求，看看它能带来什么。

In other points, as I eluded to in my comment, I do not think that querying atom:x by x is a good idea at all. You may as well not use namespaces since it defeats the purpose.

在其他方面，正如我在评论中所回避的，我认为查询atom:x×x根本不是一个好主意。您最好不要使用名称空间，因为它违背了用途。

#1