Re: FW: Extended Characters
- From: Frank <fvanbortel@xxxxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Wed, 14 Apr 2004 21:33:55 +0200
psinger1@xxxxxxxx wrote:
> I've gone through this a couple of times, and I think I've learned
> a few things from it (not that I can't learn some more). =20
>
> The NLS_LANG parameter on the Oracle client (and exactly what is
> the client is not always easy to spot in an n-tier environment)=20
> matches the codeset actually being used by the _client_, and the
> the NLS_LANG parameter on the Oracle server matches what is being
> used by the server (an easier task to verify) then everything works.
> Most likely, your web server is not using and encoding compatible with
> its NLS_LANG parameter.
>
> Notice I did not say that the NLS_LANG setting on the client must
> match that of the Server. All of your character conversions is done
> by the client; to do this it has to know what the user is using, and it
> can't get that from the Server. I would try changing the NLS_LANG
> setting on the web server to match whatever codeset you are using.
>
>
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx on behalf of Ron Rogers
> Sent: Tue 4/13/2004 2:40 PM
> To: oracle-l@xxxxxxxxxxxxx
> Cc:=09
> Subject: Re: Extended Characters
>
> Deanna,
> the =3DBF is created by holding down the "Alt" key and hitting number =
> 168. =3D
> Perhaps there is a conversion error in the application that generates =
> =3D
> those key strokes.
> Ron
>
>
>>>>deanna.schneider@xxxxxxxxxxxx 04/13/2004 1:22:01 PM >>>
>
> Hi All,
> I'm just a lowly developer, so bear with me, please. We do a lot of
> development with web applications (using ColdFusion) that insert data =
> =3D
> using
> the jdbc drivers into Oracle (8.1.7). These are the language variables =
> in
> Oracle. Supposedly, they've been set to match in the java server, too:
> NLS_LANGUAGE - American
> NLS_TERRITORY - America
> NLS_CHARACTERSET - WE8DEC (an extended character set, Western
> European)
>
> We have a recurring problem with the Microsoft Extended Characters =
> turning
> into upside down question marks on insert. The DBA and Coldfusion admins
> say, "there's nothing that can be done."
>
> The recommended hack is to change all extended characters to their html
> entities before insert - which works fine if you're using the data only =
> on
> webpages. Not such a good approach if you want it for other stuff - like
> downloadable spreadsheets and such.
>
> Can you think of anything that could be done?
>
> --=3D20
> Deanna Schneider
> UWEX-Cooperative Extension
> Interactive Media Developer
>
---------------------------
All true, but please bear in mind, that
Microsoft uses non ISO character mappings
(the Euro-sign is a prime example; however,
it's the European Union to blame, if I'm
informed correctly).
I would go for WE8MSWIN1252 as character set
for the client - anything 8 bits on the
server would be OK
Check your data with dump(column_name) to see
what characters were mapped to what code -
hopefully you'll find the culprit somewhere.
BTW - downloadable spreadsheets would be binary,
so stored in BLOBS - these aren't touched.
--
Regards,
Frank van Bortel
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts: