Edit report at https://bugs.php.net/bug.php?id=61255&edit=1
ID: 61255
User updated by: mi+php at aldan dot algebra dot com
Reported by: mi+php at aldan dot algebra dot com
Summary: Unserialize should handle incorrect or missing
string-length
Status: Open
Type: Feature/Change Request
Package: *Data Exchange functions
Operating System: All
PHP Version: 5.3.10
Block user comment: N
Private report: N
New Comment:
If the length is what's driving the parsing, then why are the strings S2 and S3
empty in my test? Shouldn't S2 be '123456' and S3 be '1234567"'?
Previous Comments:
------------------------------------------------------------------------
[2012-03-03 00:45:48] anon at anon dot anon
It depends on the lengths because the strings aren't escaped. serialize('"') =
s:1:""";
------------------------------------------------------------------------
[2012-03-02 22:26:46] mi+php at aldan dot algebra dot com
Description:
------------
A serializing string "foo" produces an intuitive result 's:3:"foo"' and
unserialize() properly decodes that back.
It would be useful, however, if the unserialize function could handle (even if
less efficiently) cases, where the string-length is missing or even specified
incorrectly. Currently any such mismatches result in empty output from the
function, even though `s:"foo"' or `s::"foo"' or even `s:4:"foo"' is no harder
to understand.
The feature would be of help to those of us, who need to a massive
search/replace in the dump of serialized objects.
Test script:
---------------
<?
$s1 = "s:7:\"1234567\"";
$s2 = "s:6:\"1234567\"";
$s3 = "s:8:\"1234567\"";
$s4 = "s::\"1234567\"";
print "S1: >" . unserialize($s1) . "<\n";
print "S2: >" . unserialize($s2) . "<\n";
print "S3: >" . unserialize($s3) . "<\n";
print "S4: >" . unserialize($s4) . "<\n";
?>
Expected result:
----------------
S1: >1234567<
S2: >1234567<
S3: >1234567<
S4: >1234567<
Actual result:
--------------
S1: >1234567<
S2: ><
S3: ><
S4: ><
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=61255&edit=1
