On Tuesday, 20 June, 2017 07:24, R Smith <rsm...@rsweb.co.za> wrote: > Every lesson is valuable! Just to be clear - there is nothing wrong > with using the CLI. When pointing it to a file that is correctly encoded > the import must work correctly (if not, it's a bug) - It's just > difficult to enter weird and wonderful Unicode characters outside the > BMP basic Latin plane (the first 127 code-points) via the console, or do > queries using them, all because the Windows console specifically is not > Unicode-enabled.
The Windows Console is fully UNICODE enabled and always has been, ever since the beginning of time. It does not, however, support any character encoding other than the proprietary Microsoft DBCS/MBCS, and then those only when one uses specific console I/O -- just like you have to use specific I/O in a gooey application -- streams do not have the code necessary to perform anything other than ANSI Code Page I/O. Specifically you CANNOT send any encoded anything to a stdio stream and expect it to get decoded. What you send (and what you receive from the keyboard) is ANSI only. This is the design of Windows. > As an aside - I never understood the reasons for that. I get that > Windows has a less "techy" clientèle than Linux for instance, and that > the backwards compatibility is paramount, and that no console command > ever need fall outside the 7-bit ANSI range of characters... but geez, > how much effort can it be to make it Unicode-friendly? It's not like the > Windows API lacks any Unicode functionality - even Notepad can handle it > masterfully. It is unicode friendly, and unicode is fully supported. The I/O streams do not support encoded byte streams is all. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
