反序列化 Yahoo 地理编码服务返回的类型时出现问题
我正在使用 Yahoo 地理编码服务,这是一项基于 RESTful XML 的服务。我无法完全反序列化 XML 响应。
我为结果创建了两个类:PlaceFinderResultSet 和 Result。 PlaceFinderResultSet 正确反序列化简单类型,但我无法反序列化复杂的“Result”节点 - 我的 Result 属性为 null。
[XmlRoot(ElementName="ResultSet")]
public class PlaceFinderResultSet
{
[XmlElement("Error")]
public int Error { get; set; }
[XmlElement("ErrorMessage")]
public string ErrorMessage { get; set; }
[XmlElement("Locale")]
public string Locale { get; set; }
[XmlElement("Quality")]
public int Quality { get; set; }
[XmlElement("Found")]
public bool Found {get;set;}
[XmlElement("Result",Type=typeof(Result),DataType="Result")]
Result Result { get; set; }
}
[XmlRoot(ElementName = "")]
[XmlType(Namespace = "http://www.tempuri.com", TypeName = "Result")]
public class Result
{
[XmlElement("quality")]
public int Quality{get;set;}
[XmlElement("latitude")]
public double Latitude{get;set;}
/** the rest of the code was omitted for brevity **/
}
以下是我尝试反序列化的 XML 示例:
<?xml version="1.0" encoding="UTF-8"?>
<ResultSet version="1.0">
<Error>0</Error>
<ErrorMessage>No error</ErrorMessage>
<Locale>us_US</Locale>
<Quality>99</Quality>
<Found>1</Found>
<Result>
<quality>72</quality>
<latitude>50.000000</latitude>
<longitude>-77.000000</longitude>
<offsetlat>50.000000</offsetlat>
<offsetlon>-77.000000</offsetlon>
<radius>500</radius>
<name>50 -77</name>
<line1>Route de la Baie-James</line1>
<line2>Baie-James, QC J0Y</line2>
<line3></line3>
<line4>Canada</line4>
<house></house>
<street>Route de la Baie-James</street>
<xstreet></xstreet>
<unittype></unittype>
<unit></unit>
<postal>J0Y</postal>
<neighborhood></neighborhood>
<city>Baie-James</city>
<county>Baie-James</county>
<state>Quebec</state>
<country>Canada</country>
<countrycode>CA</countrycode>
<statecode>QC</statecode>
<countycode></countycode>
<hash></hash>
<woeid>12697261</woeid>
<woetype>11</woetype>
<uzip>J0Y</uzip>
</Result>
</ResultSet>
<!-- gws26.maps.sp1.yahoo.com uncompressed/chunked Sun Jan 2 12:54:55 PST 2011 -->
I am working with the Yahoo geocoding service, a RESTful XML-based service. I cannot get the XML response fully deserialized.
I've created two classes for the result: PlaceFinderResultSet and Result. PlaceFinderResultSet correctly deserializes the simple types, but I cannot get the complext "Result" node to be deserialized - my Result property is null.
[XmlRoot(ElementName="ResultSet")]
public class PlaceFinderResultSet
{
[XmlElement("Error")]
public int Error { get; set; }
[XmlElement("ErrorMessage")]
public string ErrorMessage { get; set; }
[XmlElement("Locale")]
public string Locale { get; set; }
[XmlElement("Quality")]
public int Quality { get; set; }
[XmlElement("Found")]
public bool Found {get;set;}
[XmlElement("Result",Type=typeof(Result),DataType="Result")]
Result Result { get; set; }
}
[XmlRoot(ElementName = "")]
[XmlType(Namespace = "http://www.tempuri.com", TypeName = "Result")]
public class Result
{
[XmlElement("quality")]
public int Quality{get;set;}
[XmlElement("latitude")]
public double Latitude{get;set;}
/** the rest of the code was omitted for brevity **/
}
Here is an example of the XML I am trying to deserialize:
<?xml version="1.0" encoding="UTF-8"?>
<ResultSet version="1.0">
<Error>0</Error>
<ErrorMessage>No error</ErrorMessage>
<Locale>us_US</Locale>
<Quality>99</Quality>
<Found>1</Found>
<Result>
<quality>72</quality>
<latitude>50.000000</latitude>
<longitude>-77.000000</longitude>
<offsetlat>50.000000</offsetlat>
<offsetlon>-77.000000</offsetlon>
<radius>500</radius>
<name>50 -77</name>
<line1>Route de la Baie-James</line1>
<line2>Baie-James, QC J0Y</line2>
<line3></line3>
<line4>Canada</line4>
<house></house>
<street>Route de la Baie-James</street>
<xstreet></xstreet>
<unittype></unittype>
<unit></unit>
<postal>J0Y</postal>
<neighborhood></neighborhood>
<city>Baie-James</city>
<county>Baie-James</county>
<state>Quebec</state>
<country>Canada</country>
<countrycode>CA</countrycode>
<statecode>QC</statecode>
<countycode></countycode>
<hash></hash>
<woeid>12697261</woeid>
<woetype>11</woetype>
<uzip>J0Y</uzip>
</Result>
</ResultSet>
<!-- gws26.maps.sp1.yahoo.com uncompressed/chunked Sun Jan 2 12:54:55 PST 2011 -->
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
好吧,我尝试了一下,通过...
完全注释掉
[XmlType]
属性,然后...将此行更改为:
啊,序列化器很挑剔!
Ok I had a go, and I got it working by...
Commenting out the
[XmlType]
Attribute completely, and.... change this line:to this:
Gah that serializer is picky!
我建议您执行以下操作:
xsd.exe
实用程序两次阅读有关
xsd.exe
< MSDN 上的 /a> 工具 - 它非常节省时间!第一次运行:
这会将结果 XML 转换为 XML 架构 -
xsd.exe
将尽力猜测 XML 架构应该是什么样子,但您可能想查看生成的 XSD无论如何,并在必要时进行调整。第二次运行:
这会将 XSD 文件转换为 C# 类文件,然后您可以使用该文件反序列化从 Yahoo 服务返回的 XML 文件。
生成的 C# 文件太大,无法在此处发布,但我可以轻松地反序列化从发布的链接创建的示例 XML,并且我能够将其放入从该 XML 示例文件生成的 C# 类中。
另外:如果您有 Visual Studio 2008 并且安装了 WCF REST Starter Kit,Visual Studio 会提供一个新的菜单项:
通过将 XML 放入剪贴板,然后选择该菜单项,您可以让 Visual Studio 生成一个漂亮的 C# 类对于您来说,它将正确地反序列化该 XML - 非常方便!
通过一些手动工作,您也可以在 Visual Studio 2010 中获得此内容 - 请参阅 Danny Diaz 的博客文章
I would recommend the following:
xsd.exe
utility from the Microsoft Windows SDK over this file twiceRead about the
xsd.exe
tool on MSDN - it's a great timesaver!First run:
This will turn the result XML into an XML schema -
xsd.exe
will do the best to guess what the XML schema should look like, but you might want to have a look at the resulting XSD anyway, and tweak it, where necessary.Second run:
This will turn the XSD file into a C# class file which you can then use to deserialize those XML files you get back from the Yahoo service.
The resulting C# file is too large to post here, but I was easily able to deserialize the sample XML created from your link posted, and I was able to get it into a C# class generated from that XML sample file.
Also: if you have Visual Studio 2008 and you have the WCF REST Starter Kit installed, Visual Studio features a new menu item:
By putting your XML onto the clipboard and then picking that menu item, you can have Visual Studio generate a nice C# class for you that will properly deserialize that XML - very handy!
With a bit of manual work, you can get this in Visual Studio 2010, too - see Danny Diaz' blog post on it