2015-11-12 17 views
12

Próbuję zamówić listę krajów w języku chińskim za pomocą Locale.SIMPLIFIED_CHINESE, która wydaje się, że zamawia za pomocą pinyin (alfabet fonetyczny, czyli znaki są sortowane zgodnie z ich kombinacji korespondenta łacińskiego , od A do Z).Niewłaściwe sortowanie za pomocą programu Collator przy użyciu Locale.SIMPLIFIED_CHINESE

Ale znalazłem kilka przypadków, gdy zamówienia są złe. Na przykład:

  • '中' postać jest zhong1
  • znak '梵' jest fan4

odpowiedniej kolejności powinny być 梵 < 中, ale zamiast tego jest zamawiany w inny sposób.

String[] characters = new String[] {"梵", "中"}; 
List<String> list = Arrays.asList(characters); 
System.out.println("Before sorting..."); 
System.out.println(list.toString()); 

Collator collator = Collator.getInstance(Locale.SIMPLIFIED_CHINESE); 
collator.setStrength(Collator.PRIMARY); 
Collections.sort(list, collator); 

System.out.println("After sorting..."); 
System.out.println(list.toString()); 

Wyniki tego fragmentu są:

Before sorting... 
[梵, 中] 
After sorting... 
[中, 梵] 

Idąc głębiej, znalazłem zasady, które stosuje się z Locale.SIMPLIFIED_CHINESE Java. Można znaleźć w następnym obrazie: http://postimg.org/image/4t915a7gp/full/ (Zauważ, że 梵 jest po 中)

zdałem sobie sprawę przed < 口 < 口 < 口 < 口 < 口 że podświetlone na czerwono, wszystkie znaki są sortowane według ich łacińskiego korespondenta kombinacja, od A do Z. Jednak po znaku 01 < 口 口 < znaki są uporządkowane według kompozycji postaci. Na przykład, jeśli wszystkie postacie mają tę samą część (zazwyczaj lewą część postaci), są one następnie zgrupowane razem, a nie zgodnie z regułą od A do Z.

Również wszystkie znaki po < 口 口 < < < 口 口 口 < są rzadsze znaków chińskich. Więc 梵 jest mniej powszechnym znakiem niż 中, więc jest umieszczany po 口 < 口 < 口.

Zastanawiam się, dlaczego ta decyzja, jeśli jest celowo. Ale powoduje błędne sortowanie. Nie wiem, jak znaleźć rozwiązanie tego problemu.

Wielkie dzięki za poświęcony czas!

+0

Czy próbowałeś za pomocą icu4j? – fge

+0

Próbowałem pinyin4j, a ich kolejność jest dobra. icu4j jeszcze nie próbuję. Ale moje pytanie dotyczy tego, dlaczego Oracle postępuje zgodnie z tymi regułami, być może jest to błąd do zgłoszenia, lub może jest inny sposób wykorzystania Java API do sortowania z konwencjami pinyin. W mojej firmie trudno jest dodawać nowe biblioteki z powodu odpowiedzialności. Dzięki za wsparcie! – elegarpes

Odpowiedz

2

Porządek sortowania dostarczony przez moduł gromadzący w języku Java jest oparty na skokach potrzebnych do napisania tej litery.

Zobacz poniżej mały fragment, aby zademonstrować. numery Stroke zaczerpnięte z Wikitionary

// the unicode character and the number of strokes 
String[] characters = new String[]{ 
    "\u68B5 (11)", "\u4E2D (4)", 
    "\u5207 (4)", "\u5973 (3)", "\u898B (7)" 
}; 
List<String> list = Arrays.asList(characters); 
System.out.println("Before sorting..."); 
System.out.println(list.toString()); 

Collator collator = Collator.getInstance(Locale.TRADITIONAL_CHINESE); 
collator.setStrength(Collator.PRIMARY); 
System.out.println(); 
Collections.sort(list, collator); 

System.out.println("After sorting..."); 
System.out.println(list.toString()); 

wyjściu

Before sorting... 
[梵 (11), 中 (4), 切 (4), 女 (3), 見 (7)] 

After sorting... 
[女 (3), 中 (4), 切 (4), 見 (7), 梵 (11)] 

Jest prośba wzmocnienie JDK-6415666 wdrożyć sortowania według kolejności sortowania Unicode. Ale śledzenie informacji o Java 8 supported locale nie zostało zaimplementowane w Javie 8.

edit Kolejność sortowania za pomocą Collator z icu4j jest

[梵 (11), 見 (7), 女 (3), 切 (4), 中 (4)] 

kod ICU4J fragment

import com.ibm.icu.text.Collator; 
import com.ibm.icu.text.RuleBasedCollator 
... 
Locale locale = new Locale("zh", "", "PINYIN"); 
Collator collator = (RuleBasedCollator) Collator.getInstance(locale); 
Powiązane problemy