| Bug #31192 | Encoding Issue retrieving serverVersion in MysqlIO in the method doHandshake | ||
|---|---|---|---|
| Submitted: | 25 Sep 2007 22:15 | Modified: | 1 Mar 2008 13:28 |
| Reporter: | Jimbo J. | ||
| Status: | Closed | ||
| Category: | Connector/J | Severity: | S3 (Non-critical) |
| Version: | OS: | Other | |
| Assigned to: | Target Version: | ||
[31 Jan 2008 6:21]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/41475
[31 Jan 2008 6:28]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/41476
[1 Mar 2008 13:28]
MC Brown
A note has been added to the 5.1.6 changelog: Retrieving the server version information for an active connection could return invalid information if the default character encoding on the host was not ASCII compatible.
Description: In MysqlIO.java in the method: void doHandshake(String user, String password, String database) There is a line of code: this.serverVersion = buf.readString(); where buf is populated by readPacket(); The OS I am working sets the default "file.encoding" of the JVM to IBM1047 (ebcdic variant). So my problem "seems" to be that readString() (in Buffer.java) calls a String constructor to retrieve the serverversion given to it from the Mysql server in the raw byte stream contained in buf (from above). However it uses the String constructor that does not specify encoding which does exist in Buffer.java as well. So this is an interesting case where the native JVM for the client uses IBM1047, however I needed to specify "ISO8859-1" in the connection URL of the client (ala JDBC) in order to correctly translate the incoming sever version. The default cp1252 (or whatever it is) fails on our system because the conversion table has a "hole" in it causing our iconv to fail. (I guess the JVM does not have a class to manage the translation). However, our ISO8859-1 is fine. Does this make sense? It appears that JDBC assumes the default String constructor for the JVM will use ascii. Which isn't the case. Or is this supposed to fail and handled later on in the connection? I assumint that the URL Connection Property (characterEncoding) specification is what JDBC uses to pass to the String constructor? Please advise if this is not how it is supposed to operate in my scenario. Thanks. How to repeat: Impossible w/o my system. Need to work through this conceptually. Suggested fix: I imagine instead of using just ReadString(), we need to use ReadString(encoding)? Are there other areas that could suffer from this?