On Wed, Jan 06, 2010 at 08:21:05AM +0530, Harsha wrote: > I am developing a small testing application, which in vague way does > compare/diff etc. b/w the results obtained by executing a CLI command > under test. The output of this command may contain Asian character > such as Chinese(C), Japanese (J), Korean (K) and Taiwanese (T). > > And these characters may be in a specific encoding based on the OS for > example: > > Chinese - GB18030 on Solaris > UTF-8 on Linux > Japanese - Euc-jp on Solaris > SJIS on windows > UTF-8 on Solaris > Taiwanese - UFT8 on windows and linux > BIG5 on Solaris > Korean - EUC-Kr on Solaris > UTF8 on windows and linux
Solaris definitely supports UTF-8. The thing to do is to use UTF-8. You can do that by either: a) using only UTF-8 locales, or b) adding code to your application to convert between UTF-8 (used by SQLite3) and the user's locale's codeset. That is, convert user input to UTF-8, then use those strings with SQLite3, and convert output back to the user's locale's codeset before displaying it to the user. For (b) see the iconv(3C) and iconv(1) manpages to get started on codeset conversions, and the setlocale(3C), nl_langinfo(3C) and langinfo.h(3C) manpages to figure out how to get the current locale's codeset (first call setlocale(), then nl_langinfo(CODESET) to get the codeset. These are portable interfaces, available on Solaris and Linux both; I don't know how you'd do the same on Windows. > I had a glance at the documentation of SQLite, all I could figure reading > few sections of the doc. is that.. SQLite support Unicode (up to UTF-16 > LE,BE) > Is it a good idea for me to use SQLite to store the test-data involving the > above set of encoding? You can store non-UTF-8, non-ASCII strings if you use BLOBs, but I recommend (a), else (b), as described above. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
