原文地址:http://www.cnblogs.com/melonblog/archive/2013/05/09/3062303.html

原文作者:豆浆油条 - melon

本文示例代码测试环境是Windows下的APMServ(PHP5.2.6)

简述

可能大家都知道,php中有一个函数叫debug_backtrace,它可以回溯跟踪函数的调用信息,可以说是一个调试利器。

好,来复习一下。

one();

function one() {
two();
} function two() {
three();
} function three() {
print_r( debug_backtrace() );
} /*
输出:
Array
(
[0] => Array
(
[file] => D:\apmserv\www\htdocs\test\debug\index.php
[line] => 10
[function] => three
[args] => Array
(
) ) [1] => Array
(
[file] => D:\apmserv\www\htdocs\test\debug\index.php
[line] => 6
[function] => two
[args] => Array
(
) ) [2] => Array
(
[file] => D:\apmserv\www\htdocs\test\debug\index.php
[line] => 3
[function] => one
[args] => Array
(
) ) )
*/

顺便提一下类似的函数:debug_print_backtrace,与之不同的是它会直接打印回溯信息。

回来看debug_backtrace,从名字来看用途很明确,是让开发者用来调试的。直到有一天我注意到它返回的file参数,file表示函数或者方法的调用脚本来源(在哪个脚本文件使用的)。忽然我想到,如果当前脚本知道调用来源,那是否可以根据这个来源的不同,来实现一些有趣的功能,比如文件权限管理、动态加载等。

实战

实现魔术函数

获取当前函数或方法的名称

尽管PHP中已经有了__FUNCTION____METHOD__魔术常量,但我还是想介绍一下用debug_backtrace获取当前函数或者方法名称的方法。

代码如下:

//函数外部输出getFuncName的值
echo getFuncName(); printFuncName(); Object::printMethodName(); //调用了上面两个函数后,再次在外部输出getFuncName,看看是否有‘缓存’之类的问题
echo getFuncName(); function printFuncName() {
echo getFuncName();
} class Object {
static function printMethodName() {
echo getFuncName();
}
} /**
* 获取当前函数或者方法的名称
* 函数名叫getFuncName,好吧,其实method也可以当做function,实在想不出好名字
*
* @return string name
*/
function getFuncName() {
$debug_backtrace = debug_backtrace();
//如果函数名是以下几个,表示载入了脚本,并在函数外部调用了getFuncName
//这种情况应该返回空
$ignore = array(
'include',
'include_once',
'require',
'require_once'
);
//第一个backtrace就是当前函数getFuncName,再上一个(第二个)backtrace就是调用getFuncName的函数了
$handle_func = $debug_backtrace[1];
if( isset( $handle_func['function'] ) && !in_array( $handle_func['function'], $ignore ) ) {
return $handle_func['function'];
}
return null;
} //输出:
//null
//printFuncName
//printMethodName
//null

看上去没有问题,很好。

加载相对路径文件

如果在项目中要加载相对路径的文件,必需使用include或者require之类的原生方法,但现在有了debug_backtrace,我可以使用自定义函数去加载相对路径文件。

新建一个项目,目录结构如下:

我想在index.php中调用自定义函数,并使用相对路径去载入package/package.php,并且在package.php中使用同样的方法载入_inc_func.php 

三个文件的代码如下(留意index.phppackage.php调用import函数的代码):

index.php:

<?php

import( './package/package.php' );

/**
* 加载当前项目下的文件
*
* @param string $path 相对文件路径
*/
function import( $path ) {
//获得backstrace列表
$debug_backtrace = debug_backtrace();
//第一个backstrace就是调用import的来源脚本
$source = $debug_backtrace[0]; //得到调用源的目录路径,和文件路径结合,就可以算出完整路径
$source_dir = dirname( $source['file'] );
require realpath( $source_dir . '/' . $path );
} ?>

package.php:

<?php

echo 'package';

import( './_inc_func.php' );

?>

_inc_func.php:

<?php

echo '_inc_func';

?>

运行index.php

//输出:
//package
//_inc_func

可以看到,我成功了。

思考:这个方法我觉得非常强大,除了相对路径之外,可以根据这个思路引伸出相对包、相对模块之类的抽象特性,对于一些项目来说可以增强模块化的作用。

管理文件调用权限

我约定一个规范:文件名前带下划线的只能被当前目录的文件调用,也就是说这种文件属于当前目录‘私有’,其它目录的文件不允许载入它们。

这样做的目的很明确:为了降低代码耦合性。在项目中,很多时候一些文件只被用在特定的脚本中。但是经常发生的事情是:一些程序员发现这些脚本有自己需要用到的函数或者类,因此直接载入它来达到自己的目的。这样的做法很不好,原本这些脚本编写的目的仅仅为了辅助某些接口实现,它们并没有考虑到其它通用性。万一接口内部需要重构,同样需要改动这些特定的脚本文件,但是改动后一些看似与这个接口无关脚本却突然无法运行了。一经检查,却发现文件的引用错综复杂。

规范只是监督作用,不排除有人为了一己私欲而违反这个规范,或者无意中违反了。最好的方法是落实到代码中,让程序自动去检测这种情况。

新建一个项目,目录结构如下。

那么对于这个项目来说,_inc_func.php属于package目录的私有文件,只有package.php可以载入它,而index.php则没有这个权限。

package目录是一个包,package.php下提供了这个包的接口,同时_inc_func.phppackage.php需要用到的一些函数。index.php将会使用这个包的接口文件,也就是package.php

它们的代码如下

index.php:

<?php

header("Content-type: text/html; charset=utf-8");

//定义项目根目录
define( 'APP_PATH', dirname( __FILE__ ) ); import( APP_PATH . '/package/package.php' );
//输出包的信息
Package_printInfo(); /**
* 加载当前项目下的文件
*
* @param string $path 文件路径
*/
function import( $path ) { //应该检查路径的合法性
$real_path = realpath( $path );
$in_app = ( stripos( $real_path, APP_PATH ) === 0 );
if( empty( $real_path ) || !$in_app ) {
throw new Exception( '文件路径不存在或不被允许' );
} include $real_path;
} ?>

_inc_func.php:

<?php

function _Package_PrintStr( $string ) {
echo $string;
} ?>

package.php:

<?php

define( 'PACKAGE_PATH', dirname( __FILE__ ) );

//引入私有文件
import( PACKAGE_PATH . '/_inc_func.php' ); function Package_printInfo() {
_Package_PrintStr( '我是一个包。' );
} ?>

运行index.php:

//输出:
//我是一个包。

整个项目使用了import函数载入文件,并且代码看起来是正常的。但是我可以在index.php中载入package/_inc_func.php文件,并调用它的方法。

index.php中更改import( APP_PATH . '/package/package.php' );处的代码,并运行:

import( APP_PATH . '/package/_inc_func.php' );

_Package_PrintStr( '我载入了/package/_inc_func.php脚本' );

//输出:
//我载入了/package/_inc_func.php脚本

那么,这时可以使用debug_backtrace检查载入_inc_func.php文件的路径来自哪里,我改动了index.php中的import函数,完整代码如下:

/**
* 加载当前项目下的文件
*
* @param string $path 文件路径
*/
function import( $path ) { //首先应该检查路径的合法性
$real_path = realpath( $path );
$in_app = ( stripos( $real_path, APP_PATH ) === 0 );
if( empty( $real_path ) || !$in_app ) {
throw new Exception( '文件路径不存在或不被允许' );
} $path_info = pathinfo( $real_path );
//判断文件是否属于私有
$is_private = ( substr( $path_info['basename'], 0, 1 ) === '_' );
if( $is_private ) {
//获得backstrace列表
$debug_backtrace = debug_backtrace();
//第一个backstrace就是调用import的来源脚本
$source = $debug_backtrace[0]; //得到调用源路径,用它来和目标路径进行比较
$source_dir = dirname( $source['file'] );
$target_dir = $path_info['dirname'];
//不在同一目录下时抛出异常
if( $source_dir !== $target_dir ) {
$relative_source_file = str_replace( APP_PATH, '', $source['file'] );
$relative_target_file = str_replace( APP_PATH, '', $real_path );
$error = $relative_target_file . '文件属于私有文件,' . $relative_source_file . '不能载入它。';
throw new Exception( $error );
}
} include $real_path;
}

这时再运行index.php,将产生一个致命错误:

//输出:
//致命错误:/package/_inc_func.php文件属于私有文件,/index.php不能载入它。

而载入package.php则没有问题,这里不进行演示。

可以看到,我当初的想法成功了。尽管这样,在载入package.php后,其实在index.php中仍然还可以调用_inc_func.php的函数(package.php载入了它)。因为除了匿名函数,其它函数是全局可见的,包括类。不过这样或多或少可以让程序员警觉起来。关键还是看程序员本身,再好的规范和约束也抵挡不住烂程序员,他们总是会比你‘聪明’。

debug_backtrace的'BUG'

如果使用call_user_func或者call_user_func_array调用其它函数,它们调用的函数里面使用debug_backtrace,将获取不到路径的信息。

例:

call_user_func('import');

function import() {
print_r( debug_backtrace() );
} /*
输出:
Array
(
[0] => Array
(
[function] => import
[args] => Array
(
) ) [1] => Array
(
[file] => F:\www\test\test\index.php
[line] => 3
[function] => call_user_func
[args] => Array
(
[0] => import
) ) )
*/

注意输出的第一个backtrace,它的调用源路径file没有了,这样一来我之前的几个例子将会产生问题。当然可能你注意到第二个backtrace,如果第一个没有就往回找。但经过实践是不可行的,之前我就碰到这种情况,同样会有问题,但是现在无法找回那时的代码了,如果你发现,请将问题告诉我。就目前来说,最好不要使用这种方法,我有一个更好的解决办法,就是使用PHP的反射API。

使用反射

使用反射API可以知道函数很详细的信息,当然包括它声明的文件和所处行数

call_user_func('import');

function import() {
$debug_backtrace = debug_backtrace();
$backtrace = $debug_backtrace[0];
if( !isset( $backtrace['file'] ) ) {
//使用反射API获取函数声明的文件和行数
$reflection_function = new ReflectionFunction( $backtrace['function'] );
$backtrace['file'] = $reflection_function->getFileName();
$backtrace['line'] = $reflection_function->getStartLine();
}
print_r($backtrace);
} /*
输出:
Array
(
[function] => import
[args] => Array
(
) [file] => F:\www\test\test\index.php
[line] => 5
)
*/

可以看到通过使用反射接口ReflectionMethod的方法file又回来了。

类方法的反射接口是ReflectionMethod,获取声明方法同样是getFileName

总结

在一个项目中,我通常不会直接使用include或者require载入脚本。我喜欢把它们封装到一个函数里,需要载入脚本的时候调用这个函数。这样可以在函数里做一些判断,比如说是否引入过这个文件,或者增加一些调用规则等,维护起来比较方便。

幸好有了这样的习惯,所以我可以马上把debug_backtrace的一些想法应用到整个项目中。

总体来说debug_backtrace有很好的灵活性,只要稍加利用,可以实现一些有趣的功能。但同时我发现它并不是很好控制,因为每次调用任何一个方法或函数,都有可能改变它的值。如果要使用它来做一些逻辑处理(比如说我本文提到的一些想法),需要一个拥有良好规范准则的系统,至少在加载文件方面吧。

(转)利用PHP的debug_backtrace函数,实现PHP文件权限管理、动态加载 【反射】的更多相关文章

  1. 动态加载JS函数

    一般性的,当我们需要加载js文件的时候都会使用script标签来实现,类似于如下代码: 代码如下: <script type="text/javascript" src=&q ...

  2. 利用PHP的debug_backtrace函数,实现PHP文件权限管理、动态加载

    简述 可能大家都知道,php中有一个函数叫debug_backtrace,它可以回溯跟踪函数的调用信息,可以说是一个调试利器. 好,来复习一下 01 one(); 02 03 function one ...

  3. 利用Jquery的load函数实现页面的动态加载

    利用Jquery的load函数实现页面的动态加载  js的强大功能相信大家都知晓,今天通过jquery的库函数load可以更加方便的实现页面的动态刷新,经过几天的研究与探索,终于有所成效!吾心甚蔚! ...

  4. 利用javascript动态加载头部出现点击事件与hover事件无效解决方法

    这里是利用es6的promise函数来异步加载,当HTML动态加载过去的HTML片段加载完毕再执行绑定事件的js代码: 具体过程如下 这里是用了jQuery框架的例子 $(function(){ // ...

  5. 动态加载JS文件,并根据JS文件的加载状态来执行自己的回调函数

    动态加载JS文件,并根据JS文件的加载状态来执行自己的回调函数, 在很多场景下,我们需要在动态加载JS文件的时候,根据加载的状态来进行后续的操作,需要在JS加载成功后,执行另一方法,这个方法是依托在加 ...

  6. Cortex-M3动态加载三(模块调用系统函数)

    在我的arm动态加载实验中需要解决一个模块调用系统函数的问题,可以使用以下的一个方法.将系统函数固定在某一段地址空间,然后导出这一块的符号表到符号文件中,要记载的模块link的时候使用这个符号表文件, ...

  7. C# 利用反射动态加载dll

    笔者遇到的一个问题,dll文件在客户端可以加载成功,在web端引用程序报错.解决方法:利用反射动态加载dll 头部引用加: using System.Reflection; 主要代码: Assembl ...

  8. 微信小程序(五) 利用模板动态加载数据

    利用模板动态加载数据,其实是对上一节静态数据替换成动态数据:

  9. Unity 利用UGUI打包图集,动态加载sprite资源

    今天做了一个UI界面,这个界面是好友界面,该界面上有若干个好友item. 需要对每个tem的头像对象(image)动态显示对应的头像.尝试利用UGUI的图集来加载,具体实现如下: 1.首先,需要知道S ...

随机推荐

  1. CALL TRANSACTION

    概要 SUBMITと違い.トランザクションコードで呼び出すのが特徴. アドオンからの伝票照会やバッチインプットによるSAPへのデータ登録/更新処理にも利用される. なお.呼び出された側から呼び出し元へ ...

  2. DotNetty学习笔记

    DotNetty项目本身的示例很容易运行起来,但是具体到真实的应用场景,还是需要进一步理解DotNetty的通道处理细节,这样才能够在实际项目应用中处理具体的问题. 简单的场景下会有以下几个问题,第一 ...

  3. Linux入门进阶第一天——vim文本编辑器

    一.VI / VIM概述 [更新]:VIM资料参见:http://www.runoob.com/linux/linux-vim.html 是什么? 是一个文本编辑器. Vim是从 vi 发展出来的一个 ...

  4. 20155212 2016-2017-2 《Java程序设计》第1周学习总结

    20155212 2016-2017-2 <Java程序设计>第1周学习总结 教材学习内容总结 Chapter 1 Java平台概论 Java一开始就是为了有着有限内存与运算资源的消费型数 ...

  5. 20155234 2016-2017-2 《Java程序设计》第3 周学习总结

    20155234 2006-2007-2 <Java程序设计>第3周学习总结 教材学习内容总结 类是对象的设计图,对象是类的实例. 参考名称与对象数据成员同名时,可以在数据成员前使用thi ...

  6. 20155328 2016-2017-2 《Java程序设计》第三周学习总结

    20155328 2016-2017-2 <Java程序设计>第三周学习总结 教材学习内容总结 类是对象的设计图,对象是类的实例.用class定义类,用new新建一个对象. 一个原始码中可 ...

  7. 20145234黄斐《网络对抗技术》实验五,MSF基础应用

    MSF的六种模块 渗透攻击模块(Exploit Modules)渗透攻击是指由攻击者或渗透测试者利用一个系统.应用或服务中的==安全漏洞==,所进行的攻击行为. 辅助模块(Auxiliary Modu ...

  8. 解读python手册的例子a, b = b, a+b

    Python手册上有个例子,用于输出10以内的斐波那契序列.代码如下: a, b = 0, 1 while b < 10: print(b) a, b = b, a+b 用到了一些Python的 ...

  9. macOS 10.14 Mojave Apache设置:多个PHP版本

    [18/6/2018更新]由于Homebrew/php点击在2018年3月底被弃用,并将所有PHP公式移动到Homebrew/core,我们已经重新设计了我们的指南,使用这个新的水龙头. 如果您过去一 ...

  10. python学习-linux基本操作

    1.sudo 管理员root身份 2.mkdir 创建文件夹   touch 创建文件 3.rm 删除 4.chmod 赋予权限 r(读取):4 w(写):2 x(执行):1 rwx=7,r-x=5等 ...