php中函数有几个部分构成,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多出一个转义符号，

所以在显示的时候，会多出一个转义符号(上面说了，存入数据库，需要这个转义符号的，防止数据库出错)，

因此需要将系统多加的一个给去掉，就用此函数。

下面是关于这两个函数的小例子：(

$a = '["\u82cf\u5434","abck","\u4e91\u7aef"]';

$a = addslashes($a);

if(get_magic_quotes_gpc()) {

$a = stripslashes($a);

}

$a = json_decode($a);

var_dump($a);

$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这种，

3,mysql_real_escape_string

mysql_real_escape_string — 转义 SQL 语句中使用的字符串中的特殊字符，并考虑到连接的当前字符集

说明¶

string

mysql_real_escape_string (

string $unescaped_string [,

resource $link_identifier ] )

本函数将 unescaped_string 中的特殊字符转义，并计及连接的当前字符集，因此可以安全用于

Note: mysql_real_escape_string() 并不转义 % 和 _。

Example #1 mysql_real_escape_string() 例子

$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 - 不编码任何引号。

转变成实体，实体就是& &quot等，这样的形式，浏览器是解析显示出来，并不会执行它，

像这样的是html语言，浏览器会执行它，所以才会看到a连接，p样式的效果，但实体，是没有只用于显示的，

显示的时候，防止有人在html带js 如果有人提交

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注入绕过.

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