On 2016/06/24 6:11 PM, Simon Slavin wrote:
The ALT+num system for entering unusual characters is a Windows thing. On a
Mac you do it by picking the character from a virtual keyboard shown on the
display, or by holding a key down for a second to see variations on it. For
instance, if I hold down the 's' key I get three variations on 's', one of
which is esset. Whichever way I do it, I get the same Unicode character, which
I can prove using hexdump. The computer can't tell how the character was
entered.
Sorry, but whatever your problem is is going to have to be investigated by a
Windows user. Worse still, it might be different for different versions of
Windows.
I'm not sure it will be different between Windows versions (talking
different flavours of the same generation at least), but it may
definitely be different for different pieces of software on the very
same computer even.
Igor, to try and explain very simply what needs to happen for one of
your scenarios, I will try a box diagram (I hope this prints correctly):
+------ INPUT ------+ +------- TRANS -------+ +------ STORE ------+
| Get Input from | | Convert whatever | | |
| some console in | | we got from the | | Push the UTF-8 |
| whatever encoding | --> | input into UTF-8 | --> | translated value |
| or codepage etc. | | specifically | | into an SQLite |
|(like std:wstring) | || | DB |
\-------------------/\---------------------/\-------------------/
Now Send the DB to your friend in Germany or China.
+---- RETRIEVE -----+ +------- TRANS -------+ +------ OUTPUT -----+
| | | Convert the UTF-8 | | |
| Read the UTF-8 | | into whatever | | Display to user |
| from the DB | --> | encoding/code-page | --> | in console or |
| | | the target machine | | GUI in correct |
| | | or user likes. | | format. |
\-------------------/\---------------------/\-------------------/
SQLite API is only ever involved in the STORE and RETRIEVE steps. In
those steps, it expects UTF-8 and gives back whatever it was given,
assuming it to be UTF-8.
Everything else is up to the App / CLi or whatever other program is
tasked with getting information from and to users.
The problem you described about the command line interface seems that
you might get the wrong information back because you entered esset into
the console. Problem is, the console in windows using Alt-225 is not
UTF-8 (as other posts explained), it stores a byte-sequence that is not
UTF-8, but that shouldn't matter, because on return the same byte
sequence should display the same in the same console. if it doesn't,
then we have a bug (as Simon mentioned), but the bug is in the console
app, not in SQLite.
SQlite will definitely STORE and RETRIEVE stuff the same way.
Whether the SQLite Cli works as expected in Windows I do not know yet
and cannot test right now, but will do when I get home and someone else
did not do it already.
To answer your main question: Will a DB in SQLite produce the same
characters/encoding in Germany as in the US or China and can data be
safely sent from one to the other?:
The answer is: It should... if the Apps you use convert values correctly
between UTF-8 and local encodings (Steps: INPUT-TRANS-OUTPUT above),
then the SQLite API will do its part correctly (STORE-RETRIEVE) and you
should see the same things everywhere. if this isn't the case, then the
Apps you use are broken.
I hope this makes sense :)
Ryan
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
