Thanks Rowan. I’ve picked up bits and pieces from the various replies to get a basic idea of what’s going on. My question should’ve been posted on the c++ builder forum in the first place. Sorry for wasting everyone’s time.
Tom From: Rowan Worth<mailto:row...@dug.com> Sent: 09 August 2017 03:29 To: SQLite mailing list<mailto:sqlite-users@mailinglists.sqlite.org> Subject: Re: [sqlite] hex and char functions On 8 August 2017 at 18:32, x <tam118...@hotmail.com> wrote: > Why does it always turn out to be my own fault ☹ > Welcome to programming ;) It's very rare in practice to find an actual bug in a library or language, especially one as widely deployed and tested as sqlite. Glad you're sorted, I just wanted to have a quick go at clearing this up: but finding out that the UTF8 code for the UTF16 code \u0085 is in fact > \uc285 has tipped me over the edge > 1. \u0085 is a unicode code-point, 'NEXT LINE (NEL)' 2. \uc285 is a unicode code-point, 'HANGUL SYLLABLE SWIT (솅)' 3. Neither of these is a UTF8 or UTF8 "code" -- UTF8 and UTF16 are different ways of enconding/decoding unicode code-points 4. In UTF8, \u0085 is encoded as two bytes -- 0xc2 0x85 5. In UTF8, \uc285 is encoded as three bytes -- 0xec 0x8a 0x85 HTH, -Rowan _______________________________________________ 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
