Re: [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API
| From: | ignace nyamagana butera | Date: | Wed, 02 Jul 2025 19:25:03 +0000 |
| Subject: | Re: [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-127847@lists.php.net to get a copy of this message | ||
>
>
> I don't think it needs to be added to the enum, necessarily. Just make it
> a nullable argument to base64_decode.
>
> function base64_decode(string $string, bool $strict = false, ?DecodingMode
> = null): string|false
>
> That would leave the default behavior of the function intact, but also
> allows switching it over to either of the new modes (which would then just
> defer to the new implementations). And we wouldn't need to deal with
> "disallowed" modes on the new functions.
>
> Hi Larry,
The goal is not to change the signature of the existing
base64_encode
function, but rather to preserve its current non-strict behavior within the
new API. This is intended to ensure a smoother transition from the existing
API to the proposed one. Therefore, we shouldn’t alter or retrofit the
existing function. Instead, the focus should be on providing a clear
migration path for users, which is why the addition of a
DecodingMode::Unsafe case is being proposed.
If I were to follow your suggestion, I would have proposed an alternative
signature like this:
```
base64_encode(string $string, bool|DecodingMode $strict = false);
```
Where:
- Encoding\DecodingMode::Strict is identical to $strict = true
- Encoding\DecodingMode::Unsafe would be identical to $strict = false
and the current function would then become an alias of
```
Encoding\base64_decode(string $encoded, decodingMode:
Encoding\DecodingMode::Unsafe);
// or
Encoding\base64_decode(string $encoded, decodingMode:
Encoding\DecodingMode::Strict);
```
The caveat is that, in the new API, errors will throw exceptions instead of
emitting an E_WARNING and returning false. Once the current API is
eventually removed, the Encoding\DecodingMode::Unsafe mode would also be
deprecated and removed accordingly. And documentation would rightly
highlight the danger of using such settings.
Keep in mind that this is in response to Rowan comment and depending on
feedback I may not add the Encoding\DecodingMode::Unsafe to the proposal.
I know I do not represent the majority but I tend to always use strict mode
when decoding base64 encoded data and when I forget PHPStan reminds me to
do so.
Best regards,
Ignace