1. File encoding: refers to the encoding used by the page file (.html, .php, etc.) itself. Notepad and Dreamweaver will automatically recognize file encoding when opening the page, so there will be no problems. However, ZendStudio does not automatically recognize the encoding. It only opens the file with a certain encoding according to the configuration of the preferences. If you do not pay attention to it during work, open the file with an incorrect encoding. After modifying it, the garbled code will appear (I have a deep understanding).
2. Page declaration encoding: In the HTML code HEAD, you can use <meta http-equiv="Content-Type" content="text/html; charset="XXX"/> to tell the browser what encoding is used for web pages. Currently, XXX mainly uses two encodings in Chinese website development.
3. Database connection encoding: refers to which encoding is used to transmit data to the database when performing database operations. It should be noted here that it should not be confused with the encoding of the database itself. For example, the default internal latin1 encoding of MySQL is latin1 encoding, which means that Mysql stores data with latin1 encoding, and the data transmitted to Mysql with other encodings will be converted into latin1 encoding.
Knowing where encoding is involved in WEB development, we also know the reason for the occurrence of garbled code: the above three encoding settings are inconsistent. Since most of the various encodings are compatible with ASCII, the English symbols will not appear, and Chinese will be in trouble. Here are some common error situations and solutions:
1. The database uses UTF8 encoding, and the page declares that the encoding is GB2312, which is the most common reason for garbled code. At this time, the Select data in the PHP script is garbled code, and you need to use it before querying:
mysql_query("SET NAMES GBK");
Set the MYSQL connection code to ensure that the page declaration code is consistent with the connection code set here (GBK is an extension of GB2312). If the page is UTF-8 encoded, you can use:
mysql_query("SET NAMES UTF8");
Note that it is UTF8 instead of UTF-8 that is commonly used. If the encoding stated on the page is consistent with the internal code of the database, no connection encoding can be set.
Note: In fact, the data input and output of MYSQL is more complicated than mentioned above. Two default encodings are defined in the MYSQL configuration file, namely the default-character-set in [client] and the default-character-set in [mysqld] to set the default encodings used by the client connection and the database when default. The encoding we specified above is actually the command line parameter character_set_client when the MYSQL client connects to the server, to tell the MYSQL server what encoding the client data is, rather than using the default encoding.
2. The page declaration code is inconsistent with the file itself. This rarely happens because if the encoding is inconsistent, the artist sees garbled code in the browser when doing the page. More often, some small bugs are modified after publishing, and the page is opened with an error encoding and then saved. Or use some FTP software to modify files directly online, such as CuteFTP, and the software encoding configuration is incorrectly converted and encoding is caused.
3. Some friends who rent virtual hosts clearly have garbled codes even if the above three encodings are set correctly. For example, the web page is encoded by GB2312, but when IE and other browsers open, they always recognize it as UTF-8. The web page HEAD has already declared that it is GB2312. After manually modifying the browser encoding to GB2312, the page displays normally. The reason for this is that the server Apache sets the server's global default encoding and adds AddDefaultCharset UTF-8. At this time, the server will first send the HTTP header to the browser, and its priority is higher than that stated on the page, so the browser will naturally recognize it wrong. There are two solutions. Please add an AddDefaultCharset GB2312 to the configuration file's virtual machine to override the global configuration, or configure it in the .htaccess in your own directory.
2. Page declaration encoding: In the HTML code HEAD, you can use <meta http-equiv="Content-Type" content="text/html; charset="XXX"/> to tell the browser what encoding is used for web pages. Currently, XXX mainly uses two encodings in Chinese website development.
3. Database connection encoding: refers to which encoding is used to transmit data to the database when performing database operations. It should be noted here that it should not be confused with the encoding of the database itself. For example, the default internal latin1 encoding of MySQL is latin1 encoding, which means that Mysql stores data with latin1 encoding, and the data transmitted to Mysql with other encodings will be converted into latin1 encoding.
Knowing where encoding is involved in WEB development, we also know the reason for the occurrence of garbled code: the above three encoding settings are inconsistent. Since most of the various encodings are compatible with ASCII, the English symbols will not appear, and Chinese will be in trouble. Here are some common error situations and solutions:
1. The database uses UTF8 encoding, and the page declares that the encoding is GB2312, which is the most common reason for garbled code. At this time, the Select data in the PHP script is garbled code, and you need to use it before querying:
mysql_query("SET NAMES GBK");
Set the MYSQL connection code to ensure that the page declaration code is consistent with the connection code set here (GBK is an extension of GB2312). If the page is UTF-8 encoded, you can use:
mysql_query("SET NAMES UTF8");
Note that it is UTF8 instead of UTF-8 that is commonly used. If the encoding stated on the page is consistent with the internal code of the database, no connection encoding can be set.
Note: In fact, the data input and output of MYSQL is more complicated than mentioned above. Two default encodings are defined in the MYSQL configuration file, namely the default-character-set in [client] and the default-character-set in [mysqld] to set the default encodings used by the client connection and the database when default. The encoding we specified above is actually the command line parameter character_set_client when the MYSQL client connects to the server, to tell the MYSQL server what encoding the client data is, rather than using the default encoding.
2. The page declaration code is inconsistent with the file itself. This rarely happens because if the encoding is inconsistent, the artist sees garbled code in the browser when doing the page. More often, some small bugs are modified after publishing, and the page is opened with an error encoding and then saved. Or use some FTP software to modify files directly online, such as CuteFTP, and the software encoding configuration is incorrectly converted and encoding is caused.
3. Some friends who rent virtual hosts clearly have garbled codes even if the above three encodings are set correctly. For example, the web page is encoded by GB2312, but when IE and other browsers open, they always recognize it as UTF-8. The web page HEAD has already declared that it is GB2312. After manually modifying the browser encoding to GB2312, the page displays normally. The reason for this is that the server Apache sets the server's global default encoding and adds AddDefaultCharset UTF-8. At this time, the server will first send the HTTP header to the browser, and its priority is higher than that stated on the page, so the browser will naturally recognize it wrong. There are two solutions. Please add an AddDefaultCharset GB2312 to the configuration file's virtual machine to override the global configuration, or configure it in the .htaccess in your own directory.