Clemens, > Le 12 f?vr. 2016 ? 06:43, Clemens Ladisch <clemens at ladisch.de> a ?crit : > >> Convert from UTF8 to the codepage returned by GetConsoleOutputCP(). > > This would corrupt any characters not in that code page. > > When we need to handle Windows console I/O specially, we could just as > well use _O_U8TEXT, or ReadConsoleW/WriteConsoleW, without lossy > conversions through a code page.
I very well understand your concern. ( Please understand that all comments that follow are based on a fact: it looks evident that the command-line tool of sqlite3 is meant to be compiled as a narrow I/O program. It uses the standard main() and not wmain(), gets argv[] which are the narrow ones and not the wide chars version and does not attempt to use the wide chars in or out channels. ) _O_U8TEXT is something specific introduced by some visual studio version (I think VS.2005 - to be verified, but probably not something we can really expect to find in all other compilers). I tend to prefer a platform specific feature over a compiler (or compiler's runtime library) specific feature. WriteConsoleW is interesting, but will require more conditional code changes to shell.c than may be desirable. It also introduces the will to use widechar output within a program designed for narrow output at first. SetConsoleOutputCP(65001) and leaving fprintf alone (not using shell.c::utf8_printf) more or less work, but I really fear issues with older Windows versions (than the Windows 10 I'm using right now). It also has a side-effect: that setting persists for command-line session after sqlite3.exe has quit, so great care should be taken to restore it on exits. It has half the effect of using the standard command CHCP. > >> [...] unless the display font actually supports unicode and UTF8 >> encoding, display issues can appear. > > If the font does not have the needed glyphs, the console will display > boxes, but it is still possible to copy the correct character values to > the clipboard. > > So it would be a bad idea to change sqlite3's output depending on the > current code page or font. I share your view on keeping things as unicode as possible, but the frontier is thin before trying to impose our views onto Windows usages and Windows command-line users expectations. That's why I tend to favor the path of least resistance: just fit whatever the default behavior/expectation is for the a (narrow) command-line tool writing some text to the console. Most people using sqlite3.exe interactively (on windows) won't expect to have correct console output for international texts (stored in the db) using scripts which are unusual for their system. But most users will expect to be able to type and see characters which are usual for them and their system. A user on a Windows set for typical Western Europe support (CP850 for OEM and CP1252 for ANSI), will expect to be able to type and see correctly things like '?', '?', '?', '?'. And won't be surprised to have a display issue with characters more exotic to them (those are characters which they would be at pain trying to type with their keyboard). Yet those concerned can use the standard Windows command CHCP to check or change their console code page to their liking. Provided that the font configured in their cmd session is able to, they will then be able to see those other characters (and copy them properly). What I'm proposing is that sqlite3.exe merely follows (for text sent to the interactive console) the current output setting of that console. Leaving it to the user to change the console setting if wanted/needed and permitted by the Windows version at hand. Certainly not a perfect solution, but it is much better than the current situation which is completely wrong, and it does not try to correct Windows inherently wrong unicode support. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://mailinglists.sqlite.org/cgi-bin/mailman/private/sqlite-users/attachments/20160212/c8497d08/attachment.pgp>
