Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108815
MIME-Version: 1.0
References: <CAEo3Y-dTioEqVPW-7ewxsTWf6HRzp0F0TT+LqVZ3gBWB6MvreA@mail.gmail.com>
 <CAF+90c81CPKP+GN6Pqae4XnxC-BYDF9pOisd-naa38616xMQVw@mail.gmail.com>
 <CAEo3Y-f=UKfVUp5hh3vpBom6H6iJgm_mUBnC0JDv9mgoXm4k6g@mail.gmail.com> <5e5d5a0f.1c69fb81.8bdd0.93cdSMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5e5d5a0f.1c69fb81.8bdd0.93cdSMTPIN_ADDED_MISSING@mx.google.com>
Date: Mon, 2 Mar 2020 21:00:32 +0100
Message-ID: <CAF+90c9hW2spxrtk3MdvgXY4SD3xPMAt+Br+99CBTg6nip4uBw@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c0e331059fe4a4f9"
Subject: Re: [PHP-DEV] Proposal for a new basic function: str_contains
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000c0e331059fe4a4f9
Content-Type: text/plain; charset="UTF-8"

On Mon, Mar 2, 2020 at 8:10 PM Andrea Faulds <ajf@ajf.me> wrote:

> Hi,
>
> Philipp Tanlak wrote:
> > I like to elaborate on Nikitas response: I don't think a mb_str_contains
> is
> > necessary, because the proposed function does not behave differently, if
> > the input strings are multibyte strings.
>
> This is not true for all character encodings. For UTF-8 it is correct,
> but consider for example the Japanese encoding Shift_JIS, where the
> second byte of a multi-byte character can be a valid first byte of a
> single-byte character. str_contains() would have incorrect behaviour for
> this case.
>

That's of course true, but I consider it ultimately unimportant. Accepting
non UTF-8 encodings for anything other than mb_convert_encoding() is just
another failure of the mbstring API. The mb_strpos() function literally
works by converting the given string to UTF-8 and then calling the normal
strpos() on it, after sprinkling in some nice O(n) offset to byte offset
(and reverse) conversions. You are generally much better off canonicalizing
everything to UTF-8 for internal processing and using normal str*
functions. But well, that's a different discussion...

Regards,
Nikita

--000000000000c0e331059fe4a4f9--