| Author |
Windows vs. Linux behavior on ResultSet getString, top bit
|
Clayton Cramer
Ranch Hand
Joined: Aug 26, 2010
Posts: 40
|
|
|
I am running into an annoying problem. I have an application that under Windows retrieves strings from a database and the strings are what I would expect: 7-bit ASCII. Under Linux, the same application, talking to the same database, sometimes returns 8-bit ASCII. The particular symptom is that spaces, instead of being x'20', are x'a0' instead under Linux. My guess is that there is some method or setting for ResultSet or CallableStatement that says, "force all 8-bit character values to 7-bits" but I can't find it.
|
 |
Martin Vajsar
Bartender
Joined: Aug 22, 2010
Posts: 2319
|
|
Are you sure the database field is declared as a character (that is, not binary) type?
Java uses Unicode internally, so it's the JDBC driver's responsibility to handle character set conversions to match the database's character set. I'm not aware of any method that would allow you messing with that.
A quick search brought up some results that mentioned character set conversion bugs in JDBC drivers.
|
 |
Clayton Cramer
Ranch Hand
Joined: Aug 26, 2010
Posts: 40
|
|
Martin Vajsar wrote:Are you sure the database field is declared as a character (that is, not binary) type?
Java uses Unicode internally, so it's the JDBC driver's responsibility to handle character set conversions to match the database's character set. I'm not aware of any method that would allow you messing with that.
A quick search brought up some results that mentioned character set conversion bugs in JDBC drivers.
Yes, it is declared as CHAR(30). It looks like DB_LOCALE and CLIENT_LOCALE are properties associated with the database connection, and this is likely the problem: under Windows, this is CP1252; under Linux, it defaults to UTF-8 or the ISO equivalent. I probably need to force the connection to CP1252, but I have not figured out how to do that yet.
|
 |
Martin Vajsar
Bartender
Joined: Aug 22, 2010
Posts: 2319
|
|
Do you use a thin driver? In that case, I'd suggest to check whether you're using the latest version (see our Oracle FAQ for links).
If you're using an OCI driver, perhaps the encoding might be changed using environment variables (LANG, I believe). I'm not sure whether it does affect the OCI driver when used via JDBC. I've only used this variable to change the locale for EXP and IMP in the past.
|
 |
 |
I agree. Here's the link: jrebel
|
|
subject: Windows vs. Linux behavior on ResultSet getString, top bit
|
|
|