【问题标题】：Should I use YAML for Config Files in a PHP Application?我应该在 PHP 应用程序中将 YAML 用于配置文件吗？
【发布时间】：2011-12-08 13:24:04
【问题描述】：

我目前正在编写自己的 PHP 框架（用于踢球，而不是用于关键任务的东西），我正在尝试添加功能，用户可以设置框架应该使用的数据库（主数据库，然后可能一两个后备 - 比如 sqlite），某些文件所在的位置等。我应该为此使用 YAML 吗？有没有更好的方法或标准做法？

我的想法

YAML 在可读性方面对用户（非技术）友好
为了避免我的框架需要非标准 PHP 库，我必须使用类似 Symfony YAML 的东西来解析文件。
Symfony 不是要远离 YAML 了吗？
我可以使用一个包含变量的 PHP 文件，但这会使框架的设置对用户不太透明。

更新

我正在清理这个问题，使其更具建设性，并结合我得到的一些答案。

我的总体问题

与 XML 甚至 INI 文件设置等其他方法相比，YAML 有哪些优势？
关于何时使用 YAML 而不是其他方法或反之亦然，有什么好的经验法则？

【问题讨论】：

如果配置只是一个变量列表（没有嵌套或数组），自己做一个单级YAML解析器不是很容易吗？
为什么不使用简单的ini文件？ PHP为此提供了内置函数。
这让我想起了之前的一个问题：Which is faster XML or INI? - 将“更快”替换为“更好”。

标签： php yaml

【解决方案1】：

使用 json 好主意
用于加载配置文件

"username" : "root" //in json file 

 $json = file_get_contents('path/to/file');
 $data = json_decode($json);
 $data->username; //print root

用于写入配置文件

$data['username'] = 'root';

if (file_put_contents('path/to/file', json_encode($dat))) { echo "<h4 class='alert alert-success'>config updated</h4>"; }

最后一件事如果你在 web root 中使用这个 .htaccess

<IfModule authz_core_module>
Require all denied
</IfModule>
<IfModule !authz_core_module>
Deny from all
</IfModule>

【讨论】：

IF JSON 配置文件 在 public 目录 必须注意正确配置服务器，不要将该特定文件交付给任何可能的攻击者（仅通过请求每个 URL）。基于 PHP 的解决方案在安全性方面可能稍微好一些，因为它不会直接泄露整个配置文件。

【解决方案2】：

我个人的偏好是基于 PHP 的配置文件。

我知道 php，所以对我来说只为配置文件学习 yaml 是额外的工作当你可以有一个像这样的简单配置文件时，本质上它们并不难 yaml，并且不需要特殊的解释器库，只需 include('config.php') 就可以了

$config = array(
  'database' => array(
      'default' => array(
         'name' => 'dbname',
         'host' => 'localhost',
         'user' => 'username',
         'pass' => 'password'
      )
   )
);

那么你可以像这样引用配置设置

$host = $config['database']['default']['host'];

下一步是保持配置文件简单，存储所需的最少配置数据，然后使用数据库存储其余部分，并为最终用户提供管理屏幕以更改应用程序中的设置。

【讨论】：

这是一个非常成熟的传统，它具有优势（您在典型的 Web 中不必特别注意检查访问者，应用程序不会查看配置) 但我一直觉得它鼓励用户在那里进行随机黑客攻击。
addenda：有一个非常完善的函数可以从数组中导出配置：它是var_export()，如果你愿意，你可以使用ob_start() 和ob_end_clean()将其输出重定向到文件。
@ZJR ...或者只是将var_export的第二个参数设置为true，这告诉它返回结果而不是输出结果。

【解决方案3】：

否

个人经历。 YAML 似乎是一个绝妙的主意，我喜欢它和它的简单性。然后我开始在它上面投入时间：能够用一种语言阅读它并用另一种语言写作的相同概念非常诱人，但是...... 简而言之，它变成了只是一种幻觉强>，没有事实证明。

每一种 YAML 的实现都与其他的差别太大。

数组，由一个自动序列化，有时不能被另一个读取。
支持交叉引用，但它们的实现非常粗略。

引用很强大，但是：
- 对于某些核心应用程序而言，它们非常有限。
- 对于大多数基于 YAML 的低端项目而言，它们代表了矫枉过正。
因此，它们经常被大多数解析器忽略，并出错。

总结一下，这个标准还不是很好。

有一些核心概念既好又简单，但实际的标准文档中充满了关于大多数人不想使用并且实施起来困难且昂贵的功能的详细信息。。 p>

没有兼容性级别的区别，就像在 DOM（DOM 级别 1、DOM 级别 2 等）中一样，因此每个解析器实现者都实现了他觉得，在他能承受的范围内，然后放弃它，很难辨别什么有效，什么无效。

使用替代品

JSON 如果您看重跨语言数据交换语言和小冗余 方面为重中之重
INI 如果您重视性能和向后兼容性（在 PHP 上，因为 parse_ini_file() 很快，从那以后......总是）和人类的可读性/可编辑性，而不是。

【讨论】：

我想说的是，像 Spyc 库这样的库在解析 YAML 文件方面做得很好。
没有提到普通的 PHP 数组？当然，它们的性能最好，与 JSON 非常相似，但更灵活，它们允许 cmets 和条件，还允许 PHP 解析器进行适当的语法错误检查。

【解决方案4】：

我对配置文件格式进行了更多研究，并发现了 YAML 格式的有趣事实。

主要是缺点很少

1）它涉及到安装和配置附加PHP库，因为YAML模块默认不来，或者必须与symphony框架解耦并使用它。

2) 与 INI、XML、JSON 相比，读写性能在所有配置技术中最差。与 INI 文件相比，读取时间更长 http://konrness.com/php5/zend_config-benchmark-json-array-ini-xml-yaml/

3) 可读性不好，与 INI 和 XML 格式相比。当它变大时，很难用人性化的眼睛阅读和管理。

4) 与 INI 和 JSON 相比有点笨重。

所以最好使用 INI 格式而不是 YAML。

【讨论】：

【解决方案5】：

如果您正在编写一个框架，那么可以。您最终将不得不自己做更多的工作，但框架的目标是让开发应用程序的人更轻松。

Symfony 不是要远离 YAML 了吗？

不，Symony2 几乎完全由 YAML 配置。

【讨论】：

那么你推荐在这种情况下使用 YAML 吗？允许用户轻松配置应用程序的某些部分，如数据库、文件位置等，？

【解决方案6】：

我通常做的是制作一个 XML 文件并制作一个非依赖前端来修改 XML 文件中的设置。

【讨论】：

在 2011 年，我认为没有理由不在 json 中做同样的事情。（提高可读性，前提是我们缩进它）