原文链接：http://phpbestpractices.justjavac.com/
净化 HTML 输入和输出
对于简单的数据净化，使用 htmlentities() 函数, 复杂的数据净化则使用 HTML Purifier 库
经 HTML Purifier 4.4.0 测试
在任何 web 应用中展示用户输出时，首先对其进行“净化”去除任何潜在危险的 HTML 是非常必要的。 一个恶意的用户可以制作某些 HTML，若被你的 web 应用直接输出，对查看它的人来说会很危险。
虽然可以尝试使用正则表达式来净化 HTML，但不要这样做。HTML是一种复杂的语言，试图使用正则表达式来净化 HTML 几乎总是失败的。
你可能会找到建议你使用 strip_tags() 函数的观点。 虽然 strip_tags() 从技术上来说是安全的，但如果输入的不合法的 HTML（比如， 没有结束标签），它就成了一个「愚蠢」的函数，可能会去除比你期望的更多的内容。 由于非技术用户在通信中经常使用 < 和 > 字符，strip_tags() 也就不是一个好的选择了。
如果阅读了验证邮件地址一节， 你也许也会考虑使用 filter_var() 函数。 然而 filter_var() 函数在遇到断行时会出现问题， 并且需要不直观的配置以接近 htmlentities() 函数的效果， 因此也不是一个好的选择。
对于简单需求的净化
如果你的 web 应用仅需要完全地转义（因此可以无害地呈现，但不是完全去除） HTML， 则使用 PHP 的内建 htmlentities() 函数。 这个函数要比 HTML Purifier 快得多，因此它不对 HTML 做任何验证---仅转义所有东西。
htmlentities() 不同于类似功能的函数htmlspecialchars()， 它会编码所有适用的 HTML 实体，而不仅仅是一个小的子集。
示例
对于复杂需求的净化
对于很多 web 应用来说，简单地转义 HTML 是不够的。 你可能想完全去除任何 HTML，或者允许一小部分子集的 HTML 存在。 若是如此，则使用 HTML Purifier 库。
HTML Purifier 是一个经过充分测试但效率比较低的库。 这就是为什么如果你的需求并不复杂就应使用 htmlentities()， 因为它的效率要快得多。
HTML Purifier 相比 strip_tags() 是有优势的， 因为它在净化 HTML 之前会对其校验。 这意味着如果用户输入无效 HTML，HTML Purifier 相比 strip_tags() 更能保留 HTML 的原意。 HTML Purifier 高度可定制，允许你为 HTML 的一个子集建立白名单来允许这个 HTML 子集的实体存在输出中。
但其缺点就是相当的慢，它要求一些设置，在一个共享主机的环境里可能是不可行的。 其文档通常也复杂而不易理解。 以下示例是一个基本的使用配置。 查看文档阅读 HTML Purifier 提供的更多更高级的特性。
示例
陷阱
以错误的字符编码使用 htmlentities() 会造成意想不到的输出。 在调用该函数时始终确认指定了一种字符编码，并且该编码与将被净化的字符串的编码相匹配。 更多细节请查看 UTF-8 一节。
使用 htmlentities() 时，始终包含 ENT_QUOTES 和字符编码参数。 默认情况下，htmlentities() 不会对单引号编码。多愚蠢的默认做法！
HTML Purifier 对于复杂的 HTML 效率极其的低。可以考虑设置一个缓存方案如 APC 来保存经过净化的结果以备后用。
PHP 与 UTF-8
没有一行式解决方案。小心、注意细节，以及一致性。
PHP 中的 UTF-8 糟透了。原谅我的用词。
目前 PHP 在低层次上还不支持 Unicode。有几种方式可以确保 UTF-8 字符串能够被正确处理， 但并不容易，需要深入到 web 应用的所有层面，从 HTML，到 SQL，到 PHP。我们旨在提供一个简洁、 实用的概述。
PHP 层面的 UTF-8
基本的字符串操作，如串接 两个字符串、将字符串赋给变量，并不需要任何针对 UTF-8 的特殊东西。 然而，多数 字符串函数，如 strpos() 和 strlen，就需要特殊的考虑。 这些函数都有一个对应的 mb_* 函数：例如，mb_strpos() 和 mb_strlen()。 这些对应的函数统称为多字节字符串函数。 这些多字节字符串函数是专门为操作 Unicode 字符串而设计的。
当你操作 Unicode 字符串时，必须使用 mb_* 函数。 例如，如果你使用 substr() 操作一个 UTF-8 字符串，其结果就很可能包含一些乱码。 正确的函数应该是对应的多字节函数， mb_substr()。
难的是始终记得使用 mb_* 函数。即使你仅一次忘了，你的 Unicode 字符串在接下来的处理中就可能产生乱码。
并不是所有的字符串函数都有一个对应的 mb_*。如果不存在你想要的那一个，那你就只能自认倒霉了。
此外，在每个 PHP 脚本的顶部（或者在全局包含脚本的顶部）你都应使用 mb_internal_encoding 函数，如果你的脚本会输出到浏览器，那么还得紧跟其后加个mb_http_output() 函数。在每个脚本中显式地定义字符串的编码在以后能为你减少很多令人头疼的事情。
最后，许多操作字符串的 PHP 函数都有一个可选参数让你指定字符编码。 若有该选项， 你应始终显式地指明 UTF-8 编码。 例如，htmlentities() 就有一个字符编码方式选项，在处理这样的字符串时应始终指定 UTF-8。
MySQL 层面的 UTF-8
如果你的 PHP 脚本会访问 MySQL，即使你遵从了前述的注意事项，你的字符串也有可能在数据库中存储为非 UTF-8 字符串。
确保从 PHP 到 MySQL 的字符串为 UTF-8 编码的，确保你的数据库以及数据表均设置为 utf8mb4 字符集， 并且在你的数据库中执行任何其他查询之前先执行 MySQL 查询 `set names utf8mb4`。这是至关重要的。 示例请查看连接并查询 MySQL 数据库一节内容。
注意你必须使用 `utf8mb4` 字符集来获得完整的 UTF-8 支持，而不是 `utf8` 字符集！原因请查看进一步阅读。
浏览器层面的 UTF-8
使用 mb_http_output() 函数 来确保你的 PHP 脚本输出 UTF-8 字符串到浏览器。 并且在 HTML 页面的 <head> 标签块中包含 字符集 <meta> 标签块。
示例
处理日期和时间
使用DateTime 类。
在 PHP 糟糕的老时光里，我们必须使用 date()， gmdate()， date_timezone_set()， strtotime()等等令人迷惑的 组合来处理日期和时间。悲哀的是现在你仍旧会找到很多在线教程在讲述这些不易使用的老式函数。
幸运的是，我们正在讨论的 PHP 版本包含友好得多的 DateTime 类。 该类封装了老式日期函数所有功能，甚至更多，在一个易于使用的类中，并且使得时区转换更加容易。 在 PHP 中始终使用 DateTime 类来创建，比较，改变以及展示日期。
示例
陷阱
如果你不指定一个时区，DateTime::__construct() 就会将生成日期的时区设置为正在运行的计算机的时区。之后，这会导致大量令人头疼的事情。 在创建新日期时始终指定 UTC 时区，除非你确实清楚自己在做的事情。
如果你在 DateTime::__construct() 中使用 Unix 时间戳，那么时区将始终设置为 UTC 而不管第二个参数你指定了什么。
向 DateTime::__construct() 传递零值日期（如：“0000-00-00”，常见 MySQL 生成该值作为 DateTime 类型数据列的默认值）会产生一个无意义的日期，而不是“0000-00-00”。
在 32 位系统上使用 DateTime::getTimestamp() 不会产生代表 2038 年之后日期的时间戳。64 位系统则没有问题。
检测一个值是否为 null 或 false
使用 === 操作符来检测 null 和布尔 false 值。
PHP 宽松的类型系统提供了许多不同的方法来检测一个变量的值。 然而这也造成了很多问题。 使用 == 来检测一个值是否为 null 或 false，如果该值实际上是一个空字符串或 0，也会误报为 false。 isset 是检测一个变量是否有值， 而不是检测该值是否为 null 或 false，因此在这里使用是不恰当的。
is_null() 函数能准确地检测一个值是否为 null， is_bool 可以检测一个值是否是布尔值（比如 false）， 但存在一个更好的选择：=== 操作符。=== 检测两个值是否同一， 这不同于 PHP 宽松类型世界里的 相等。它也比 is_null() 和 is_bool() 要快一些，并且有些人认为这比使用函数来做比较更干净些。
示例
陷阱
测试一个返回 0 或布尔 false 的函数的返回值时，如 strpos()，始终使用 === 和!==，否则你就会碰到问题。
end
LeanCloud，领先的 BaaS 提供商，为移动开发提供强有力的后端支持。更多内容请关注「 LeanCloud 通讯」
1208
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
