My environment: Simplified Chinese Win2000 Pro + SP3 MySQL Server 4.0.12 J2sdk 1.4.01 Connetcor-J 3.0.7 Problem: JDBC is used to insert and read Garbled text strings in the database. First, everything in the MySQL database is stored in binary format and supports any data, including Chinese. Go to the command line Insert into testtable values ('Chinese '); Select * From testtable; All are displayed normally. However, although there is no problem in accessing Chinese, there is a problem in sorting and matching. Therefore, if your database contains Chinese characters, remember to add a line in the configuration file, such as [mysqld] in C:/winnt/My. ini: Default-character-set = GBK Then restart the MySQL server. Note that GBK must be in lower case. Otherwise, mysqld cannot be started. Second, the database is okay. Let's take a look at the Java program. It is boring to add a debugging statement in the program: Out. println ("Chinese "); It also shows that the entire Java environment is normal. Therefore, of course, it is related to Java and MySQL, and MySQL JDBC driver has a problem. Analysis, Java uses Unicode internally, and MySQL uses iso-8xxx by default (forgot), so JDBC driver to pass the query string to MySQL server, will do Unicode-> iso-8xxx conversion, the iso-8xxx-> Unicode conversion is performed when the results are received from the MySQL server. (Unicode-> GBK will appear when the results are displayed on the screen, but it is none of the above .) This is a problem. When I insert the Chinese string of the database under the command line as GBK (which is the default for simplified Chinese Windows), when the JDBC driver accepts the query result, must be converted to GBK-> Unicode. Verify that the Chinese string s read from the database, New String (S. getbyte ("iso-8xxx"), "GBK ") Convert s to a Unicode-> iso-8xxx to the original form it stores in the database. We know that it is GBK, so we use GBK-> Unicode manually, so that the Java program is explicitly normal. Similarly, when writing to the database, we expect the JDBC driver will put Unicode-> GBK, but the result is Unicode-> iso-8xxx, of course, is garbled. There are a lot of articles, so far, and tell us: To solve Chinese problems, manually transcode yourself. This is really irresponsible. If each string needs to be manually transcoded, it indicates a problem with the program design. Think about it. The guy who writes MySQL JDBC driver will not even know about transcoding? So I looked at readme IN THE connector-j-3.0.7 and found a solution: Connection = drivermanager. getconnection ("JDBC: mysql: // localhost/test? User = root & Password = & useunicode = true & characterencoding = GBK "); This tells JDBC driver to force transcoding based on specified parameters In fact, there is still a problem. If the MySQL server must use a iso-8xxx, it will only use the previous method. But I remember that my MySQL was GBK, And I have changed my. ini? How does JDBC driver not automatically detect the character set of MySQL server? At this time we can see the advantages of open source code connector-j-3.0.7 source code indeed has read MySQL server information, including character set. Know from the annotations, The author writes his own Conversion Function for Unicode conversion to a single-byte character set, and claims to be a fraction faster than JVM. So there is a section in the Code. If the block database uses a single byte, it calls its own conversion function. But after this code, I forgot to hand over the multi-Byte Character Set to JVM for conversion, so it became the default iso-8xxx conversion. My modification method is as follows: Line 1969 of the file COM/MySQL/jdbc/connecter. Java, This. dounicode = true; // force the issue Move the four rows above to 1964 rows and put them in front of the following row: Try { With the JDBC driver re-compiled by this Code, your Java database access program can correctly read and write Chinese without any modifications, but remember that MySQL server needs default-character-set = GBK I used it to test a few small programs. The text in the text is displayed as normal, and there are no crashes or exceptions. Haha, I feel very good. |