Encoding error in gpx tracklog

[αdαmsκι]

This is confusing. I've got some gpx tracklog files (ie files removed from my Garmin Etrex 20 showing where I've ridden). The files from the Garmin will happily upload to bikehike, ridewithgps etc., but if I simply copy the text into another text editor (such as Kate, notepad or gedit) and save the file, making sure to change the extension to .gpx, it won't upload to bikehike, ridewithgps etc. I've made absolutely no changes to the data. I'm running Linux Mint. Any idea what the issue is because it's doing my head in?

[Feanor]

Is it due to the fact that the Linux-based editor is replacing the MS-DOS / Windows end-of-line characters with Unix-style ones on saving?
That's the major difference between text files in the DOS / Windows world and the Unix world.

See if your editors have options relating to that.
Configure the editor not to 'automatically convert' to UNIX format or whatever, and leave them in the original format.

[vorsprung]

After I edit gpx files by hand I always use an XML validator program on them

ISTR mint is a Debian variant so "apt-get install libxml2-utils" should give you a program "xmllint" (yes with two L)  run this from a shell with the -noout option on your file
and it will show the errors

[fuaran]

Or the wrong character encoding. The first line of the GPX file should be an XML tag that specifies the encoding.
eg

Code: [Select]

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
I think this will usually be UTF-8. So make sure your text editor is set to save as that encoding.

[αdαmsκι]

Kate does have options relating to end of line characters, but changing it to Windows still results in the same issue.

Encoding is UTF-8.

I am confused.com

Given up for the moment & used the old Windows laptop to edit the tracklog.

[Feanor]

Then can you do a binary compare of the file before and after editing, and see what's being messed up?

[αdαmsκι]

I can't see anything amiss upon visual inspection.

[Feanor]

Yes, that's why a binary comparison is required.
The difference will be in the characters you can't see, not the ones you can.

If you are able to make 2 file available for comparison ( an original that works, and one which has simply been load-saved with no other modification in an editor that does not ) then I'd be happy to do a binary / hex compare and determine the difference.

And I'm betting a marzipan hat it is related to EOL characters.
And I hate marzipan.

[frankly frankie]

Sometimes it's as simple as a c/r added to the end of the file.  Though BikeHike is usually pretty tolerant of dodgy files.

[αdαmsκι]

Well I am now running the latest version of Mint and Sublime text editor and all is good. Thanks for the various tips.