引言
为了把配置参数独立出来,用以区分开发环境,线上环境等功能, 或者手动切换缓存的驱动,队列的驱动,邮件服务器地址,等等等等, 这些可以方便地标记。所以laravel使用 .env 文件包裹这些配置数据,也就是键值对。
学习时间
一般情况下,我们不允许修改env文件的内容,除非手动处理。可是在编程中难免遇到非修改不可的情况, 那么又该如何动态地操作env文件内的键值对呢?
假设对于系统使用 key:generate 生成的 APP_KEY 不安全,在做自动化部署,批量部署时有动态修改 APP_KEY 这个键的需求。该怎么来实现呢?
其实,env文件不过是一个文本文件,遵循 key=value 这样的标准格式进行书写,全程使用字符串匹配, 单行直到换行符停止。
那么修改 env 文件内容,无非就是找到相关的键,然后将值替换掉,如此而已。
下面给出第一个版本,也就是简单粗暴的 file_put_contents,先获取env文件的路径:
$path = base_path('.env');
需要判断文件是否存在:
if (file_exists($path)){
// 文件存在
}
文件存在则先读出文件的所有内容到一个 字符串 变量内:
$origin = file_get_contents($path);
假设我们的新 APP_KEY 存在变量 $new_key 内,首先获取原始的 APP_KEY的值:
$old_key = env('APP_KEY');
字符串操作当然要使用字符串替换函数直接匹配,我们使用 str_replace,env文件的数据量毕竟不大, 这么也也没有太大性能的问题。
$result = str_replace('APP_KEY=' . $old_key, $new_key, $origin);
这样$result内存储的就是最新的env文件的值,接下来写入env文件就行了:
file_put_contents($result);
默认是覆写,所以执行完程序,env文件就是最新的动态修改的数据了。
深入一步
上面的代码还是有瑕疵的,因为对于错误故障处理基本上没有,这很容易造成错误。 另外对于env这么重要的文件操作,直接使用字符串替换,整个文件的读和覆写, 本身的风险就非常高。
如何改造我们的操作方式,使其更为安全呢?我们需要兼容性更好的代码。本节我们尝试使用正则匹配的方式, 来解析env文件,并逐行读取,逐行操作,逐行判断, 对于存在的键值,进行覆盖;对于不存在的,则进行创建。 这样就可以兼容新建和更新两种功能,且支持的键值更为灵活。
封装为助手函数,假设传入的参数为数组,且是关联数组。声明函数如下:
function updateEnv($data = array()){}
函数体内书写逻辑,首先非空判断:
if (! count($data)) {return;}
如果不是关联数组,也同样不接受,因为env文件必须明确指定键和值。 关联数组只用判断数组的键与自动序列化的键不同即可:
if (array_keys($data) === range(0, count($data) - 1)) {return;}
准备匹配模式:
$pattern = '/([^\=]*)\=[^\n]*/';
这就是env文件书写的格式。上一节我们已经介绍过了。我们把旧的env文件读入一个数组,并声明新的数组,存储最新的配置文件数据:
$envFile = base_path() . '/.env';
$lines = file($envFile);
$newLines = [];
然后遍历旧的文件数据,逐行解析:
foreach ($lines as $line) {
preg_match($pattern, $line, $matches);
if (!count($matches)) {
$newLines[] = $line;
continue;
}
if (!key_exists( trim ($matches[1]), $data)) {
$newLines[] = $line;
continue;
}
$line = trim($matches[1]) . "={$data[trim($matches[1])]}\n";
$newLines[] = $line;
}
上面只是一个大致的处理流程,这个解析过程,你可以独立为自定义函数,或者其他解析引擎,具有通用性。
最后把解析完的新数据,完整写入env文件内:
$newContent = implode('', $newLines);
file_put_contents($envFile, $newContent);
至此,env文件的更新操作就完成了。
写在最后
本文通过两种方式实现了在程序内动态创建和更新env全局配置文件文件数据的功能, 第二种方法容错性更好,具有通用性,扩展性强,所以我们推荐。 第一种做法没有错误处理,生产环境下几乎不能用。大家知道思路就好了。
Happy coding 🙂
相关文章
本站已关闭游客评论,请登录或者注册后再评论吧~