This content has been marked as final. Show 4 replies
1. The answer is as simple as: It works because the application could save 1252 character set data to the database without any conversion.
2. Yes. But you need a trick: convert the database to use WE8MSWIN1252 but do not convert any data in it.
This can be achieved using FROMCHAR parameter of character set scanner.
So the trick is that you set FROMCHAR to 1252 even if it is not because you know that your application saved data into the database using this character set. So this way you fix your database character set.
csscan FULL=Y FROMCHAR=WE8MSWIN1252 TOCHAR=WE8MSWIN1252 LOG=csscan_from_win1252_to_win1252 CAPTURE=Y ARRAY=1000000 PROCESS=2
thanks for your reply.
Obviously, no conversion is taking place. But when we try the same with e.g. SQL Developer, which uses JDBC as well, we fail when trying to insert a € sign. It always ends up as hex BF (upside question mark). This also what we expect because jdbc is converting between 1252 and p1 and therefore fails. What is the difference between a weblogic web application that uses JDBC and SQL Developer?
As far as I know SQL Developer always using UTF8 as client character set. That's why it fails when tried to convert from utf to p1.
My assumption is that you did not setup NLS_LANG for your weblogic or could not setup the UTF8 for JDBC, so it defaults to the 7-bit ASCII character set (this default could be weblogic version dependent! but I know older versions used ASCII as default for sure - btw you did not specify weblogic version yet only JDBC). So the important part comes here: no conversion from ascii to p1 so the data goes into db in 1252. This is just an assumption. So I would try to dig in deeper in this area...
JDBC does certain optimizations for selected character sets and this optimization may depend on the particular JDBC version. It is possible that this optimized conversion passes the codes through. This also assumes that the Web side of things does a similar pass-through. Therefore, I am not surprised that you may have some 0x80 codes in the database. But in no case you should rely this. Use the method described by Zoltan (csscan FROMCHAR=WE8MSWIN1252 TOCHAR=WE8MSWIN1252) followed by ?/rdbms/admin/csalter.plb to repair the character set declaration of your database. After fixing the database character set declaration, make sure that Weblogic pages are generated as UTF-8. If they are generated as iso-8859-1, the application may stop accepting Windows-specific characters.