使用xstream解析Google地理编码

Question

我正在使用Java和XStream通过http解析Google地理编码请求。我的想法是拥有一个具有所有地理编码属性（例如纬度/经度，城市，省/州等）的Address类，但是我在使用xstream解析xml时遇到了问题。

Google的回应与此类似：

<?xml version="1.0" encoding="UTF-8" ?>
<kml xmlns="http://earth.google.com/kml/2.0"><Response>
  <name>98 St. Patrick St, Toronto</name>
  <Status>
    <code>200</code>
    <request>geocode</request>
  </Status>
  <Placemark id="p1">
    <address>98 St Patrick St, Toronto, ON, Canada</address>
    <AddressDetails Accuracy="8" xmlns="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0"> <Country><CountryNameCode>CA</CountryNameCode><CountryName>Canada</CountryName><AdministrativeArea><AdministrativeAreaName>ON</AdministrativeAreaName><Locality><LocalityName>Toronto</LocalityName><Thoroughfare><ThoroughfareName>98 St Patrick St</ThoroughfareName></Thoroughfare><PostalCode><PostalCodeNumber>M5T</PostalCodeNumber></PostalCode></Locality></AdministrativeArea></Country></AddressDetails>
    <ExtendedData>
      <LatLonBox north="43.6560378" south="43.6497426" east="-79.3864912" west="-79.3927864" />
    </ExtendedData>
    <Point><coordinates>-79.3896388,43.6528902,0</coordinates></Point>
  </Placemark>
</Response></kml>

不能很好地显示出来，但是代码的内容在AddressDetails标记中。

无论如何，我是Java和XStream的新手，所以API术语对我来说有点混乱。我只需要能够编写一些映射器将所有这些标签（即CountryName）映射到我的Address对象中的一个属性（即address.country
= blah），该地址对象将非常简单，主要是针对国家/地区的字符串名称等，并以经纬度为单位浮动。

文档和示例仅显示了直接映射，其中每个xml标记直接映射到对象名称相同的属性。但是，在我的情况下，标签的命名与对象attr的命名不同。我真正想要的只是朝着正确方向迈出的第一步。

Answer 1

我在几个项目中都使用过XStream。不幸的是，您的问题并不是XStream真正要解决的问题。您也许可以使用其转换器机制来实现您的近期目标，但是会遇到限制。简而言之，XStream并非旨在将树结构A转换为树结构B
－其目的是将Java域模型转换为某种合理的XML。当您不太在乎所生成的XML的细节时，XStream是一个很好的工具。如果您比Java对象更关心XML，请看一下XMLBeans
－ Java很丑陋，但是它非常符合模式。

对于您的项目，我将通过XML bean运行Google
XML架构，生成一些Java，这将为您提供一种更熟练的手动编码转换器的方法。您可以使用原始的DOM树，但是您将拥有类似于myAddress.setStreet（root.getFirstChild（）。getAttribute（“
addr1”））））的代码。使用XML
Bean，您可以说出myAddress.setStreet（googleResult.getAddress（）。getStreetName（）;

我会忽略JAXB，因为它试图将接口与实现分离开来会增加不必要的复杂性。Castor也可能是一个不错的工具，但是我已经好几年没有使用它了。

简而言之，没有很多好的对象到对象或XML到对象的转换器可以很好地处理结构转换。在我看到的尝试声明式解决方案的解决方案中，它们似乎都比使用XStream /
XmlBeans以及手工编码的结构转换要复杂得多（并且不再可维护）。