Live data from Hacker News

Why we can't process Emoji anymore

gist.github.com

81–90 of 162 posts

Re: Why we can't process Emoji anymore

#81
A couple of reasons why it makes sense for V8 and other vendors to use UCS2:

- The spec says UCS2 or UTF16. Those are the only options.

- UCS2 allows random access to characters, UTF-16 does not.

- Remember how the JS engines were fighting for speed on arbitrary benchmarks, and nobody cared about anything else for 5 years? UCS2 helps string benchmarks be fast!

- Changing from UCS2 to UTF-16 might "break the web", something browser vendors hate (and so do web developers)

- Java was UCS2. Then Java 5 changed to UTF-16. Why didn't JS change to UTF-16? Because a Java VM only has to run one program at once! In JS, you can't specify a version, an encoding, and one engine has to run everything on the web. No migration path to other encodings!

Re: Why we can't process Emoji anymore

#82
post #80

Earlier quoted context omitted.

Why do you want to count Unicode characters? Why do you care if it is fast to do so? Why would you ever need to use character-based string indexing? UTF-16 solves problems that don't exist. (Honestly, I would love it if someone could explain what the purpose of counting characters is, because I don't know why you'd ever do that, except when you're posting to Twitter.)

> Why do you want to count Unicode characters? Because, there are other countries which use more than English language? I fucking hate you ascii-centric ignorant morons sometimes, you know, for example - display welcome message character by character fro left to right - Extract the first character because it's always the surname - catch two non-ascii keyword and find its index in a string In the first example, should…

I think you misunderstand. I wasn't asking why Unicode characters should be counted instead of bytes or ASCII characters, I was asking why you would even want to count characters at all.

> I fucking hate you ascii-centric ignorant morons

Nice.

> You ignorant, arrogant fuck.

This is why I quit posting under an alias, so I wouldn't be tempted to say such things.

> display welcome message character by character fro left to right

UTF-16/UCS-4/UCS-2 doesn't solve anything here. Counting characters doesn't help. For example, imagine if you try to print Korean character-by-character. You might get some garbage like this:

    ᄋ
    아
    안
    안ᄂ
    안녀
    안녕
    안녕ᄒ
    안녕하
    안녕하ᄉ
    안녕하세
    안녕하세ᄋ
    안녕하세요
Fixed width encodings do not solve this problem, and UTF-8 does not make this problem more difficult. I am honestly curious why you would need to count characters -- at all -- except for posting to Twitter.

Splitting on characters is garbage. (This example was done in Python 3, so everything is properly encoded, and there is no need to use the 'u' prefix. The 'u' prefix is a nop in Python 3. It is only there for Python 2.x compatibility.)

    >>> x
    '안녕하세요'
    >>> x[2:4]
    'ᆫᄂ'
I tried in the Google Chrome console, too:

    > '안녕하세요'.substr(2,2)
    "하세"
    > '안녕하세요'.substr(2,2)
    "ᆫᄂ"
I'm not even leaving the BMP and it's broken! You seem to be blaming encoding issues but I don't have any issues with encoding. It doesn't matter if Chrome uses UCS-2 or Python uses UCS-4 or UCS-2, what's happening here is entirely expected, and it has everything to do with Jamo and nothing to do with encodings.

    >>> a = '안녕하세요'
    >>> b = '안녕하세요'
    # They only look the same
    >>> len(a)
    5
    >>> len(b)
    12
    >>> def p(x):
    ...     return ' '.join(
                'U+{:04X}'.format(ord(c)) for c in x)
    
    >>> print(' '.join('U+{:04X}'.format(ord(c))
              for c in b))
    >>> print(p(a))
    U+C548 U+B155 U+D558 U+C138 U+C694
    >>> print(p(b))
    U+110B U+1161 U+11AB U+1102 U+1167 U+11BC U+1112 U+1161 U+1109 U+1166 U+110B U+116D
See? Expected, broken behavior you get when splitting on character boundaries.

If you think you can split on character boundaries, you are living in an ASCII world. Unicode does not work that way. Don't think that normalization will solve anything either. (Okay, normalization solves some problems. But it is not a panacea. Some languages have grapheme clusters that cannot be precomposed.)

Fixed-width may be faster for splitting on character boundaries, but splitting on character boundaries only works in the ASCII world.

Re: Why we can't process Emoji anymore

#83
post #80

Earlier quoted context omitted.

Why do you want to count Unicode characters? Why do you care if it is fast to do so? Why would you ever need to use character-based string indexing? UTF-16 solves problems that don't exist. (Honestly, I would love it if someone could explain what the purpose of counting characters is, because I don't know why you'd ever do that, except when you're posting to Twitter.)

> Why do you want to count Unicode characters? Because, there are other countries which use more than English language? I fucking hate you ascii-centric ignorant morons sometimes, you know, for example - display welcome message character by character fro left to right - Extract the first character because it's always the surname - catch two non-ascii keyword and find its index in a string In the first example, should…

Could you not have communicated your examples without the hostility?

Re: Why we can't process Emoji anymore

#84
post #80

Earlier quoted context omitted.

> Why do you want to count Unicode characters? Because, there are other countries which use more than English language? I fucking hate you ascii-centric ignorant morons sometimes, you know, for example - display welcome message character by character fro left to right - Extract the first character because it's always the surname - catch two non-ascii keyword and find its index in a string In the first example, should…

I think you misunderstand. I wasn't asking why Unicode characters should be counted instead of bytes or ASCII characters, I was asking why you would even want to count characters at all. > I fucking hate you ascii-centric ignorant morons Nice. > You ignorant, arrogant fuck. This is why I quit posting under an alias, so I wouldn't be tempted to say such things. > display welcome message character by character fro left…

> Counting characters doesn't help.

Why? If you can count characters (code points) then it's natural that you can split or substring by characters.

Try this in javascript:

    '안녕하세요'.substr(2,2)
Internally Fixed length encoding is much faster than variable-length encoding.

> Unicode does not work that way.

It DOES.

> Splitting on characters is garbage.

You messed up Unicode in Python in so many levels. Those characters you seen in Python console is, actually not Unicode. These are just bytes in sys stdout that happens be to correctly decoded and properly displayed. You should always use the u'' for any kind of characters. '안녕하세요' is WRONG and may lead to unspecified behaviors, it depends on your source code file encoding, intepreter encoding and sys default encoding, if you display them in console it depends on the console encoding, if it's GUI or HTML widget it depends on the GUI widget or content-type encoding.

> I'm not even leaving the BMP and it's broken!

Your unicode-fu is broken. Looks like your example provided identical Korean strings, which might be ICU module in Chrome auto normalized for you.

> You can't split decomposed Korean on character boundaries.

In a broken unicode implementation, like Chrome browser v8 js engine.

> I happen to be using Python 3. It is internally using UCS-4.

For the love of BDFL read this

http://www.python.org/dev/peps/pep-0414/

http://docs.python.org/3/whatsnew/3.3.html

Re: Why we can't process Emoji anymore

#85
post #84

Earlier quoted context omitted.

I think you misunderstand. I wasn't asking why Unicode characters should be counted instead of bytes or ASCII characters, I was asking why you would even want to count characters at all. > I fucking hate you ascii-centric ignorant morons Nice. > You ignorant, arrogant fuck. This is why I quit posting under an alias, so I wouldn't be tempted to say such things. > display welcome message character by character fro left…

> Counting characters doesn't help. Why? If you can count characters (code points) then it's natural that you can split or substring by characters. Try this in javascript: '안녕하세요'.substr(2,2) Internally Fixed length encoding is much faster than variable-length encoding. > Unicode does not work that way. It DOES. > Splitting on characters is garbage. You messed up Unicode in Python in so many levels. Those characters…

I'm sorry but you're wrong. I suggest you inform yourself better of the subject you're talking about before you call people "ignorant morons" next time.

dietrichepp is talking about Normalized Form D, which is a valid form of Unicode and cannot be counted using codepoints like you're doing.

Maybe you can try:

'𠀋'.substr(0,1)

Re: Why we can't process Emoji anymore

#86
post #85
post #84

Earlier quoted context omitted.

> Counting characters doesn't help. Why? If you can count characters (code points) then it's natural that you can split or substring by characters. Try this in javascript: '안녕하세요'.substr(2,2) Internally Fixed length encoding is much faster than variable-length encoding. > Unicode does not work that way. It DOES. > Splitting on characters is garbage. You messed up Unicode in Python in so many levels. Those characters…

I'm sorry but you're wrong. I suggest you inform yourself better of the subject you're talking about before you call people "ignorant morons" next time. dietrichepp is talking about Normalized Form D, which is a valid form of Unicode and cannot be counted using codepoints like you're doing. Maybe you can try: '𠀋'.substr(0,1)

yeah sure why not.

    >>> u'𡘓'[0:1]
    u'\U00021613'

    >>> u'Hi, Mr𡘓'[-1]
    u'\U00021613

    >>> u'𠀋'[0:1]
    u'\U0002000b'

Javascript won't work because UCS2 in js engine, duh.

Actually Javascript is messed up with Unicode string and binary strings, that's why Nodejs invented Buffer

http://nodejs.org/api/buffer.html

Re: Why we can't process Emoji anymore

#87
post #84

Earlier quoted context omitted.

I think you misunderstand. I wasn't asking why Unicode characters should be counted instead of bytes or ASCII characters, I was asking why you would even want to count characters at all. > I fucking hate you ascii-centric ignorant morons Nice. > You ignorant, arrogant fuck. This is why I quit posting under an alias, so I wouldn't be tempted to say such things. > display welcome message character by character fro left…

> Counting characters doesn't help. Why? If you can count characters (code points) then it's natural that you can split or substring by characters. Try this in javascript: '안녕하세요'.substr(2,2) Internally Fixed length encoding is much faster than variable-length encoding. > Unicode does not work that way. It DOES. > Splitting on characters is garbage. You messed up Unicode in Python in so many levels. Those characters…

Code points aren't letters.

Consider the following sequence of code points: U+0041 U+0308 [edit: corrected sequence]

That equals this european letter: Ä

Two code points, one letter. MAGIC! You can also get the same-looking letter with a single code point using U+00C4 (unicode likes redundancy).

Not all languages have letters. Not all languages that have letters represent each one with a single code point. Please think twice before calling people "morons."

Re: Why we can't process Emoji anymore

#88
post #85
post #84

Earlier quoted context omitted.

> Counting characters doesn't help. Why? If you can count characters (code points) then it's natural that you can split or substring by characters. Try this in javascript: '안녕하세요'.substr(2,2) Internally Fixed length encoding is much faster than variable-length encoding. > Unicode does not work that way. It DOES. > Splitting on characters is garbage. You messed up Unicode in Python in so many levels. Those characters…

I'm sorry but you're wrong. I suggest you inform yourself better of the subject you're talking about before you call people "ignorant morons" next time. dietrichepp is talking about Normalized Form D, which is a valid form of Unicode and cannot be counted using codepoints like you're doing. Maybe you can try: '𠀋'.substr(0,1)

[deleted]

Re: Why we can't process Emoji anymore

#89
post #87
post #84

Earlier quoted context omitted.

> Counting characters doesn't help. Why? If you can count characters (code points) then it's natural that you can split or substring by characters. Try this in javascript: '안녕하세요'.substr(2,2) Internally Fixed length encoding is much faster than variable-length encoding. > Unicode does not work that way. It DOES. > Splitting on characters is garbage. You messed up Unicode in Python in so many levels. Those characters…

Code points aren't letters. Consider the following sequence of code points: U+0041 U+0308 [edit: corrected sequence] That equals this european letter: Ä Two code points, one letter. MAGIC! You can also get the same-looking letter with a single code point using U+00C4 (unicode likes redundancy). Not all languages have letters. Not all languages that have letters represent each one with a single code point. Please thin…

> Two code points, one letter.

Yes I under stand there are million ways to display the same shape using various unicode. But how does that make code point counting impossible?

AND if you explictly using COMBINING DIAERESIS instead of single U+00C4, counting diaeresis separately is wrong somehow?

Why don't we make a law stating that both ae and æ is single letter?

Re: Why we can't process Emoji anymore

#90
post #86
post #85

Earlier quoted context omitted.

I'm sorry but you're wrong. I suggest you inform yourself better of the subject you're talking about before you call people "ignorant morons" next time. dietrichepp is talking about Normalized Form D, which is a valid form of Unicode and cannot be counted using codepoints like you're doing. Maybe you can try: '𠀋'.substr(0,1)

yeah sure why not. >>> u'𡘓'[0:1] u'\U00021613' >>> u'Hi, Mr𡘓'[-1] u'\U00021613 >>> u'𠀋'[0:1] u'\U0002000b' Javascript won't work because UCS2 in js engine, duh. Actually Javascript is messed up with Unicode string and binary strings, that's why Nodejs invented Buffer http://nodejs.org/api/buffer.html

You've moved the goalposts:

  u'\U00021613'
This is a UTF-32 code unit, not a UTF-16 code unit. Even UTF-32 doesn't help when you have combining characters. I suggest you read dietrichepp's post again, he's talking about Normalization Form D.
Post reply on HN