The converter doesn't seem to remove the second byte which is zero. ( 66 00 6F 00 6F 00 equals "foo" ) As far as I know UTF-8 uses only one byte per ascii character. How do I get this thing to remove the zero byte?
12:20 0 RDBMS DRIBBLE Convert from 5, size is 90, content: 66 00 6F 00 6F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
this data is utf-16, babel can deal with that, too.
i'm looking into installing oracle now, so that i can test it myself...
Hm, the connection encoding is UTF-16. SBCL doesn't support UTF-16. Therefore I have to convert the UTF-16 string with babel to UTF-8 if babel does such a thing. Sounds promising. But, if that is right, why isn't this done by default. Is there a lisp that uses UTF-16? I will try this later, have to eat and thank you.
-- attila
chris
!DSPAM:4cd166f348585239786034!
12:20 0 RDBMS DRIBBLE Convert from 5, size is 90, content: 66 00 6F 00 6F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
this data is utf-16, babel can deal with that, too.
i'm looking into installing oracle now, so that i can test it myself...
Hm, the connection encoding is UTF-16. SBCL doesn't support UTF-16. Therefore I have to convert the UTF-16 string with babel to UTF-8 if babel does such a thing.
reading this makes me think that you don't have a clear model of lisp strings/unicode/encodings.
i don't remember reading this article, but a quick glance looks promising: http://www.joelonsoftware.com/articles/Unicode.html
in short: you need to convert between lisp strings and byte arrays, sending/receiving byte arrays to/from the database. the encoding needed for OCI, oracle's C interface, is utf-16.
utf-8 is nowhere in the picture (if not the encoding emacs/slime uses to communicate with the cl process).
cl-rdbms-devel@common-lisp.net