This can be solved by decoding $text and $prefix beforehand with utf8_decode and later encoding them again with utf8_encode.

this solution is likely wrong, because utf8_decode and utf8_encode are quite confusing (and converting UTF-8 to ISO-8859-1 cannot be done for all inputs as ISO-8859-1 cannot represent all of Unicode)

Indeed, this preg_replace is wrong. It not only doesn't handle utf8, but it doesn't handle character width also.
@Moskito89 would you like give this issue a try?

Thanks for pointing this out @stof, I actually overlooked the fact that not all characters can be converted. So it seems like preg_replace needs to be replaced.
Yes @nicolas-grekas, you can assign the issue to me. I will look for a solution.

I have now looked into the problem and found two possible solutions.

The simplest approach would first be to replace preg_replace with mb_ereg_replace_callback. It can process UTF-8 and otherwise works almost identically. So instead of writing:

$text = $prefix.preg_replace('~([^\\n]{'.$width.'})\\ *~', "\$1\n", $text);

Could be there:

$text = mb_ereg_replace_callback(
    '([^\\n]{'.$width.'})\\ *', 
    function ($matches) {
        $line = rtrim($matches[0]);
        return $line.PHP_EOL;
    }, 
    $text
);

The problem is that mb_ereg_replace_callback is very slow: in my tests it was ten times slower than preg_replace, which I find very unsatisfactory. In addition, mb_ereg_replace_callback requires, as far as I know, ext-mbstring.

That's why I wrote another piece of code where I changed the functionality completely so that the breaks are created manually. The commit with the changes and the second approach can be found here: BitAndBlack@63ac82d

I have added some tests, the previous and the new ones work. The process is also slower than the original preg_replace, but not as much as mb_ereg_replace_callback: in my test (with 1 million iterations) it was about three to four times slower, which I would still consider acceptable.

Please write me your thoughts and let me know how we can move on. Thanks!

Well, if we want to work with UTF-8, using preg_replace with a regexp using the u modifier might work. But this will then cause issues if the string is not UTF-8

Yes that's true, unfortunately. Which encodings do we have to deal with? Would you tell me some characters or strings for testing?

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

This bug still exists. I'm currently waiting for @stof's reply.

Well, we don't know which encodings are used by apps using the component. But I suspect that windows-1252 might be used for instance, as that's the encoding used by cmd.exe by default for its output

I'm sorry, but I can't solve that — I know too little about character encoding...

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

Bug still exists.

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

Bug still exists.