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.
Any ideas?
Best, Jonas
PS. This was tested on Palm OS 5 (Clie simulator). But the problem is there on a physical device as well (Tungsten T).
-- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
