Mysql garbled Problem Analysis and Solution

During the development process, you cannot avoid spam or a series of problems caused by spam. Garbled characters are the cause of character sets. They generally do not have much to do with the logic. That is to say, there is no problem in the overall direction of the system. A vulnerability occurs in a small place, which causes the program to fail to run normally, so Garbled text is a very disgusting thing. Here, we will briefly introduce the garbled problem we have encountered, the ideas in the process of solving the problem, and the general operations. What we need to learn is how to analyze the problem and solve the problem, the difference between "fish" and "fish" is not just to solve the current difficulties again and again based on the operations on the Internet.

Background:
The function to be implemented is very simple. Use dom4J to read the XML file and then use Spring and Hibernate to write data to the MySql database (multiple tables). Of course, the whole process is completed by Spring to control the transaction at one time, rollback is performed due to an exception.
Symptom: an error is reported when half of data is written to the database. The general error message is that the record is not unique.
Analysis and Operations:
Check your code and use HibernateTemplete in Spring to save the data.

Observe again: it seems to be a problem with foreign key constraints, because every time data is inserted into a table with foreign keys, it cannot be input.
Analysis and Operations:
Since it is a foreign key table problem, we should first determine what the content in the foreign key table is, so manually change the database isolation level to view the data, which is indeed garbled!

Q: How do I access the database with garbled characters?
Analysis and Operations:
It is garbled when reading xml, or when writing data to the database. Breakpoint debugging again to test whether the code is garbled in the program.

Symptom: No garbled information is printed in eclipse.
Analysis and Operations:
This shows that there is no problem in the program and it is a database problem. So first change the database link string to specify the encoding, then change the database encoding, and then breakpoint debugging again.

Symptom: the database is still garbled, but the garbled form is changed. It was all "?". It's a mess of text.
Analysis and Operations:
Obviously, the above series of operations to modify the encoding format work, but they are not modified. Check the encoding formats again. No problems are found.
The problem was once deadlocked ......
For help: It is too difficult to use the command window. Use a third-party client, so use a third-party client. The strange thing is that the client shows no problem!
Analysis and Operations:
If the client has no problem with the command window, it indicates that the database is not garbled, and garbled characters may be displayed on the command line. Set the command line display characters, and the display is normal! Test data import again ---- everything is OK.

Thoughts and summary:
Symptom: in fact, this problem was solved when the encoding was modified for the first time, but because the program was not executed during the breakpoint debugging, it was always considered that the database was still garbled.
Summary:
The program should be completed during each debugging and the error context should be simulated, rather than focusing on the error itself.

Symptom: XML encoding, dom4j reading encoding, database encoding, database connection string encoding, and command line window display encoding are involved here. Which of the above cannot solve the problem (I am not aware of the last one ).
Summary:
The concept of concept is to grasp every control variable, from the beginning to the end, consciously jump out of the environment to make assumptions.