Question

我有一个使用Xerces XML解析器的应用程序，它弄乱了一个文件，该文件原本打算在文本字段中包含省略号（3个点）。

文件说它采用utf-8编码：

   <?xml version="1.0" encoding="utf-8"?>

问题字符串在记事本中如下所示：

   <tvo:BuylineDescription>LOCAL NEWS …NOT AIRING 9/3</tvo:BuylineDescription>

，即Chrome和记事本都在其中看到省略号字符。但是，如果我对文件进行十六进制转储，那么实际上就是十六进制2026，十六进制转储应用程序将其解释为空格和＆符。

4C4F43414C204E45 575320264E4F5420 LOCAL NEWS &NOT
414952494E472039 2F333C2F74766F3A AIRING 9/3</tvo:

十六进制2026是省略号的unicode值，但这不是unicode文件。好的，所以也许生成该文件的应用刚刚以unicode复制，并且是从某处复制/粘贴的（是的，我认为用户打算将省略号放在那儿）。但是，为什么这些应用程序将这2个字节的序列解释为UTF-8 XML文件中的unicode？如果这些应用程序出现省略号，为什么它会弄乱Xerces？也就是说，这是合法的UTF-8吗？哦，这个文件是作为单个SOAP'string'变量接收的-也许在传输过程中发生了一些代码翻译...

最重要的是-我的应用无法处理此文件。但是如果我用三个句号替换“＆”号，那么Xerces不会有任何问题。因此，要么我需要预扫描此字符序列并替换它，要么让发送者停止发送它。但是当然，在某些情况下，在空格后面加上“＆”号是合法的，因此预扫描可能会变得棘手。

这是别人早已想出如何应对的古老问题吗？我在这里看到很多类似的帖子-似乎没有什么完全匹配。

Answer 1

这里肯定发生了一些奇怪的事情。如果文件确实包含十六进制转储显示的两个字节x20 x26，那么我看不到任何应用程序会将其解释为省略号而不是（空格，＆）。

这是完全合法的UTF-8。解释为UTF-8，它是（空格，“＆”号），而Xerces之所以令人窒息，并不是因为它是不好的UTF-8，而是因为其中有一个＆符，没有引入法律实体或字符引用。

省略号的UTF-8编码为三个字节，xE2 x80 xA6。

我总是对十六进制转储感到怀疑。一些工具可以显示内存中的内容，而不是磁盘上的内容，而且并不总是相同的。如果我感到偏执，可以使用自己的代码以字节流的形式读取文件并以十六进制打印每个字节（Saxon中有执行此操作的代码：directionsService.route(request,function(response,status){ if (status==google.maps.DirectionsStatus.OK){ calculatedDistance = response.routes[0].legs[0].distance.value /1000; createTripObject(orig,dest, calculatedDistance) } }）

Answer 2

事实证明，原始XML文件包含有效的xE2 x80 xA6 UTF-8省略号，但是位于我和文件创建者之间的存储转发框已损坏它。不知道具体如何，但是我知道存储转发框将XML文本临时存储在SQL Server数据库中。因此，我的猜测是它将其存储在无法处理UTF-8的文本字段中，这就是发生损坏的地方。

就其价值而言，Xerces可以很好地处理UTF-8省略号，但无论是它（还是我的应用程序）都可以在省略号处截断字符串。我会再待一天。很高兴知道gSoap在传输过程中不会破坏UTF-8文本。

具有UTF-8编码的XML文件包含十六进制2026，该十六进制会弄乱xerces

2 个答案: