Everything

php

Proposal: Support for RFC4648 in PHP

php.internals

nyamsprod the funky webmaster

1 year ago

Greetings,

I have been playing around with an RFC proposal for some time and recently
after discussing it with Tim Düsterhus he has volunteered
to do the implementation so I would like to submit to you an RFC around
data encoding in PHP. The goal of the RFC is to fully implement
RFC4648 (base16 , base32, base64).

I know that PHP already has `base64_encode` and `base64_decode` and
`bih2hex` and `hex2bin` but those functions only provide a partial support
for RFC4648.
In my RFC proposal I would like to introduce, instead, a new namespace
`Encoding` that will host an all new and improved API which will cover the
complete RFC,
will be consistent and easily extendable for future data encoding
algorithms addition.

For reference, this is not a new topic, the issue with the current
implementation is well documented in the mailing list as well as a past
attempt to
add RFC4648 to the language.

- base64_encode without padding https://externals.io/message/122630
- base64 url format https://externals.io/message/119243
- [RFC] RFC4648 encoding https://externals.io/message/91858#91964

If people are interested I will proceed with a karma request and create the
draft RFC.

Best regards,
Ignace Nyamagana Butera

Hans Henrik Bergan

1 year ago

On Thu, 12 Jun 2025 at 18:53, ignace nyamagana butera
<nyamsprod@gmail.com> wrote:

>
> Greetings,
>
> I have been playing around with an RFC proposal for some time and recently after discussing it with Tim Düsterhus he has volunteered
> to do the implementation so I would like to submit to you an RFC around data encoding in PHP. The goal of the RFC is to fully implement
> RFC4648 (base16 , base32, base64).
>
> I know that PHP already has `base64_encode` and `base64_decode` and `bih2hex` and `hex2bin` but those functions only provide a partial support for RFC4648.
> In my RFC proposal I would like to introduce, instead, a new namespace `Encoding` that will host an all new and improved API which will cover the complete RFC,
> will be consistent and easily extendable for future data encoding algorithms addition.
>
> For reference, this is not a new topic, the issue with the current implementation is well documented in the mailing list as well as a past attempt to
> add RFC4648 to the language.
>
> - base64_encode without padding https://externals.io/message/122630
> - base64 url format https://externals.io/message/119243
> - [RFC] RFC4648 encoding https://externals.io/message/91858#91964
>
> If people are interested I will proceed with a karma request and create the draft RFC.
>
> Best regards,
> Ignace Nyamagana Butera

Why do it in core?
Is userland base16/base32 performance unsatisfactory?

Ayesh - PHP.Watch

1 year ago

>
> Why do it in core?
> Is userland base16/base32 performance unsatisfactory?

Even if the performance is satisfactory, having this in core can help
user-land code to get rid of their own implementations (which they
often do, to be URL-safe, for example).

I imagine native implementations can make use of CPU SIMD acceleration
as well, like we already do for the current base64 functions.

The initial message also mentions adding this functionality into a
separate namespace, so I'm quite positive with this proposal. Even
more so than the previous proposals that proposed to add new
parameters to the base64 functions.

nyamsprod the funky webmaster

1 year ago

On Thu, Jun 12, 2025 at 7:23 PM Hans Henrik Bergan <divinity76@gmail.com>
wrote:

> On Thu, 12 Jun 2025 at 18:53, ignace nyamagana butera
> <nyamsprod@gmail.com> wrote:
> >
> > Greetings,
> >
> > I have been playing around with an RFC proposal for some time and
> recently after discussing it with Tim Düsterhus he has volunteered
> > to do the implementation so I would like to submit to you an RFC around
> data encoding in PHP. The goal of the RFC is to fully implement
> > RFC4648 (base16 , base32, base64).
> >
> > I know that PHP already has `base64_encode` and `base64_decode` and
> `bih2hex` and `hex2bin` but those functions only provide a partial support
> for RFC4648.
> > In my RFC proposal I would like to introduce, instead, a new namespace
> `Encoding` that will host an all new and improved API which will cover the
> complete RFC,
> > will be consistent and easily extendable for future data encoding
> algorithms addition.
> >
> > For reference, this is not a new topic, the issue with the current
> implementation is well documented in the mailing list as well as a past
> attempt to
> > add RFC4648 to the language.
> >
> > - base64_encode without padding https://externals.io/message/122630
> > - base64 url format https://externals.io/message/119243
> > - [RFC] RFC4648 encoding https://externals.io/message/91858#91964
> >
> > If people are interested I will proceed with a karma request and create
> the draft RFC.
> >
> > Best regards,
> > Ignace Nyamagana Butera
>
>
> Why do it in core?
> Is userland base16/base32 performance unsatisfactory?
>

Hi Hans,

If I take base32 as an example, if you look at packagist for userland
implementations packages, you will get different results with none telling
you which version (alphabet) is being used
and if the decoding is strict or not.. The same is true for base64, there
are different flavours of base64 with each their usefulness. The RFC will
address these issues and provide a consistent API to tackle them.

Best regards,
Ignace Nyamagana Butera

Máté Kocsis

1 year ago

Hi Ignace,

I fully support the idea, and I also share the opinion that PHP should
evolve by improving its standard library
from the mostly procedural APIs consisting of functions here and there to
"cleaner", more organized and consistent
object oriented APIs. I also agree that performance sensitive topics that
are backed by standards are a perfect fit for adoption.

So good luck with the RFC!

Regards,
Máté