爱华网在很多研讨会和培训班上我遇到过许多人，他们还不明白为什么要使用XML也不知道如何在他们的应用中使用XML。一些来自诸如Gartner公司的报告建议说，商业公司不能再做局外人了，不能对XML置之不理。如果你还不清楚XML到底有什么好处的话，你并不是唯一的人。
我决定把与人们和媒体关于XML话题的交谈整理成文，列出XML在应用中的五个最令人喜爱的用法。尽管这些并不能包含XML的所有潜在应用，至少是些最重要的领域。
1、数据交换
用XML在应用程序和公司之间作数据交换已不是什么秘密了，毫无疑问应被列为第一位。那么为什么XML在这个领域里的地位这么重要呢？原因就是XML使用元素和属性来描述数据。在数据传送过程中，XML始终保留了诸如父/子关系这样的数据结构。几个应用程序可以共享和解析同一个XML文件，不必使用传统的字符串解析或拆解过程。
相反，普通文件不对每个数据段做描述(除了在头文件中)，也不保留数据关系结构。使用XML做数据交换可以使应用程序更具有弹性，因为可以用位置(与普通文件一样)或用元素名(从数据库)来存取XML数据。
2、Web服务
Web服务是最令人激动的革命之一，它让使用不同系统和不同编程语言的人们能够相互交流和分享数据。其基础在于Web服务器用XML在系统之间交换数据。交换数据通常用XML标记，能使协议取得规范一致，比如在简单对象处理协议(Simple Object Access Protocol, SOAP)平台上。
SOAP可以在用不同编程语言构造的对象之间传递消息。这意味着一个C#对象能够与一个Java对象进行通讯。这种通讯甚至可以发生在运行于不同操作系统上的对象之间。DCOM, CORBA或Java RMI只能在紧密耦合的对象之间传递消息，SOAP则可在松耦合对象之间传递消息。
3、内容管理
XML只用元素和属性来描述数据，而不提供数据的显示方法。这样，XML就提供了一个优秀的方法来标记独立于平台和语言的内容。
使用象XSLT这样的语言能够轻易地将XML文件转换成各种格式文件，比如HTML, WML, PDF, flat file, EDI, 等等。XML具有的能够运行于不同系统平台之间和转换成不同格式目标文件的能力使得它成为内容管理应用系统中的优秀选择。
4、Web集成
现在有越来越多的设备也支持XML了。使得Web开发商可以在个人电子助理和浏览器之间用XML来传递数据。
为什么将XML文本直接送进这样的设备去呢？这样作的目的是让用户更多地自己掌握数据显示方式，更能体验到实践的快乐。常规的客户/服务(C/S)方式为了获得数据排序或更换显示格式，必须向服务器发出申请；而XML则可以直接处理数据，不必经过向服务器申请查询-返回结果这样的双向“旅程”，同时在设备也不需要配制数据库。
甚至还可以对设备上的XML文件进行修改并将结果返回给服务器。想像一下，一台具有互联网功能并支持XML的电冰箱将会给市场带来多么大的冲击吧。你从此不必早起去取牛奶了！
5、配制
许多应用都将配制数据存储在各种文件里，比如.INI文件。虽然这样的文件格式已经使用多年并一直很好用，但是XML还是以更为优秀的方式为应用程序标记配制数据。使用.NET里的类，如XmlDocument和XmlTextReader，将配制数据标记为XML格式，能使其更具可读性，并能方便地集成到应用系统中去。使用XML配制文件的应用程序能够方便地处理所需数据，不用象其他应用那样要经过重新编译才能修改和维护应用系统。
如前所述，这里提到的五种使用XML的途径不包括全部场合。我希望这些可以有助于你思考如何
顶
好
================================================================
CSDN 论坛助手 Ver 1.0 B0402提供下载。 改进了很多，功能完备！
★ 浏览帖子速度极快！[建议系统使用ie5.5以上]。 ★ 多种帖子实现界面。
★ 保存帖子到本地[html格式]★ 监视您关注帖子的回复更新。
★ 可以直接发贴、回复帖子★ 采用XML接口，可以一次性显示4页帖子,同时支持自定义每次显示帖子数量。可以浏览历史记录！
★ 支持在线检测程序升级情况，可及时获得程序更新的信息。
★★ 签名 ●
可以在您的每个帖子的后面自动加上一个自己设计的签名哟。
Http://www.ChinaOK.net/csdn/csdn.zip
Http://www.ChinaOK.net/csdn/csdn.rar
Http://www.ChinaOK.net/csdn/csdn.exe [自解压]
??????????????
顶上去。
1
up
很好！还有没有高手补充？？
补充：
==========================================================
xml的应用是什么？xml到底能做什么，我把自己的经验和体会整理了一下。
首先说，xml的技术有两项的很显著的特点。
1，数据和现实的分离。
2，数据的自描述性。
下面我就从这两个方面，结合自己的经验和丛书中了解的知识，简单的谈一下。
第一：数据和现实的分离。
比如说你手头上有一篇的资料(我们这里先假定是文字的资料，因为如果涉及到图，影像等范围就太广了，也不是我只能力所及)，是xml的数据的格式，好了，如果你的客户想通过互联网看看你的资料。你就可以使用一个aaa.xsl把你的xml的数据格式化为HTML的格式，同时这里面有个补充一点，因为你可以控制你要显示的内容，你可以过滤掉对于客户不能看到的信息。但是这里面你并没有动原来的数据。
如果你的老板想把资料打印出来，作为报表向上级汇报，还是用原来的数据，再写一个bbb.xsl，把xml的数据输出为一个漂亮的报表的形式。ok了。
如果你以前的数据是txt的格式，你就必须从新的要做两种的格式，
一个html的，一个报表的。你的工作最多时copy，copy的
2，数据的自描述性。
比如说我的个人信息。
对于数据库来说，可能建立一个users的表。建立不同的字段。
数据取得可以是
rs("name")="jiangtianpeng"
rs("Emial")="wfxian@263.net"
rs("Id")="dadapeng"
但是没有了rs或者对于外部来说又如何的区分id和name的区别。
dadapeng是id?还是name?
jiangtianpeng是name?还是id?
ok
用xml描述一下个人信息
<person>
<name>jiangtianpeng</name>
<id>dadapeng</id>
<natio>china</nation>
....
<email>wfxian@263.net</email>
</person>
是不是一目了然。
实际上面的问题就涉及到了不同系统之间的xml的交换。xml是不同系统之间的桥梁。
我谈一下我工作的xml经验
我现在的工作是一个中文，英文，俄文三种语言的网站，
比如我们通过com组件的得到一个用户的信息
可能是
<user id=‘feiddd‘ name_CN="王" name_EN="ddddf"
name_RU=‘这里是俄文‘ 。。。。等等的信息 />
在中文上就写一个显示中文的xsl,
在英文上就写一个显示英文信息的xsl。
如果不用这种技术，将会很麻烦的。
哪个xml解析器好用呢？最好通用一些的
我觉得配置文件用xml 不如ini, 我以前有两个应用程序都是用xml保存配置信息，后来都改成ini
xml修改起来不太直观
内容管理？我看不出来有什么必要用xml.
我所做的程序都用数据库保存数据，送到客户边都是HTML,用jsp 和 php ,asp 之类的程序。
如果 Dreamweaver 支持直接“所见即所得”地编辑，我倒可以考虑用xml .现阶段不考虑用xml
难的一见的好论题！！！是这几个月来，论坛中最好的，我对你们的努力表示感谢
怎么没人续了
还有一个不知道是不是优点或者缺点。
它把服务器端的压力转移到客户端了。
"它把服务器端的压力转移到客户端"我认为是好事。
XML 就是运行效率慢了些。
你要知道目前有很多人向我抱怨打开贴子的速度太慢了。
当然这跟目前对ie5.5以上，以下版本的机制处理不一样也有关，但如果贴子回复过长，就是ie6.0也很慢
ｖｅｒｙ ｇｏｏｄ
收藏
UP一下，呵呵
UP
xml 解析起来好像是有点慢，不过以后肯定会有改变的，
哈哈，这是一好论文 ，thanks
UP
什么UP，UP，UP呀？同志们，发点有意义的回复吧。
我个人认为这个论题十分有意义，自从XML发布以来，对于论述它的应用文章不多，而且不够深入（也许有些我没看到，也不可能全部都看到），所以XML在系统设计方面，得不到快速的应用与发展，请CSDN的各位高手多抛砖引玉，讨论研究一下XML在实际中的应用问题，XML绝对是以后网络世界的应用大趋势。
再来！
收藏
我做了N年的编程，综观整个计算机软件几十年的发展，只有3种技术是惊天动地的：
（1） OOP
（2） Visubal Basic (世界上最优秀的可视化编程语言，程序员对VB不精通是一种莫大的悲哀)
（3） XML
一个计算机人员如果把精力过多地放在了解不同的数据格式，学习不同的编程语言，使用不同的操作系统，炫耀不同的小技巧，钻研不同的硬件接口，分析不同的通讯协议，那么，他必将一事无成。因为这些所谓的技术只是今后软件工人或机器人就可以完成的一些机械的，重复的，简单的工作。
我，ERPBug，世界顶级编程大师，曾经说过一句名言：“编程就是对字符串的操作”，而XML正是对我所说的话的一种验证。当一个程序员真正体会到我这句话时，他就可以称得上是一个高手了。
当你真正知道编程是多么的简单时，你才能集中精力构思数据模型和软件结构，你才能把你的创造性发挥淋淋尽至。一个程序员的生命就在于创新。
“可视化编程”是OOP发展的必然结果，“字符串”是OOP的一个缩影。OOP是细胞，分子的数学符号。
XML的编程就是对字符串的编程，只有受过良好的正规训练的人，即，精通数据结构，精通编译原理，具有很强的数学逻辑思维能力的人，才知道怎样进行“字符串编程”
只有知道“字符串编程”的人才知道怎样开发操作系统，怎样开发数据库系统，怎样开发编程语言，怎样开发高性能的应用软件，怎样发挥中国人的聪明才智。
XML的灵活性，XML的扩充性，XML的简单性，XML的“字符串”性，正是XML的精华所在。
去体会XML吧，用心去体会！！！
最科学的东西，一定是最简单的。
世人皆醉，唯我独醒，我是一个智者，但我已经老了。
写于 2002/04/11 深夜
呵呵
我才看了xml一点点皮毛，我想问一下，xml用文本传输数据，怎么对数据进行加密~！
你的体会应该是那些发明这些技术的人的感慨吧：）
可能你终于理解了人家的思维了
然而当你明白的时候，可能你还不算智者，这只是别人的思维。你的呢？期待...
大哥，你就是神，你是雅典娜，你是圣母马力亚，你是耶苏，你是宙斯！
反正浏览CSDN就经常死机，而且是用WIN2K。
即使它有很多好处，单就这一点就会让人不喜欢，或许等它更成熟些，再来用吧。
To scarab(没有尾巴的鲨鱼):
不好意思，我吹牛吹过头了。XML重要之处不在于关于XML的技术，而是XML成为一种“标准”，有了标准之后，我们才能减少很多重复的，繁琐的，没有任何价值和意义的工作，我们才能抽出时间来思考，我们才能有我们自己的思想。
我相信我有很多好的思想，但我能把它变成标准吗？我有很多好的技术，我要费多少精力才能把它变成产品？我终于有了我一流的产品，我如何才能把它变成商业效益。你要知道，在中国，想做一点事情有多么难。
这个社会，脚踏实地干活的人无法生存，无法立足，坑蒙拐骗的公司生意日渐红火。有的软件公司靠“炒作概念”，“销售思想”就能赚大把的赚钱，而一些小的软件公司有一流的产品，却无人问津。再摘抄几句名言，送给大家：
（1） 国内某位大型酒厂的老总曾说过：“只要广告做的好，我连地上的土都能卖出大价钱来。
（2） 大唐电讯的老总曾说过：“三流的企业卖产品，二流的企业卖技术，一流的企业卖标准（卖概念）
另：我吹牛的目的，无非想激一激中国的程序员，希望大家不要见怪。我对中国的程序员真是“恨铁不成钢”。
真希望能经常与大家一起神侃，但还得去为生活奔波啊。
呵呵
相信自己
“编程就是对字符串的操作”
！？？？
to ERPBug:
我的偶像终于出现了！！！！！
只不过－－－－－－－－－－－
你的想法是否有点过于悲观呢？
1） 国内某位大型酒厂的老总曾说过：“只要广告做的好，我连地上的土都能卖出大价钱来。
（2） 大唐电讯的老总曾说过：“三流的企业卖产品，二流的企业卖技术，一流的企业卖标准（卖概念）
这两句说的对，确实如此呀！！！
看完！走！
我们公司既象二流企业，又象三流企业，又还跟一流企业沾点边，这算什么企业？？？：（
至于XML的作用，ChinaOK(蓝蝶）已经讲得和好了。
我本人并不太关心XML的具体技术，我只需要XML的设计思想，用来补充我自己的东西。
我对XML并不太了解，但当我第一次看到XML的格式的时候，我就知道它是我要找的东西，我也更加坚信我以前的设计思想都是正确的。
有意义
xml的伟大意义在于：它使数据标准化成为了可能。
计算机的实质就是数据处理机。不管是什末计算机，它们都在程序的控制下重复的做着三件事，数据接收，数据存储，数据输出。
从宏观上看，这些程序只有一个区别，那就是数据描述的标准不同。应用程序除了流程控制外，所做的另一件事就是数据解析。由于没有通用的数据描述标准，所以，不同的数据定义需要定义者提供专门的程序进行处理。
在以前，运行环境以单机或局域网为主，还好控制。但进入互联网时代，情况就不同了。企业之间面临着巨大的数据交换的需求，但谁也不能要求对方采用自己定义的数据标准，处理的方法有两个：一是在处理对方数据前，将其转换为与己方标准兼容的数据格式；另一种，则是定义一个数据表达标准，大家的数据都准循该标准。这样，各方的程序都可以直接处理这些数据。可以看出，第一种方法的效率低，而且数据转换的兼容性差，而后者则没有这些问题。XML就是在这种需求下出现的，它是一种元数据描述语言，人们可以用它定义一套数据表达标准，然后在此标准下提供数据。
1,在浏览这张XML页面时,确实要消耗大量的内存,我打了好几次,都是IE死掉,
想上面那位老兄说的死机是可能的
2
,"这个社会，脚踏实地干活的人无法生存，无法立足，坑蒙拐骗的公司生意日渐红火。有的软件公司靠“炒作概念”，“销售思想”就能赚大把的赚钱，而一些小的软件公司有一流的产品，却无人问津。"
我也有同感
3
请教,在BROWSER里如何把XML数据传给WEB服务器,谢谢
１． 你可以使用我的这个小程序来浏览ｃｓｄｎ
２． 的确如此。
３． 可以用XMLHTTP来发送
================================================================
CSDN 论坛助手 Ver 1.0 B0402提供下载。 改进了很多，功能完备！
★ 浏览帖子速度极快！[建议系统使用ie5.5以上]。
★ 多种帖子实现界面。
★ 保存帖子到本地[html格式]
★ 监视您关注帖子的回复更新。
★ 可以直接发贴、回复帖子
★ 采用XML接口，可以一次性显示4页帖子,同时支持自定义每次显示帖子数量。
可以浏览历史记录！
★ 支持在线检测程序升级情况，可及时获得程序更新的信息。
★★ 签名 ●
可以在您的每个帖子的后面自动加上一个自己设计的签名哟。
Http://www.ChinaOK.net/csdn/csdn.zip
Http://www.ChinaOK.net/csdn/csdn.rar
本签名由 CSDN 论坛助手自动添加！
XML方是，我认为千万不要用在程序内部，太浪费资源了！XML本身就是为了和外界进行接口的。我们公司的一些项目，就走入了这个误区：什么参数交换、传递，都是用XML.faint！在COM+方式下，搞的复杂无比！！！
xml是种简单易学的标准，但XSL就没有这么简单
我想知道如何在写XML的时候分页？比如是CSDN的文章就没有分页？
还有CSDN 怎么没有提供回复者对自己回复文章的删除功能？？
XML的确是就划时代，用字符文本的办法解决了数据的格式
gz
看了以上高见，有些说得有理，但有些就不大明白了。比如，我现在有一个系统，可能是ＭＳＳＱＬＳＥＲＶＥＲ做数据库，也有可能是用ＯＲＡＣＬＥ或ＳＹＢＡＳＥ之类的做数据库。前端用的是ＰＢ做的Ｃ/Ｓ程序。这时我想将之改成B/S ，这时ＸＭＬ能做什么呢？我的资料存在ＤＡＴＡＢＡＳＥ中，要说数据格式，恐怕ＸＭＬ是没法与之相比的。再说，现在的资料库越来越大，几百Ｍ甚至上Ｇ的数据库并不是稀奇事，想象一下，这些资料不是存放在数据库中而是用ＸＭＬ文件存放，是否会好恐怖？而又假如，这些资料原是存放在数据库中，然后后你要将之转成ＸＭＬ，又是多么恐怖的一件事？
不过也许我是因为对ＸＭＬ不了解才这样说。 但我曾买了本机械工业出版社的≤ＸＭＬ技术内幕≥，从头翻到尾，还是搞不清ＸＭＬ有什么用。呵呵，我太笨了
XML最好不要解析,而只是用适当的数据生成,这样的方向最快
XML分页是可以的在样例中有一些函数,可以的
但是很多函数有争议,不统一,兼容性不好
说白了就两种
数据交换和数据存储。
xml到底好不好？我想问问csdn就可以得到一些答案，改用xml以后对他们的整个网站建设维护是不是起到了事半功倍的效果，好坏就可见其一斑。xml是标准？那么是不是以后我们就没有所谓的txt，jpg，doc等等的类型文件？通通.xml，然后通通xml解析？只是好奇，呵呵。我现在想保存本页，下载了xml，可是没有xsl就看不到页面，是不是ie6就可以做到保存成html？是不是这就是所谓的把问题抛给了客户端？html变成了xml和xsl两，总觉得有点怪怪的，数据和格式（处理）分离真很‘爽’吗？？
peifu, peifu
XML不是万能的，它有它的适用返回。
它是计算机发展到现在阶段的产物，它的思想也没有什么特别，只不过是它成为标准而已，所以才重要。
话又回到“他是计算机发展到现在阶段的产物”，如果在286时代，绝对是即时有XML也不会通用。因为没有这么多空间、内存。XML使用的方法太笨。但它的思想是很好的--一种方便，明晰的表现数据和之间关系。（我想）
XML值得去学（我以为）
我始终在希望，标准与标准之间应该能沟通才是。
XML只是一种数据格式
但是这种格式能摆脱运作平台的影响
我用XML是把它当作数据交换的标准格式
现在国内的XML标准还很少
正需要大家共同努力
呵呵，我是一个低手，只看了一点点
请问一下xml对于数据的安全性？
欢迎各位高手赤脚
收藏
收藏
shou chang
mark!
前面有几位伙计谈到了XML的安全性（尤其在EDI中），我也想知道。不知那位可以告知。
转贴neilchen(我菜)的文章：
启用 XML 安全性
XML 加密和 XML 签名简介
XML 是因特网以及近来 Web 服务持续增长和开发的主要支持者。但是，在实现 XML 语言的全部能力之前，还有许多与安全性相关的工作要做。目前，加密整个 XML 文档、测试其完整性和确认其发送方的可靠性是一个简单的过程。但是，越来越有必要对文档的某些部分也使用这些功能，以便以任意顺序加密和认证以及涉及不同用户或发起方。目前，在与 XML 相关的安全性领域方面开发规范的最重要部分是 XML 加密、XML 签名、XACL、SAML 和 XKMS。本文介绍前两个。
简介
XML 已经成为一种用于在因特网上交换数据的有价值机制。SOAP，这种发送 XML 消息的方式，促使进程以一种前所未有的方式相互通信，而 UDDI 看起来正在快速成为整合 Web 服务的供应商和用户的标准；服务本身是 XML 以 WSDL （即“Web 服务描述语言”）形式描述的。如果没有 XML，将不可能有这种灵活性和能力，并且，正如许多人所说的，将有必要发明元语言。
安全性领域是另一个快速增长的领域。在不同团体之间建立信任的传统方法在公共因特网上已不合适，实际上，在大型 LAN 和 WAN 上也不合适。在这些情况下，基于非对称密码术的信任机制可能会非常有用，但实际上，部署和密钥管理的方便性、互操作性的范围和提供的安全性远不如各种的“公钥基础设施”（Public Key Infrastructures (PKI)）的热情的供应商曾让我们相信的那样。处理层次数据结构，以及带有机密、访问权限或完整性等不同需求的数据的子集特别困难。另外，具有不同于 XML 文档的现今标准安全性控制的应用程序一点都不简单。
目前，一些团体正积极投身于检查这些问题和开发标准的活动中。其中主要的相关开发是 XML 加密和相关的 XML 签名、“可扩展访问控制语言（XACL）”和相关的“安全性断言标记语言（SAML — 以前是互为竞争对手的 AuthML 和 S2ML 的结合）”。所有这些都由 OASIS 和“XML 密钥管理规范（XKMS）”驱动。本文将 介绍 XML 加密和 XML 签名。
XML 加密和 XML 签名
象其它任何文档一样，可以将 XML 文档整篇加密，然后安全地发送给一个或多个接收方。例如，这是 SSL 或 TLS 的常见功能，但是更令人感兴趣的是如何对同一文档的不同部分进行不同处理的情况。XML 的一个有价值的好处是可以将一整篇 XML作为一个操作发送，然后在本地保存，从而减少了网络通信量。但是，这就带来了一个问题：如何控制对不同元素组的授权查看。商家可能需要知道客户的名称和地址，但是，无需知道任何正在使用的信用卡的各种详细信息，就像银行不需要知道购买货物的详细信息一样。可能需要防止研究人员看到有关个人医疗记录的详细信息，而管理人员可能正好需要那些详细信息，但是应该防止他们查看医疗历史；而医生或护士可能需要医疗详细信息和一些（但不是全部）个人资料。
密码术现在所做的远远不止隐藏信息。消息摘要确定文本完整性，数字签名支持发送方认证，相关的机制用于确保任何一方日后无法拒绝有效事务。这些都是远程交易必不可少的元素，现在，用于处理整个文档的机制开发得相当好。
有了一般的加密，对 XML 文档整体进行数字化签名不是问题。然而，当需要对文档的不同部分（可能由不同的人）签名，以及需要与选择性的方法一起来这样做时，就会出现困难。也许不可能或者不值得强制不同部分的加密工作由特定人员按特定顺序进行，然而成功地处理文档的不同部分将取决于是否知道这点。此外，由于数字签名断言已经使用了特定专用密钥来认证，所以要小心签名人是以纯文本形式查看文档项的，这可能意味着对由于其它原因而加密的部分内容进行了解密。在另一种情况下，作为更大集合中的一部分，可能对已经加密过的数据进行进一步加密。在牵涉单一 XML 文档（可能由一些不同的应用程序和不同的用户处理在工作流序列中使用的 Web 表单或一系列数据）的事务集中考虑的不同可能性越多，就越可能看到巨大的潜在复杂性。
还有其它问题。XML 语言的强项之一是，搜索是明确的，无二义性的：DTD 或 Schema 提供了相关语法的信息。如果将包括标记在内的文档的一部分作为整体加密，就会丧失搜索与那些标记相关的数据的能力。此外，如果标记本身被加密，那么一旦泄漏，它们将被利用对采用的密码术进行纯文本攻击。
这些是工作组正在考虑的一些方面。
XML 加密示例
XML 加密语法的核心元素是 EncryptedData 元素，该元素与 EncryptedKey 元素一起用来将加密密钥从发起方传送到已知的接收方，EncryptedData 是从 EncryptedType 抽象类型派生的。要加密的数据可以是任意数据、XML 文档、XML 元素或 XML 元素内容；加密数据的结果是一个包含或引用密码数据的 XML 加密元素。当加密元素或元素内容时，EncryptedData 元素替换 XML 文档加密版本中的该元素或内容。当加密的是任意数据时，EncryptedData 元素可能成为新 XML 文档的根，或者可能成为一个子代元素。当加密整个 XML 文档时，EncryptedData 元素可能成为新文档的根。此外，EncryptedData 不能是另一个 EncryptedData 元素的父代或子代元素，但是实际加密的数据可以是包括现有 EncryptedData 或 EncryptedKey 元素的任何内容。
加密工作草案给出了一些示例来演示：加密的颗粒度如何根据要求的不同而不同，以及可能出现什么结果。清单 1 中的代码片断显示了带有信用卡和其它个人信息的未加密 XML 文档。在某些情况下（例如，隐藏支付机制的信息），可能希望加密除客户名称以外的所有信息，清单 2 的代码片断演示了如何这样做。
转贴neilchen(我菜)的文章：
清单 1. 显示 John Smith 的银行帐户、5000 美元限额、卡号和有效期的的信息
<?xml version=‘1.0‘?>
<PaymentInfo xmlns=‘http://example.org/paymentv2‘>
<Name>John Smith<Name/>
<CreditCard Limit=‘5,000‘ Currency=‘USD‘>
<Number>4019 2445 0277 5567</Number>
<Issuer>Bank of the Internet</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>
清单 2. 除名称之外全部被加密的加密文档
<?xml version=‘1.0‘?>
<PaymentInfo xmlns=‘http://example.org/paymentv2‘>
<Name>John Smith<Name/>
<EncryptedData Type=‘http://www.w3.org/2001/04/xmlenc#Element‘
xmlns=‘http://www.w3.org/2001/04/xmlenc#‘>
<CipherData><CipherValue>A23B45C56</CipherValue></CipherData>
</EncryptedData>
</PaymentInfo>
但是，在其它情况下，可能只需要隐藏一些敏感内容 — 可能来自商家或其它第三方 — 清单 3 演示了这点。（请注意，显示了与加密内容相关的标记名。）
清单 3. 只隐藏了信用卡号的加密文档
<?xml version=‘1.0‘?>
<PaymentInfo xmlns=‘http://example.org/paymentv2‘>
<Name>John Smith<Name/>
<CreditCard Limit=‘5,000‘ Currency=‘USD‘>
<Number>
<EncryptedData xmlns=‘http://www.w3.org/2001/04/xmlenc#‘
Type=‘http://www.w3.org/2001/04/xmlenc#Content‘>
<CipherData><CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
</Number>
<Issuer>Bank of the Internet</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>
可能还有必要加密文档中的所有信息，清单 4 演示了这点。
清单 4. 隐藏了全部内容的加密文档
<?xml version=‘1.0‘?>
<EncryptedData xmlns=‘http://www.w3.org/2001/04/xmlenc#‘
Type=‘http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml‘>
<CipherData><CipherValue>A23B45C56</CipherValue></CipherData>
</EncryptedData>
CipherData 可以封装，也可以引用原始加密数据。在第一种情况下，CipherValue 元素的内容显示原始数据，而在第二种情况，使用 CipherReference 元素，这包括了一个指向加密数据位置的 URI。
转贴neilchen(我菜)的文章：
规范的 XML
对应用了密码散列算法的消息进行最轻微的更改也会产生不同的值。这为消息完整性方面提供了信任，并适于通常用法，但是也引入了进一步的复杂性 — 两个 XML 文档虽然在逻辑上相等，但可能在确切文本比较中不同。象行定界符、空标记、在属性中使用十六进制而不是名称以及在特定情况下存在注释或注释变体这样的事情都可以成为文档的逻辑结构不受影响而实际彼此不同的实例。规范的 XML 规范描述了一种生成文档的物理表示（也成为范式）的方法，该范式解释允许的变体，以便如果两个文档具有同一范式，则认为两个文档在给定应用程序上下文中是逻辑相等的。
对于加密、特别是数字签名来说，这尤为重要，因为很明显，逻辑上相同的文本变体不应该表示文档的完整性及其发送方的认证是可疑的。用不同工具（譬如，解析器）生成不同文本（并因而生成不同消息摘要）进行处理时也可能发生这样的事。因此，在生成签名和验证计算期间，应该在范式上进行消息摘要。如果摘要匹配，这将确定：即使文本形式可能不同，它们在其上计算的范式也匹配。
XML 签名示例
可以将 XML 签名应用到任意数据内容。那些应用到相同 XML 文档中数据的签名称为封装或被封装的签名，而那些数据在签名元素外部的签名称为分离签名。清单 5 取自签名候选推荐文档，它是一个简单分离签名的实例。
清单 5. 一个简单分离签名的示例
[s01] <Signature Id="MyFirstSignature"
xmlns="http://www.w3.org/2000/09/xmldsig#">
[s02] <SignedInfo>
[s03] <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/
REC-xml-c14n-20010315"/>
[s04] <SignatureMethod Algorithm="http://www.w3.org/2000/09/
xmldsig#dsa-sha1"/>
[s05] <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
[s06] <Transforms>
[s07] <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-
20010315"/>
[s08] </Transforms>
[s09] <DigestMethod Algorithm="http://www.w3.org/2000/09/
xmldsig#sha1"/>
[s10] <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
[s11] </Reference>
[s12] </SignedInfo>
[s13] <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
[s14] <KeyInfo>
[s15a] <KeyValue>
[s15b] <DSAKeyValue>
[s15c] <p>...</p><Q>...</Q><G>...</G><Y>...</Y>
[s15d] </DSAKeyValue>
[s15e] </KeyValue>
[s16] </KeyInfo>
[s17] </Signature>
实际签名的信息是位于 s02 行和 s12 行之间，即 SignedInfo 元素。在签名的部分中包含用于计算 SignatureValue 元素的算法的引用，而那个元素本身位于签名部分之外（在 s13 行上）。s04 行上的 SignatureMethod 引用的是将规范的 SignedInfo 转换成 SignatureValue 所用的算法。它是密钥相关的算法和摘要算法（在这里是 DSA 和 SHA-1）的组合，可能还具有象填充这样的操作。KeyInfo 元素（在这里位于 s14 行和 s16 行之间 — 该元素是可选的）指出用来验证签名的密钥。
转换
正如前面所提到的，加密、签名、修改和可能进行的更多签名所发生的顺序有很多种可能性。用户可能需要向已经部分加密或部分签名的表单字段中输入更多数据，并且需要能够在不妨碍以后的验证和解密的前提下这样做。为解决这种情况，W3C 最近发布了一个有关 XML 签名的解密转换工作草案。（请参阅参考资料。）
下面这个示例摘自那个文档，它演示了如何建议文档接收方采用正确的解密和签名验证顺序。第一个代码段显示了要签名的文档部分 — order 元素；其中，第 7 行到第 11 行的 cardinfo 元素是关于个人和财务方面的详细信息，它是纯文本，但也存在一些加密数据（第 12 行）。
清单 6. XML 文档中的 order 元素
[01] <order Id="order">
[02] <item>
[03] <title>XML and Java</title>
[04] <price>100.0</price>
[05] <quantity>1</quantity>
[06] </item>
[07] <cardinfo>
[08] <name>Your Name</name>
[09] <expiration>04/2002</expiration>
[10] <number>5283 8304 6232 0010</number>
[11] </cardinfo>
[12] <EncryptedData Id="enc1"xmlns="http://www.w3.org/
2001/04/xmlenc#">...</EncryptedData>
[13] </order>
清单 7. 经过签名和进一步加密、且现在显示转换信息的 order 文档
[01] <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
[02] <SignedInfo>
[03] ...
[04] <Reference URI="#order">
[05] <Transforms>
[06] <Transform Algorithm="http://www.w3.org/2001/04/
xmlenc#decryption">
[07] <DataReference URI="#enc1"
xmlns="http://www.w3.org/2001/04/xmlenc#"/>
[08] </Transform>
[09] <Transform Algorithm="http://www.w3.org/TR/2000/
CR-xml-c14n-20001026"/>
[10] </Transforms>
[11] ...
[12] </Reference>
[13] </SignedInfo>
[14] <SignatureValue>...</SignatureValue>
[15] <Object>
[16] <order Id="order">
[17] <item>
[18] <title>XML and Java</title>
[19] <price>100.0</price>
[20] <quantity>1</quantity>
[21] </item>
[22] <EncryptedData Id="enc2"
xmlns="http://www.w3.org/2001/04/xmlenc#">...</EncryptedData>
[23] <EncryptedData Id="enc1"
xmlns="http://www.w3.org/2001/04/xmlenc#">...</EncryptedData>
[24] </order>
[25] </Object>
[26] </Signature>
第 1 行到 第 26 行的 Signature 元素现在包含前面的 order 元素（位于第 16 行到第 24 行），和以前的加密纯文本 cardinfo（显示在第 22 行这一行中）。有两个转换引用：解密（第 6 行到第 8 行）和规范化（第 9 行）。解密转换指示签名验证器解密除 DataRef 元素中第 7 行指定的数据之外的所有加密数据。解密了第 22 行中的 EncryptedData 元素之后，规范化 order 元素并且恰当地验证签名。
其它相关语言和规范
![使用XML的五种场合[精华] apple pay 的使用场合](http://img.413yy.cn/images/31101031/31021751t010c4b82b1f2c49d22.jpg)
隐藏 XML 文档中的敏感信息、建立完整性以及认证这些文档的不同部分的来源主要通过遵循加密和签名规范中列出的步骤来处理的，在引用的 W3C 草案中描述该规范（请参阅参考资料）。另外，还有其它紧密相关的领域，例如认证用户或系统、标识授权级别和管理密钥，所有这些都与 XML 安全性相关。
SAML 是一个由 OASIS 驱动的模型，它尝试融合相互竞争的 AuthML 和 S2ML 规范，使认证和授权信息的互换便于进行。“可扩展访问控制标记语言”是与 SAML 紧密相关的，但它更着重于特定 XML 文档的上下文中的面向主题特权对象的安全性模型，它也由 OASIS 指导，又是被称为 XACML 或 XACL（即使在同一些文档中）。通过用 XACL 编写规则，策略制订者可以定义，对于特定 XML 文档和前面所述的情况中的相关事情，由谁来实施哪些访问特权。
W3C 委员会现在正在考虑 XKMS，它打算建立一个位于 XML 签名标准顶部的密钥管理协议。有了 SAML、XACL 和其它倡议，XKMS 是构成应用于 XML 文档的安全性这个大框架中的重要元素。有了它，可以立杆见影地极大简化认证和签名密钥的管理；它通过将数字证书处理功能、撤回状态检查和认证路径位置和验证从所涉及的应用程序分离来做到这点 — 例如，通过把密钥管理委托给因特网 Web 服务。
在满足使用的便利性、可靠性和强健性方面，XML 安全性还有很多路要走。但是目前，正在取得良好的进展。
参考资料
• Jayanthi Suryanarayana 编写的 developerWorks 教程 SOAP 消息的数字签名解释了如何因安全性考虑而对您的 SOAP 消息进行数字签名和加密。
• Doug Tidwell 著的“XML 安全性套件”：增加电子商务的安全性演示了一些 Web 安全性的基础，描述了“XML 安全性套件”的组件并给出了一些示例来演示“XML 安全性套件”中的技术如何增加 Web 贸易的安全性。
• OASIS 联盟站点包括 The XML Cover Pages: XML and Encryption、Robin Cover 的有关这些活动的活动目录和有关出版物。该站点还有一份详细说明“安全性断言标记语言（SAML）”的草案文档。
• W3C 工作草案 XML Encryption Requirements 列出了“XML 加密”的设计原则、范围和需求。它包括与加密语法、数据模型、格式、密码处理以及外部要求和协调相关的要求。
• XML Encryption Syntax and Processing 详细说明了加密数据并以 XML 显示结果的过程。数据可以是任意数据（包括一份 XML 文档）、一个 XML 元素或 XML 元素内容。
• XML-Signature Requirements 列出了设计“XML 数字签名”规范的设计原则、范围和要求。它包括与签名语法、数据模型、格式、密码处理以及外
收藏此版面，没办法，明天要考试了，大后天再慢慢体会。
to ErpBug
大虾: 我对你的佩服简直如滔滔江水延绵不决...
“一个计算机人员如果把精力过多地放在了解不同的数据格式，学习不同的编程语言，使用不同的操作系统，炫耀不同的小技巧，钻研不同的硬件接口，分析不同的通讯协议，那么，他必将一事无成。因为这些所谓的技术只是今后软件工人或机器人就可以完成的一些机械的，重复的，简单的工作。”
就我个人粗浅的学识我也能体会到这句话的好来。太多的开发人员把精力过分投入到一些小技巧的钻研上，进而沉醉于这样的成就并且志得意满；他们津津乐道于什么什么语言速度更快，或者因为数据库表中增加了一列一个字节长度的字段而惊呼“浪费了存储空间”；但是如何抽象现实的业务、怎样的系统框架才更利于未来的扩展都被忽视了；在一些人眼里“解决方案”一词是那么遥远而陌生，实际上呢，用户需要的是什么？ solution,solution还是solution。
申明一点，我不是反对在具体技术或技巧上的钻研，只是想给那些“唯技术论”者提提醒，防止捡了芝麻丢西瓜的遗憾。
