Well, the 😣 was a copy-and-pasted block so you could see, but it looks like the forum here converted it :-) And when I Googled 😣 it brought up the emoji that I'd copied.

So there's a theoretical way to convert £ðŸ˜ to 😣...

Be sure to use UTF8 encoding (page, form, but also the database if you are storing this text in a DB). Then when you output the text to a page, use the htmlentities (if you use PHP)

One of my WP sites includes a javascript to convert emojis. I don't want to paste the whole thing here because it's built for WordPress, but I'll bet that emoji scripts are probably available from different sources. The one I see is referencing a baseURL of s.w.org and uses a jquery in the script that references "js?ver=4.9.1"

I don't think it converts html entities like 😣 because the script is full of .svg images.

There's also the issue of potential device tracking through the upload & storing of user emoji.

it looks like the forum here converted it

The forums are constrained to Latin-1 (either 8859 or 1252 depending on circumstances). All other characters turn into numerical encoding.

Forms in &# are decimal. Forms in &#x are hexadecimal. Same number, different ways of writing it. 😣 = 😣 = (appropriately enough) “persevering face”. Emojis are way up in the upper ranges of unicode--codes beginning in F, here F0 9F 98 A3--so if they are reinterpreted as any one-byte encoding you will end up with four characters, as you saw.

:: business with text editor ::

:: further business with Character Viewer, because text editor refuses to oblige ::

Yup, there they come. F0 = ð, 9F = Ÿ; 98 = ˜; A3 = £, where the second and third are only visible in Windows-Latin-1, not in ISO-Latin-1.

I am frankly surprised to learn that any mobile device in the world still defaults to a one-byte encoding. Are you sure you're not sending out conflicting encoding information in a header somewhere?

I am frankly surprised to learn that any mobile device in the world still defaults to a one-byte encoding. Are you sure you're not sending out conflicting encoding information in a header somewhere?

There shouldn't be, that code came from a post that I made through my Samsung S7 about a week ago. And I just had a post go through with an iPhone, iOS 11.2.6:

😂�🤮

The post starts on a contenteditable element, then when you submit it goes through a Perl script. I save an unfiltered copy in one table immediately, then run profanity filters and everything, then write it to a live table, but the copy I showed here came from the unfiltered copy so that's exactly how it came through.

The MySQL database is UTF-8 encoded; specifically, it says "Server charset: UTF-8 Unicode (utf8)".

There's also the issue of potential device tracking through the upload & storing of user emoji.

What do you mean?