Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:127659 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 6CC991A00BC for ; Fri, 13 Jun 2025 08:54:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1749804765; bh=ggAVdmLgXGndt5p54oQ8knPDLwSZH2vFPZHzrbw9DBI=; h=References:In-Reply-To:From:Date:Subject:To:From; b=UoeZKJMleA7dYTWNQ9c6Yw7mw6j1Hg7ZCHzyWyQ03kWYXgEguLGQmS1El26Ye2eY2 mgrj2a6yJkuutU5z4SRVCnDJCiJI6zRt0UVkWblH1mP9wKbwQFnlijW+IIQgW2NuBI PuWbAl+aI9oo738ckWpYr8AgK9GdaomNbCqvb3wmU4pZM3ZO+1Cgxcg1W0fJQOgIQa sPYKY1E9UWkLlzmbAAa9ozlMkx8JW8tWqk182zXV5aD/ljzBcRs80/u6cvkAKJs0NN OAn98A3j5mpt/J6D8nRuDQdyCXiXVb9iaFAg/ZKAqX0z03RW02H82vtSObK0CDN0Qs Kx1lNDGyXi39Q== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 15331180061 for ; Fri, 13 Jun 2025 08:52:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 13 Jun 2025 08:52:44 +0000 (UTC) Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-747ef5996edso1826709b3a.0 for ; Fri, 13 Jun 2025 01:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749804884; x=1750409684; darn=lists.php.net; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=ggAVdmLgXGndt5p54oQ8knPDLwSZH2vFPZHzrbw9DBI=; b=jo8ft61IVgaj5PJVvLmvJF0hS40PFaBMMeJvWDj1d1/J2SZN6JX0/isxRwJG1Omk0K sS0wgyeNmmHZwnymKJV7x8uahDGbC+Eg5EfyFImym77vSNQumSBQ0WEXWyuzTGA9yqJ/ 88BJnu4Ygj0QW3K32dRjIg+LVxZcTW3wZ5r0oW5Bi5ZTiTZzos10FCCTxstFgruu0vYh f9yKZ9Ji5PU0tpVMh9sRT+TwsqQFgHxa9lJh60hJ4o+pIP7Rn/PLpQjbTEMexHz26Uq8 Ztgsn0Nfg1hr2xr4KwZmAIwogMHfpvpcT2mIHHOHar2MpdMnDvVi1BAFTRWgrxH0aJqP mpJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749804884; x=1750409684; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ggAVdmLgXGndt5p54oQ8knPDLwSZH2vFPZHzrbw9DBI=; b=kwa+3LGvNjI3KkqV2awshr1DDs3gSzrMzTbe5kRFRB/kkkDJ2P1drfIcTm64wya/tF 5sKemqdbqE29q7HidHbbzHQFGDYgPnb1LCGyidA0v34xEa6NXt3ImH7r/KSoIP68gQYS usL9F11PPdQkcVphos399lREGxJLzdevygOFT+WaEvf95hWhN99bFgqEaNbeqsS68p7n mOwCKNPP28nJfKNF1br2ZiarPTNyD6oK6I6tSOpjdngNvxIC9A2yRzDTH9UsAi3/C+CB Kb+qGxDh6tbRRPpAefCdqI4yIIvQbtkEjTF6ttAIzShq+pe254slNIMV+vxQNKTXNUoW n4fA== X-Forwarded-Encrypted: i=1; AJvYcCU+SuqbVh7lnDOUAMyh6Y6U4yKFmXvas7Vc8ALJXXcQmbwEZ3EzlvMgpomQrF7xa8zfSkaFOAuIt8o=@lists.php.net X-Gm-Message-State: AOJu0YxluQODMGHO+rErCKKtoj10NO6NlTdpE/3JYvrOLzPwguKXQWiJ TEdzm4rLSDtqkz26Y+l4gpqC/zEHVBRjzVS0pJqGYKKwyboR59SOx5vDsZWsp/NYlTdIOljg8Lq YcR+/FC0Dfhqm5A6KfLDsld2mk7DGFf8= X-Gm-Gg: ASbGncua0mZu5Bqjr00WZGTmrkdwKK19L+tcDqcGSOJ/PglWfuSpiSN8rKZAlwF4m62 jBDM4H/POw3svPPzei+lan9KJaU72f0j50rUAKwu5JniFbYCSXW9jgkF1iBfuQjFFHRV0gAAjRV ARX70WjGhligJUeKBrJkU7Tyw+s+3ZMTcCtnNdBa+v4Hne X-Google-Smtp-Source: AGHT+IH9v41aY5m2UuDvCkD0clwo+pSfs4DxK6OY8QwwkO3y5jO52n4Cqf3Sb4UNfGg8xIjmXNwydFQY0JGXsQvMrVs= X-Received: by 2002:a05:6a00:a86:b0:748:1bac:ad5f with SMTP id d2e1a72fcca58-7488f7a2036mr3386468b3a.12.1749804883709; Fri, 13 Jun 2025 01:54:43 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 13 Jun 2025 10:54:32 +0200 X-Gm-Features: AX0GCFvrtsFRQpjLRsuMAZGUn3UAtBPaeU-gir601AwrP_pzOaf9-SQMtqX2_VE Message-ID: Subject: Re: [PHP-DEV] Proposal: Support for RFC4648 in PHP To: Hans Henrik Bergan , PHP Internals List Content-Type: multipart/alternative; boundary="000000000000851347063770322b" From: nyamsprod@gmail.com (ignace nyamagana butera) --000000000000851347063770322b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 12, 2025 at 7:23=E2=80=AFPM Hans Henrik Bergan wrote: > On Thu, 12 Jun 2025 at 18:53, ignace nyamagana butera > wrote: > > > > Greetings, > > > > I have been playing around with an RFC proposal for some time and > recently after discussing it with Tim D=C3=BCsterhus 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 suppor= t > 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 th= e > 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 --000000000000851347063770322b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Jun 12, 202= 5 at 7:23=E2=80=AFPM Hans Henrik Bergan <divinity76@gmail.com> wrote:
On Thu, 12 Jun 2025 at 18:53, ignace nyamagana= butera
<nyamsprod@gmai= l.com> wrote:
>
> Greetings,
>
> I have been playing around with an RFC proposal for some time and rece= ntly after discussing it with Tim D=C3=BCsterhus he has volunteered
> to do the implementation so I would like to submit to you an RFC aroun= d 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 `b= ih2hex` and `hex2bin` but those functions only provide a partial support fo= r 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 algo= rithms addition.
>
> For reference, this is not a new topic, the issue with the current imp= lementation is well documented in the mailing list as well as a past attemp= t to
> add RFC4648 to the language.
>
> - base64_encode without padding https://externals.io/message= /122630
> - base64 url format https://externals.io/message/119243<= br> > - [RFC] RFC4648 encoding https://externals.io/message/9= 1858#91964
>
> If people are interested I will proceed with a karma request and creat= e 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 exa= mple, if you look at packagist for userland implementations packages, you w= ill get different results with none telling you which version (alphabet) is= being used
and if the decoding is strict or not.. The same is tr= ue for base64, there are different=C2=A0flavours of base64 with each their = usefulness. The RFC will address these issues and provide a consistent API = to tackle them.

Best regards,
Ignace Nya= magana Butera


--000000000000851347063770322b--