The documentation should be clarified, but the current behavior is both intentional and preferable. The use of character offsets should be avoided wherever possible.

> PREG_OFFSET_CAPTURE always counts utf-8 special characters as
> *2* (bytes)

To clarify: UTF-8 characters are not necessarily counter as 2
bytes.

Right, the clarification here should be that this is always a "byte offset" including in UTF8 mode.

> The use of character offsets should be avoided wherever possible.

Why?
When using *byte* offsets to split a string, you might end up with an invalid string, due to some "half"-characters.

@thomas: If your pattern matches at a character boundary, then of course the returned byte offset will also always be located at a character boundary.

The only way you could end up with a byte offset that is not on a character boundary is if your pattern explicitly requests that by using a single code unit match (\C). If it does, the result would not even be representable with a character offset.

What I meant: My current code works with character numbers (`mb_substr()`, `mb_strlen()`). If I switched to byte numbers, I'd have to change this to `substr()` and `strlen()`; and if anything goes wrong there, I'm not just extracting some wrong characters, but rather completely *destroying* the entire string...

So why is it preferable to work with byte offsets?

And what's the point in having a dedicated modifier for UTF-8, if it doesn't make a difference in the end?
I think you should support this modifier here too, and leave the decision (byte vs. character offsets) to the user. I mean: This is exactly the point of such a switch, isn't it?

First, all offsets in the PCRE extension are byte offsets.
Changing that would be a massive BC break.

Second, UTF-8 character offsets enforce sequential access to
characters and substrings, while byte offsets allow random access,
which is way faster.

If you still feel strongly that this should be changed, please
write a mail to the internals mailing list[1], since this
bugtracker is not suitable for this kind of discussion.

[1] <https://www.php.net/mailing-lists.php#internals>

> And what's the point in having a dedicated modifier for UTF-8, if it doesn't make a difference in the end?
> I think you should support this modifier here too, and leave the decision (byte vs. character offsets) to the user. I mean: This is exactly the point of such a switch, isn't it?

The modifier controls how the pattern and input string are interpreted. You want /[äöü]/ to match the characters ä, ö and ü, not their constituent bytes in the UTF-8 encoding. It has no relation at all to the meaning of offsets, which are always proper byte offsets.

Here's what I posted to the "php.internals" mailing list: https://news-web.php.net/php.internals/111983