Hi,

On Fri, Jun 24, 2016 at 12:51 PM, R Smith <rsm...@rsweb.co.za> wrote:
>
>
> 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.

OK, so all in all.
What I gather from all your replies is that however I enter the data -
table name, table fields -
whether it will be with "ALT+num", or directly typing it on the
keyboard, and independently
on where the input is produced - US, Germany or China - querying such
database will work.
correctly around the world.

Am I understanding this right?

If yes, than going back to my original post:

struct Table
{
    std::wstring name;
    std::vector<Fields> fields;
    std::vector<FKeys> foreign_keys;
};

std::wstring_convert<std::codecvt_utf8<wchar_t> > myconv;
const unsigned char *tableName = sqlite3_column_text( stmt, 0 );
pimpl->m_tables[m_catalog].push_back( Table( myconv.from_bytes( (const
char *) tableName ), fields, foreign_keys ) );

This code compiled with MSVC 2010 as C++11 snippet will crash
on the "ALT+225" symbol inside myconv.from_bytes().
And if my understanding above is correct - it shouldn't crash.

So what can I do to fix it?

Thank you.

>
> 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
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to