From: Addison Phillips (addison@yahoo-inc.com)
Date: Wed May 30 2007 - 00:31:28 CDT
You don't say what you see for the characters after making the changes,
so it is difficult to diagnose.
Please note that you may already have lost the characters in the
database. Once they are stored as question marks or other replacement
characters, that's what they are forever. Did you try (with one or
another of these configurations) inserting known-good characters and
retrieving them? Or are you just trying to view existing data (how do
you know it is good??) Can you see/type the characters into the shell
where you are planning on viewing them? It is important to check each
stage of your configuration to see that it works appropriately.
Note that your database encoding is the windows code page 1252 encoding.
In this encoding, the "oe" ligature character's byte values are 0x8C
(capital) and 0x9C (lowercase), which are in the C1 control range for
ISO 8859-15. A conversion must take place between the database and the
shell in this case. If your connection isn't set correctly, you may not
have correctly encoded data to view. (Of course, it could also be a font
issue or some other problem.)
Addison
Ankit Jain wrote:
> Hi
> please find my settings and then guide me where i am wrong
> SQL> select * from V$NLS_PARAMETERS
> PARAMETER
> VALUE
> ---------------------------------------------------------------- ----------------------------------------------------------------
>
> NLS_LANGUAGE
> AMERICAN
> NLS_TERRITORY
> AMERICA
> NLS_CURRENCY
> $
> NLS_ISO_CURRENCY
> AMERICA
> NLS_NUMERIC_CHARACTERS .,
> NLS_CALENDAR
> GREGORIAN
> NLS_DATE_FORMAT
> DD-MON-RR
> NLS_DATE_LANGUAGE
> AMERICAN
> NLS_CHARACTERSET
> WE8MSWIN1252
> NLS_SORT
> BINARY
> NLS_TIME_FORMAT
> HH.MI.SSXFF
> AM
> NLS_TIMESTAMP_FORMAT
> DD-MON-RR HH.MI.SSXFF
> AM
> NLS_TIME_TZ_FORMAT
> HH.MI.SSXFF AM
> TZR
> NLS_TIMESTAMP_TZ_FORMAT
> DD-MON-RR HH.MI.SSXFF AM
> TZR
> NLS_DUAL_CURRENCY
> $
> NLS_NCHAR_CHARACTERSET
> AL16UTF16
> NLS_COMP
> BINARY
> NLS_LENGTH_SEMANTICS
> BYTE
> NLS_NCHAR_CONV_EXCP
> FALSE
>
>
> 19 rows selected.
>
>
> NLS_LANG is not set on AIX machine (client machine-Oracle 9.2.0.1
> <http://9.2.0.1/>)
> LANG parameter earlier was en_US for all
>
> i tried setting NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P15 on both oracle
> user and myapp user
> now i set (for oracle user , myapp user) it to en_US.8859-15
>
> Even then no success. what else configuration could be revised?
>
> Regards, Ankit
>
> On 5/10/07, *Addison Phillips* <addison@yahoo-inc.com
> <mailto:addison@yahoo-inc.com>> wrote:
>
> One of the locales Ankit lists is:
>
> en_US.8859-15
>
> Any of the 8859-15 locales should be able to display the character, but
> that is only part of the problem.
>
> It is important to ensure that the character in question can survive the
> whole round trip to and from the database. The terminal display locale
> is only a small part of this.
>
> First, check the encoding used by the Oracle database:
>
> SELECT * FROM V$NLS_PARAMETERS;
>
> Look for NLS_CHARACTERSET in the results. And then look at the
> connection character encoding used by the client (usually part of the
> NLS_LANG environment variable, such as
> "AMERICAN_AMERICA.WE8ISO8859P15").
>
> These all need to be compatible. For example, if your database uses the
> encoding AL32UTF8 (that is, UTF-8), then the database can store the
> characters you want---encoded as UTF-8. If your connection encoding is
> WE8ISO8859P15 (that is, ISO 8859-15), then you will get bytes consistent
> with that encoding in your queries---the database converts them to/from
> UTF-8 for storage using the specified encoding. It is very likely that
> your connection encoding is set to ISO 8859-1, though, and this is
> possible source of your woes (otherwise, instead of inverted question
> mark, you'd see random garbage bytes until you set your locale to use
> 8859-15).
>
> Oracle does conversions to match the client character set. If you choose
> "WE8ISO8859P1" as the encoding, the oe liguature character will be
> converted to the substitution character, regardless of the locale you
> set. So be sure you set all of your settings (locale, NLS_LANG, database
> encoding) to match or at least support the characters you need.
>
> Note that there is no requirement to use a French or France-specific
> locale to do this. Those locales are necessary only if you want French
> behavior such as date formats, number formats, sorting, and so forth.
> For character display all you need is the correct character encoding.
>
> Best Regards,
>
> Addison
>
> ====
>
> For further reading, check out the Oracle Globalization Guide,
> especially Chapter 3:
>
> http://tinyurl.com/kwyql
>
> You might also find this configuration guide to be of some small use:
>
> http://www.inter-locale.com/whitepaper/learn/learn_to_type.html
>
> --
> Addison Phillips
> Globalization Architect -- Yahoo! Inc.
>
> Internationalization is an architecture.
> It is not a feature.
>
> Philippe Verdy wrote:
> > I see that you are trying to store exactly the list of non ASCII
> letters
> > needed for writing French, but your system does not list support
> for any
> > French locale, only English US and default POSIX…
> >
> > Second: œ and Œ are not in any of the encodings supported in the
> lists
> > of locales.
> >
> > Yes they are not in ISO 8859-1 (only in ISO 8859-15 which made a
> > fewchanges for the Euro, and for French) but in Windows-1252 (the
> > Windows "ANSI" codepage for Western European Latin).
> >
> > May be this will work if you install the locales for French…
> >
> >
> >
> >
> ------------------------------------------------------------------------
> >
> > *De :* unicode-bounce@unicode.org
> <mailto:unicode-bounce@unicode.org>
> [mailto:unicode-bounce@unicode.org <mailto:unicode-bounce@unicode.org>]
> > *De la part de* Ankit Jain
> > *Envoyé :* mercredi 9 mai 2007 15:06
> > *À :* unicode@unicode.org <mailto:unicode@unicode.org>
> > *Objet :* Œœ on IBM AIX
> >
> >
> >
> > Hi All
> >
> >
> >
> > I am using IBM AIX version 5.1, oracle 9.2 client and Oracle 10g
> server.
> >
> >
> >
> > I am passing the following characters: Àà Ââ Ææ Çç Éé Èè Êê Ëë Îî
> Ïï Œœ
> > Ôô Ùù Ûû Üü Ÿ ÿ. these characters get stored in the database, but
> when i
> > retrieve them, "Œœ " becomes inverted question mark...
> >
> >
> >
> > I checked the locales of the IBM AIX and found the following:
> >
> >
> >
> > C
> > POSIX
> > (..)
> >
> > en_US
> > (….)
> >
> > en_US@alt.lftkeymap <mailto:en_US@alt.lftkeymap>
> <mailto:en_US@alt.lftkeymap <mailto:en_US@alt.lftkeymap>>
> >
> >
> > One can see that there is not UTF-8 locale here.
> >
> >
> >
> > I suppose that "Œœ" character can be viewed using UTF-8 encoding.
> >
> > if that supposition is right, then how to install UTF-8 locale
> here or
> > if i am wrong, how to retrieve them
> >
>
>
>
>
> --
> Regards/ Ankit
-- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature.
This archive was generated by hypermail 2.1.5 : Wed May 30 2007 - 00:33:38 CDT