Atitit 防注入 sql参数编码法
目录
1.2. 提升可读性pg_escape_literal — 转义文字以插入文本字段 1
1.3. 推荐pg_escape_string() 转义 text/char 数据类型的字符串 2
1.4. 2. mysql_real_escape_string() (推荐指数4) 2
预先处理法固然好，但是毕竟麻烦，调试不方便
-
-
-
- Escaping
-
-
通过使用mysqli 扩展，你可以利用 mysqli_real_escape_string() 函数来 escape包含在 SQL 查询中的所有数据。PostgresSQL 的 pgsql 扩展提供 pg_escape_bytea()、 pg_escape_identifier()、 pg_escape_literal() 和 pg_escape_string() 函数
基于以上原因，并不推荐使用 escaping。它可以用来救急，如果你用来抽象的数据库程序库不强制参数绑定就能进行 SQL 查询，可能就需要使用它。否则你应该避免使用 escape。它很混乱，容易出错，而且因数据库扩展不同而存在差异。
缺点，必须要conn才可。。
pg_escape_literal — 转义文字以插入文本字段
pg_escape_literal （[ resource $connection ]， string $data ）：字符串
pg_escape_literal（）转义用于查询PostgreSQL数据库的文字。它以PostgreSQL格式返回转义文字。pg_escape_literal（）在数据前后添加引号。用户不应添加引号。建议使用此函数而不是 pg_escape_string（）。如果列的类型是bytea，则必须改用pg_escape_bytea（）。对于转义标识符（例如表，字段名称），必须使用 pg_escape_identifier（）。
pg_escape_string ( string $data ) : string
pg_escape_string() 转义 text/char 数据类型的字符串，返回转义后的字符串。建议用此函数替代 addslashes()。
Note:
本函数需要 PostgreSQL 7.2 或以上版本。
由于addslashes()不检测字符集，所以有宽字节注入风险，所以php中添加了这个函数。
这个函数本来是mysql的扩展，但是由于存在宽字节的问题，php基于mysql的扩展开发了此函数。
gbk宽字符漏洞导致的sql注入
https://www.91ri.org/8611.html
http://www.cnblogs.com/suihui...
mysql_real_escape_chars()是mysql_escape_chars()的替代用法。
与addslashes()相比，不仅会将' " NOL(ascii的0)转义，还会把r n进行转义。同时会检测数据编码。
按php官方的描述，此函数可以安全的用于mysql。
此函数在使用时会使用于数据库连接(因为要检测字符集)，并根据不同的字符集做不同的操作。如果当前连接不存在，刚会使用上一次的连接。
mysql_real_escape_string()防注入详解
此方法在php5.5后不被建议使用，在php7中废除。
参考：https://segmentfault.com/q/10...
- 在防注入方面，addslashes()可以防止掉大多数的注入，但是此函数并不会检查变量的编码，当使用例如中文gbk的时候，由于长度比较长，会将某些gbk编码解释成两 .
addslashes()与stripslashes()是功能相反的函数。
addslashes()用于对变量中的' " 和NULL添加斜杠，用于避免传入sql语句的参数格式错误，同时如果有人注入子查询，通过加可以将参数解释为内容，而非执行语句，避免被mysql执行。
不过，addslashes()添加的只在php中使用，并不会写入mysql中。
那么，tripslashes()的作用是将加了的php变量去掉，由于不会写入mysql中，所以从mysql查询出来的内容不需要再tripslashes()。
在防注入方面，addslashes()可以防止掉大多数的注入，但是此函数并不会检查变量的编码，当使用例如中文gbk的时候，由于长度比较长 ，会将某些gbk编码解释成两个ascii编码，造成新的注入风险(俗称宽字节注入)。见下面2。
如果从网页表单、php、mysql都使用utf8编码，则没有这个问题。
基于此函数的风险，并不建议使用，推荐使用下面3中的方法。
PostgreSQL 函数 « PHP Manual _ PHP 中文手册.html