Re: extended ASCII seems not to exist for some clients

Thank you all for the information you gave me ! I learned a lot about charactersets and manage now to explain what happened. G8 !

Regards.

Christian.

"Frank" <fbortel_at_home.nl> wrote in message news:3E018C19.4080703_at_home.nl...
> Christian BIERO wrote:
> > Hello,
> >
> > I've got the following problem.
> > I've got a script to insert data into some table. This script contains
some
> > accents.
> > The target database has the following DATABASE params (cf select below)
> > According to the charset : WE8ISO8859P15, the DB supports accents like
'é'
> > or 'à'.
> >
> <snip!>
>
> This has little to do with the database, but with the charactersets
> defined on server and client side. Actually, the network layer is
> responsable for the "translation" between different charactersets.
> If your client is US7ASCII (which used to be the default Oracle
> characterset for far too long!), no extended characters whatsoever!
> Could it be that:
> - you server/telnet session does not have a characterset set at all?
> (check your environment)
> - you DOS session uses codepage 850 (as said before).
>
> Your é has code 0xE9; that is é translated to 0xE9 in cp 8859P15
> (Iso Latin 1 plus Euro). In cp850 (DOS), 0xE9 is Ú.
> Defined nothing, the client would probably use US7ASCII. As 0xE9 is
> not supported (it's 8 bits), the msb falls off, resulting 0xE9 to
> become 0x69. This is the letter i.
>
> Works for me...
>
> BTW, 8859P15 will not process the euro sign correctly in Windoze
> environments, M$ has chosen, in all it's wisdom, to map the Euro
> to an entirely different character than the ISO - use MSWIN1252 instead.
>
> Grtz, Frank
>
Received on Fri Dec 20 2002 - 09:03:10 CST