Re: Character set blues...

From: Frank van Bortel <fvanbortel_at_netscape.net>
Date: Sat, 26 Mar 2005 18:07:24 +0100
Message-ID: <d244mm$bl$1@news6.zwoll1.ov.home.nl>

Jeremy wrote:
> In article <d21fke$oh1$1_at_news1.zwoll1.ov.home.nl>, Frank van Bortel
> says...
>

>>- your HTTP Post, stored in a CLOB is correct when posted through
>>   the ISO8859P1 DAD.
>>
>>- your HTTP Post, stored in a CLOB *seems* incorrect when posted
>>   through the UTF DAD.
>>
>>Do you have any clue as to what actually is stored, when you use
>>the UTF DAD? Try to find out, e.g. by using the dump function.
>>My guess is, you will find just 1 byte of the two actually used.
>>
>>

>
>
> ===
> Through ISO8859P1 DAD:
>
> â ä à å ç ê ë
>
> Typ=1 Len=14: 226,32,228,32,224,32,229,32,231,32,234,32,235,32
>
> ===
>
> Then the same character string through the UTF8 DAD:
>
> ¿ ¿ ¿
>
> Typ=1 Len=6: 191,32,191,32,191,32
>

[snip]

Just what I expected: you miss the first byte (all 0, but nevertheless)!
You can test for yourself, using an NCHAR column (provided the db was created, using a UTF character set for NCHARs).

Your problem is simple (basically): you only have room for 1 byte, where you offer two, or more.
Like storing accented characters in an US7ASCII database.

If you really want it to be UTF, you can either introduce NCHAR columns (like I did in the example), or migrate to UTF being the standard character set. The AL16UTF16 seems to be closest to MS Windows, so if your clients use MS Win for browser, or platform, that would be a good choice (less character conversions).

I fail to see the use, though, as WE8ISO8859P1 (or WE8MSWIN1252) perfectly show and process your special characters. Just my 2.5 c (¤)

-- 
Regards,
Frank van Bortel

Received on Sat Mar 26 2005 - 11:07:24 CST