JDBC connection MySQL garbled exception handling summary
When learning JDBC some time ago, you should connect to MYSQL to obtain data. According to the teacher's sample data, I need to save some information such as names, all of which are in English. I didn't want to use English at that time, so I saved my roommate's name. Hey hey, as a result, there was a problem.
@H_ 419_ 4@
Connect to database statement:
Query statement:
I used my name for the query, NullPointerException. Obviously, no corresponding data was found in my name, but it exists in the database. Why?
Baidu's answer is Chinese garbled code. The solution is to modify the statement connecting to the database as follows:
Try again!
All right! But why? What are the two parameters? Why does it solve the problem after adding it?
These two parameters are explained as follows:
The default value of both parameters is false. In other words, when we connect to MySQL, we specify the character set used for the connection, and everything will be normal. But I still don't know much about the mechanism, so I continue to check.
Originally, there was a character set conversion process when the MySQL connection was used for query and other operations:
1. When MySQL server receives a request, it will send the request data from character_ set_ Convert client to character_ set_ connection;
2. Remove the request data from character before internal operation_ set_ The connection is converted to the internal operation character set, and its determination method is as follows:
• use the character set setting of each data field;
• if the above values do not exist, use the default character set setting of the corresponding data table (MySQL extension, non SQL standard);
• if the above values do not exist, use the default character set setting of the corresponding database;
• if the above values do not exist, character is used_ set_ Server settings.
3. Convert the operation result from the internal operation character set to character_ set_ results。
What do these character sets represent?
character_ set_ Server: default internal operation character set
character_ set_ Client: the character set used by the client source data
character_ set_ Connection: connection layer character set
character_ set_ Results: query result character set
character_ set_ Database: the default character set of the currently selected database
character_ set_ System: character set of system metadata (field name, etc.)
I also found some common questions. Although they are different from my questions, they are of great reference significance.
• the connection character set is not set before inserting utf8 encoded data into the data table with the default character set of utf8, and the connection character set is set to utf8 during query
During C insertion, according to the default settings of the MySQL server, character_ set_ client、character_ set_ Connection and character_ set_ Results are Latin1;
The data of C insertion operation will go through the character set conversion process of Latin1 = > Latin1 = > utf8. In this process, each inserted Chinese character will be saved from the original 3 bytes to 6 bytes;
The result of C query will go through the character set conversion process of utf8 = > utf8, and the saved 6 bytes will be returned intact, resulting in garbled code
• before inserting utf8 encoded data into the data table with the default character set of Latin1, the connection character set is set to utf8
C when inserting, according to the connection character set setting, character_ set_ client、character_ set_ Connection and character_ set_ Results are utf8;
C the inserted data will be converted into "? After the character set of utf8 = > utf8 = > Latin1. If the original data contains Unicode characters outside the range of \ u0000 ~ \ u00ff, it will be converted to"? Because it cannot be represented in the Latin1 character set (0x3f) symbol. Its contents cannot be recovered no matter how the connection character set is set in future queries.
(this part is extracted from brother bird's blog, and a link will be attached later)
The tables in my database are encoded in utf8, but the connection character set is not set when I connect for the first time, so it defaults to Latin1. After the conversion from utf8 = > Latin1, garbled codes are generated. I used GBK code for the second time, but I didn't use utf8 code. Why can it be? In fact, it is a truth. Chinese is not in the coding of Latin1, but in GBK and UTF8, so there will be no problem.
The above is the solution to the disordered code exception of JDBC connection mysql. If you still don't understand anything, you can discuss it in the message area below.