[Haskell-cafe] HDBC 2.1, UTF8 and Umlauts

[John Goerzen]

Günther Schmidt wrote:
> Am 04.05.2009 um 21:07 schrieb John Goerzen:
> 
>> 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.
>>
> I'll try, it will take me some time since I've never written a test in  
> haskell.

You don't really have to make a special unit test.  Just a simple client
program that creates a table, inserts some data, reads it back, and
demonstrates the corruption.

> That'll be harder to do since I'm on XP here, but I'll try that too,

No problem.  It's just

runghc setup configure -f buildtests
runghc setup build

and just run runtests



>>>
>>>
>>>
>>> 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
>>>>>
>>>>>
>>>
> 
>