Wait, really? I thought normalization form C was the form where composite characters were always used when possible. Why restrict by the number of codepoints (vs characters) if you're explicitly going to use the form which goes out of its way to use multi-codepoint characters?
The only reason I can think of is that they internally use UTF-32, so counting codepoints is more efficient. But I thought they used UTF-8.
Edit: the other reason I can think of is that conversion to normalization form C already counts the codepoints. Though I can't imagine making it also count characters would be nontrivial.
Most likely, because Twitter is a microblog, and 140 character posts is it's thing.
I'm sure it had some historical technical limitation to 140 ASCII or maybe 70 utf-8 chars (or something else logical), but they probably had to accomodate people who wanted to use non-English characters in a post and not get a lecture on unicode encoding; and some slightly offensive "so ... people like you only get 70 chars" message.
In non-english languages, it is frequent to be restricted to 70 characters/SMS following usage due to a character not fitting in the 7bit GSM Alphabet[0]. When going over, the handset has to switch to UTF-16 (2 bytes per BMP character, 4 for non-BMP characters)
I think Twitter should use whichever usually gives the user the most characters, to prevent them from getting burnt.
I think in many cases, the normalized form is more permissive, as it puts "character plus diacritic" together into one character. In a language with lots of diacritics, the number of codepoints might be more than the number of normalized characters (depending on the client). You wouldn't want to allow (say) ~70 Korean characters on one OS, and 140 on another, just because they use different codepoints to represent certain characters - one with character then diacritic (2 codepoints?), another with both crammed together in one codepoint.
But as I said, I'm not a unicode guru (and I don't know much about Korean, I just saw it as an example). This might be wrong.
No, you're absolutely right that counting by codepoints penalizes some languages. The surrogates I know best are simple, European ones: accents, for example. The normalization twitter uses according to other posters in this thread (the recommended one from the Unicode standards organization, Form C) always uses the multi-codepoint form when possible, for compatibility reasons. That's why it baffles me if they count by codepoint and not character!
> The normalization twitter uses according to other posters in this thread always uses the multi-codepoint form when possible
You're confused, that is NFD (Normalization Form Decomposed). NFC is the result of a canonical composition of the sequence.
> That's why it baffles me if they count by codepoint and not character!
Because "characters" are a fuzzy (if not meaningless) concept in Unicode, especially when talking about the implementation side. "Grapheme cluster" is well defined, but most languages have little support for it.
Codepoints is easy to implement, it's well defined and in many case an NFC codepoint will roughly map onto what users think of as a character.
> Wait, really? I thought normalization form C was the form where composite characters were always used when possible.
NFC is the form where composed codepoints are used the most, hence the "smallest" form post-normalization.
> Why restrict by the number of codepoints (vs characters) if you're explicitly going to use the form which goes out of its way to use multi-codepoint characters?
The only reason I can think of is that they internally use UTF-32, so counting codepoints is more efficient. But I thought they used UTF-8.
Edit: the other reason I can think of is that conversion to normalization form C already counts the codepoints. Though I can't imagine making it also count characters would be nontrivial.