Analysis and resolution of Chinese garbled characters in the communication between Android and PC

The initial realization of the Android and PC server communication, and encountered the legend of the headache of Chinese garbled problem. Since there is garbled, then the reason is naturally the protocol is not through.
We know that the default encoding standard in Eclipse is GBK, and the default layout file encoding standard for Android program development is Utf-8, so that when we communicate with each other, we will inevitably get garbled. To solve it, we should start with the transformation of the two.
First we know that the encoded character set of the text obtained from the Android phone interface is utf-8, so when our Java file gets it it is compiled in utf-8 form. So here, after getting the text in the EditText, it outputs it with the output stream, and the server side uses a string to receive a line of characters from the input buffer stream.

Java code

2. Read Client Information
4. While (true) {
6. While (is.available () > 0) {
8. //transcoding before
10. String msg_client1 = Brd.readline ();
12. System.out.println ("before transcoding:" + msg_client1);
14. //transcoding
16. String msg_client = new String (Msg_client1.getbytes ("GBK"),
18. "Utf-8");
20. String enter = new string ("\ r \ n". GetBytes ("Utf-8"));
22. //transcoding after printing out
24. SYSTEM.OUT.PRINTLN ("client:" + msg_client);
28. String msg_server = msg_client1 + Enter;
32. Os.write (Msg_server.getbytes ());
34. Os.flush ();
36. Thread.Sleep (1000);
40. }
42. }

Do not guess, at this time because the server-side encoding standard is GBK, read out the string must be garbled. So below, we'll get a byte array compiled in UTF-8 format. So, the long-awaited Chinese characters finally came out.

But there is no discovery, when the input of an even number of Chinese characters, get the correct results, and input odd number of, the last word becomes "?? ”？
What is this again? Tangled here for a long time, so to search the standard character set encoding, and finally found the reason. For GBK This encoding, the Chinese corresponds to the number of bytes is 2byte, while in Utf-8, Chinese is the corresponding three bytes. So when you enter an odd number of characters, the last byte cannot be compiled in GBK. For example, UTF-8 encoded 3 words, encoding is 123|456|789, in the transmission to the server, the system thinks that the 9 bytes is GBK encoding, so it becomes 12|34|56|78|9. The extra byte in the back cannot be compiled into Chinese characters, which is commonly used at this time. "To replace. So the last byte becomes "? "(ASCII code is 63). Then turn it into a utf-8, then become 123|456|78? At this point the third Word cannot be read correctly, so the result (two question marks) appears.
Now, how to solve it? After trying all kinds of encoding conversion, wandering in a variety of garbled between still can't solve, suddenly think, the previous reading way is through the BufferedReader line of reading, so that the input stream in the character buffer, has destroyed the last byte. So, if you get a byte array directly without destroying it, can it be solved? Change the code here, directly using the resulting byte array to form a string, and then ...

Java code

2. Read Client Information
4. While (true) {
6. While (is.available () > 0) {
10. byte[] bb = new byte[is.available ()];
12. Is.read (BB);
14. //transcoding before
16. String msg_client1 = new String (BB);
18. System.out.println ("before transcoding:" + msg_client1);
22. //transcoding
24. String enter = new string ("\ r \ n". GetBytes ("Utf-8"));
26. String msg_client = new String (BB, "Utf-8");
28. SYSTEM.OUT.PRINTLN ("client:" + msg_client);
32. //Send
34. String msg_server = msg_client1 + Enter;
36. Os.write (Msg_server.getbytes ());
38. Os.flush ();
40. Thread.Sleep (1000);
42. }

You can see that the odd number of Chinese characters can also be read! Yes Although this small problem tangled for a long time, but also let oneself know the coding of the secret, the harvest is very big.
Finally, explain the method of new String (Str.getbytes ("DD"), "CC"). In short, the use of this method is that when the actual encoding of your string is "CC", and the system as "DD", this line of code can be used to get the correct encoding.