On 5-5-2015 12:25, Clemens Ladisch wrote: > Staffan Tylen wrote: >> I must admit that I'm a bit confused here. If I'm not wrong UTF-8 differs >> from ascii when the value is higher than '7f'x, but storing data in sqlite >> as text with character values beteen 'x80'x and 'ff'x seems to be no >> problem. I previously thought that this could only be done in blob format. >> >> create table t (a); >> insert into t values(cast(x'ff' as text)); >> select a,length(a),hex(a) from t; >> |1|FF >> >> My conclusion is that storing single-byte characters of any value is >> allowed, is this true? > > SQLite assumes that all strings you give it are encoded in UTF-8, and > does not actually check the encoding. It gives you the same string > back, so you could, in theory, use a different encoding, as long as you > do not use any database string processing functions. In practice, I > would not recommend this. > >> At the bottom it says: *Note to Windows users:* The encoding used for the >> filename argument of sqlite3_open() and sqlite3_open_v2() must be UTF-8, >> not whatever codepage is currently defined. Filenames containing >> international characters must be converted to UTF-8 prior to passing them >> into sqlite3_open() or sqlite3_open_v2(). >> >> So what does "must be converted" mean? I don't know how sqlite3.exe works >> here but if I do >> >> sqlite3 ?.db >> >> where '?' as we've seen is '82'x it happily creates a file with a >> non-displayable character in the first position that seems to be 1 byte >> long. > > The shell assumes that its arguments are UTF-8, and gives the filename > unchanged to sqlite3_open*(). When you've entered the filename in the > Windows console with the default settings, it is not encoded in UTF-8. > >
now it becomes time that windows will do some things with UTF-8.... (sigh) ;-) /me currently watching "Your PC will restart serveral times. Sit back and relax" while installing updates for technical preview to Windows 10
