5 Blind Squirrels Posted May 28, 2011 Share 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 Link to comment
+fegan Posted May 28, 2011 Share Posted May 28, 2011 e-mail sent requesting a geocache_visits.txt file for testing Quote Link to comment
+Red90 Posted May 28, 2011 Share Posted May 28, 2011 Just copy and paste a sample of the text file here. Quote Link to comment
+Wampus-N-Pickle Posted May 28, 2011 Share 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 Link to comment
+fegan Posted May 28, 2011 Share 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 Link to comment
+Wampus-N-Pickle Posted May 28, 2011 Share 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 Link to comment
John E Cache Posted May 28, 2011 Share Posted May 28, 2011 Try playing with text encoding.Safari 1.1: Selecting a Text Encoding Quote Link to comment
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.