Günther Schmidt wrote:
Hi John,
I'm afraid so.
If it came back as an SqlString "G\252nni" then it propably wouldn't be a problem.
Can you boil this down to a few-line self-contained test program so I can try it myself? I do have test cases for Unicode stuff and they are all passing here. I would like to be able to eliminate your environment as a culprit. Incidentally, could you run make test in the HDBC-sqlite3 source directory?
Am 04.05.2009 um 20:47 schrieb John Goerzen:
Günther Schmidt wrote:
Hi John,
what I just noticed is that *all* strings come back as SqlByteStrings. That's normal, and pretty much irrelevant, since fromSql takes care of it.
It's documented, even: the SqlByteString is assumed to be in UTF-8, and is decoded when converted to a String.
It is not correct to have \252 in the SqlByteString. The proper sequence there is \xc3\xbc. When converted to String, *then* it should be \252.
Are you positive you're seeing \252 in the SqlByteString? That doesn't make any sense to me. It's not a valid UTF-8 encoding.
How have Umlauts been behaving on your end? Were they as mean to you as they were to me?
ie. I get my "Günni", (G\252nni), back as an SqlByteString "G\252nni" instead of an SqlString "G\252nni".
So when I cast, ie. fromSql x :: String, I get an "G\65533nni", which is where the garbling occurs.
BTW this is the 3rd time now that I'm writing the same bloody email, my email client "clipped" the previous 2.
Günther