lgommans
commented
5 years ago So the data was all there, but PHP's unserialize() did not seem to like the odd character. It acted the same as when I typo'd an invalid string length, though I didn't investigate whether it was the same issue (i.e. byte count wrong due to encoding). There is not a word about encoding on the PHP unserialize() documentation page, not even in the comments. I guess nobody uses this ¯\_(ツ)_/¯
Changed encoding of file metadata to JSON. Which was fun, too:
// Just verifying that json_decode is the inverse of json_encode:
echo [1,2][1]; // prints 2, as expected
echo json_decode(json_encode([1,2]))[1]; // still prints 2, as expected (data in == data out)
// Looks good! So I implemented it... why doesn't it work? This is why:
echo ["a"=>1]["a"]; // prints 1, as expected
echo json_decode(json_encode(["a"=>1,"b"=>2]))["a"]; // throws a stack trace
// Argh. Looking at the documentation, you need to pass another parameter to get the expected behaviour:
echo json_decode(json_encode(["a"=>1]), true)["a"]; // prints 1
Got a well-written user report about not being able to download a file. Upon investigation (luckily I saw the report before the link expired), it turned out that the serialized data in the database contains a non-ASCII character. Browsers act weird, but with
curl -vit can be seen that the connection is prematurely closed.