I've found that TxtConvertEncoding may be unable to round-trip text containing newline or carriage return characters. It is possible I'm doing something wrong, but I've tried various methods of encoding newlines in my UTF-8 data, including the 0x2029 and 0x2028 codes.
Here's a short sample that illustrates the problem (should be problematic both on western and Japanese roms, although I have to admit my most recent tests of this particular piece have been on Japanese roms only):
Char *buff1, buff2[256], buff3[256]; unsigned short len1, len2, len3;
buff1 = "aaa\r\n\bbb"; // any combination seems to fail... len1 = StrLen( buff1 );
len2 = 255;
// This conversion works, and seems to retain the \r\n combination into
ShiftJIS if system
// character encoding is ShiftJIS. encoding is from sysFtrNumEncoding
err = TxtConvertEncoding( true, NULL, buff1, &len1, encoding,
buff2, &len2, charEncodingUTF8, "?", 1 );
len3 = 255; // This conversion fails, replacing the \r\n combination with "?" (as specified) err = TxtConvertEncoding( true, NULL, buff2, &len2, charEncodingUTF8, buff3, &len3, encoding, "?", 1 );
NOTE: The code is missing the piece for getting the system encoding, and may have minor spelling flaws (typed from memory).
Do I really have to write a loop to stop at the failing characters, decode the UTF8 data to detect newlines? To me it seems like a bug that text going one way can't be converted the other.
On Japanese ROMs with OS versions less than 5.3 there's a bug where converting from Unicode (e.g. UTF-8) to Shift-JIS fails for any character code < 0x20. So unfortunately you'll have to write a cover routine. If I get a few moments I'll try to do the same and post it here.
-- Ken -- Ken Krugler <http://www.krugler.org> +1 530-265-2225
-- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
