> it looks for the BOM and treats strings as LE or BE dynamically That is the whole purpose of a BOM, isn't it? Are you saying that SQLite (or any other system for that matter) should take a string that self-identifies as UTF16BE but go ahead and treat it as if it where in native byte order (UTF16LE)? In other words, pretend the BOM doesn't exist, or that it is just another unicode character? It don't think it is advisable to change SQLite to work that way. Even apart from the backwards-compatibility issues that such a change would provoke, it seems like the wrong behavior. If you goal is to store something that you never want SQLite to reformat, then store that something as a BLOB, not as TEXT. I will take the action to update the documentation to try to make these points clearer.