At 12:00am -0700 00-04-12, Palm Developer Forum digest wrote:
>Subject: Japanese Palms
>From: "Richard Burmeister" <[EMAIL PROTECTED]>
>Date: Tue, 11 Apr 2000 15:05:27 -0500
>X-Message-Number: 104
>
>I have been using some code to to generate a "unique" registration code for
>people who register my shareware app, based on their HotSync user name. My
>app checks the HotSync name when they attempt to enter a registration code
>and enables all application features if they enter the right code. I would
>like to make this work with the new Japanese Palms. This creates various
>problems:
>
>1) I don't know what the format of Japanese user names will be. Will they
>be encoded with charEncodingCP932, charEncodingShiftJIS, or
>charEncodingPalmSJIS?
Character encodings on the device will always be
charEncodingPalmXXXX, since Palm adds a few extra characters to the
control range. So charEncodingPalmSJIS is the same as
charEncodingCP932 (the Windows standard), plus these special glyphs.
Likewise charEncodingPalmLatin is the same as charEncodingCP1252,
plus these glyphs.
>2) The palmos35colorJapanese.rom on Poser appears to use
>charEncodingPalmSJIS, but I am not sure how to test reg codes on it -- some
>chars I type are translated to Katakana, some are not.
I assume you mean that when you enter ASCII characters, and the FEP
is on, some get transliterated to Hiragana or Katakana, while others
are not. Each Kana character has a matching sequence of ASCII used to
enter it from a keyboard (or Graffiti), and any invalid ASCII
sequences are left as-is.
>3) How can I determine all the chars that can be entered into a Japanese
>Palm without actually having one?
>
>Any input will be appreciated.
The short answer is that any valid Shift-JIS character should be
accepted. Shift-JIS has both single and double-byte characters.
The long answer depends on what type of processing you need to do to
the text. If you're munging it a byte at a time, then the range of
valid byte values is 0x20 - 0x7E and 0x80 - 0xFF (though 0xFD - 0xFF
will currently never appear).
If you need to process it a character at a time, then you'd want to
use TxtGetNextChar to grab characters from the string. At that point,
the range of possible values in the resulting WChar variable will be
0x0020 - 0x007E, 0x0080, 0x00A0 - 0x00DF, 0x00FD - 0x00FF, 0x8140 -
0x817E, 0x8180 - 0x81FC, 0x8240 - 0x827E, and so on ad nauseam.
Though I don't see why you'd need to treat the data as characters
versus bytes.
-- 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.palm.com/devzone/mailinglists.html
