how about base64_encode(string $string, int $flags = 0): string with $flags accepting BASE64_RFC4648 and BASE64_NO_PADDING or something to that effect?
On Mon, 9 Jan 2023 at 22:56, David Gebler <davidgeb...@gmail.com> wrote: > > On Mon, Jan 9, 2023 at 9:42 PM Derick Rethans <der...@derickrethans.nl> > wrote: > > > On 9 January 2023 18:49:28 GMT, Sara Golemon <poll...@php.net> wrote: > > >I've been working with JWTs lately and that means working with Base64URL > > >format. (Ref: https://www.rfc-editor.org/rfc/rfc4648#section-5 ) > > >This is essentially the same thing as normal Base64, but instead of '+' > > and > > >'/', it uses '-' and '_', respectively. It also allows leaving off the > > >training '=' padding characters. > > > > > >So far, I've just been including polyfills like this: > > > > > >function base64url_decode(string $str): string { > > > return base64_decode(str_pad(strtr($str, '-_', '+/'), (4 - > > >(strlen($str) % 4)) % 4, '=')); > > >} > > > > > >function base64_encode(string $str): string { > > > return rtrim(strtr(base64_encode($str), '+/', '-_'), '='); > > >} > > > > > >These work fine, but they create a LOT of string copies along the way > > which > > >shouldn't be necessary. > > >Would anyone mind if skipped RFC and just added `base64url_encode()` and > > >`base64url_decode()` to PHP 8.3? > > > > Should these be new functions, or options to base64_encode instead? I'd > > guess base64_decode could just accept both? > > > I think from a UX/DX perspective, separate functions would be my > preference, base64_url_encode and base64_url_decode (extra underscore which > I feel is more consistent with PHP stock library). One consideration though > is that base64_urlencode or base64_url_encode are function names which are > likely already defined by a number of userland projects or libraries, since > it's a very common thing to do with the prevalence of JWTs, so if the RFC > process is being bypassed in this case, a new optional parameter to > base64_encode might be better. But I think it would be weird to have > base64_encode(bool $urlEncode = false) or something, which is presumably > what it would look like. > > Dare I float the suggestion of a Base64 class, making base64_encode and > base64_decode functions aliases for Base64::encode() and Base64::decode() > respectively, then new Base64::urlEncode() and urlDecode() methods? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
