Practical experience in MySQL Coding

We are going to discuss with you the practical operation experience of MySQL encoding. I am a popular fan of MySQL Databases and I am very interested in the practical application of MySQL databases, the following is a summary of MySQL coding experience. There is no theoretical basis as described below, which is purely an experience. MySQL (the best combination with PHP) uses 4.1

We are going to discuss with you the practical operation experience of MySQL encoding. I am a popular fan of MySQL Databases and I am very interested in the practical application of MySQL databases, the following is a summary of MySQL coding experience. There is no theoretical basis as described below, which is purely an experience. MySQL (the best combination with PHP) uses 4.1

We are going to discuss with you the practical operation experience of MySQL encoding. I am a popular fan of MySQL Databases and I am very interested in the practical application of MySQL databases, the following is a summary of MySQL coding experience.

There is no theoretical basis as described below, which is purely an experience.

MySQL (the best combination of PHP and MySQL) uses version 4.1 or above, and uses the default for whatever character set it is. You do not need to set MySQL (the best combination with PHP ).

Then an example of using GB2312 and UTF-8 is given.

Well, you only need to ensure that the PHP file that you write the insert SQL statement is encoded as GB2312. Congratulations, the data you read from the PHP file that uses the GB2312 encoding that reads the select SQL statement is also GB2312.

Similarly, as long as you insert the PHP file into the database is UTF-8 encoding, then you enter the UTF-8, read out also use encoding for UTF-8 read.

What if I enter it as GB2312 and show that I want to use UTF-8?

If all your php files are UTF-8 encoded, then you must use iconv for encoding conversion during INSERT, convert str into GB2312 library, read the same, use iconv to convert UTF-8 display.

What encoding is used on your front-end page, so your strings have already been encoded in this way. So, even if they are stored in the database, their machine code must be like that, no matter where they are stored, no matter what encoding MySQL (the best combination with PHP) specifies, it does not convert your data when entering data. As long as you ensure that your front-end entry uses a UTF-8, then you also read the UTF-8.

Why is there always a problem with using PHPMYADMIN for import?

I have not studied the working principle of PHPMYADMIN, but his PHP files are UTF-8 encoding, that is, the imported data is UTF-8, you use the PHP file GB2312 to read, of course, a pile of chaos.

I guess there are three solutions:

When reading data, use set name to convert its MySQL encoding. I don't know if it is feasible,

After reading the data, use iconv to convert it to GB2312,

You do not need to use PHPMYADMIN to import data. Just write a PHP script for GB2312 to import the data.

In a word, what MySQL encoding is used when you input the data? What encoding is used when you read the data. If you want to display this encoding as another encoding type, you need to use iconv or mbstring for encoding conversion.

The above is only personal experience, and there is no time to study the theory. You are welcome to discuss or correct your suggestions.