Bug report: CLOBs: specified encoding (UTF-8) is ignored, system enc. used

Using DbVisualizer 9.0.5, Oracle 10g DB, table with CLOB column, database default character encoding is UTF-8 (AL32UTF8). Steps to reproduce the problem: # Create a file with UTF-8 encoding and with some national characters (e.g. cyrillic chars). For example: Датские кинематографисты (I have attached the example file ru.txt) # With DbVis connect to DB, open table data, double-click the cell (CLOB type), select "Open file", specify encoding UTF-8 (attached image img1.png), browse for file ru.txt # Observe, that even in edit window the encoding is lost (file is opened as Cp1257 or ASCII, cyrillic characters not shown) # Commit the record to database. # select the data with the help of: select DBMS_LOB.substr(COLUMN_NAME, 50) from TABLE_NAME; example is shown in attached image img2.png # Observe ASCII symbols, not unicode symbols. Example of correctly working program: NetBeans v7.3, attached image img3.png shows the result of the same query (DBMS_LOB.substr) when file was uploaded with NetBeans. Core problem: CLOB open file dialog does not care about specified encoding, file is always loaded using system default encoding.

Workarround is to add the following line to file dbvis.vmoptions: -Dfile.encoding=UTF-8 this overrides default system encoding to be UTF-8.

Hi Donatas, Thanks for reporting this problem and providing a work-around. We will look into a fix for it. Best Regards, Hans

Any idea when this bug will be fixed? DbVizualizer 9.0.6 did not had the fix, release notes for 9.0.7 do not mention the fix either.

Yes, this build handles UTF-8 (and other encodings) correctly, big thanks! Donatas

Hello Roger, this still seems to be an issue in the linux version of dbvis. I use this linux version: Product: DbVisualizer Pro 9.0.7 Build: #1935 (2013/06/04 10:02) Java VM: Java HotSpot(TM) Client VM Java Version: 1.6.0_26 Java Vendor: Sun Microsystems Inc. OS Name: Linux OS Arch: i386 OS Version: 3.2.0-48-generic-pae When i paste NON-ASCII characters into a Oracle 'long raw' field via the cell editor, then the system encoding (UTF-8) is used instead of the database encoding 'ISO-8859-15'. Just like Donatas described it previously. So under linux i still have to use this workaround: dbvis.vmoptions: -Dfile.encoding=ISO-8859-15 I double checked, that this is not true in this windows version of dbvis: Product: DbVisualizer Pro 9.0.7 Build: #1935 (2013/06/04 10:02) Java VM: Java HotSpot(TM) Client VM Java Version: 1.6.0_43 Java Vendor: Sun Microsystems Inc. OS Name: Windows XP OS Arch: x86 OS Version: 5.1

Hello Roger, i'm sorry, but this issue doesn't seem to be fixed in this Version: Product: DbVisualizer Pro 9.0.8 Build: #1940 (2013/07/16 15:16) Java VM: Java HotSpot(TM) Client VM Java Version: 1.6.0_26 Java Vendor: Sun Microsystems Inc. OS Name: Linux OS Arch: i386 OS Version: 3.2.0-49-generic-pae In fact it seems to be completely unchanged. The problem is still the same. Regarding your answer, posted on 03.07.2013, please keep in mind that this bug affects the linux version only. As i already pointed out in my initial posting on 03.07.2013 there's nothing wrong with the windows version 9.0.7. So your proposal to give the fix a try by using this windows version left some doubt wether this fact is clear. Hope this can be fixed in one of the next releases, to get rid of the static workaround in the dbvis.vmoptions file.

Hello Roger, thanks for your feedback. I'll try to provide you with some info to reproduce the issue. First some specs of the software involved Workstation with DbVisualizer 9.0.8: Ubuntu 12.04.2 LTS fully patched (Kernel 3.2.0-49-generic-pae) NLS_LANG=American_GERMANY.AL32UTF8 Database Driver: Oracle Thin (Oracle Instant Client 10.2) (http://docs.oracle.com/cd/B19306_01/appdev.102/b14294/install.htm) Database Server: Oracle8i Enterprise Edition Release 8.1.7.4.0 (Debian GNU/Linux 3.1 Kernel 2.4.34.2) NLS_LANGUAGE = AMERICAN NLS_CHARACTERSET = WE8ISO8859P15 NLS_NCHAR_CHARACTERSET = WE8ISO8859P15 So here's a short step-by-step instruction on how to reproduce the issue: 1. Have a table with a column of type 'LONG RAW' in an ISO encoded database. 2. Open this table in a new tab. 3. Choose an exisiting row, or create a new one, and edit the 'LONG RAW' field by choosing 'Edit cell in Window...' in the right-click- context-menue. 4. Insert a non-ascii character like the latin small letter 'a' with diaeresis: ä 5. In cell editor, switch to the tab 'Hex viewer' (if you've created a new row previously, then you may have to close and reopen the cell editor, to get the 'Hex Viewer' tab). If the hex value is 'c3 a4' (in case you inserted the 'ä'), then you have just inserted a multibyte UTF-8 character, which might not be the thing you expected ;-) Workaround: Make sure you have the following line in your 'dbvis.vmoptions' file: -Dfile.encoding=ISO-8859-15 Do step 1 to 5 again. Now the hex value should be 'e4' (in case you inserted the 'ä'), and everything looks well. So, hope this helps reproducing the issue. best regards roland