On Sat, Aug 28, 2010 at 12:47 AM, Hans-Georg Michna <firstname.lastname@example.org>
> It's a solution, but not the only one. Post 1.4.2, it willAh, so the problem was already recognized!
> look like:
> bash-3.2$ echo "1,2,Xyx<hello>" | ./gpsbabel -i csv -f - -o
> kml -F - | grep hello
I fear that is not a complete solution. It does prevent breaking
XML, but when you load such a GPX file into any other program,
like Garmin's MapSource, you will actually get:
because other programs have no idea in what way the text was
encoded or that it was encoded at all. To my knowledge the GPX
standard does not prescribe encoding.
GPX prescribes XML. XML prescribes entity encoding and that is a legal encoding. Validate it and see:
echo "1,2,Xyx<hello>" | ./gpsbabel -i csv -f - -o gpx -F /tmp/blah && SAX2Count -f /tmp/blah
/tmp/blah: 8158 ms (7 elems, 9 attrs, 14 spaces, 50 chars)
If Mapsource gets this wrong (and it's late enough I don't want to boot Windows to see) then we need to rattle Garmin's cage.
inside the text has to be altered. (CDATA, unfortunately, is not
something like a transparent encoding. Its inventors have not
thought it through to the end.)
Yes, it's a legendary botch - and one reason why we do entity encoding instead of CDATA quoting when we can.