News for hackers. Stuff that matters.
Re:Unicode sorting is hard and why browsers added special em... by est on Sunday June 27, 2021 @11:58PM (#27658007)
It's not Unicode sorting is hard, it's mostly because CJK, ideograms, emojis, and many other non-alphabetical languages do not have order.

It's not a bug, it's by design.

Re:Unicode sorting is hard and why browsers added special em... by lifthrasiir on Monday June 28, 2021 @12:32AM (#27658154)
> [...] CJK, ideograms, emojis, and many other non-alphabetical languages do not have order.

Uh, no? Most if not all scripts do have letter order, CJK(V) "ideographs" included. The actual problem is twofold: the letter order might not be unique, and the word order might be completely different from the letter order. CJK(V) "ideographs" exhibit both problems---their word order is phonetic, while letter order is based on shapes and different dictionaries use different rules---and it is very common in Chinese and Japanese that the string meant to be sortable has pronunciation attached (e.g. Wikipedia).

Also, believe it or not, even emojis do have order too [1], albeit arbitrary one.

[1] https://unicode.org/emoji/charts/emoji-ordering.html

Re:Unicode sorting is hard and why browsers added special em... by naniwaduni on Monday June 28, 2021 @01:46AM (#27658509)
Even English a few edge cases where collation order doesn't match letter order: titles are typically ordered ignoring initial A/The, names are often sorted by surname (even when written with given name first); famously, M'/Mc are are traditionally sorted with Mac, along with a host of special cases that get gleefully thrown out in this era of doing very dumb very fast.
Re:Unicode sorting is hard and why browsers added special em... by gumby on Monday June 28, 2021 @12:42AM (#27658192)
It's not sensible to call out non-alphabetic (by which I imagine you exclude all phonemic systems including abjads, syllabaries, etc all of which have full character order.

Even in Latin scripts, sorting order is language-specific and can even be domain specific (e.g. some languages sort phone books differently from dictionaries).

For "CJKV" systems there are ordering methods such as radicals and, as in European languages, ordering can depend on what you want to accomplish.

Re:Unicode sorting is hard and why browsers added special em... by minikomi on Monday June 28, 2021 @01:01AM (#27658282)
Speaking for Japanese, there is certainly an "order" for words, but that order is based on the readings of words, which may be difficult to ascertain from just the string.

https://en.m.wikipedia.org/wiki/Goj%C5%ABon

Eg. Words starting with 一人 can be read as both いちにん (ichinin as in 一人前 - food for one person) or ひとり (hitori - 一人暮らし - living alone)

Re:Unicode sorting is hard and why browsers added special em... by glandium on Monday June 28, 2021 @01:29AM (#27658412)
Also some independent words can have different readings. Eg. 紅葉 is both こうよう and もみじ.
Re:Unicode sorting is hard and why browsers added special em... by naniwaduni on Monday June 28, 2021 @01:49AM (#27658528)
大人気 is my favourite of those, as a particularly long ambiguous homograph where the two common readings don't even have overlapping meanings.
Re:Unicode sorting is hard and why browsers added special em... by glandium on Monday June 28, 2021 @02:09AM (#27658628)
Indeed, that one can be funny especially when split over a line ending. You start reading it as one, and no, it was the other. I've had this experience several times with this specific word.
Re:Unicode sorting is hard and why browsers added special em... by beeforpork on Monday June 28, 2021 @07:23AM (#27660410)
(1) 大人気 (おとなげ, otonage) - maturity

(2) 大人気 (だいにんき, daininki) - very popular

Re:Unicode sorting is hard and why browsers added special em... by esjeon on Monday June 28, 2021 @01:31AM (#27658424)
FYI, Korean alphabet (Hangul) is fully ordered[1], and Korean unicode block[2] strictly follows it.

[1]: https://en.wikipedia.org/wiki/Hangul#Alphabetic_order

[2]: https://unicode.org/charts/PDF/UAC00.pdf

Re:Unicode sorting is hard and why browsers added special em... by est on Monday June 28, 2021 @02:04AM (#27658606)
Hangul has order because it's enumerable. Hanja on the other hand, does not have order and it's not enumerable.

(not enumerable as in written text as strokes can be combined and invented on the fly, enumerable if you think it's a finite charset on computers)

Re:Unicode sorting is hard and why browsers added special em... by yorwba on Monday June 28, 2021 @05:08AM (#27659564)
New characters can be invented on the fly, but not every random scribble would be considered a character. In practice, only a handful of different stroke types are used, which gives even newly invented nonsense characters a recognizable visual style. For any finite stroke count, there's only a finite number of combinations, so the infinte set of characters with unbounded stroke count can be enumerated.

It can also be sorted using the radical and stroke count, although then you can't enumerate it in order because there's an infinite number of possible characters for each radical.

Re:Unicode sorting is hard and why browsers added special em... by oehtXRwMkIs on Monday June 28, 2021 @02:05AM (#27658608)
It's so annoying how "CJK" groups Hangul with completely different writing systems. And even makes people think they're similar.
Re:Unicode sorting is hard and why browsers added special em... by gumby on Monday June 28, 2021 @02:14AM (#27658658)
Well, Hanja can also appear inline in otherwise Hangul texts. Vietnamese has a similar issue though their use of an extended Roman alphabet ended up in a slightly different place, Unicode-wise. I don't remember the decision but I believe it might have been at the request of some RoK people.

There might also be an issue if old Hanja-only texts need to be handled differently from Hanzi rendering/processing. That would not surprise me.

Still, I agree it seems pretty weird.

Re:Unicode sorting is hard and why browsers added special em... by lmm on Monday June 28, 2021 @03:00AM (#27658852)
Hangul and Hiragana are not so dissimilar AFAIK? But the point of saying "CJK" is the other direction: codepoints subject to Han unification may represent Hanzi, Kanji or Hanja.
Re:Unicode sorting is hard and why browsers added special em... by anoncake on Monday June 28, 2021 @04:53PM (#27667962)
Hangul is actually just an alphabet. Each square hangul character is composed of 2-3 letters. Hiragana is a syllabary.
Re:Unicode sorting is hard and why browsers added special em... by DemocracyFTW on Monday June 28, 2021 @06:23AM (#27659991)
> Korean alphabet (Hangul) is fully ordered

Buuuut historically, there have been several ways to arrange Hangul linearly, and the prevailing sorting in dictionaries differes between North and South Korea.

Re:Unicode sorting is hard and why browsers added special em... by lifthrasiir on Monday June 28, 2021 @06:39AM (#27660101)
This is why I had to point out that order does exist, just that there are too many such orders.
Re:Unicode sorting is hard and why browsers added special em... by nitwit005 on Monday June 28, 2021 @01:55AM (#27658554)
Even English has no defined ordering for all characters. What is the ordering of punctuation marks? Do upper case or lower case letters go first? How do you deal with white space characters?

ASCII ordering is just an arbitrary standard that mapped numbers to letters so people could make computer hardware interoperate. It's not always a sensible sort ordering.

Re:Unicode sorting is hard and why browsers added special em... by tyingq on Monday June 28, 2021 @02:29AM (#27658716)
Pedantic, I know, but the original 1963 ASCII document did speak a lot about collation and ordering. Perhaps a lot of it doesn't make sense today, but the sort order wasn't accidental.

http://www.bahaistudies.net/asma/ascii.pdf

Re:Unicode sorting is hard and why browsers added special em... by thaumasiotes on Monday June 28, 2021 @02:53AM (#27658820)
> Even English has no defined ordering for all characters. What is the ordering of punctuation marks? Do upper case or lower case letters go first? How do you deal with white space characters?

This isn't really true; there are well-defined, standardized answers to all of those:

- For purposes of alphabetizing, punctuation marks are completely ignored, as if they weren't present. "Stop me!" and "Stop, me!" are identical strings.

- Case is also ignored. "AAAAAGH" and "aaaAagh" are identical strings.

- Spaces are not ignored. Sort order is determined by the text before the first space. Shorter sorts before longer. "A bird", "a cat", and "a deer" all sort under "a" and above "ab".

Note that these are rules for English, not rules for arbitrary sequences of binary data. They look the way they do because they model the data as a sequence of English words.

Re:Unicode sorting is hard and why browsers added special em... by crazygringo on Monday June 28, 2021 @11:14AM (#27662989)
It's not really well-defined if "ignored" means "sort arbitrarily".

You can't just say "Stop me!" and "Stop, me!" are identical. You have to define which comes first.

Re:Unicode sorting is hard and why browsers added special em... by thaumasiotes on Monday June 28, 2021 @02:40PM (#27665859)
> You can't just say "Stop me!" and "Stop, me!" are identical. You have to define which comes first.

Why? All real-world applications of sorting must handle sorting identical objects. Saying that "Stop me!" and "Stop, me!" are identical doesn't cause any problems that aren't also caused by saying "Stop me!" and "Stop me!" are identical.

Re:Unicode sorting is hard and why browsers added special em... by crazygringo on Monday June 28, 2021 @04:03PM (#27667155)
But they're not identical, they differ by a comma.

It's a desired feature of sorting algorithms that they should be deterministic, in which case arbitrarily ordered input should produce identical output.

Otherwise, having non-deterministic output just makes everything harder -- harder to make comparisons, more work to write tests, etc.

Re:Unicode sorting is hard and why browsers added special em... by thaumasiotes on Monday June 28, 2021 @07:45PM (#27669805)
> But they're not identical, they differ by a comma.

This makes as much sense as saying that "Stop me!" and "Stop me!" aren't identical, because one of them is first and the other is second.

It's true, but it's not relevant to sorting them.

Your "desired feature of sorting algorithms" is most commonly realized as the question of whether the algorithm provides a "stable" sort -- that is, whether two values that compare equal are guaranteed to occur in the same order in the (sorted) output that they did in the (unsorted) input. There are applications where this is considered desirable, and many other applications where it isn't. But there are no applications in which it's not possible for two values to compare equal. For the question of stable sorting to arise in the first place, you have to have already realized that you're going to be sorting things that compare equal.

Re:Unicode sorting is hard and why browsers added special em... by crazygringo on Monday June 28, 2021 @08:21PM (#27670065)
...which is why it's generally desirable for unequal things to never compare equal.

Stability is about preserving the order of items that compare equally. That's a different topic.

I'm talking about it being desirable not to underspecify the comparison function (sorting rules), so that unequal items are never compared as equal.

Re:Unicode sorting is hard and why browsers added special em... by kps on Monday June 28, 2021 @10:30AM (#27662468)
‘Shorter sorts before longer’ is the reason ASCII puts space first and textual punctuation before alphabetics.
Re:Unicode sorting is hard and why browsers added special em... by mjevans on Monday June 28, 2021 @02:27AM (#27658704)
The way most native English speakers (and writers) that I know, including myself, would sort such a set is to ignore the set (regexp) \W . The 'C' (blind bit sorting) Locale is more sensitive and a suitable default for simple machine focused environments.

E.G. of sorting how English humans tend to:

`A string with non-letters ignores the non-letters.

Ace