Thoughts on htmlspecialchars and htmlentities handling special characters

In firefox, use & ldquo; View & rdquo; & ldquo; page source code & rdquo; in the & rdquo; menu to view the html source code and the selected content, and then click & rdquo; check the source code & ldquo; of the selected Part. the source code is different. we prefer to trust the former instead of the latter. For example, if the page is gbk, there is a form. enter this character in the input box & ldquo; & #12539; in firefox, use "page source code" in the "View" menu to view the html source code and the selected content, and then click "View selected Source Code". the source code is different. we would rather trust the former, do not trust the latter. For example, if the page is gbk, there is a form. enter the character "token" in the input box of the form and save it to the data library as "token". if it is then displayed on the page (gbk character), it will be displayed as is: "unknown", if you use "view the source code of the selected part" to check it, his html source code is still this weird dot, but if you use "page source code" to view it, he will see the original "dot". The same is true for many characters:❤

Because this symbol is saved as "bytes" in the database (why is it stored mainly because your page is gbk and cannot be transmitted normally, therefore, it can only be converted to special characters before it can be uploaded to the server). Therefore, if it is directly displayed without conversion, it will also be displayed as the original point, however, special characters must be processed when the server sends a string to the client, for example, using the htmlentities function. In this way, & in the characters will be converted to &, and the DOT will not be displayed normally.

In this process, I will consider what process should we follow to process the string passed in the form: (magic_quotes_gpc is set to 0 by default here. this setting is also recommended in any project in the future. if gpc is 1, first, perform stripslashes processing on all data ):

Htmlspecialchars mysql_real_escape direct
Form ------------------------------> -------------------------------> DB ---------> html

Or:

Mysql_real_escape htmlspecialchars
Form -------------------------------> DB -----------------------------------> html

In fact, I think the two are basically the same, and the returned html results are both correct and can process the data. I used the second form before. I encountered some problems, mainly in the case of an error in the form and asked the customer to modify the data and submit it again, originally, the data submitted by the form is directly returned (without any processing) to the form, but for some special characters, such as single quotation marks or double quotation marks, an exception may occur when the returned result is returned, or it is not displayed, or the display is abnormal. So we need to process the data in htmlspecialchars. So I started to consider the first process. if a form verification error occurs, I can return the result after htmlspecialchars and re-assign the data to the form without leading to an error in the form content. But there is a fatal problem in the first process. Do we need to save the displayed data in the database or the original data? Of course, it is best to use raw data. Therefore, we still need to use the second process. when returning the error page, we also need to use htmlspecialchars for conversion. although it is troublesome, this will not cause problems.

When we study the differences between htmlentities and htmlspecialchars functions, we test the character "gbk missing ". The string is not changed after htmlspecialchars ($ str, ENT_QUOTES. However, after htmlentities ($ str) or even htmlentities ($ str, ENT_QUOTES, 'gb2312') (it should be gbk, but gbk is not supported here), the result is changed: "gbkçá] Ó Ð µä" and" gbkçá ". So I decided to use htmlspecialchars to replace htmlentities in all circumstances, and I didn't need to write any _ myhtmlentities to fix the original problem of htmlentities. Of course, the reason why htmlentities are garbled is not only because of its own problems, but also because the characters passed in are only available in gbk, which is not found in gb2312, but can only be handled using gb2312, so an error occurs.

However, the question about how to record the webpage content characters in the database is true or escaped in html. I have seen and recognized it in a good textbook: Actually, everything works, I personally use the characters after saving and escaping, and then directly display them on the webpage when retrieving from the database, whether it is the title or content of the article. As for the encoding, of course, it is all utf8. We would rather sacrifice execution efficiency than hurt this.