my_config.ini 与 my_config.php

StackOverflow https://stackoverflow.com/questions/823352

  •  05-07-2019
  •  | 
  •  

题

在工作中，我们使用 .ini 文件在调用框架的其余部分之前设置变量（我认为它是

function getConfigVars(){
    //read my_config.ini file
    ....
    //call framework
}

我一直想知道这样做是否有好处。

在我看来，你必须编写访问规则来阻止人们从网络上查看它，并且 php 必须解析它并理解它。

那么，为什么使用 my_config.ini 而不是 my_config.php？它不像任何人都应该在设置后触摸它，而且似乎更方便的是，只要调用变量，并且无论您在哪里使用 ini 变量/解析它的错误，都可以让您的 IDE 自动完成文本。

有帮助吗？

解决方案

Zend Framework 包含一个配置解析，用于解析以ini格式写入的文件（ Zend_Config_Ini ），听起来这就是你正在使用的。

配置文件不应该位于文档根目录中，如果它不在您的文档根目录中，则不需要重写规则，因为无论如何都没有人可以访问它。

  

INI格式专门用于提供配置数据键层次结构和配置数据段之间的继承。通过用点或句点字符（。）分隔键来支持配置数据层次结构。部分可以通过使用冒号字符（:)跟随部分名称以及要从中继承数据的部分的名称来扩展或继承其他部分。

来自 Zend_Config_Ini 页面。

Zend Framework使用它来允许您拥有多个配置参数，一个用于分段，一个用于开发，一个用于生产。这也允许轻松设置生产和开发的数据库设置，并具有两个非常不同的设置。在ini文件中设置的不同路径位于包含的位置。这使得将代码从开发转移到生产变得更加容易，因为知道开发的所有内容都将立即关闭。

当然，这可以通过PHP脚本实现，但是需要更多地解析各种配置变量以及if / then检查，而使用parse_ini_file（）会自动为您完成所有这些。

其他答案也已经指出，非程序员可能需要更改设置为配置变量的网站上的变量和/或某些内容（例如，站点布局中使用的站点标题）。 INI文件易于理解和阅读，即使对于之前从未编程的人也是如此。

我目前正在处理的网站示例：

[production]
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0
includePaths.library = APPLICATION_PATH "/../library"
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
bootstrap.class = "Bootstrap"
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"
resources.layout.layoutPath = APPLICATION_PATH "/layouts/scripts"
resources.db.adapter       = "PDO_SQLITE"
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users.db"

resources.view[] =

[staging : production]

[testing : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users-testing.db"

[development : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users-dev.db

这使得为代码可以运行的各种环境提供多个数据集非常容易。

其他提示

对于那些提出这个问题的人，因为他们想知道在使用必须解析的INI文件和简单包含的PHP文件（并且可以通过PHP缓存）之间是否存在任何性能差异：是的，那里是差异，但它们是如此之小，以至于它并不重要。

我的基准测试场景是一个带有20个键/值对的config.ini文件和一个config.php文件，其中包含与定义相同的20个键/值对。在Ubuntu Linux 13.04上PHP版本是5.4.9。

key1 = value1
...
key20 = value20

VS 

<?php
define("key1", "value1");
...
define("key2", "value20");

两个测试脚本，包括配置：

<?php
$CONF = parse_ini_file("config.ini");

VS 

<?php
require_once "config.php";

我用ab -c 25 -n 10000测试了性能。

没有PHP缓存的结果：

ini: Requests per second:    2660.89 [#/sec] (mean)
php: Requests per second:    2642.28 [#/sec] (mean)

APC PHP缓存的结果：

ini: Requests per second:    3294.47 [#/sec] (mean)
php: Requests per second:    3307.89 [#/sec] (mean)

我多次运行测试，自然数字每次都会有所不同，但共识是：<=>在没有使用PHP缓存时稍快一点，<=>在PHP缓存时更快一点用过的。但差异很小，决定不应以绩效为基础。

可以肯定的是，你的问题提出了一个公平的观点。

有几点赞成 .ini 文件：

  • 使用另一种语言的文件. 。如果您想拥有 Perl、Python、Ruby 等。脚本执行的操作对于该语言来说特别容易，并且需要访问项目设置，如果您将设置存储在 PHP 文件中，那么您将不走运。

  • 人工编辑数据. 。尽管您在问题中驳回了它，无论有意与否，很可能有人最终会介入其中，而且可能不是技术人员。INI 格式比 PHP 代码要简单得多，即使它只是一堆变量声明

  • 更新设置. 。我认为创建一个新的 INI 文件比编写一个 PHP 文件要容易得多。然而，这是相当主观的，但值得一提。

  • 设置变量之间的关系. 。使用 INI 文件为您的设置提供层次结构是相当简单/直观的。虽然这在 PHP 中也是可能的，但它并不那么整洁，并且如果您尝试使用深度嵌套的关联数组来存储信息，可能会变得难看。

除此之外，在大多数情况下，“必须保护其免受 Web 访问”对 INI 的敲击并不相关，因为大多数 PHP 项目（至少是我参与的项目）都在远离根目录的地方保存了大量代码文件夹，设置通常就在那里。

非程序员修改配置变量可能更容易......如果您的工作场所需要这样做。

我发现<?php和?>的小心放置可以阻止它显示，而parse_ini_file（）仍然会从文件中获取相关数据。

保护它的最佳方法是将其置于docroot之上，并拒绝在服务器设置中访问* .ini。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top