在firefox中，使用“查看”菜单中的“页面源代码”查看html源代码 跟 选中要看的内容然后点击”查看选中部分的源代码“ ，得到的源代码不相同，我们宁可相信前者，而不要相信后者。举例来说：页面为gbk的，中有一个表单，通过表单中的输入框输入这个字符“・”，保存到数据 库中的是“・”，如果接着将它查出来在页面上显示（gbk字符），他会显示回原样：“・”，如果使用“查看选中部分的源代码”查 看，他的html源代码仍然是这个怪异的点号，但是如果使用“页面源代码”查看，他会现出原形“・”。同样很多字符也一样：❤
因为这个符号在数据库中以“・”保存（为什么要以这个保存，主要是因为你的页面是gbk的，无法正常传输这个字符，因此只能转换成特殊字符才能传到服务器），所以每次读出的时候如果不经过转换直接显示，也会显示为原来的那个点，但是我们一般在服务器端向客户端发送字符串时都要对其中的特殊字符进行处理，比如使用htmlentities函数。这样的话，就会将字符中的&转换为&，点号也就无法正常显示了。
在这个过程中，我考虑，我们应该按照什么流程来处理表单传入的字符串：（这里默认magic_quotes_gpc设置为0，以后任何项目中也推荐这样设置，如果gpc为1，那么首先对所有数据进行stripslashes处理）：
form ------------------------------> -------------------------------> DB ---------> html
还是：
mysql_real_escape htmlspecialchars
form -------------------------------> DB ---------------------------------> html
其实我这里认为两者基本都一样，最后返回的html结果都正确，都能处理好数据。我之前使用的是第二种形式，其中遇到了一些问题，主要是在表单出错后返回，让客户修改数据重新提交时遇到的问题，原来是直接将表单提交的数据返回（不经过任何处理）重新赋给表单，但对于某些特殊的字符，比如单引号或者双引号，再返回时就 会出现异常的情况，或者不显示，或者显示不正常。于是需要我们对数据进行htmlspecialchars处理。于是我开始考虑第一个流程，如果表单验证错误，可以在htmlspecialchars后面返回，将数据重新赋给表单而不会导致表单内容出错的问题。但是第一个流程有个致命的问题，我们在数据库中要保存显示的数据呢还是要保存原始的数据呢？当然最好是原始的数据。因此我们还得使用第二个流程，在返回错误页面的时候，我们也得使用 htmlspecialchars进行转换，虽然比较麻烦，但这样不会出现问题。
在研究htmlentities和htmlspecialchars两个函数的不同点的过程中，我们测试这个字符传：“gbk鐘沒有的”。经过 htmlspecialchars($str, ENT_QUOTES),这个字符串没有改变。但是经过htmlentities($str)甚至htmlentities($str, ENT_QUOTES, 'GB2312')（应该是gbk，但这里不支持gbk），结果分别变为：“gbkç姏]ÓеĔ 和 “gbkç姏]有的”。于是决定不管在任何情况下都应该使用htmlspecialchars来代替htmlentities，同时也不需要自己写什么 _myhtmlentities来修复htmlentities原有的问题。当然htmlentities出现乱码的原因不光是因为它本身的问题，也是因 为传入的字符是在gbk中才有的，gb2312中没有，但只能使用gb2312来处理，于是出现错误。
不过关于数据库中记录网页内容字符的问题，到底存真实的，还是html转义过的，我在一本很好的教材上看到并也认可：其实都可以，我个人现在用的是存转义后的字符，然后，从数据库取出时直接显示在网页，无论是文章标题还是内容。至于编码，当然是全utf8。宁可牺牲执行效率，也不为这个伤神。
立即学习“前端免费学习笔记（深入）”；
