Thanks so much for the info. The problem then is that there's no universal standard as to how multicharacter characters might be implemented in a different country. It depends on their hack.
The issue is that the person will enter their hotsync ID to get a registration code to unlock the game. This process uses the web's method of handling the special character, which I've found to use UTF-8. If the person's Palm also uses UTF-8, then there's no issue - buffer matches buffer. But if the person's palm doesn't use UTF-8, then the unlock code won't work, and there's no general way to know how the person's hotsyncID is really stored.
OK, the fact that they're entering the HotSync ID via a web page is useful information. So the real problem is that the algorithm used to calculate a registration key (on the web server) is getting the text in UTF-8, and thus the key that it generates from that data doesn't match what the verification code calculates on the device, right?
There's a related issue, in that the HotSync ID entered on the desktop will use the desktop's legacy character encoding, but this might not match the device's character encoding. But that's a less common situation, as if they aren't in agreement, then you can't use the desktop software to view data synced from the device.
I can think of a few possible solutions to this problem:
1. I think you can force the web page to POST using the PC's legacy encoding. For a Russian user, this would be CP1251, which should match what they're using on the device.
But from what I remember, there are some browsers and desktop versions where this doesn't work properly.
2. Always submit using UTF-8 (Unicode). Ask the user what language they're using on their device, and include that information in the POST. Then use ICU or similar utility code to convert from UTF-8 to the device encoding, which you should be able to derive from the user's language.
Pretty painful amount of work for the number of users it would help.
3. Always submit using UTF-8. Anything > 0x7F gets mapped to a generic character code. Do the same thing on the device.
This weakens your validation algorithm, as it folds a bunch of different character code points together.
4. Always process everything using UTF-8. On the device, convert the user's HotSync ID from the device encoding to UTF-8 before you do your validation.
This won't work on versions of Palm OS earlier than 3.5.2, because there's no TxtConvertEncoding support (though you could handle the Latin case yourself, which would cover most of your users). Also some 3rd party hacks don't implement proper support for this call in their patches.
Perhaps Palm could use the same format they use with localization resource overlays with HotsyncIDs.
Not sure what this means. Overlays are localized using the device's character encoding. The HotSync ID is assumed to be in the same character encoding as the device for the reason describe above.
-- Ken
Ken Krugler wrote:
SUMMARY: How does the PalmOS store Russian characters in a HotsyncID?
That's up to the 3rd party hack used to provide Cyrillic support on a Palm OS device. I'm guessing they just use Windows code page 1251.
DETAIL: My PalmOS app reads the HotsyncID using DlkGetSyncInfo(NULL,NULL,NULL,pszBuffer,NULL,NULL); This works for any 8-bit character set, which covers most European characters and accents, but of course not Asian characters or dead keys.
dead keys?
And why doesn't it work with multi-byte characters? You're just reading the user name into a string buffer, right?
But I just got my first customers with Russian characters in their HotsyncIDs, which breaks my code because it only sees the ASCII.
What do you mean by "only sees the ASCII"? If your code only works with 7-bit ASCII then yes, you'd have a problem with Cyrillic.
Russian characters can be stored using UNICODE or UTF-8,
They could use UTF-8, but I don't think that's the encoding being used.
so I was wondering what format the PalmOS uses to store Russian characters, and whether or not they would show up using DlkGetSyncInfo?
All I need to be able to do is encode the bytes representing the Russian characters and my code will work, but I have no idea how they are represented on the Palm HotsyncID. (Or I need to know how DlkGetSyncInfo will reveal Russian characters and then my program will also work.)
Are you sure your code works with 8-bit characters? That's where I'd look first.
-- Ken
-- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200
-- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
