oracle replaces ISO-8859-1 characters with question marks

[Noah]

The problem I'm having is that whenever a user enters
accented characters character into a form field the characters
are getting stored as question marks in the database.
For example, "façade" (c with cedilla) is stored as "fa?ade"
Does anyone have any idea how to fix this problem?

My page has a meta header to set Content-Type:
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
I traced the input to the PHP form submission page.
I printed the posted form fields and the characters
come through as expected, so I'm pretty sure that this
is a problem with the database side.
I'm using Oracle 10g running on Linux. I'm using PEAR db.
My update query is simple and straightforward:
UPDATE release SET message='façade' WHERE release_id=5831;
I have included my Oracle NLS database parameters.

Yours,
Noah

SQL> select * from NLS_DATABASE_PARAMETERS;

PARAMETER VALUE
------------------------------ ----------------------------------------
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET WE8ISO8859P1
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
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_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_RDBMS_VERSION 10.1.0.2.0

[Andy Hassall]

On 22 Feb 2005 15:25:15 -0800, "Noah" <no**********@gmail.com> wrote:

The problem I'm having is that whenever a user enters
accented characters character into a form field the characters
are getting stored as question marks in the database.
For example, "façade" (c with cedilla) is stored as "fa?ade"
Does anyone have any idea how to fix this problem?

My page has a meta header to set Content-Type:
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
You'd be better off with a proper HTTP header, but anyway...
I traced the input to the PHP form submission page.
I printed the posted form fields and the characters
come through as expected, so I'm pretty sure that this
is a problem with the database side.
I'm using Oracle 10g running on Linux. I'm using PEAR db.
My update query is simple and straightforward:
UPDATE release SET message='façade' WHERE release_id=5831;
Hopefully you're not actually running that - you're using bind variables in
the real thing, right?
I have included my Oracle NLS database parameters.

SQL> select * from NLS_DATABASE_PARAMETERS;

PARAMETER VALUE
------------------------------ ----------------------------------------
NLS_CHARACTERSET WE8ISO8859P1

OK, so you can definitely store the things, so it's a client issue.

What's the NLS_LANG environment variable set to? This the most likely suspect
- if set wrongly it can easily give the problems described.

What's the definition of the table - message is just a VARCHAR2, right?

--
Andy Hassall / <an**@andyh.co.uk> / <http://www.andyh.co.uk>
<http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool

[Noah]

Great! Everything worked from the command-line sqlplus
when I set the environment variable:
export NLS_LANG=american_america.WE8ISO8859P1
So it was a client issue. But when I tried to set the same
environment variable from PHP using:
putenv("NLS_LANG=american_america.WE8ISO8859P1"));
the accented chars still get replaced, but now they are replaced with
upside-down Spanish question marks. Weird.

It works fine if I set the environment variable before I start Apache.
I wish it would work from the code side, but at least it works.

Yours,
Noah