First of all, the following is not necessarily correct, but reasonable:today when writing a Web project with a get way to carry some Chinese parameters sent to the server, the server received, verify the rationality, and then insert the databaseThe whole process has produced a few garbled phenomenon, at first it is puzzling, try a variety of online solutions to start their own thinking and testing, found some clues, so make a record, also please see this post of the people to discuss its correctness.
first, from the URL of the Get method to receive the Chinese parameter, and then directly after the receiving end of the output generated the first garbled phenomenon, this reason isURL submission is encoded according to ISO-8859-1 encoding, initially mistakenly thought that the URL encoding can be set with Urlencoder, in fact, urldecoder do only the surface of the work, and not modify the bottom storage of the machine 0 and 1, the so-called surface work, It is like, "you" the word with the symbol is replaced (here is just an example) and then on the server side with the urldecoder literally to restore back to "you", a bit as if the literal encryption and decryption work, In fact, these Chinese characters are still submitted to tomcat with ISO-8859-1 encoding, assuming that the word "you" is stored in iso-8859-1 code at the bottom of the data is 0101, when Tomcat received 0101 and then put him in string s package up, This time if you print System.out.println (s) can be garbled, the reason is that your local default encoding is not iso-8859-1, so that Java will show 0101 as the default encoding according to the local symbol, through the cmd CHCP command can view the native default encoding, my machine is GBK, if in GBK 0101 for "@" symbol, then you print it is @, so if you want to print without garbled, you can pass string s = new String (S.getbytes ( "Iso-8859-1"), "native default encoding Method"), the encoding will be converted and then output, so that the word "you" from the iso-8859-1 0101 conversion cost machine default encoding corresponding to the 01 sequence, for example, under the GBK "You" corresponds to 1010, So at this point, s at the bottom of the storage from 0101 to 1010, and sometimes you may also find that if you do this conversion can also get the correct Chinese output:String (S.getbytes ("iso-8859-1"), "GB2312") (assuming the native code is GBK), because GB2312 is a subset of GBK, GBK is an expanded version of GB2312, so although most of the time it is correct, the display will go wrong when it encounters characters that are not included in GBK and GB2312.
then I solved this garbled problem after the data written to the database, and then from the MySQL command line Select a bit garbled, because my database jdbc:mysql://127.0.0.1:3306/open_push? Characterencoding=utf-8 cause, because the last step I have to convert the code to GBK, and then I tell the database I give you the data is UTF-8 encoded (if the database table storage data is stored in GB2312), So the database will think that you give him the Chinese character is UTF-8 encoding and not GBK, he will you give his character into GB2312 encoding method is to query the UTF-8 turn GB2312 encoding conversion table instead of GBK to GB2312 encoding conversion table, This causes the transcoding error, the natural display of the data will not be correct, so you do not want to appear garbled problem must honestly tell the database you give him the data is encoded according to what encoding, this is the role of setting characterencoding, if you give the code is GBK, You need to set CHARACTERENCODING=GBK, if you give the UTF-8 set CHaracterencoding=utf-8, this time you may find you in the database command line in the select of a bit or garbled, You'll be amazed I told the database I gave you is UTF-8 code Ah, why also show me is garbled, I guess this may not blame the database, because the database is really actually in accordance with UTF-8 to you stored data, but after you select out, command line to show you this process is used or your local default encoding GBK, so the select out of the display is garbled, if you modify your machine's default encoding for UTF-8, the results will be correct.
A little thought on garbled characters in Javaweb project
