Re: Oracle characterset confusion when storing encoded passwords

On Feb 4, 10:44 am, 151 <ga..._at_my-deja.com> wrote:
> Hello there, I hope someone can help me with a problem that I believe
> relates to character encoding in oracle....
>
> I have a simple Java password encoding routing that XORs a password
> then sends it off the be stored in a VARCHAR2 field.  The Java class
> is running inside Tomcat which is configured to UTF-8.  So far..so
> good.
>
> To check the password when a user logs in (via a JSP) I fetch the
> encoded version from the Oracle DB and then re-run the encode method
> agains the users input - if the result matches - login is fine.
>
> This all works fine for anything in the single byte encoding range.
> However, if I try the same thing with characters used by other
> languages (often referred to as the extended ascii set though I
> understand this to be mis-named) it fails...
>
> So somewhere along the way what I send to the DB (at user registration
> time) to store in the VARCHAR2 as the encoded password is being
> changed slightly.
>
> The Oracle DB seems to be set to the WE8ISO8859P15 characterset and I
> am sure this is where the problem lies.
>
> my question then is: if I insert data into a VARCHAR2 field into the
> DB that was encoded as UTF8 originally - if the database is using
> WE8ISO8859P15 - would this result in the data being "altered"?
>
> Thanks for reading if you got this far!

It would result in converting a multi-byte character in a single-byt character, with Oracle potentially 'falling back' on a different character or a question mark.
A workaround is to store the data in a NVARCHAR2 column, and set the National characterset of the database to something UTF8 compatible.

--
Sybrand Bakker
Senior Oracle DBA