5 Blind Squirrels Posted May 28, 2011 Posted May 28, 2011 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 Quote
+fegan Posted May 28, 2011 Posted May 28, 2011 e-mail sent requesting a geocache_visits.txt file for testing Quote
+Red90 Posted May 28, 2011 Posted May 28, 2011 Just copy and paste a sample of the text file here. Quote
+Wampus-N-Pickle Posted May 28, 2011 Posted May 28, 2011 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 Quote
+fegan Posted May 28, 2011 Posted May 28, 2011 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. Quote
+Wampus-N-Pickle Posted May 28, 2011 Posted May 28, 2011 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 Quote
John E Cache Posted May 28, 2011 Posted May 28, 2011 Try playing with text encoding.Safari 1.1: Selecting a Text Encoding Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.