Should not your application just retrieve the UTF-8 text and format it for 
display to the user?  User <-> Software formatting (and input/output diddling 
of any type) should only be done ONCE (on INPUT from the user or on OUTPUT to 
the user) as close to the User as possible and should *NEVER EVER* be done as 
an intermediate step that is used for any other purpose (that originating from 
or terminating with a user).

It is neither possible nor expected for a "Data Storage System" to know about 
the local foibles of the user -- that is an application programming (UI) issue. 
 "Data Storage Systems" store data in a user-foible-free state.  Date/Time are 
UTC ISO8601, text (encoded) is just a bunch of character units stored 
side-by-each, blobs are just a sequence of bytes stored side-by-each, integers 
are, well, integers in binary format; and, floating point is stored in floating 
point format (as an approximation to a value).

Placement of comma's/decimal points, display precision of floating point 
numbers, formatting of dates and "bag-o-bytes" (encoded text or blobs) are UI 
issues and not properly a part of the "Data Storage System".

That SQLite contains a "printf" function is quaint, but it is merely quaint and 
should not be expected to provide the same capabilities as a "proper" UI.

The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-----Original Message-----
>From: sqlite-users [mailto:sqlite-users-
>] On Behalf Of Ralf Junker
>Sent: Saturday, 17 February, 2018 10:40
>Subject: [sqlite] printf() problem padding multi-byte UTF-8 code
>Example SQL:
>   length(printf ('%4s', 'abc')),
>   length(printf ('%4s', 'äöü')),
>   length(printf ('%-4s', 'abc')),
>   length(printf ('%-4s', 'äöü'))
>Output is 4, 3, 4, 3. Padding seems to take into account UTF-8 bytes
>instead of UTF-8 code points.
>Should padding not work on code points and output 4 in all cases as
>sqlite-users mailing list

sqlite-users mailing list

Reply via email to