Quote:> I have changed the NLS_CHARACTERSET parameter of our database
> to the UTF2 character set - AL24UTFFSS and set the NLS_LANG
> parameter of our OAS web server (DAD section) to
> JAPANESE_JAPAN.JA16SJIS and we are still unable to display
> unicode kanji.
I'm guessing that the character set of your database is not
unicode. The NLS_ variables are environmental stuff so that an
application knows in what language the characters that are
retrieved from the database are supposed to be displayed when
retrieved. BUT, the character set that you asked to be retrieved
must be at least a subset/supported by the character set of the
database. So, if your database is in US7ASCII, then the Japanese
character sets will never be able to be stored in the database.
I'm guessing the character set of your database is US7ASCII?
You must create the database using the "character set =
'AL24UTFFSS'" clause. I know, ouch, but I'm guessing the
character set of your database is US7ASCII. You can't support
Kanji in a database created with that character set. You must
recreate the database to support multibyte character sets.
Does this make sense?
Quote:> The unicode is not being retrieved from the table, just
> displayed in an html link.
I'm guessing that you are seeing the &#xxxx; phenomenom which
confused us early on in solving this issue.
If one enters kanji characters in a browser and the browser isn't
set to accept kanji, the browser will convert the kanji to an
ascii representation for display purposes only. These characters
are of the form, &#xxxx; and if you look at it, that's any where
from 6 characters on up for each Kanji character.
Did this help?
I don't want to be the rock. Yeah, okay, what do you want to be?
I want to be the piece of glass.