[axchadxs]

Fixes #3340

What was wrong

truncateUrl cuts a URL at 255 characters. When the cut landed inside a percent-encoded escape (for example %E9%A0%80), the result ended with a partial escape such as % or %E right before the ... <truncated> marker. That fragment is not valid percent-encoding, so the output could be misread.

What changed

• truncateUrl now checks whether the first 255 characters end in % or % plus one hex digit. If so, the cut moves back to before the %, so a partial escape is never left behind.
• URLs that already fit within the limit are returned unchanged, and long URLs that don't end in a partial escape (like long data: URLs) are cut at 255 characters as before.
• Incomplete multi-byte characters are now dropped too, back to their first byte, so the output never ends in half a character.

Tests

Added cases to tests/utils/text.test.ts:

• a cut that lands after %E
• a cut that lands right after a lone %
• a 3-byte character cut after its first byte
• a 3-byte character cut after its second byte
• a 4-byte character cut after its third byte
• a complete multi-byte character exactly at the cut, which must be kept

All of them except the last fail without the fix and pass with it. The last one passes either way and guards against removing too much.

[wolfib]

Thanks!

I believe this solution is incomplete. For multibyte UTF-8 characters, we don't want to just remove the incomplete final byte, but previous bytes as well up to the beginning of the multibyte-character.

[axchadxs]

Good catch, thanks! Fixed in a30d89b: after dropping a partial %XX escape, truncateUrl now also drops a trailing incomplete multi-byte UTF-8 sequence back to its lead byte (2-, 3- and 4-byte characters). Added tests for each case plus one confirming a complete character at the cut is kept.