I had proposed (private email) some set of changes to shell.c to support 
unicode as fully as possible, including keyboard handling and output display, 
within the limits of the glyphs available in the unicode font selected for the 
windows console.

I see the support of unicode in sqlite3.exe (3.13) has made progress, but this 
is still very basic and far from what can be achieved by the code (even heavily 
refactored) I had proposed.

With 3.13 I can for instance run: sqlite3 ?cole.db and get that db to open 
successfully.
But I can't then type .read ?cole.txt and get that file to open and execute 
(Error: cannot open "?cole.txt").
In fact, the partial proper job is done for interpreting filename characters on 
the Windows command line, but it looks like it goes as far.

If the file was to open successfully, I'm pretty sure it wouldn't run 
correctly. Sample content is:
(hope your email reader supports utf8 properly and you have fonts for the 
correct glyphs rendering)

BEGIN TRANSACTION;
CREATE TABLE ?cole(? text, ? text);
INSERT INTO ?cole VALUES('?cole','?uro');
INSERT INTO ?cole VALUES('??','Chinese');
INSERT INTO ?cole VALUES('?????','Cyrillic');
INSERT INTO ?cole VALUES('????','Arabic');
CREATE TABLE ????(?? text);
INSERT INTO ???? VALUES('?????');
COMMIT;

(by the way I have absolutely no knowledge of whatever characters I entered in 
Chinese, Cyrilic script or Arabic nor what meaning that would have if there's 
one, these are just some characters for dumb testing).

In fact, sqlite3.exe ?cole.db ".read ?cole.txt" does exactly the same (Error: 
cannot open "?cole.txt").

Looking quickly at shell.c 3.13 the main culprit is to continue to try to 
convert to / from MBCS (through utf8_printf and the like) which ties all the 
I/O to a single 'code page' instead of going to /from UTF-16 and using Windows 
W APIs to read/write from/to the console. Which means at least that output 
intended for the console can't be simply sent through fputs to file FILE* 
descriptor, and keyboard input cannot be obtained simply from fgets.

Unfortunately, I have a busy week-end in front of me, but next week I'll bring 
a new patch based on shell.c (3.13) to overcome these.
It certainly is not a significant issue but a pleasant convenience for users on 
Windows platform having to deal with databases content highly internationalized.

-- 
Meilleures salutations, Met vriendelijke groeten, Best Regards,
Olivier Mascia, integral.be/om


Reply via email to