Edit report at http://bugs.php.net/bug.php?id=49461&edit=1
ID: 49461 Comment by: norman dot albusberger at profiflitzer dot de Reported by: sebastian dot schleussner at angstrom dot uu dot se Summary: parse_ini_file: semicolon in section header Status: Bogus Type: Feature/Change Request Package: *General Issues Operating System: Linux PHP Version: 5.3.0 Block user comment: N Private report: N New Comment: Has anybody a solution for the browscap problem? There is a way if you use the parse_ini_file-function but the browscap.ini (like most other inis) is parsed by php itself on startup of the web server. Is there a way to set params how the inis are parsed? I dont really like to downgrade to php 5.2. because its much faster. Or how do i have to edit the browscap.ini to work with php 5.3? Thank you. Previous Comments: ------------------------------------------------------------------------ [2010-12-21 09:27:11] wangyi6854 at sohu dot com How can I get right result with get_browser()? The function can't take 'INI_SCANNER_RAW' like parameter. ------------------------------------------------------------------------ [2010-12-20 13:27:45] [email protected] See the 3rd (optional) parameter to parse_ini_file(), INI_SCANNER_RAW is used internally for the browscap stuff. ------------------------------------------------------------------------ [2009-09-09 06:45:14] sebastian dot schleussner at angstrom dot uu dot se Just tried the second part of your suggestion, oc3ans. Here's another inconsistency. A *key* with an escaped semicolon is *ignored* in PHP 5.2.10. But in PHP 5.3.0 it causes the parsing to quit silently - it does not fail as with unescaped semicolons in sections, and returns the lines before the "malformed" one, but does not read any further. ------------------------------------------------------------------------ [2009-09-09 06:30:02] sebastian dot schleussner at angstrom dot uu dot se Okay, classification as "bug" may be debatable, and note that I have made this a "Feature/Change Request". At the very least, it is an undocumented and irritating change of functionality. Next, it is a change that breaks normal parsing of the widely used browscaps.ini, which PHP's own get_browser still reads flawlessly. Most importantly, semicolons ARE allowed inside quotes, and I think it is very logical to interpret the square brackets of section titles as quoting, too (as pre-5.3 PHP did). There is no legitimate use of a semicolon *for starting a comment* before the closing square bracket, so there is no reason to interpret it as such. If one wants to add a comment on the title line, one can do so after the closing bracket. As to accepted standards: On the one hand my experience is that there is a lot of variation in the format of INI files, so a parser should be reasonably lenient. On the other hand I have never seen backslash escaping in INI files and I'm not at all sure it is part of any "accepted standard" for them. It only works partly anyway, and inconsistently. Take this file: ;sample3.ini [a\;b];c x=y\;z y="a;b" z="a\;b" and run print_r(parse_ini_file("sample3.ini", true)); You get (PHP 5.2.10 and 5.3.0): Array ( [a\;b] => Array ( [x] => y\ [y] => a;b [z] => a\;b ) ) No bailout, but (a) the backslash remains inside title and quotes, (b) the escaping does not work in values. No good, IMHO. Variable z shows that titles and quoted strings are still considered equally in terms of backslashes, and x demos that unquoted ;'s are always filtered, but while the unescaped ; in y is allowed, it's not in the title in 5.3 -- that's inconsistent and should be reverted. I rest my case. ------------------------------------------------------------------------ [2009-09-09 05:40:48] oc3ans at gmail dot com According to accepted standards of ini files the semicolon is starting a comment that lasts till the end of the line, so IMHO this is not a bug, if you want to include semicolons in the keys or sections you should escape it with a backslash. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49461 -- Edit this bug report at http://bugs.php.net/bug.php?id=49461&edit=1
