php 几个函数理解

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 语句中使用的字符串中的特殊字符，并考虑到连接的当前字符集

说明 ¶

string  mysql_real_escape_string (  string $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 实体

预定义的字符是：

• & （和号） 成为 &
• " （双引号） 成为 "
• ' （单引号） 成为 '
• < （小于） 成为 &lt;
• > （大于） 成为 &gt;

第二个参数是：

ENT_COMPAT - 默认。仅编码双引号。

ENT_QUOTES - 编码双引号和单引号。

ENT_NOQUOTES - 不编码任何引号。

转变成实体，实体就是&amp; &quot等，这样的形式，浏览器是解析显示出来，并不会执行它，<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注入绕过.

以上是自己的经验和理解，在加上网上的一些资料。 可能有误区，希望指出！