|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2011-09-12 17:20 UTC] iliaa@php.net
[2011-09-12 17:20 UTC] iliaa@php.net
-Status: Open
+Status: Closed
-Assigned To:
+Assigned To: iliaa
[2011-09-12 17:20 UTC] iliaa@php.net
[2012-04-18 09:48 UTC] laruence@php.net
[2012-07-24 23:40 UTC] rasmus@php.net
[2013-11-17 09:36 UTC] laruence@php.net
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sat Oct 25 23:00:01 2025 UTC |
Description: ------------ Per RFC2045, section 6.8, base64 decoding should not count line breaks and other whitespace as errors. When using $strict=True, base64_decode() does ignore whitespace, except at the end of any base64 encoded data that ends with padding characters (=). If there is whitespace after the padding character(s), the string is rejected under strict testing. This is incorrect. One particular problem with this is that you cannot reliably round-trip base64 encode/decode with strict checking when using chunk_split() on the encoded data, because chunk_split puts a newline at the end of the data. If the length of the original data is a multiple of 3, it works, otherwise it does not. Test script: --------------- <?php function test($s) { $v = chunk_split(base64_encode($s)); $r = base64_decode($v, True); echo "$s="; var_dump($r); } test('PHP'); test('PH'); test('P'); Expected result: ---------------- PHP=string(3) "PHP" PH=string(2) "PH" P=string(1) "P" Actual result: -------------- PHP=string(3) "PHP" PH=bool(false) P=bool(false)