this question might be one for the DBI:Oracle gurus amongst you:
I'd like to retrieve UTF-8 encoded data from an Oracle 10g database (Enterprise Edition Release 10.2.0.3.0 - 64bit Production, with parameters NLS_LANGUAGE=AMERICAN, NLS_TERRITORY=AMERICA, NLS_CHARACTERSET=UTF8) running in a Solaris 10 environment. Since my locale's default character set is ISO 8859-1 aka latin1 I have to prevent Oracle from re-coding output accordingly. A colleague told me that setting the environment variable NLS_LANG from inside my Perl script by
should do the trick - and it does under Perl v5.6.1 with DBI v1.40.$ENV{'NLS_LANG'} = 'AMERICAN_AMERICA.UTF8';
However, under Perl v5.8.6 with DBI v1.601 this assignment seems to have almost no effect at all: Instead of the UTF-8 byte combo \xC3\x84 (representing U+00C4 aka LATIN CAPITAL LETTER A WITH DIAERESIS), for example, I get only the single byte \xC4 (latin1 code for U+00C4!) or - if I omit the line in question - the single byte \x41 (latin1 code for a simple A).
This experience made me suspect that modifying $ENV{'NLS_LANG'} was deprecated at some point in Perl/DBI history. Is that true?
If yes, can you please point me to some document describing the currently recommended way to make the Oracle server believe that no character re-coding is necessary?
Humble greetings
Locutus
In reply to Is setting $ENV{'NLS_LANG'} deprecated? by Locutus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |