vtd-xml evalXPathToString奇怪的行为/无法正常工作

Question

In the second example below, why does evalXPathToString print junk1.45 rather than just 1.45 ?

I am using version 2.12 of vtd-xml.

String xml = "<xmlDoc><noele>junk</noele><valss>1.45</valss></xmlDoc>";

VTDGen vtdGen = new VTDGen();
vtdGen.setDoc(xml.getBytes(StandardCharsets.UTF_8));
vtdGen.parse(true);
VTDNav vtdNav = vtdGen.getNav();

AutoPilot autoPilot = new AutoPilot(vtdNav);
autoPilot.selectXPath("/xmlDoc/valss");
System.out.println(autoPilot.evalXPathToNumber()); // prints 1.45

autoPilot = new AutoPilot(vtdNav);
autoPilot.selectXPath("/xmlDoc/valss");
System.out.println(autoPilot.evalXPathToString()); // prints junk1.45

Answer 1

I have tried this on the latest build... and both return 1.45...

This appears to be one of the bugs that has been introduced in 2.12 and subsequently reported and fixed. The reason it is introduced is because 2.12 aims to fully support mix-content type of XPath evaluation... that is, if you eval xpath "/xmlDoc" to a string, it returns junk1.45..

Also, this bug only concerns evalXPathToString...not other three evaluation methods... I believe /xmlDoc/valss/text() will be one workaround...

If you don't want to wait for the formal release of 2.13 to amend this issue.. you can download the file and build a jar yourself with the following steps...

1. get the patch... go to vtd-xml's cvs host site... http://vtd-xml.cvs.sourceforge.net/viewvc/vtd-xml/ximple-dev/com/ximpleware/LocationPathExpr.java

2. drop the file under com.ximpleware

3. run the build.bat on windows... or whatever is equivalent on your unix machine

4. get the new jar file and replace the old 2.12 jar in the classpath...

Let me know if it works for you or not...