Hi Elke,

Eventually downloaded the source, but can't find any tables in vsp81.c!

Do they need to be created?  If so, could you send me a copy of the built
version?

Many thanks,

David




"Zabach, Elke" <[EMAIL PROTECTED]> on 17/11/2003 10:10:11 AM

To:    "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject:    RE: UPPER with DBCS


Hi,

please see file
http://www.unicode.org/Public/UNIDATA/UnicodeData.txt

and the description for this
http://www.unicode.org/Public/3.2-Update/UnicodeData-3.2.0.html

for those character mapped to uppercase
resp vsp81.c in our source.

For korean / chinese there are only few entries, for greek, latin 1
you will find several mapped to upper

Elke
SAP Labs Berlin


> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Donnerstag, 13. November 2003 00:11
> To: Zabach, Elke
> Subject: RE: UPPER with DBCS
>
>
>
> Hi Elke,
>
> still trying to get my head around what is and is not
> supported at this
> time.
>
> can you give me some examples of "single ucs2 characters which have a
> well-defined Single UCS2 uppercase counterpart"?  Do you know
> if this would
> cover simplified chinese or korean for example?
>
> Also, is all this the same when it comes to sorting with DBCS?
>
> Many thanks,
>
> David
>
>
>
>
> "Zabach, Elke" <[EMAIL PROTECTED]> on 08/10/2003 02:36:00 AM
>
> To:    "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> cc:
> Subject:    RE: UPPER with DBCS
>
>
> [EMAIL PROTECTED] wrote:
> >
> > Hi,
> >
> > How does SAP handle the UPPER function with DBCS?  Isn't
> > uppercase pretty
> > language-specific in double-byte character sets?
> >
> You are right, it is language-specific. It is handled as J�rg
> wrote last
> year:
> lower/uppercase mapping for unicode is implemented using
> tables extracted
> from unicode.org ftp side. (see vsp81.c created by
> genUCS2CaseMaps.pl).
> There is a compromise however, between a database and a text
> editor for
> some characters (like German-Sharp-S, ligatures, some precomposed
> characters and all letters with 'iota-subscript' or
> 'iota-adjust'. In short
> words: all convertions, that would modifiy the length of the
> string are not
> handled correctly and could not, since the internal interface does not
> support different input and output length before and after conversion.
>
> Only those SINGLE UCS2 characters which have a well-defined
> SINGLE UCS2
> uppercase counterpart are therefore handled as expected.
>
> Elke
>  SAP Labs Berlin
>
>
>
>
 >






--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to