Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114896
MIME-Version: 1.0
References: <8de4d96a-75d1-d732-020e-30bce0a5e03d@gmail.com> <CAF+90c_GV2gE=7WFpAZ5nHPSs_22B6b0PGOqStnyGNmxj_=TDg@mail.gmail.com>
In-Reply-To: <CAF+90c_GV2gE=7WFpAZ5nHPSs_22B6b0PGOqStnyGNmxj_=TDg@mail.gmail.com>
Date: Tue, 15 Jun 2021 22:46:23 +0100
Message-ID: <CAEKnhAH+0zA3ei+dS8-cV-Xr+koCikx+--Pg2H=APpgPPMuoMg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Timon de Groot <tdegroot96@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005f430605c4d4e8e1"
Subject: Re: [PHP-DEV] [RFC][Draft] Add json_encode indent parameter
From: bukka@php.net (Jakub Zelenka)

--0000000000005f430605c4d4e8e1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 7, 2021 at 11:53 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Thu, Jun 3, 2021 at 6:11 PM Timon de Groot <tdegroot96@gmail.com>
> wrote:
>
> > Hi internals,
> >
> > I'd like to present my RFC for adding the indent parameter to the
> > json_encode function:
> >    https://wiki.php.net/rfc/json_encode_indentation
> >
> > The `string|int $indent =3D 4` parameter adds the ability to specify th=
e
> > indentation for
> > the JSON encoder. Amount of spaces can be specified by a number and a
> > string can be
> > specified to set a custom indentation like `\t` or whatever.
> >
> > As this is my first RFC (and contribution) for PHP, I'm all kind of new
> > to the process, standards, etc.
> > Please let me know if I could do something better.
> >
> > Looking forward to feedback/input on the RFC.
> >
>
> As has been brought up in
> https://github.com/php/php-src/pull/7093#issuecomment-855170601, the
> string
> version of the $indent parameter allows you to create invalid JSON,
> something that json_encode() does not currently allow. I tend to agree th=
at
> it would make sense to validate that the indent only contains whitespace
> characters, and not =F0=9F=9A=80.
>
>
I agree with this, it should validated to be also consistent with UTF-8
validation. For example if it's not valid utf8, it returns false (unless
ignoring or substitution is enabled). In any case it never returns invalid
json atm. I don't think it's a good idea to break that assumption.

Cheers

Jakub

--0000000000005f430605c4d4e8e1--