Why does my field notes upload as Chinese Characters?

[5 Blind Squirrels]

 

I'm using a new Garmin Oregon 450t. It's a really nice unit and is working well for us. I have one issue that is driving me nuts however. Each time I upload a field note from the unit to GC everything gets converted to Chinese. I have verified the actual text file is indeed English. I do clear the geocache_visits.txt file after each upload. Can anyone tell me why this is happening? I am working off a mac computer and I am using the Safari web browser to communicate with GC. Any help in understand and trying to correct this would be great.

 

Thank you,

 

5 Blind Squirrels

[+fegan]

e-mail sent requesting a geocache_visits.txt file for testing

[+Red90]

Just copy and paste a sample of the text file here.

[+Wampus-N-Pickle]

This seems like an endian issue.

 

"geocache_vists.txt" file is a UTF-16 file. In other words, instead of an old-school ASCII text file where each character is one byte, a UTF-16 file typically uses 2 bytes (there are some exceptions) to represent each character. That gives a range of 64K characters - plenty to support extended character sets. The first two bytes in the file are read to determine whether the file is a "big" or "little" endian. It appears that somewhere along your chain of events, this value is getting swapped - and then subsequently read incorrectly. So, instead of the number '1' being stored (or read) as character code 0x0031, it's 0x3100 - which is probably a Chinese or Kanji character.

 

You might want to change up your workflow (use a PC instead of a MAC) to find out what step is messing up the endian-ness of the file.

 

Hope that helps!

 

Regards,

- Steve

[+fegan]

This seems like an endian issue.

 

"geocache_vists.txt" file is a UTF-16 file. In other words, instead of an old-school ASCII text file where each character is one byte, a UTF-16 file typically uses 2 bytes (there are some exceptions) to represent each character. That gives a range of 64K characters - plenty to support extended character sets. The first two bytes in the file are read to determine whether the file is a "big" or "little" endian. It appears that somewhere along your chain of events, this value is getting swapped - and then subsequently read incorrectly. So, instead of the number '1' being stored (or read) as character code 0x0031, it's 0x3100 - which is probably a Chinese or Kanji character.

 

You might want to change up your workflow (use a PC instead of a MAC) to find out what step is messing up the endian-ness of the file.

 

Hope that helps!

 

Regards,

- Steve

 

Hence my request for a file via e-mail rather than simply copy/paste an example in the forum. And I have access to both Mac and Windows for testing.

[+Wampus-N-Pickle]

Hence my request for a file via e-mail rather than simply copy/paste an example in the forum. And I have access to both Mac and Windows for testing.

Ah - missed your post. I just saw the request for the copy/paste.

 

- Steve

[John E Cache]

Try playing with text encoding.Safari 1.1: Selecting a Text Encoding