设想一个简单的场景：你的应用需要同时处理来自两个不同数据源的XML文档。一个文档描述图书信息，其中使用了<title>元素表示书名；另一个文档描述人员档案，同样使用了<title>元素表示职称。当这两个文档被合并到同一个XML结构中，或者当一段代码需要同时解析它们时，解析器面对两个<title>就会产生歧义——它们到底是同一种语义还是两种完全不同的概念？在没有额外信息的情况下，这种冲突无法自动消解。
XML在设计之初就允许用户自定义标签，这带来了极大的灵活性，但也埋下了名称冲突的隐患。HTML之所以没有这个问题，是因为它的所有标签都由规范预先定义好了，而XML作为元语言，本身并不规定任何具体标签。当不同的行业组织、不同的软件系统都按照自己的习惯定义XML结构时，同一个词被用于不同含义的概率非常高。例如<table>在一个文档中可能指数据库表，在另一个文档中可能指HTML风格的表格布局。命名空间机制提供了一种将元素和属性与某个唯一标识符关联起来的方法，从而让同名标签在不同上下文中可以和平共处。
xmlns属性的两种声明方式：默认命名空间与前缀命名空间
xmlns属性是XML命名空间的核心语法，它本质上是一个特殊的属性，用于把一个命名空间URI绑定到元素上。第一种是默认命名空间声明，写法为xmlns="命名空间URI"。一旦在某个元素上声明了默认命名空间，该元素本身及其所有未被其他前缀覆盖的后代元素，都会自动归属于这个命名空间。看下面的代码片段：
<catalog xmlns="http://www.ipipp.com/book">
<book id="b001">
<title>XML入门指南</title>
<author>张三</author>
</book>
</catalog>
在这个例子中，<catalog>、<book>、<title>、<author>这些元素都位于http://www.ipipp.com/book这个命名空间之下。注意id属性并不自动属于默认命名空间，这是很多初学者容易忽视的一点——默认命名空间只作用于元素，不作用于属性。属性要进入命名空间，必须使用前缀声明。
第二种是前缀命名空间声明，写法为xmlns:前缀="命名空间URI"。这种方式会给命名空间起一个短小的别名，然后通过前缀:元素名的形式来限定元素或属性。下面是一个混合使用默认命名空间和前缀命名空间的例子：
<bk:catalog xmlns:bk="http://www.ipipp.com/book"
xmlns:au="http://www.ipipp.com/author"
xmlns="http://www.ipipp.com/catalog">
<bk:book au:id="b001">
<bk:title>深入理解XML</bk:title>
<au:name>李四</au:name>
</bk:book>
</bk:catalog>
这里<bk:catalog>和<bk:book>属于图书命名空间；<au:name>属于作者命名空间；而<bk:title>因为前缀bk被保留，所以它属于图书命名空间，不受默认命名空间的影响。属性au:id通过前缀au被明确归入作者命名空间，这一点符合属性必须显式使用前缀才能进入命名空间的规则。
前缀只是一个占位符，它的具体字符串并不重要，真正决定元素归属的是前缀所绑定的URI。同一个文档中，可以用不同的前缀绑定同一个URI，它们在语义上是完全等价的。不过在实际开发中，通常建议保持前缀的一致性，以提高可读性。
命名空间URI的本质：不一定可访问，只是唯一标识符
许多开发者第一次接触命名空间时，会误以为xmlns属性值中的URI必须指向一个真实存在的网络资源，比如某个XSD文件或者在线文档。实际上，命名空间URI的唯一作用就是提供一个全局唯一的字符串标识符。它采用URI的形式，只是为了利用域名体系的唯一性来避免冲突。解析器不会去访问这个URI，也不会从中下载任何内容。
例如xmlns="http://www.w3.org/1999/xhtml"这个XHTML命名空间，虽然URI确实可以访问并返回一些规范说明，但即便网络断开，XML文档仍然是合法且可解析的。同样，你完全可以使用一个不存在的域名作为命名空间URI，只要它在你的应用范围内是唯一的，就能正常工作。常见的做法是使用组织拥有的域名加上项目路径，例如http://mycompany.com/project/schema/v1，但没有人会真的在浏览器里打开这个地址。
既然URI只是一个字符串，那为什么不直接使用任意字符串而要用URI呢？原因在于URI有一套成熟的全局唯一性保障机制。域名由注册机构管理，同一个域名不会被两个不相关的组织同时拥有，因此以域名开头的URI天然具有唯一性。而如果使用像book这样的短字符串，两个不同的公司都可能定义book命名空间，冲突依然存在。URI只是借用互联网的命名体系来规避冲突，并不承担资源定位的职责。
要注意的是，命名空间URI的比较是逐字符精确比较的，区分大小写。例如http://www.ipipp.com/Book与http://www.ipipp.com/book是两个完全不同的命名空间。解析器在比较时不会做任何规范化处理，连结尾是否带斜杠都会影响结果。
DOM解析中的命名空间处理与常见误区
在DOM编程中，命名空间会影响节点名称的读取方式。以Java的DOM API为例，如果使用getElementsByTagName("title")来查询元素，它只能匹配没有命名空间的<title>元素，而无法匹配<bk:title>。要正确获取带命名空间的元素，必须使用支持命名空间的版本，例如getElementsByTagNameNS("http://www.ipipp.com/book", "title")，其中第一个参数是命名空间URI，第二个参数是本地名称（不带前缀）。
另一个常见误区是认为前缀是节点名称的一部分。实际上，在DOM树中，每个带命名空间的节点都存储了三个关键信息：命名空间URI、本地名称、前缀。节点名称nodeName通常是前缀:本地名称的形式，但localName属性只包含本地部分，namespaceURI属性包含完整的URI。如果你使用XPath来查询节点，同样需要根据是否声明命名空间来选择匹配方式。在XPath 1.0中，默认没有命名空间的概念，所有未加前缀的节点名都匹配无命名空间的节点；要匹配带命名空间的节点，必须在实现中注册命名空间绑定。
在实际的XML Schema校验中，命名空间的作用更加突出。XSD文档的目标命名空间必须与被校验的XML文档中声明的命名空间一致，否则校验会失败。例如一个XSD定义了targetNamespace="http://www.ipipp.com/book"，那么被校验的XML实例必须通过默认或前缀声明引用相同的命名空间。如果一个XML文档完全没有使用任何命名空间，那么它就不能用带有目标命名空间的XSD来校验，除非使用xsi:noNamespaceSchemaLocation这一类机制。
对于SAX解析器，命名空间信息会通过回调参数传递。在SAX2中，startElement方法通常提供了namespaceURI、localName和qName三个参数。如果解析器开启了命名空间处理，namespaceURI和localName会有效，而qName可能为空；如果未开启，则只有qName有效。开发者需要根据实际需求设置解析器的namespaceAware属性，否则可能拿到意料之外的结果。
属性与命名空间：一个容易被忽略的细节
之前已经提到，默认命名空间不会作用于属性。这意味着如果你声明了xmlns="http://www.ipipp.com/book"，那么元素<book version="1.0"/>中的version属性并不属于任何命名空间。要让属性进入命名空间，必须显式使用前缀，例如<book bk:version="1.0" xmlns:bk="http://www.ipipp.com/book"/>。这个规则源自XML命名空间规范的设计决策，目的是避免属性名称的冲突过于泛滥，因为属性通常依附于特定的元素，其含义往往已经由元素上下文确定。
另一个细节是属性名中不能同时出现多个前缀。例如<book bk:version:extra="1.0">是非法写法，因为属性限定名只允许最多出现一个冒号，且冒号前面的部分必须是已声明的前缀。冒号在XML名称中具有特殊意义，未声明前缀就使用冒号会导致解析错误。因此，在编写XML文档时，如果属性名中需要包含冒号，那冒号前的部分必须是已经通过xmlns绑定的前缀。
此外，xmlns属性本身在DOM中具有特殊属性节点。它们以xmlns或xmlns:前缀的形式存在，但命名空间URI通常是http://www.w3.org/2000/xmlns/。当你在DOM中遍历属性时，这些声明性的属性也会被列出，但有些解析器会将其与普通属性区分开。在实际处理中，除非你需要动态修改命名空间声明，否则一般不需要关心它们。
XML命名空间虽然看起来只是增加了一个xmlns属性，但它解决了XML作为可扩展标记语言在跨系统、跨组织交换数据时的核心矛盾。理解默认命名空间与前缀命名空间的差异、URI的标识符本质、属性不继承默认命名空间这些细节，能够帮助开发者在解析、校验和生成XML时避免大量隐蔽的错误。当一份XML文档未来可能被合并、转换或与第三方系统交互时，从一开始就设计好清晰的命名空间策略，远比事后补救更加省力。
