Ted,
>I didn't insert it. I 'inherited' it from a (mercifully nameless)
>predecessor.
>I want to put this data into a database to make it easily accessible
I'm no SQLite guru (really NO), but here is my 2 cent advice.
First decide or determine what is (or shall be) your database
encoding. Even if SQLite has no problem storing ANSI (or EBCDIC or
anything else) strings untouched, I would strongly recommend you select
either UTF-8 or UTF-16 if your situation doesn't impose something
else. This way your data is garanteed to display stored data
independant of the user's codepage (if applicable). This choice is to
be made at database creation and can't be changed, short of dumping the
base and re-loading it into a fresh one using another (internal) encoding.
Independantly of the selected Unicode internal encoding, you can use
any two UTF interfaces to SQLite: the xxx or the xxx16 functions. But
of course, supply data encoded consistently with the functions you invoke.
As I understand it, your data is not yet stored in the base. When/if
this is the case, use whatever transcoding tool you find handy to
re-encode your data before pushing it into the SQLite base, if needed.
For instance, the 'degree symbol' is {0xB0} ANSI (Latin1 codepage), is
{0xC2 0xB0 } as UTF-8 and {0x00B0} as UTF-16. But even if the ANSI
(Latin1) charset between 0x80 and 0xFF map to corresponding Unicode
codepoints, beware that they need to be UTF-8 encoded if you want them
to display correctly using a UTF-8 tool.
OTOH you can as well choose to store ANSI (for instance) data, but you
need to retrieve/display back data using the same encoding. The catch
is that non-Unicode (e.g. ANSI) tools are fading away, even in the Win*
world.
J-C
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
