The experience summary of the MySQL coding problem

The following description has no theoretical basis and is purely empirical.

MySQL uses more than 4.1 version, the tube is what character set, all use default. Do not have to set MySQL.

Then give an example of using GB2312 and UTF-8.

All right, you just make sure your php file code for the INSERT SQL statement is GB2312, and congratulations, the data you read with the GB2312 encoded PHP file with the Select SQL statement is also GB2312.
Similarly, as long as you insert the database PHP file is UTF-8 code, then you input is UTF-8, read out the same use encoded as UTF-8 read.

What do I do if I enter it as a GB2312, showing what to do with UTF-8?

If all your PHP files are UTF-8 encoded, then you must use Iconv to encode the conversion when you insert, turn str into GB2312, and read the same, use Iconv to UTF-8 display.

What encoding does your front-end page use, so your strings have been encoded by this code, so, although the storage, his machine code is certainly so, no matter where, regardless of what MySQL specifies the code, he entered the data, does not convert your data. Just make sure your front end entry uses UTF-8, then you read the UTF-8.

Why is it always a problem to use phpMyAdmin import?

I have not studied the working principle of phpmyadmin, but his PHP files are UTF-8 encoded, that is, the import data are UTF-8, you use GB2312 php file to read, of course, a heap of chaos.
Solution I guess there are three kinds:

When reading, use the set name to convert it to code, not knowing if it works,

After reading, use Iconv to convert it to GB2312,

Do not phpmyadmin import, you write a GB2312 php script import can.

In a word, what code do you use when you input it, then what is the code when you read it? If you want to display this code as a different encoding, you need to encode it using Iconv or mbstring.

Above only for personal experience, no time to study theory. You are welcome to discuss or have errors please correct me.