Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111990
Message-ID: <C9BEF938-E426-4D14-B8D3-5ECCCF34C8DD@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FFB96616-EC34-4862-8B60-BB2BF0D64A48"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Fri, 2 Oct 2020 22:11:46 +0200
In-Reply-To: <cd1a914c-aeb2-9c73-147c-bb49a78318a5@landauer.at>
Cc: internals@lists.php.net
To: Thomas Landauer <thomas@landauer.at>
References: <cd1a914c-aeb2-9c73-147c-bb49a78318a5@landauer.at>
Subject: Re: [PHP-DEV] Suggestion: Make all PCRE functions return *character*
 offsets, rather than *byte* offsets if the modifier `u` (PCRE_UTF8) is given
From: claude.pache@gmail.com (Claude Pache)

--Apple-Mail=_FFB96616-EC34-4862-8B60-BB2BF0D64A48
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

Working with UTF-8-encoded strings does not implies working with =
mb_string functions or with code-point counts. Personnally, I work with =
standard string functions, plus [Grapheme functions] =
(https://www.php.net/manual/en/ref.intl.grapheme.php =
<https://www.php.net/manual/en/ref.intl.grapheme.php>) when I need to =
split my string between =E2=80=9Ccharacters=E2=80=9D (which means for me =
=E2=80=9Cgrapheme clusters=E2=80=9D, not =E2=80=9Ccode points=E2=80=9D, =
so that mb_string functions are useless for me). In particular, =
PREG_OFFSET_CAPTURE does always what I need, even when using the /u =
flag.

If this is a feature that you want to implement, I suggests adding a =
flag PREG_UTF8_CODEPOINT_OFFSET_CAPTURE.

=E2=80=94Claude




--Apple-Mail=_FFB96616-EC34-4862-8B60-BB2BF0D64A48--