What are these chars?

Question

How is possible to do this ʘͥͥͥͥͥͥͥͥͥͥͥͥͥͥ͒_ʘͥͥͥͥͥͥͥͥͥͥͥͥͥͥ͒ in a html input field?

Or this:

ه҉̿҉̿҉̿҉̿҉̿҉̿҉̿҉̿҉̿҉̿҉҉҉҉҉҉҉҉҉҉҉҉҉҉ ه҉̿҉̿҉̿҉̿҉̿҉̿҉̿҉̿҉̿҉̿҉҉҉҉҉҉҉҉҉҉҉҉҉҉

I just copied and pasted from a Twitter profile. I guess that they are pasting unicode chars in hex but looking at http://www.htmlescape.net/unicode_charts.html I couldn't find any char that overflow vertically or left.

I'm asking because I want to know how this can be avoided. It's possible that people start to use this and break the look and style of many commentable sites, just like I did. Sorry...

Answer 1

It's so called Combining Diacritical Marks. The code in the question, in particular, uses U+0365 COMBINING LATIN SMALL LETTER I character. You can easily create yourself something very similar right in the browser, using this code:

var iMark = String.fromCharCode(869); // 0x365 in decimal
var testString = 'f' + Array(11).join(iMark); // f with 10 dots above

This behaviour (combining all these marks instead of using just a single one) is well described in the official FAQ:

Q: Unicode doesn't contain the character I need, which is a Latin letter with a certain diacritical mark. Can you add it?

A: Unicode can already express almost anything you will ever need in any field of study by using a combination of Latin, IPA, or other base letters with the various combining diacritical marks. For example, if you need a highly specialized character such as “Z with stroke, cedilla, and umlaut”, you can get this combination by using three existing character codes in combination:

 U+01B5 LATIN CAPITAL LETTER Z WITH STROKE
 U+0327 COMBINING CEDILLA
 U+0308 COMBINING DIAERESIS

With appropriate rendering software, that sequence should produce a glyph combination like this:

Even if the combination is not available in a particular font, it is unambiguous and Unicode conformant systems should transmit and retain the sequence without distortion, and it may be processed programmatically.

How to deal with this (potential) nastiness without affecting the valid texts? One possible approach, I suppose, is normalizing (NFC) the strings first, then stripping away all the non-valid characters.