Re: Displaying 'umlaut' character
From: Frank van Bortel <fbortel_at_home.nl>
Date: Sun, 26 Sep 2010 17:26:11 +0200
Message-ID: <dae33$4c9f6614$524ba3af$22333_at_cache3.tilbu1.nb.home.nl>
On 09/22/2010 06:35 PM, joel garry wrote:
> On Sep 22, 12:20 am, Frank van Bortel<fbor..._at_home.nl> wrote:
>> On 09/22/2010 06:50 AM, dn.p..._at_gmail.com wrote:
>>
>>
>>
>>> My aim is to display the ‘special’ (NON-Ascii) German character/
>>> diacritic umlaut or diaresis correctly on a browser. The browser calls
>>> a cgi perl-script which resides on a linux server. The browser which
>>> calls the perl-script displays Vietnamese characters correctly (but
>>> not the umlaut) without any special setting. The script sets NLS_LANG
>>> variable to AMERICAN_AMERICA.UTF8 and uses utf8 module, but that’s
>>> about it.
>>
>>> $ENV{'NLS_LANG'}='AMERICAN_AMERICA.UTF8';
>>> Works for Vietnamese characters, but not with umlaut (ö).
>>
>>> But even before we get to a perl-script, perhaps the LC_CTYPE env
>>> variable needs to be set correctly. From my windows laptop, if I
>>> access Oracle through Oracle Query Server, I can see the umlaut. But
>>> if I open a linux-window, initiate an sqlplus session, and run the
>>> same SQL, I do not see the umlaut correctly. I have tried a few values
>>> for the env variable LC_CTYPE (like iso_8859_1, en_US,
>>> en_US.iso88591), but with no luck. The surprising thing is that
>>> ‘umalut’ is a muck-known alphabet, Vietnamese alphabets are less-
>>> known. Yet the Vietnamese characters are being displayed correctly.
>>
>>> What settings should I use in a perl-script or for a linux-window to
>>> see the umlaut correctly? Please advise.
>>
>> Maybe this helps: (shameless self promotion)http://vanbortel.blogspot.com/2009/04/special-characters-part-i.html
>> Last part is here:http://vanbortel.blogspot.com/2010/01/special-characters-part-iv.html
>
> Thanks for that Frank, I'm always forgetting where I've seen the
> excellent write-up.
>
> It always need to be emphasized that using the wrong database
> character set creates a ticking time bomb, as Oracle is so
> sophisticated about automatic conversions in various circumstances.
>
> jg
> --
> _at_home.com is bogus.
> http://www.fastcompany.com/1690122/bmw-touts-integration-with-ipads-blackberry-google
Date: Sun, 26 Sep 2010 17:26:11 +0200
Message-ID: <dae33$4c9f6614$524ba3af$22333_at_cache3.tilbu1.nb.home.nl>
On 09/22/2010 06:35 PM, joel garry wrote:
> On Sep 22, 12:20 am, Frank van Bortel<fbor..._at_home.nl> wrote:
>> On 09/22/2010 06:50 AM, dn.p..._at_gmail.com wrote:
>>
>>
>>
>>> My aim is to display the ‘special’ (NON-Ascii) German character/
>>> diacritic umlaut or diaresis correctly on a browser. The browser calls
>>> a cgi perl-script which resides on a linux server. The browser which
>>> calls the perl-script displays Vietnamese characters correctly (but
>>> not the umlaut) without any special setting. The script sets NLS_LANG
>>> variable to AMERICAN_AMERICA.UTF8 and uses utf8 module, but that’s
>>> about it.
>>
>>> $ENV{'NLS_LANG'}='AMERICAN_AMERICA.UTF8';
>>> Works for Vietnamese characters, but not with umlaut (ö).
>>
>>> But even before we get to a perl-script, perhaps the LC_CTYPE env
>>> variable needs to be set correctly. From my windows laptop, if I
>>> access Oracle through Oracle Query Server, I can see the umlaut. But
>>> if I open a linux-window, initiate an sqlplus session, and run the
>>> same SQL, I do not see the umlaut correctly. I have tried a few values
>>> for the env variable LC_CTYPE (like iso_8859_1, en_US,
>>> en_US.iso88591), but with no luck. The surprising thing is that
>>> ‘umalut’ is a muck-known alphabet, Vietnamese alphabets are less-
>>> known. Yet the Vietnamese characters are being displayed correctly.
>>
>>> What settings should I use in a perl-script or for a linux-window to
>>> see the umlaut correctly? Please advise.
>>
>> Maybe this helps: (shameless self promotion)http://vanbortel.blogspot.com/2009/04/special-characters-part-i.html
>> Last part is here:http://vanbortel.blogspot.com/2010/01/special-characters-part-iv.html
>
> Thanks for that Frank, I'm always forgetting where I've seen the
> excellent write-up.
>
> It always need to be emphasized that using the wrong database
> character set creates a ticking time bomb, as Oracle is so
> sophisticated about automatic conversions in various circumstances.
>
> jg
> --
> _at_home.com is bogus.
> http://www.fastcompany.com/1690122/bmw-touts-integration-with-ipads-blackberry-google
Thanks for the thumbs up.
However - one thing I was trying to clarify,
is the fact that
* you do not store characters; you store code points
* there's no such thing as a wrong database character set
(a.k.a. there's always one way to screw up, at least!)
-- Regards, Frank van BortelReceived on Sun Sep 26 2010 - 10:26:11 CDT