1,addslashes
PHP 指令 magic_quotes_gpc 为 on,它主要是对所有的 GET、POST 和 COOKIE 数据自动运行addslashes()。
不要对已经被 magic_quotes_gpc 转义过的字符串使用 addslashes(),因为这样会导致双层转义。
遇到这种情况时可以使用函数 get_magic_quotes_gpc() 进行检测,当接收到的数据需要插入数据库时,
如果magic_quotes_gpc没有开启,需要手动加addslashes函数,(开启的话,一般不需要在处理,因为会自动加addslashes)
因为如果有单引号或双引号,addslashes会自动在前面在加一个转义符号(反斜杠),
这样数据库不会报错,插入到数据库,加入的这个转义符号是不会插入到数据库的。
2,stripslashes
反引用一个引用字符串。
Note:
如果 magic_quotes_sybase 项开启,反斜线将被去除,但是两个反斜线将会被替换成一个。
一个使用范例是使用 PHP 检测 magic_quotes_gpc 配置项的 开启情况(在 PHP 5.4之 前默认是开启的
)并且你不需要将数据插入到一个需要转义的位置(例如数据库)。例如,你只是简单地将表单数据直接输出。
因为你只是输出,不存储到数据库,这样当magic_quotes_gpc开启,会运行addslashes多出一个转义符号,
所以在显示的时候,会多出一个转义符号(上面说了,存入数据库,需要这个转义符号的,防止数据库出错),
因此需要将系统多加的一个给去掉,就用此函数。
下面是关于这两个函数的小例子:( magic_quotes_gpc开启)
$a = '["\u82cf\u5434","abck","\u4e91\u7aef"]';
$a = addslashes($a);
if(get_magic_quotes_gpc()) {
$a = stripslashes($a);
}
$a = json_decode($a);
var_dump($a);
下面手动加的:( magic_quotes_gpc开启)
$a =[\"\\u82cf\\u5434\",\"abck\",\"\\u4e91\\u7aef\"]
//$a = addslashes($a);
if(get_magic_quotes_gpc()) {
$a = stripslashes($a);
}
$a = json_decode($a);
var_dump($a);
第一个是调用函数加的,第二个是手动加的 第一个可以正确解出,第二个却不行(一个反斜杠都没有了),
自己分析可能是: 通过addslashes加的 \ 应该是不被PHP当成转义符号,
如果自己加的PHP会当成转义符号来处理,[\"\\u82cf\\u5434\",\"abck\",\"\\u4e91\\u7aef\"]
这样自己加的在用stripslashes是不行的(PHP把第一个当成转义符号,其实也就一个\了);
但出现一个问题,是我遇到的,我这边post接收一个json_encode中文的数据,unicode编码了,格式如上\uxxx\uxxxx这种,magic_quotes_gpc开启的,系统会自动加addslashes,接收到的数据应该变成类似(\\uxxxx\\uxxxx),但我用stripslashes去除,却把现在反斜杠都去掉了,变成了(uxxxxuxxxx),导致json_decode不出来, 不经过striptslashes就OK了,这点想不通,难到striptslashes会去掉两个? 不对啊,为什么呢? 难到对于接收到的数据,服务器自动加的也会被当成转义符号?不明白,希望有明白的高人,给指点下!
3,mysql_real_escape_string
mysql_real_escape_string — 转义 SQL 语句中使用的字符串中的特殊字符,并考虑到连接的当前字符集
$unescaped_string
[,
resource $link_identifier
] )
本函数将 unescaped_string
中的特殊字符转义,并计及连接的当前字符集,因此可以安全用于 mysql_query()。
Note: mysql_real_escape_string() 并不转义 % 和 _。
Example #1 mysql_real_escape_string() 例子
<?php
$item = "Zak's and Derick's Laptop";
$escaped_item = mysql_real_escape_string($item);
printf ("Escaped string: %s\n", $escaped_item);
?>
以上例子将产生如下输出:
Escaped string: Zak\'s and Derick\'s Laptop
上面是我直接复制官网手册了,没有细用过,不太了解,应该和addslashes一样的功能。
4,htmlspecialchars
htmlspecialchars() 函数把一些预定义的字符转换为 HTML 实体
预定义的字符是:
第二个参数是:
ENT_COMPAT - 默认。仅编码双引号。
ENT_QUOTES - 编码双引号和单引号。
ENT_NOQUOTES - 不编码任何引号。
转变成实体,实体就是& "等,这样的形式,浏览器是解析显示出来,并不会执行它,<a>
像这样的是html语言,浏览器会执行它,所以才会看到a连接,p样式的效果,但实体,是没有只用于显示的,
显示的时候,防止有人在html带js 如果有人提交<script>alert(1)<\script>,只会显示,不会执行。
5,urldecode
在php中urldecode和urlencode是一对双胞胎,如果在url中包含了中文,urlencode函数属于必用的。为什么呢? 因为中文有很多编码,简体主要有gb2312和utf-8这两种,其中主流的浏览器都默认是utf-8编码的。所以在url包含了汉字时,浏览器会把汉字作为utf-8编码发送(部分浏览器为解决字符集问题会做urlencode功能相同的编码),而大部分的php服务端也都采用utf-8,这样就不会出现乱码问题。可像ie6这样的老家伙,总是喜欢使用gb2312进行传送,这样到了服务器端接收就成了乱码。为了保证我们程序的可靠性,对url中的中文部分进行urlencode是一直良好的习惯! 可能使用urlencode习惯了,在接收参数的时候我们也习惯用urldecode进行解码,因为他们本来就是一对吗?岂不知这样就带来了一个安全隐患。经过查询php手册得知,对于编码后的字符串发送到服务器端,php总是会自动进行解码,而我们再使用urldecode函数就是进行了二次解码,虽然这个没问题,但是带来了安全隐患。 比如编码后的字符串%2527提交到后台,php首先进行一次自动解码,%25编码后是%,因此我们收到的字符串是%27,而如果这时我们调用了urldecode的话,会再次进行解码,%27变为’,这样就成功了躲过了我们过滤系统,而这样的注入目前还没有几个程序的脚本可以检测到。 所以说,我们多次一举还带来了安全隐患,当你看到这个文章的时候,urldecode是废弃的时候了!
注:发现了点意外,有的服务器并不对urlencode后的编码自动解码,而文中提到“对于编码后的字符串发送到服务器端,php总是会自动进行解码”,猜测至少是5.3以上版本才会这样。但这不影响urldecode是一个危险的函数,目前发现多例因此函数而出错的sql注入绕过.
以上是自己的经验和理解,在加上网上的一些资料。 可能有误区,希望指出!