Hi László, Please note that in https://www.sqlite.org/lang_corefunc.html#length
it says that "For a blob value X, length(X) returns the number of bytes in the blob." Troy On Sat, 2020-04-11 at 09:15 +0200, László Böszörményi (GCS) wrote: > Control: tags -1 +wontfix > > Hi Troy, > > On Thu, Apr 9, 2020 at 6:03 PM Troy Korjuslommi <g...@gyw.com> wrote: > > The LENGTH() function should return the number of bytes for a > > column of type BLOB > > (according to sqlite3 documentation). However, when data is valid > > UTF-8, it returns the > > number of characters, not bytes. This means that LENGTH(column) is > > less than the number of > > actual bytes returned from SELECT. > Please note that I'm the Debian maintainer of the package, not > affiliated with the SQLite maintainers. They have a forum[1] for such > discussion and requests. > This time I know the answer why column data converted unicode string. > First, length() [2] converts its parameter to a number of characters > first. You can test it with a number even, see the output of: select > length(100); > It will be three as the integer 100 is converted to "100" which is > three characters wide. But the more generic answer is how datatypes > are handled in SQLite [3]: "SQLite uses a more general dynamic type > system. In SQLite, the datatype of a value is associated with the > value itself, not with its container." In short, it doesn't matter > that your column type is BLOB - the value of it will be store as is, > in your case as a unicode string. > Hence this is expected and it's how SQLite works. Please close this > bugreport or I plan to do it in some days. > > Regards, > Laszlo/GCS > [1] https://sqlite.org/forum/forummain > [2] https://www.sqlite.org/lang_corefunc.html#length > [3] https://www.sqlite.org/datatype3.html