[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] Bug in UTF8-Validation Code?
From:       "Zeugswetter Andreas ADI SD" <ZeugswetterA () spardat ! at>
Date:       2007-04-04 10:02:07
Message-ID: E1539E0ED7043848906A8FF995BDA57901E7B6D4 () m0143 ! s-mxs ! net
[Download RAW message or body]


> > When the database uses a single byte encoding, the chr function
takes 
> > the binary byte representation as an integer number between 0 and
255 
> > (e.g. ascii code).
> > When the database encoding is one of the unicode encodings it takes
a 
> > unicode code point.
> > This is also what Oracle does.
> 
> Sorry, but this is *NOT* what Oracle does.
> At least if we can agree that the code point for the Euro 
> sign is 0x20AC.

yes

> 
> SQL> SELECT ASCII('EUR') AS DEC,
>   2         TO_CHAR(ASCII('EUR'), 'XXXXXX') AS HEX
>   3  FROM DUAL;
> 
>        DEC HEX
> ---------- ----------------------------
>   14844588  E282AC
> 
> The encoding in this example is AL32UTF8, which corresponds 
> to our UTF8.

You are right, I am sorry. My test was broken.

To get the euro symbol in Oracle with a AL32UTF8 encoding you use
chr(14844588)

Andreas

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

[prev in list] [next in list] [prev in thread] [next in thread]