Stripping emojis from a string is already supported by the EmojiTransliterator:

use Symfony\Component\Emoji\EmojiTransliterator;

$emojiStrippingTransliterator = EmojiTransliterator::create('emoji-strip');

$string = 'my input string which may have emojis';

$stringWithoutEmoji = $emojiStrippingTransliterator->transliterate($string);

So this can be done even if symfony/string does not have a method doing that for you.

And btw, the same question applies for this use case than for previous ones: is the issue in the third-party services related to not accepting emojis or is it about not accepting multi-bytes UTF-8 codepoints (maybe only the ones using 4 bytes) ?

And btw, the same question applies for this use case than for previous ones: is the issue in the third-party services related to not accepting emojis or is it about not accepting multi-bytes UTF-8 codepoints (maybe only the ones using 4 bytes) ?

I'm not certain about it. They are not that explicit

@MolloKhan the question is what do they reject (and why). See for instance #48853 (comment): the broken utf8 type in MySQL (which uses utf8mb3) rejects all 4-bytes characters, which will reject most emojis (but not all) but also other things.

Rejecting only emojis is actually much more explicit than rejecting 4-bytes codepoints.

Yea, but they don't say. The API call just fails with "invalid data". I discovered that removing all emojis fixes the issue. Anyway, I was not aware that the Symfony Emoji component already has this feature, so if you don't find a real value add a shortcut to it in the String component, I think we can close this request

Well, both issues you linked were saying that they leverage the EmojiTransliterator to implement the stripping.

I will close this issue as I don't think the use case mentioned here is sufficient to revisit our decision to reject the shortcut in the String component.