//使用字符串拼接的方式
String name = ...  
String attribute = ...  
String xml = "<root>"  +"<name att=\""+ attribute +"\">"+ name +"</name>"+"</root>";

//使用JDom的方式
Element root = new Element("root");  
root.setAttribute("att", attribute);  
root.setText(name);  
Document doc = new Documet();  
doc.setRootElement(root);  
XmlOutputter out = new XmlOutputter(Format.getPrettyFormat());
String xml = out.outputString(root);

请不要这样一连串的发帖，严重会被当做刷帖处理。

一般情况下，我们只要一提到XML，大多数问题都会集中到解析 XML和 XML结构等方面。在这类技术领域，W3C提出了 DOM 和 SAX规范用来解析数据，Sun提供了Java XML Pack，而 Apache则推出了Xerces 和Xalan。然而，几乎没有什么关注的目光投射到输出XML这一问题上来。把JavaBeans和Swing组件变成 XML的项目倒有一些，但大多数情况下，开发人员只不过希望能用定制的格式输出数据结构，这个任务其实不难。
我会具体提到好几种用Java创建XML文档的方案。它们都各自具备不同的优点，有些很简单，有些则会依赖于某些强大的类库。下面我就从最简单的方法说起。
使用StringBuffer 类
最简单、同时也是最常用的XML文档创建方法就是自己动手。你可以采用StringBuffer 类或者某些Writer 类。其优点是你不需要用到其他库，而且也不用创建多余的对象。可是，这一举措同时也带来了很多缺点。首当其冲的就是无法保证XML的格式正确性。字符在置入String 对象的时候必须仔细考虑。你得特别小心 XML实体的出现，比如用<取代〈等。 清单A 对此举例说明。
程序清单A 的输出结果是：
〈person name="Jon Smith" age="21"/〉
在这个简单的例子里，如果人名很古怪，比如Jon "The Cat" Smith，那么输出格式就出问题了。这段代码在获取名字的时候没有处理引号，结果输出的代码就成了下面这样子，显然这种表示是错误的：
〈person name="Jon "The Cat" Smith" age="21"/〉
在阅读源代码的时候很难跟踪隐藏在Java内的 XML 。想反，这种开发措施中大约1半左右的错误都归结为没有封闭的标签和错误的引号处理，简而言之就形成了无效的XML。
更明晰和简单的方法：DOM
第2个办法就是DOM，也就是所谓的文档对象模式（Document Object Model）。在给定对象结构之后，你可以把它转换为某种格式的XML对象结构，然后输出结果。可用的结构类型很多，范围包括 Jakarta Element Construction Kit （ECS）项目的 XML类到完全遵守DOM规范的解析器等，比如Xerces，通常，版本越小输出XML的方法就越简单。清单B 就是一个采用ECS的例子。
清单B 提出了一种输出数据的简明办法。事实上，你可以把两个输出行合并为一个，方法是把output 方法附在新的XMLDocument之后。这是一种采用ECS的有类语法模式，用起来方便之极。不过，这种方法不能很好地针对人员的年龄复制if-null 保护。为了实现这种保护，你必须采用清单C中的代码。
ECS 表现出了好几种优点，你不必避免引号字符（"）。你也不需要完全封闭标签，对象会为你做这些工作的，任何XML字符，比如〈或者〉都被 < 和 >代替，ECS可谓最简单的DOM方法。而用W3C的DOM、JDOM或者Dom4J来处理这种风格的代码则更为复杂一些，当然，W3C的DOM仍然具有独立解析的优点。
采用ECS输出XML的缺点包括了对象所引出的问题。你必须在写出内容之前建立对象。这样做在大多数情况下还是不错的，可你在输出大型XML文件的时候则不希望建立这种XML结构。同样的问题对其他大多数DOM方法也存在。
比起简单地采用Writers 或者 StringBuffer 类而言，ECS相当接近于一种标记。它的体积比较大，但只有很小一部分才用来输出XML。最大的问题是它的活动余地不大。它击败了其他同类型的方案，因为其他类型更大、更笨重而且更复杂。
SAX
SAX（Simple API for XML）可以替代DOM风格的 XML 解析。它由一系列事件或者代码在解析XML文件时所调用的回调函数组成。在你把结果直接输出到Strings的情况下它并不能派多大的用场。但是，它可以用在间接的、更为复杂的方式下。
输出Strings 的代码可以代替输出SAX事件。这一招可比仅仅输出Strings要高多了，它可以加入到一个简单的基类由其把SAX事件转换为XML。
让我们看看下面的例子，这个例子中使用了以下几个类：
Person: 业务对象，先前已经进行了说明
PersonInputSource: 接纳Person 对象
PersonXMLReader: 知道如何把PersonInputSource 转换为SAX 事件
XMLPrettyPrinter: 把SAX 事件转换为 XML的ContentHandler
其中最重要的代码在PersonXMLReader内，如清单D所示。
清单 D 中的代码说明了 Person 对象是如何被转换为一系列 SAX 事件的。但这可不是个最简单的活。用SAX把 Person 转换为 XML 是通过清单E中的代码实现的。
采用SAX 显然让你掌握了强大的计算能力，因为你可以在XML上附带SAX解析器而没有采用XMLPrettyPrinter。但是，在增加处理器的时候也会增加复杂性； SAX 是一种更复杂的概念。在多数情况下，简单的方法往往效果最佳。
一旦基本组件编写出来（XMLPrettyPrinter是一个基本InputSource，一个XMLParser 对象），产生事件就是小事一桩了。输出新的 XML 结构只需要 parse 方法和插入组件即可。
围绕SAX 事件建立XML还不是一个快捷、便利的措施。
采用XmlWriter 类
最后我提出个自己的方案，这就是XmlWriter 类。我的思路是采用一种界于太简单和太复杂之间的技术来输出 XML 。
重要的设计需求如下：
封装java.io.Writer
提供Writer类的API
尽可能地处理XML
避免建立大型对象结构
允许 ECS链式风格
实现以上的这些需求可以让 XML 写成两种风格。首先，它可以用java.lang.Writer 代码写出来，如清单F所示。
其次，它可以用链式方法的编码风格写成，这倒和ECS类似，因为每个write方法都返回 XmlWriter 自身。清单G 给出了这样的例子。
从性能角度上看，XmlWriter 具有一定的显著优势，它几乎没有创建其他对象。具有相当的功能性，可以处理基本的XML片段（但没有注释、缩排或者文档类型）。最重要的是，用起来很简单。
其负面问题已经提到过了，它不能处理注释、缩排或者文档类型。而ECS在 XML 对象写出自身时可以封闭标签，XmlWriter 需要你调用 endEntity 方法。如果实体没有终止就调用该方法就会扔出 XmlWritingException。最后，还有一个close 方法。它并不封闭writer对象，但会完成任何编写中的XML 。或许最重要的是，它会在实体没有终止的情况下扔出XmlWritingException 。
小结
产生XML方法有好几种方法。XmlWriter 并不一定是最佳的XML创建工具，但是这种方法填补了太简单、太笨重乃至太复杂之间的鸿沟