On 20 Jun 2017, at 2:24pm, 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. To clarify the clarification, you can use the SQLite shell tool just fine as long as you use it to process files, rather than expect characters which are entered through the keyboard or shown on the display to work. So use ".read" or ".output" or ".once", and then use a non-console program to view the results. Don’t type your text and view the results on the display. I don’t know the technical details of how windows does piping within the console. It may or may not work to use command lines with ">" or "|" in. > 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. The console you see is pretty-much the one which was in Windows 3.1. It does not use the modern API written post-unicode, it calls the old single-character Windows routines which are still in Windows so old programs don’t suddenly stop working. It has numerous parts which assume one keypress == one character == one octet == one space on the display these assumptions are not only in the code for the console itself but in the Windows routines it calls to do the work. Rewriting the console to use the newer API calls, and also deal with the above assumptions not being true would be so major that Microsoft might as well start again from scratch. And I’d expect the resulting code to be two or three times the size, and to be slower in execution. This affects Powershell too, since Powershell runs inside the console. But Powershell might do piping correctly, or be an improvement on the original shell in some other way. I don’t use Windows at work so I don’t know. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
