On Tue, Oct 7, 2014 at 5:39 AM, Richard Hipp <d...@sqlite.org> wrote:

> On Tue, Oct 7, 2014 at 12:06 AM, J Decker <d3c...@gmail.com> wrote:
>
> > I saw a few things go by about unicode... and understand that it should
> > just work to store the data as characters...
> >
> > I'm getting a unrecognized token... and think this page isn't right...
> > I was playing with greek translation of 'mary had a little lamb'
> >
> >
> I ran the following script through the sqlite3 command-line shell and it
> works fine:
>
> CREATE TABLE option4_values(option_id, string, segment);
> REPLACE INTO option4_values(`option_id`,`string`,`segment`)
>  VALUES('8b377a68-4358-11e4-ace4-3085a9903449','Μαίρη είχε ένα μικρό
> αρνί',0);
> SELECT * FROM option4_values;
>
> Hmm... wonder what it's getting....


> I suggest that the problem is in your programming language, or in the
> wrapper that links your programming language to SQLite, not in SQLite
> itself.  Can you tell us what programming language and what operating
> system you are using?
>
> C, visual studio 2012 build, windows.
built with UNICODE enabled... instead of multi-byte character set....
it could be my conversion routine... I'm using wcstombs_s  with _MSC_VER
set... before it was just faililng, because wcstombs_s doesn't convert
anything with a high bit set... so I added a handler to replace it with a
utf-8 16 bit character encode (expands to 3 bytes  as described here
http://en.wikipedia.org/wiki/UTF-8#Description  )

if( err == 42 )
{
(*ch++) = 0xE0 | ((unsigned char*)wch)[1] >> 4;
(*ch++) = 0x80 | ( ( ((unsigned char*)wch)[1] & 0xF ) << 2 ) | ( (
((unsigned char*)wch)[0] ) >> 6 );
(*ch++) = 0x80 |  ( ((unsigned char*)wch)[0] & 0x3F );
}

which works... if I mouse-over on char * string it shows the right unicode
characters.
The logging that I included in the first message was converted from
wchar_t* to char* and then the sqlite3_strerror() is expanded from char *
to wchar_t * and still shows the right characters....

 I just cannot identify the unrecognized token... it's obviously not at
character 0... (that's gotten by comparing the pzTail result of
sqlite3_prepare_v2 )...




> --
> D. Richard Hipp
> d...@sqlite.org
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to