Que signifie le tri dans les langues à deux octets?

Question

J'ai un code qui trie les colonnes de la table par les propriétés de l'objet. Il m'est apparu que dans le Japonais ou le Chinois (non-alphabétique des langues), les chaînes qui sont envoyés à la fonction de tri par rapport à la façon alphabétique langue.

Prenez par exemple une liste de noms de famille Japonais:

寿拘 (Suzuki)
松坂 (Matsuzaka)
松井 (Matsui)
山田 (Yamada)
藤本 (Fujimoto)

Quand j'ai trier la liste ci-dessus via le Javascript, le résultat est:

寿拘 (Suzuki)
山田 (Yamada)
松井 (Matsui)
松坂 (Matsuzaka)
藤本 (Fujimoto)

Ceci est différent de l'ordre des Japonais syllabaire, qui arrangerait la liste phonétiquement (à la manière d'un dictionnaire Japonais serait):

寿拘 (Suzuki)
藤本 (Fujimoto)
松井 (Matsui)
松坂 (Matsuzaka)
山田 (Yamada)

Ce que je veux savoir, c'est:

1. Fait un double-byte character vraiment comparé avec les autres dans une sorte de fonction?
2. Ce qui se passe vraiment dans ce genre?
3. (Crédit supplémentaire) le résultat de telle sorte dire quelque chose? Le concept de tri vraiment travailler dans des pays d'Asie (et d'autres) langues? Si oui, que signifie-t-il et que doit-on viser à la création d'une fonction de comparaison pour ces langues?

---

ADDITIF POUR RÉSUMER LES RÉPONSES ET D'EN TIRER DES CONCLUSIONS:

Tout d'abord, merci à tous ceux qui ont contribué à la discussion. Cela a été très instructif et utile. Spécial shout-out à bobince, Mensonge Ryan, Gumbo, Jeffrey Zheng, et Larry K, pour leur en profondeur et analyses réfléchies. J'ai reçu le coche à Larry K pour me pointer vers une solution à ma question échoué à prévoir, mais j'ai jusqu'-cochée à chaque réponse que j'ai trouvé utile.

Le consensus semble être que:

1. Les chinois et les Japonais, les chaînes de caractères sont triés par des points de code Unicode, et leur ordre peut être fondée sur un raisonnement qui peut être d'une certaine façon intelligible avertis les lecteurs, mais n'est pas susceptible d'être d'une grande valeur pratique pour aider les utilisateurs à trouver l'information qu'ils recherchent.

2. Le type de la fonction de comparaison qui serait nécessaire pour faire une sorte du point de vue sémantique ou phonétique utile, c'est bien trop compliqué à envisager, surtout depuis que les résultats seraient probablement moins satisfaisant, et en tout cas, la comparaison des algorithmes devrait être modifié pour chaque langue. Le meilleur de permettre le tri de procéder, sans même tenter une fonction de comparaison.

3. J'ai été sans doute se poser la mauvaise question ici. C'est, je pensais trop à "l'intérieur de la boîte", sans considérer que la vraie question n'est pas comment faire le tri utile dans ces langues, mais comment dois-je fournir à l'utilisateur un moyen utile de chercher des éléments dans une liste. Les occidentaux pensent automatiquement le tri dans ce but, et j'ai été coupable de cela. Larry K m'a signalé un article de Wikipédia qui suggère une fonction de filtrage peut-être plus utile pour les lecteurs Asiatiques. C'est ce que j'ai l'intention de poursuivre, il est au moins aussi rapide que le tri, le côté client. Je vais garder la colonne de tri parce que c'est bien compris dans les langues Occidentales, et parce que les locuteurs d'une langue serait de trouver le tri des dates et les autres numérique-les types de données utiles. Mais je vais aussi ajouter que le mécanisme de filtrage, ce qui serait utile dans de longues listes pour n'importe quelle langue.

Answer 1

Fait un double-byte character vraiment comparé avec les autres dans une sorte de fonction?

Le natif String type en JavaScript est basé sur le code UTF-16 unités, et c'est ce qui est comparé. Pour les personnages dans le Plan Multilingue de Base (que tous ces sont), c'est la même chose que les points de code Unicode.

Le terme de "double-byte", comme dans les codages comme Shift-JIS a pas de sens dans un contexte web: DOM et les chaînes de caractères JavaScript natif de l'Unicode, l'original octets dans l'encodage de la page reçue par le navigateur sont partis depuis longtemps.

Le résultat de telle sorte dire quelque chose?

Peu. Les points de code Unicode ne prétendons pas offrir toute commande particulière... pour l'un, parce qu'il n'y est pas accepté à l'échelle mondiale de la commande. Même pour le plus fondamental cas de ASCII des caractères latins, les langues sont en désaccord (par exemple. si v et w sont de la même lettre, ou si les majuscules d' i est I ou İ). Et CJK devient beaucoup gnarlier que cela.

Le principal Unicode CJK Unifiée Idéogrammes bloc qui arrive à être commandés par les radicaux et le nombre de coups (dictionnaire Kangxi ordre), ce qui peut être vaguement utile. Mais l'utilisation de caractères à partir de l'autre CJK blocs d'extension, ou de les mélanger dans certains kana, ou romaji, et il n'y aura pas de sens de commande entre eux.

Le Consortium Unicode , ne tenter de définir quelques règles d'ordonnancement, mais c'est complexe et n'est généralement pas tenté dans un niveau de langue. Les systèmes qui en ont vraiment besoin de la langue sensibles au tri des capacités (par exemple. Systèmes d'exploitation, bases de données) ont tendance à avoir leur propre classement des régimes.

Ceci est différent de l'ordre des syllabaires Japonais

Oui. Au-dessus et au-delà de classement en général, il est extrêmement difficile tâche de gérer les kanji avec précision par syllabe, parce que vous avez à deviner la prononciation. JavaScript ne peut pas réaliste de savoir que par "藤本' vous voulez dire ‘Fujimoto "et non pas" touhon, ce genre de chose nécessite en profondeur les dictionnaires intégrés, et encore peu fiables heuristiques... pas le genre de chose que vous voulez intégrer dans un langage de programmation.

Answer 2

Vous pourriez mettre en œuvre l' Unicode Collation Algorithm en Javascript si vous voulez quelque chose de mieux que la valeur par défaut JS trier des chaînes de caractères. Peut améliorer certaines choses. Bien que l'Unicode doc états:

Le classement n'est pas uniforme; elle varie en fonction de la langue et de la culture: Les allemands, les français et les Suédois trier les même les personnages différemment. Il peut également varier en fonction de l'application spécifique: même au sein de la même langue, les dictionnaires peuvent trier différemment les répertoires ou livre des indices. Pour non alphabétique des scripts tels que l'Orient Asiatique idéogrammes, l'assemblage peut être soit phonétique, ou en fonction des l'apparence du personnage.

L' article de Wikipedia souligne que, depuis le classement est si difficile, non alphabétique des scripts, maintenant un jours, la réponse est, il est très facile de rechercher des informations à l'entrée de caractères, plutôt que par la recherche dans une liste.

Je suggère que vous parlez bien informés les utilisateurs finaux de l'application pour voir comment ils feraient mieux de tel pour se comporter. Le problème de la commande des caractères Chinois n'est pas unique à votre demande.

Aussi, si vous ne voulez pas mettre en œuvre le classement dans votre système, une autre solution serait de créer un service Ajax qui stocke les noms dans une base de données MySql ou autre base de données, puis recherche les données avec un relevé de l'ordre.

Answer 3

Les chaînes sont comparées caractère par caractère, où la valeur de point de code définit l'ordre:

La comparaison de chaînes de caractères utilise un simple lexicographique de la commande sur les séquences de la valeur de point de code de valeurs. Il n'y a pas de tenter d'utiliser le plus complexe, du point de vue sémantique orientée définitions de caractère ou une chaîne de l'égalité et de collecte d'ordre défini dans la spécification Unicode. Par conséquent, les chaînes qui sont canoniquement égaux selon le standard Unicode pu tester que l'inégalité. En effet, cet algorithme suppose que les deux chaînes sont déjà normalisées forme.

Si vous avez besoin de plus que cela, vous aurez besoin d'utiliser une comparaison de chaînes de caractères qui peut prendre des classements en compte.

Answer 4

D'autres ont répondu à l'autre question, je vais prendre celui-ci:

que doit-on viser à la création d'un fonction de comparaison pour ces langues?

Une façon de le faire est que, vous aurez besoin de créer un programme qui peut "lire" les personnages; c'est, en mesure de cartographier les hanzi/caractères kanji pour leur "son" (pinyin/hiragana lecture). Au niveau le plus simple, cela signifie une base de données des cartes hanzi/kanji pour les sons. Bien sûr, cela est plus difficile qu'il n'y paraît (pas de jeu de mots destiné), puisque beaucoup de caractères peut avoir différentes prononciations dans différents contextes, et les Chinois ont beaucoup de dialectes différents à prendre en compte.

Une autre façon, est à l'ordre par l'ordre des traits. Cela signifie qu'il y aurait besoin d'être une base de données des cartes hanzi/kanji à leurs coups. Un autre problème: le Chinois et le Japonais écrit dans différents avc commandes. Cependant, à côté de Japonais et de Chinois différence, à l'aide de l'avc de la commande est beaucoup plus homogènes à l'intérieur d'un seul texte, car les hanzi/caractères kanji sont presque toujours écrits à l'aide du même ordre des traits, indépendamment de ce qu'ils signifient, ou la façon dont ils sont lus. Une idée similaire est de trier par radicaux au lieu de la plaine de l'avc commandes.

La troisième voie, est le tri par des points de code Unicode. C'est simple, et donne toujours indiscutablement cohérente de la commande; toutefois, le problème est que l'ordre de tri est dénuée de sens pour l'homme.

La dernière possibilité est de repenser à propos de la nécessité absolue de la commande, et l'utilisation de quelques heuristiques de trier par pertinence pour les besoins de l'utilisateur. Par exemple, dans un logiciel de caddie, vous pouvez les trier en fonction de l'utilisateur habitudes d'achat ou par prix. Ce genre permet d'éviter le problème, mais la plupart du temps ça fonctionne (sauf si vous êtes à la compilation d'un dictionnaire).

Comme vous le remarquez, les deux premières méthodes nécessitent la création d'une énorme base de données de l'un-à-plusieurs de cartographie, mais encore, ils ne donne pas toujours un résultat utile. La troisième méthode, nécessitent également une énorme base de données, mais de nombreux langages de programmation disposent déjà de cette base de données intégré dans la langue. La dernière est un peu de l'heuristique, sans doute plus utile, cependant, ils sont voués à ne jamais donner de la cohérence de la commande (bien pire que les deux premiers de la méthode).

Answer 5

Oui, les personnages peuvent être comparés. Ils sont généralement comparés à partir de leurs points de code Unicode, même si, qui sont assez différentes entre les hiragana et kanji, ce qui fait du tri potentiellement inutiles en Japonais. (Kanji emprunté à partir du Chinois, mais l'ordre qu'ils avaient apparaissent dans le Chinois ne correspondent pas à l'ordre du hiragana qui me représentent le même sens). Il y a des classements qui pourrait rendre certains des personnages de "l'égalité" à des fins de comparaison, mais je ne sais pas si il y en a un qui vais envisager un kanji équivalente à celle de l'hiragana qui me comprennent sa prononciation, surtout depuis qu'un personnage peut avoir un certain nombre de différentes prononciations.

En Chinois ou en coréen, ou d'autres langues qui n'ont pas de 3 alphabets différents (dont un qui est tout à fait irrégulière), il serait probablement moins d'un problème.