我正在将一些XML发布到AWS的API网关方法中,该方法已集成到SNS。然后,一个SQS队列订阅了该主题。而且我有一个C#进程,该进程会间歇性地轮询队列,并且需要反序列化XML。
问题在于,XML标记之间的空格最终会在某处沿行进行编码,因此制表符变为\t
,而新行变为\r\n
。但是这些最终成为字符串中的物理令牌。
发布到API网关的XML示例:
<?xml version="1.0" encoding="utf-8"?>
<ProfileInformation>
<Username>bgs264</Username>
</ProfileInformation>
从SQS队列中读取的字符串:
<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<ProfileInformation>\n\t<Username>bgs264</Username>\n</ProfileInformation>
请注意,声明中的属性最终以\"
结尾,发布的空白最终以\t
,\r\n
等结尾。
但是,这些并不是“字符串在调试器中出现的样子,但实际上是一个制表符”,它们在字符串中实际上是这样的。
因此,当我尝试反序列化时,请使用
using (var reader = new StringReader(message))
var myObj = serializer.Deserialize(reader) as ProfileInformation);
我得到:
InvalidOperationException:XML文档中存在错误(1、15)。
它引用声明中的第一个\
字符,如version=\"1.0\"
我的直接想法是简单地将string.Replace
\t
替换为空字符串等,但这是不可接受的,因为用户的用户名实际上是bgs\t264
可能是有效的,这里的替换将是导致不一致。在此示例中,我假设我会在消息中得到bgs\\t264
,因此替换将错误地导致我离开bgs\264
。
因此,我需要修复这些\n\t
字符在XML标签之间出现的位置。
对于它的价值,我还有一个用Go编写的lambda,它对此没有任何问题,只需将完全相同的字符串反序列化为XML。所以这一定有可能。
我的初衷:
HttpUtility.DecodeHtml
,但我
不要以为实际上是我要解码的HTML! 答案 0 :(得分:1)
我会猜到,并且某些谷歌搜索似乎支持该理论,即您所看到的消息已转换为JSON,并且转义序列是其结果。
理想的方法是调查并防止这种情况的发生。我对SNS的了解不多,无法为您提供建议,您表示这是一个入门者,因此最简单的方法是在收到邮件后立即撤销此过程。
您可以使用Json.NET之类的JSON库来做到这一点:
var jsonString = string.Format("\"{0}\"", message);
var xmlString = JsonConvert.DeserializeObject<string>(jsonString);
using (var reader = new StringReader(xmlString))
{
var profileInformation = (ProfileInformation) serializer.Deserialize(reader);
}