Support non-ASCII characters in SQLiteConnection.prepare
Originally reported on Google Code with ID 17
If the SQL query includes some non-ascii characters, the prepare method fails to translate
them to the correct charset for sqlite.
The following test fails:
SQLiteStatement st = cnx.prepare("select '\uD840\uDC40';");
st.step();
Assert.assertEquals("\uD840\uDC40", st.columnString(0));
There is no problem with SQLiteStatement.bind(int, String). The problem seems to come
from the JNI code (_SQLiteManualJNI.sqlite3_prepare_v2).
I attached an unit test.
Reported by olivier.monaco@free.fr
on 2010-08-20 13:36:58
<hr> * Attachment: CharsetBugTest.java
Comments (5)
-
-
Account Deleted ``` In fact, I'm working on a JDBC layer on-top sqlite4java. This issue breaks a unit test. I don't really need this issue to be fixed. I'll check the charset in my JDBC layer.
Thanks. ```
Reported by `olivier.monaco@free.fr` on 2010-08-23 12:29:21
-
``` I've accepted this issue, but it's low priority for now.
(A JDBC layer? Nice to hear you're using sqlite4java, but you know Xerial SQLite JDBC driver, don't you? [http://www.xerial.org/trac/Xerial/wiki/SQLiteJDBC]) ```
Reported by `sereda` on 2010-08-23 22:19:47 - Status changed: `Accepted` - Labels added: Type-Enhancement, Priority-Low - Labels removed: Type-Defect, Priority-Medium
-
Account Deleted ``` This is for my work. We already use the Xerial driver but with issues (major is no concurrency). So I rewrite one.
As a personal project I also create some kind of persistence layer onto of sqlite4java (http://code.google.com/p/tyco/source/list?repo=s4j-persister but at a very early stage). So, you're project is useful for me ;). ```
Reported by `olivier.monaco@free.fr` on 2010-08-23 22:26:38
-
Account Deleted Reported by
evjava@almworks.com
on 2014-07-12 14:20:32 - Status changed:Fixed
- Log in to comment
``` Thanks for reporting the issue. The prepare() and exec() calls do assume that SQL passed is in ASCII characters. This should have been documented better (and, arguably, the SQL should have been verified for charset) - right now there's a note for the com.almworks.sqlite4java package about this and in exec() javadoc.
While I'll think about implications of lifting that restriction, is there any real-life requirement for that? Do you really need to pass string literals that otherwise would be passed through bind() method? Note that such statements are not likely to be effectively cached.
Igor ```
Reported by `sereda` on 2010-08-20 14:20:19