Sıralama neden ɛ = e diyor?


25

ɛ("Latin epsilon") bazı Afrika dillerinde, genellikle İngilizce "yatakta" ünlü harfini temsil etmek için kullanılan bir harftir. Unicode'da U + 025B olarak kodlanmıştır, her günden çok farklı e.

Ancak, eğer sortaşağıdakileri yaparsam :

eb
ed
ɛa
ɛc

Bu sortgöz önünde bulundurur ɛve eeşdeğer görünüyor :

ɛa
eb
ɛc
ed

Burada neler oluyor? Ve amaçlarına göre yapmanın ɛve eayırt etmenin bir yolu var sortmı?


21
sıralama kuralları 'harmanlama' olarak adlandırılır, bu googlinginize yardımcı olursa
BlueRaja - Danny Pflughoeft 26:18

1
Bir metin dosyasının içine eakarışık bir sayı koymayı deneyin ɛave sıralayın. Daha eaönce her zaman sıraladığını göreceksiniz ɛa. Yani hayır, eşit kabul edilmezler.
Bakuriu,

Belli bir nokta olabilir, ancak henüz açıkça önerildiğini görmedim: sözcükleri $ (sort_african_language) şeklinde sıralıyorsanız, yapılacak doğal şey yerel ayarı $ (certain_african_language) olarak ayarlamaktır.
Federico Poloni

@FedericoPoloni Çok iyi bir nokta! Ne yazık ki bu dil için yapılmış herhangi bir yerel ayar bulamadım.
Draconis

1
@ GermánBouzas Bu, özellikle Latin alfabesine uyması için tasarlanmış bir form olan "Latin epsilon" dur. Hemen hemen aynı görünüyorlar, ancak Latin epsilonu U + 025B, Yunanca epsilon ise U + 03B5.
Draconis

Yanıtlar:


67

Hayır, onları eşdeğer olarak görmüyor, sadece aynı birincil ağırlığa sahipler. Böylece, ilk yaklaşımda aynı şekilde sıralarlar.

Bir GNU sisteminde / usr / share / i18n / locales / iso14651_t1_common'a (çoğu yerel ayar için temel olarak kullanılır) bakarsanız (burada glibc 2.27 ile birlikte) göreceksiniz:

<U0065> <e>;<BAS>;<MIN>;IGNORE # 259 e
<U025B> <e>;<PCL>;<MIN>;IGNORE # 287 ɛ
<U0045> <e>;<BAS>;<CAP>;IGNORE # 577 E

e, ɛVe Eaynı birincil ağırlığa sahip eve Eaynı ikincil ağırlığı, sadece üçüncü ağırlık bunları ayırır.

Dizeleri karşılaştırırken, sort( strcoll()standart libc işlevi dizeleri karşılaştırmak için kullanılır), tüm karakterlerin birincil ağırlıklarını karşılaştırarak başlar ve dizelerin birincil ağırlıklara eşit olması durumunda yalnızca ikinci ağırlığa gider (ve diğer ağırlıklarla vb.) .

İlk yaklaşımda durum sıralama düzeninde göz ardı ediliyor gibi görünüyor. Abarasındaki sıralar aave acancak Absıralama önce veya sonra olabilir ab(bazı diller var dil kuralına bağlı olarak <MIN>önce <CAP>İngiliz İngilizcesi, bazılarında gibi <CAP>önce <MIN>Estonya gibi).

Eğer eaynı sıralama düzenini olarak vardı ɛ, printf '%s\n' e ɛ | sort -usadece bir satır döndürecektir. Ama <BAS>türlü önce <PCL>, etek başına sıralar önce ɛ . eɛesonradan EEE(ikincil ağırlıkta) EEEsonradan sıralama yapar eee(bunun için üçüncü ağırlığa çıkmamız gerekir).

Şimdi eğer sistemimde glibc 2.27 varsa, çalıştırıyorum:

sed -n 's/\(.*;[^[:blank:]]*\).*/\1/p' /usr/share/i18n/locales/iso14651_t1_common |
  sort -k2 | uniq -Df1

Aynı 4 ağırlıkta tanımlanmış birkaç karakterin olduğunu fark edeceksiniz. Özellikle, bizim our ile aynı ağırlıklara sahiptir:

<U01DD> <e>;<PCL>;<MIN>;IGNORE
<U0259> <e>;<PCL>;<MIN>;IGNORE
<U025B> <e>;<PCL>;<MIN>;IGNORE

Ve elbette:

$ printf '%s\n' $'\u01DD' $'\u0259' $'\u025B' | sort -u
ǝ
$ expr ɛ = ǝ
1

Bu GNU libc yerellerinin bir böceği olarak görülebilir. Diğer çoğu sistemde, yerel ayarlar, tüm farklı karakterlerin sonunda farklı sıralama düzenine sahip olduğundan emin olun. Bir sıralama düzeni var ve aynı sıralama sonunda yok karakterlerin binlercesi var GNU yerel üzerinde, kırılma gibi (sorunların her türlü neden, hatta kötüleşir comm, join, lsdeterministik olmayan emir sahip veya Neználkovo ... ), bu nedenle bu sorunlar etrafında çalışmak için kullanmaLC_ALL=C önerisi .

Yorumlarda @ ninjalj tarafından belirtildiği gibi, Ağustos 2018'de yayımlanan glibc 2.28, AFAICS'te yine de aynı sıralama düzeninde tanımlanmış bazı karakterler veya harmanlama öğeleri olmasına rağmen, bu cephede bazı iyileştirmelerle geldi. Ubuntu 18.10'da, glibc 2.28 ve en_GB.UTF-8 yerel ayarında.

$ expr $'L\ub7' = $'L\u387'
1

(U + 00B7 neden yalnızca L/ ?! ile birleştiğinde U + 0387 olarak eşdeğer sayılır l?)

Ve:

$ perl -lC -e 'for($i=0; $i<0x110000; $i++) {$i = 0xe000 if $i == 0xd800; print chr($i)}' | sort > all-chars-sorted
$ uniq -d all-chars-sorted | wc -l
4
$ uniq -D all-chars-sorted | wc -l
1061355

(hala 1 milyondan fazla karakter (Unicode aralığının% 95'i, 2.27'de% 98'den düşme), sıralama düzenleri tanımlanmadığı gibi diğer karakterlerle aynı sıralamada bulunur).

Ayrıca bakınız:


3
Bu tam olarak aradığım şeydi! <PCL>Bütünlüğü için ne anlama geliyor ? Diğerleri Başkent, Minik ve Temel görünüyor?
Draconis

3
@Draconis, harmanlama sembolü <PCL> # 16 parçacıklı / tuhaf
Stéphane Chazelas

Gerçekten de bir dosyaya bir demet koyar eave ɛakarıştırırsak, sorther şeyin eas'den önce sıralandığını görürüz ɛa.
Bakuriu

2
Glibc'nin 2.28 itibaren codepoint bir 4 seviyeli ağırlığı için son çare olarak kullanılmalıdır, bkz sourceware.org/git/... sourceware.org/bugzilla/show_bug.cgi?id=14095
ninjalj

1
@ cat, üzgünüm, demek istediğim strcoll(), düzenlemeye bakın.
Stéphane Chazelas 27:18

15

erkek sıralama:

   ***  WARNING  ***  The locale specified by the environment affects sort
   order.  Set LC_ALL=C to get the traditional sort order that uses native
   byte values.

O zaman dene: LC_ALL=C sort file.txt


1
Bu çalışır! Peki neden varsayılan yerel ayar bu tamamen ayrı kod noktalarının aynı olduğunu düşünüyor? Bunun neden olduğunu merak ediyorum.
Draconis

@Draconis "Varsayılan yerel ayar" nedir?
Kamil Maciorowski

@KamilMaciorowski Çevre değişkeninin boş bir değeri; Hangi bölgeye karşılık geldiğinden emin değilim.
Draconis

3
@ Boşsa LC_ALL, boşsa, sortdiğer LC_*değişkenleri LANGveya bazı yapılandırma dosyalarını kullanabilir.
NieDzejkob

1
LC_COLLATEdize sıralama özgü olanı, LANGekstra genel olanıdır.
ShadowRanger

8

Ɛ karakteri e ile aynı değildir, ancak bazı yerler harmanlama üzerine bu işaretleri birbirine yakın toplayabilir. Bunun nedeni dile özgüdür, fakat aynı zamanda bazı tarihsel ya da hatta politik arka plandır. Örneğin, çoğu insan muhtemelen € uro para biriminin Avrupa’ya sözlükten yaklaşmasını beklemektedir .

Neyse şu anda çalıştırmak kullandığınız harmanlamadan görmek için locale, locale -asize sistemde ve değişim harmanlama söz hakkından mevcut bölgelerin listesine verecektir Csadece için bir sıralama vadede LC_COLLATE=C sort file. Sonunda, farklı yerel ayarların dosyanızı nasıl sıralayabildiğini görmek için

for loc in $(locale -a)
    do echo ____"${loc}"____
    LC_COLLATE="$loc" sort file
done

İhtiyacınıza uygun yerel ayarı seçmek için sonucu bir parça pişirme aletine bağlayın.


Bu harika bir açıklama, ancak semboller birbirleriyle yakın değil aynı görünüyorlar.
Draconis

1
Hayır, aynı sayılmazlar. Düz ekle eadaha sonra, dosyaya satır sort -usize hem alacak eave ɛaçıktıda. Harmanlamaya karşı en iyi strateji avoid ( export LC_COLLATE=C) işlevidir . Aksi takdirde, birçok çirkin şeyler olacaktır (örn. /tmp/[a-z]Yer bashmaç olacak /tmp/ave /tmp/Aancak /tmp/Z).
mosvy

@ mosvy Huh, ilginç… bu yüzden sipariş amaçları için aynı sayılıyorlar ama benzersiz amaçlar için değiller?
Draconis

aynı sayılmazlar. bkz burada bu konuda bir açıklama.
mosvy

1
glibc fnmatch()ve regexp aralıklarında sabitlenebilen @ ninjalj, ancak bazılarını bashkullanarak kendi aralığını uygulayanlar değildir strcoll(). ksh93, aralık uygulamasının kullandığı strcoll()ve aynı zamanda aralık sonlarının durumunu kontrol ettiği ve her iki ucun da küçük olması durumunda yalnızca küçük harflerle eşleştiği için sorunu hiç yaşamadı . zsh aralıkları, strcoll () değil kod noktasına göre yapıldığı gibi bir sorun yaratmaz.
Stéphane Chazelas
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.