MySQL garbled characters

The biggest problem with coding is that

Database a server storage code (assuming the server, database, table, and field are all the same)
Database B connection code, which is very critical. After MySQL 5.0 is started, the client configuration in my. ini server is usually used after the command line is connected.
"Set names 'utf8. You can use "show variables like 'character % '" To View
C Indicates the encoding of the import file. For example, if your import script is user. SQL, there is also an encoding.

(1) Experiment 1

The file is encoded in gb2312 format and imported using the client source command. The default value is utf8, while the MySQL server uses utf8 for storage.
When you use the client for query, you can see the correct display. The binary file of gb2312 is treated as utf8 during import. If utf8 is used for query
The binary is actually the binary of gb2312. This process is not converted.
 
(2) Experiment 2
 
The file is UTF-8 encoded and imported using the client's source command. The default value is utf8, while the MySQL server uses utf8 for storage.
When you use the client to perform a query, the error message is displayed directly. During import, the binary file of utf8 is treated as utf8. If utf8 is used for query
The binary is actually the binary of utf8, and no conversion is performed in this process. By default, the Operating System Client displays the gb2312 code page, which is garbled.
However, if JDBC is used for connection, the returned result is displayed correctly. I think JDBC uses the client settings in server for connection by default, that is, utf8, especially for MySQL 5.0 or above, it seems that setting useunicode = true & characterencoding does not work, but utf8 is still used. The final returned binary and client
The same is the binary of utf8, while the MySQL driver may be able to identify this as utf8, and the string can be converted to the local encoding (gb2312) of the operating system during display, which is JDBC
Drive credit.
 
(3) experiment 3
 
Similarly, both the client and server are set to utf8. Then, paste the script to EMS and use show SQL editor to import the script. Then, it is found that the table content in EMS is normal,
The client selects garbled code, and the JDBC program is garbled. Strange.
Later, we transcoded the JDBC string from Latin1 to gb2312, which is normal.
New String (Rs. getstring (2). getbytes ("Latin1 ")
The default-charset used for EMS import turned out to be Latin1.

(4) Experiment 4
The file is UTF-8 encoded, and the client is set to gb2312. The source cannot be imported, and data too long is reported.
It should be the UTF-8 binary, some of which do not exist in gb2312, so the error is returned.

In the final analysis, it is best to use UTF-8 encoding, so it is not easy to produce garbled characters.

In addition, if the text T is encoded as A and the binary value is XX, the connection uses encoding B during import, and the database uses encoding c.
Then, the Code Conversion of B --> C is adopted when receiving the database, that is, XX is mapped to C as B, for example, YY.

In order not to cause garbled characters, the connection should be set to B when data is retrieved, and the conversion from YY to XX occurs in C --> B.
The binary data returned from the database is XX. Use the code page encoded as a to display the text T in the operating system.