Featured White Papers

• What Developers Want: The End of Application Redeploys

Sponsored Links

• Career opportunities at Harman- Careers That’ll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Unicode development with DbForms, MySQL 4.1, and friends

Developing a Unicode-enabled application with DbForms and MySQL 4.1

By Neal Katz, JavaWorld.com, 09/06/04

Page 2 of 4

Now that we have covered the big picture, let's start looking at the individual steps required to get things working.

Getting Unicode to work

The first thing we did was write a standalone Java program that would read in Thai characters from a MySQL database and write them out to a file. The test database was populated by hand. The program's key part is the section that opens the connection:

DriverManager.setLogWriter(new PrintWriter(System.out));
Class.forName("com.mysql.jdbc.Driver");
Connection db =
DriverManager.getConnection(
"jdbc:mysql:///" + dbname +
"?requireSSL=false&useUnicode=true&characterEncoding=UTF-8",
   "root", "");

The setLogWriter() function is used for diagnostics and isn't needed in production, but is helpful for tracking down problems.

The JDBC (Java Database Connectivity) connect string has three parameters. Their meaning should be obvious. We used requireSSL=false since we had problems building MySQL 4.1.x from scratch using SSL (Secure Socket Layer) on Linux. We didn't try very hard though; in our environment, SSL was not important. The useUnicode and characterSetEncoding parameters tell the JDBC subsystem that the database is Unicode and everything is UTF-8. Note that the string UTF-8 is the Java way of specifying the charset; MySQL uses the string utf8. If changing charsets, you'll have to compare what Java supports with what MySQL supports.

We also copied the above code to a JSP page and ensured we could display Thai. The only tricky part of that exercise was setting the page output charset. That was accomplished by putting the following line at the top of each page:

<%@ page contentType="text/html;charset=UTF-8" language="java" %>

Note: If you use Apache with mod_jk (the Apache module for running Tomcat as a plug-in within Apache), you will have to configure Apache to treat the page as UTF-8 as well; the Apache setting might overwrite the Tomcat setting (depending on which version you use). Our project used Tomcat as a standalone server.

Our next step was to get things working with DbForms. We started by using the GUI tool and setting the JDBC connect string, jdbc:mysql:///dbtest?requireSSL=false&useUnicode=true&characterEncoding=UTF-8. The tool then created a dbforms-config.xml file. Scroll down to the bottom of the file and you should see:

<dbconnection
  Name="jdbc:mysql:///stpneal2?requireSSL=false&amp;useUnicode=true
    &amp;characterEncoding=UTF-8"
  isJndi = "false"
  conClass  = "com.mysql.jdbc.Driver"
  username = "root"
  password  = ""/>

Note: If you do not see &, then you are using an old version of the GUI tool, which does not handle XML escaping correctly.

In the DbForms GUI tool, click on the XSL Transformation tab and create some JSP files. You can then review the code produced to see what DbForms and the GUI tool can do for you in terms of generating ready-to-use JSP pages.

We then manually edited the generated JSP files and inserted the <%@ page contentType="text/html;charset=UTF-8" language="java" %> directive. After verifying it worked, we modified the XSL files used by the GUI tool to generate the code. The change will vary file-to-file, but it will look something like this: