Bug #55413 [Com]: str_getcsv doesnt remove escape characters
Edit report at https://bugs.php.net/bug.php?id=55413edit=1 ID: 55413 Comment by: spidgorny at gmail dot com Reported by:mathielen at gmail dot com Summary:str_getcsv doesnt remove escape characters Status: Open Type: Bug Package:Strings related Operating System: ubuntu 11.04 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: 5.3.10 is affected too. A bug in a primitive function like this after years of evolution should be embarrassing. Previous Comments: [2012-04-27 03:08:46] darren at dcook dot org Another way of looking at the code in comment 1 is that the behaviour is correct (for parsing Excel-style csv), but the documentation is confusing. In my testing the within quotes is being handled correctly (and the $escape parameter is either not being used, or has not got in my way yet). But as another viewpoint, if we take the original bug report example and do: $line = 'A;Some \Stuff\;C' print_r(str_getcsv($line, ';', '', 'x')); (BTW, I'm using 'x' to mean no escaping; using a '' uses the default instead!!) Output is: Array ( [0] = A [1] = Some \Stuff\ [2] = C ) This almost makes sense if you consider it treated the second field as three sub-strings: Some \ Stuff\ The problem is, if that was true, the 3rd sub-string got parsed wrongly. The 3rd sub-string should have evaluated to a blank string. Summary: something is wrong. Either there is a bug to fix, or the $escape parameter should be removed completely, or the function needs to document the intended behaviour for corner cases like these. [2011-11-27 13:58:49] xoneca at gmail dot com The bug can be reproduced with any escape character but quote char. Test script: --- $line = 'A;Some Stuff;C'; $tokens = str_getcsv( $line, ';', '', '' ); print_r( $tokens ); Actual and Expected Result: --- Array ( [0] = A [1] = Some Stuff [2] = C ) [2011-08-12 13:30:02] mathielen at gmail dot com Description: Escape-characters should only escape the next character if it is the delimiter-character. The Escape character itself should then be removed from the result. Test script: --- $line = 'A;Some \Stuff\;C'; $token = str_getcsv($line, ';', '', '\\'); print_r($token); Expected result: Array ( [0] = A [1] = Some Stuff [2] = C ) Actual result: -- Array ( [0] = A [1] = Some \Stuff\ [2] = C ) -- Edit this bug report at https://bugs.php.net/bug.php?id=55413edit=1
Bug #30195 [Com]: scandir etc cannot read Chinese file/folder name
Edit report at http://bugs.php.net/bug.php?id=30195edit=1
ID: 30195
Comment by: spidgorny at gmail dot com
Reported by:percy at savant dot us
Summary:scandir etc cannot read Chinese file/folder name
Status: No Feedback
Type: Bug
Package:*Directory/Filesystem functions
Operating System: windows xp/2003
PHP Version:5CVS-2004-09-22 (dev)
Block user comment: N
Private report: N
New Comment:
Same problem (files with question marks) with Russian files in PHP 5.3.0 on
Windows 7.
mb_convert_encoding() can't help converting question marks.
Maybe DirectoryIterator will help.
Previous Comments:
[2010-08-29 18:13:24] onekamil at gmail dot com
Hi, have the same problem and my solution is: using mb_convert_encoding.
$open = opendir($path);
foreach( $open as $value )
{
$value = mb_convert_encoding($value, mb_detect_order($value), UTF-8);
}
If saving file to folder using urlencode. To view using urldecode.
[2007-03-31 23:30:05] missingno at ifrance dot com
Same problem here.
On WinXP with PHP 5.2.0, using iso-8859-1 as charset for the system (though the
filesystem uses utf-8 for folders/files names).
I need to access folders whose names are encoded using UTF-8.
readdir/scandir won't allow me to do so (returning '?' for characters outside
the system charset).
The page is served like this:
header('Content-Type: text/html; charset=utf-8');
So the browser really isn't at fault.
Serving the document with a more specific charset is not an option since I have
to display texts in many different languages on the page.
As moleary at preg dot org suggested, it would be really nice to have an option
to force PHP to use a certain encoding while accessing the filesystem. Or
maybe, make it so that it uses the same encoding as the filesystem instead of
defaulting to iso-8859-1...
[2006-07-10 10:02:31] gandhavallakiran at yahoo dot co dot in
hi i have used the babel class in my coding of php. but it could not read the
characters of china and japan i.e. special characters. it is displaying the
blank space instead of china or japan text. could you help me in this reacord
how to display china characters in php. please it is very urgent kindly help me.
[2005-02-25 01:00:07] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2005-02-17 15:22:16] moriyo...@php.net
Note that all of these are PHP code, so paste it within
?php ?.
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=30195
--
Edit this bug report at http://bugs.php.net/bug.php?id=30195edit=1
Bug #31326 [Com]: Object Destruction Order
Edit report at http://bugs.php.net/bug.php?id=31326edit=1
ID: 31326
Comment by: spidgorny at gmail dot com
Reported by: sir dot gallahad at gmail dot com
Summary: Object Destruction Order
Status: No Feedback
Type: Bug
Package: Scripting Engine problem
Operating System: Linux
PHP Version: 5.0.2
New Comment:
Hi,
I wonder why it's being not addressed for such a long time. This seems
an important bug to me. Consider:
?php
class Index {
var $user;
function __destruct() {
if ($GLOBALS['i']-user === $this) {
// update preferences in DB
}
}
}
$i = new Index();
?
This works counter-intuitive and $GLOBALS['i'] is UNSET at the time the
__destruct is called. The destructor is supposed to be called BEFORE the
object itself is destroyed. Please change the order to FILO.
Previous Comments:
[2006-08-23 17:56:45] richardkmiller at gmail dot com
This defect has affected me as well. I like the suggestion of
ebenblues: destroy objects in order of references pointing to
them (lowest to highest). The LIFO suggestion by sir dot
gallahad would also solve my problem,
[2005-06-09 17:09:11] ebenblues at yahoo dot com
I believe this is a bug in PHP's garbage collection. The ordering in
which __destruct methods are called can be very important when objects
contain instances of other objects as class variables. I have run into
problems because of the simple order that PHP uses to call __destruct
methods.
The order in which objects are destroyed should be determined by the
number of references left which point to the object (I believe Java does
something like this). In general, the Zend engine should use something
like the following algorithm for garbage collection:
foreach (object left to destroy) {
if(no references point at this object) {
call object's __destruct method
destroy object
}
}
The only hole in this algorithm is that an object that contains a
reference to itself will never be destroyed and cause an endless loop in
the algorithm above. These types of objects should be destroyed last.
The above algorithm can be easily modified to achieve this. Please
address this issue with PHP garbage collection. Thanks!
[2005-03-20 18:05:49] sni...@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Open. Thank you.
[2005-02-28 21:05:52] sni...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2004-12-28 20:27:18] sir dot gallahad at gmail dot com
Description:
First of all. It's not a bug. It's a sugestion to give more stability to
the engine.
When the Zend Engine reaches the end of a script page it cleans up the
classes that have been created.
Nowadays it cleans up in the order the classes have been created.
I suggest that it would be a safer routine to destroy a class following
a heap of objects (first in last out).
It would help some nesting routines, not mentioning the memory
allocation.
Reproduce code:
---
?
$ident = 0;
class Tag {
public $aVar;
function __construct( $pMe ) {
global $ident;
$this-aVar = $pMe;
echo
str_repeat(nbsp;nbsp;nbsp;nbsp;,$ident).[.$this-aVar.]br;
$ident++;
}
function __destruct() {
global $ident;
$ident--;
echo
str_repeat(nbsp;nbsp;nbsp;nbsp;,$ident).[/.$this-aVar.]br;
}
}
$v1 = new Tag(tag1);
$v2 = new Tag(tag2);
$v3 = new Tag(tag3);
echo 'brbr';
?
Expected result:
[tag1]
[tag2]
[tag3]
[/tag3]
[/tag2]
[/tag1]
Actual result:
--
[tag1]
[tag2]
[tag3]
[/tag1]
[/tag2]
[/tag3]
--
Edit this bug report at http://bugs.php.net/bug.php?id=31326edit=1
#34502 [Com]: method chaining on constructor causes parse error
ID: 34502
Comment by: spidgorny at gmail dot com
Reported By: goat at daholygoat dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.0.5
New Comment:
Here's the ugly trick how to do object instantiation and chaining in
one line:
$view-loginForm = end($_ = array(
$l = new Login(),
$l-render()-chain()-everything()-you()-like()
));
$_ and $l are two unnecessary variables. I told you - it's ugly.
Anybody can make it better?
Any ETA for implementing it in PHP directly?
Hello visitor. Please vote.
Previous Comments:
[2005-09-16 10:00:51] goat at daholygoat dot com
@Johannes:
I don't really get your interpretion of the problem. A() is of course
the constructor (A() in A). The constructor returns an object of type A.
returnStr() is a method of A, so when calling returnStr() on a new A(),
it should invoke returnStr() on a new object of A. For example, in Java
it's fine to do this:
System.out.println(new Object().toString());
Which makes sense because when you _can_ do method chaining (which you
can in PHP5), there are many times where you just want to call one chain
on a new object, instead of seperately instantiating the class.
So I have to go with Derick pointing out it's simply not supported
right now.
[2005-09-14 23:25:33] johan...@php.net
By reading the code I'd expect that A is some function
returning an object. returnStr() being a method of that
object returning a class name used for new. (Somehow a
combination of new $a; and a simple
function_call()-methodCallOnReturnedObject() which is
possible since PHP 5) I would like some syntax like this,
too - but thinking about it I see too much confusion and
didn't find a nice solution which is clear when reading
code.
I set this to bogus since I think it's too much confusion,
but if you have a nice and clear syntax feel free to
re-open it - I'd be happy, but don't see how this is
possible without logic conflicts :-)
[2005-09-14 21:26:50] der...@php.net
I think this is simply not supported right now, so marking as a Feature
Request
[2005-09-14 21:14:57] goat at daholygoat dot com
Description:
When doing method chaining on a constructor (without seperately
instantiating the object first), a parse error occurs.
Reproduce code:
---
class A
{
private $str;
function A($str)
{
$this-str = $str;
}
function returnStr()
{
return $str;
}
}
echo new A(hello)-returnStr();
Expected result:
The reference to an object of A created with A's constructor would
allow me to call returnStr() on it.
Actual result:
--
I'm getting a parse error.
PHP Parse error: parse error, unexpected T_OBJECT_OPERATOR, expecting
',' or ';'
--
Edit this bug report at http://bugs.php.net/?id=34502edit=1
