Servlet JDBC character conversion problem

Discussions

Web tier: servlets, JSP, Web frameworks: Servlet JDBC character conversion problem

  1. Servlet JDBC character conversion problem (4 messages)

    Hi,

      I'm having a strange problem. I'm developing a J2EE Web Application, with Entity Beans, Servlets, JSPs and so on. I've started to get character conversion problems, and I've isolated the piece of code giving me problems.

      The code is:

      DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
      Connection con = DriverManager.getConnection ("jdbc:oracle:thin:@oraclehost:1521:orcl", "user", "password");
      dumpTable(con, out);
      String updateStatement = "UPDATE IDIOMAS SET IDIOMA = 'Español' WHERE IDIDIOMA = 1";
      PreparedStatement prepStmt = con.prepareStatement(updateStatement);
      prepStmt.executeUpdate();
      prepStmt.close();

      If I paste this code into a JSP, then I get the desired result, BUT, if I paste and run the code from a Servlet (exactly the same code), then my "Español" becomes "Espaýol"... I've tried almost everything, I've runned the Servlet on the J2EE server and locally whit the debugger, and the same result.

      My DataBase server is a Oracle 8.1.7 Database, and I'm using Oracle 9i Application Server (the Orion AS).

      The problem is the same with "á", "é", "í" and so on.

      I'll apreciate any kind of help you can give me.

        Thanks in advance, and please forgive my English.

            Gustavo Comba

    Threaded Messages (4)

  2. I had the same problem with French characters on Oracle... Use the Oracle function CHR() to replace the character with the ascii code in the string:

    UPDATE IDIOMAS SET IDIOMA = 'Espa' || CHR(164) || 'ol' WHERE IDIDIOMA = 1

    Ascii code 164 is the ñ character.

    Greg.
  3. Hi Greg,

      I apreciate your answer, but I'm afraid I've simplified a little the example.

      My real code is inside the database access functions of my EJB Entity Beans (BMP), and look something like that:

      String updateStatement = "UPDATE IDIOMAS SET IDIOMA = ? WHERE IDIDIOMA = ? ";
      PreparedStatement prepStmt = con.prepareStatement(updateStatement);
      prepStmt.setString(1, m_Idioma);
      prepStmt.executeUpdate();
      prepStmt.close();

      Where "Idioma", which is a standard java.lang.String, eventually is "Español", and my "ñ" is replaced with the "ý".

      In this case the code doesn't know about the charactes inside the String.

      I could use the specific Oracle java datatypes, but I want that my application stay vendor-independant, database-independant, J2EE Server-independant. (that is because I'm using Java! ;-) )

      Thanks anyway, and if you have any clue why the same code called from a JSP is working OK (even when I instanciate the EJB in the JSP), I'll thank you more!

      Gustavo
  4. One of the biggest bottlenecks in JDBC implementations is the cost of type conversions—moving data from database datatypes to Java datatypes. Most databases do not store character data in UCS-2, the character set used internally by Java. Java doesn't have native support for Oracle's decimal number support, which requires a conversion to a Java datatype. Also, creation of Java objects can be expensive, so just initializing an array of 1000 Java objects can be a bottleneck.
     
    XDB addresses these problems with lazy type conversions. Often, large trees of parsed XML elements are never accessed, or if they are accessed, their values aren't used by the application. XDB only converts the data for Java when the Java application first asks for it. Consider the case of a JSP that wants to load a name from the database and print it out in the generated HTML output. Typical JSP implementations would read the name from the database (which probably contains data in the ASCII or ISO8859 character sets) convert the data to UCS-2, and return it to Java as a String. The JSP wouldn't look at the contents of the string, but merely print it out after printing the enclosing HTML, probably converting back to the same ASCII or ISO8859 for the client browser. XDB provides a write interface on XMLTYPE so that any element can write itself directly to a stream (such as a ServletOutputStream) without conversion through Java character sets.
  5. Help[ Go to top ]

    Hi Gustavo,

    Did you resolve the problem ? We have the same issue

    regards

    JF