Qu'est-ce que le tri signifie dans les langues non alphabétiques (c'est-à-dire asiatiques)?

Vous pouvez implémenter l' Algorithme de collage Unicode en Javascript si vous voulez quelque chose de mieux que le type JS par défaut pour les chaînes. Peut-être améliorer certaines choses. Bien que le doc Unicode indique:

La collation n'est pas uniforme; Il varie en fonction de la langue et de la culture: les Allemands, les Français et les Suédois trient les mêmes caractères différemment. Il peut également varier selon une application spécifique: même dans la même langue, les dictionnaires peuvent trier différemment que les annuaires téléphoniques ou les livres. Pour les scripts non alphabétiques tels que les idéogrammes de l'Asie de l'Est, le classement peut être soit phonétique, soit basé sur l'apparence du personnage.

L' article de Wikipedia souligne que, puisque le classement est tellement difficile dans les scripts non alphabétiques, maintenant un jour la réponse est de rendre très facile de rechercher des informations en entrant des caractères, plutôt que de regarder dans une liste.

Je vous suggère de parler à des utilisateurs finaux vraiment compétents de votre application pour voir comment ils se croiraient mieux. Le problème de la commande de caractères chinois n'est pas unique à votre application.

En outre, si vous ne souhaitez pas implémenter le classement dans votre système, une autre solution vous permettrait de créer un service Ajax qui stocke les noms dans une base de données MySql ou autre, puis recherche les données avec un énoncé de commande.

Un personnage à deux octets est-il vraiment comparé à l'autre dans une fonction de tri?

Le type de String native dans JavaScript est basé sur les unités de code UTF-16, et c'est ce qui est comparé. Pour les caractères dans le plan multilingue de base (ce que tout cela est), c'est le même que les points de code Unicode.

Le terme «double-octet» comme dans les encodages comme Shift-JIS n'a aucun sens dans un contexte Web: les chaînes DOM et JavaScript sont natives Unicode, les octets d'origine dans la page encodée reçue par le navigateur ont disparu depuis longtemps.

Le résultat d'un tel genre signifie-t-il quelque chose?

Peu. Les points de code Unicode ne prétendent pas proposer une commande particulière … pour un, car il n'y a pas de commande acceptée globalement. Même pour le cas le plus simple de caractères latins ASCII, les langues sont en désaccord (par exemple, si v et w sont la même lettre, ou si les majuscules de i sont I ou İ ). Et CJK devient beaucoup plus génial que ça.

Le bloc Unicode CJK Unified Ideographs en bloc est classé par ordre radical et nombre de traits (ordre du dictionnaire Kangxi), ce qui peut être vaguement utile. Mais utilisez des caractères à partir de n'importe quel autre bloc d'extension CJK, ou mélangez-en certains kana ou romaji, et il n'y aura aucun ordre significatif entre eux.

Le Consortium Unicode tente de définir certaines règles de commande générales, mais il est complexe et n'est généralement pas tenté au niveau de la langue. Les systèmes qui ont vraiment besoin de capacités de tri sensibles au langage (par exemple, OS, bases de données) ont tendance à avoir leurs propres schémas de classement.

Ceci est différent de l'ordre du syllabaire japonais

Oui. Au-delà et au-delà des problèmes de classement en général, il s'agit d'une tâche extrêmement difficile à gérer avec exactitude les kanji par syllabe, car il faut deviner la prononciation. JavaScript ne peut pas savoir de façon réaliste que par '藤 本' vous voulez dire 'Fujimoto' et non 'touhon'; Ce type de chose nécessite des dictionnaires intégrés en profondeur et des heuristiques encore peu fiables … pas le genre de chose que vous voulez construire dans un langage de programmation.

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

La comparaison des chaînes utilise une commande lexicographique simple sur les séquences de valeurs de valeur de point de code. Il n'y a aucune tentative d'utiliser les définitions de caractère ou de chaîne plus complexes et sémantiquement orientées, et l'ordre de classement défini dans la spécification Unicode. Par conséquent, les chaînes qui sont canoniquement égales selon la norme Unicode pourraient tester l'inégalité. En effet, cet algorithme suppose que les deux chaînes sont déjà sous forme normalisée.

Si vous avez besoin de plus que cela, vous devrez utiliser une comparaison de chaînes qui peut prendre en compte les collations.

D'autres ont répondu aux autres questions, je prendrai celle-ci:

Que faut-il rechercher pour créer une fonction de comparaison pour ces langues?

Une façon de le faire est que vous devrez créer un programme capable de "lire" les caractères; C'est-à-dire capable de mapper les personnages hanzi / kanji à leur «son» (lecture pinyin / hiragana). Au niveau le plus simple, cela signifie une base de données qui mène les hanzi / kanji aux sons. Bien sûr, cela est plus difficile qu'il n'y paraît (jeu de mots non prévu), car beaucoup de personnages peuvent avoir des prononciations différentes dans différents contextes, et les chinois ont beaucoup de dialectes différents à considérer.

Une autre façon, c'est de commander par ordre de course. Cela signifie qu'il devrait y avoir une base de données qui trace les hanzi / kanji à leurs traits. Un autre problème: les écrits chinois et japonais dans différents ordres d'AVC. Cependant, en dehors de la différence japonaise et chinoise, l'utilisation de l'ordre des trajets est beaucoup plus cohérente dans un seul texte, puisque les caractères hanzi / kanji sont presque toujours écrits en utilisant le même ordre de course indépendamment de ce qu'ils ont signifié ou de leur lecture. Une idée similaire est de classer par radicaux au lieu d'ordres de trajectoire simple.

La troisième façon est trier par code Unicode. C'est simple, et donne toujours des ordres incontestablement cohérents; Cependant, le problème est que l'ordre de tri n'a pas de sens pour l'homme.

La dernière façon est de repenser la nécessité d'une commande absolue et d'utiliser certaines heuristiques pour trier en fonction des besoins de l'utilisateur. Par exemple, dans un logiciel de panier, vous pouvez trier selon les habitudes d'achat de l'utilisateur ou par prix. Cela évite le problème, mais la plupart du temps il fonctionne (sauf si vous compilez 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 mappage un-à-plusieurs, mais ils ne donnent toujours pas toujours un résultat utile. La troisième méthode nécessite également une base de données énorme, mais de nombreuses langues de programmation ont déjà intégré cette base de données dans la langue. La dernière façon est un peu heuristique, probablement plus utile, mais ils sont condamnés à ne jamais donner une commande constante (bien pire que la première méthode).

Oui, les personnages sont comparés. Ils sont généralement comparés en fonction de leurs points de code Unicode, ce qui est très différent entre hiragana et kanji – ce qui rend le tri potentiellement inutile en japonais. (Kanji emprunté aux Chinois, mais l'ordre qu'ils apparaissaient en chinois ne correspond pas à l'ordre de la hiragana qui représenterait la même signification). Il y a des collations qui pourraient rendre certains des caractères «égaux» à des fins de comparaison, mais je ne sais pas s'il y en a un qui considérera qu'un kanji est équivalent à l'hiragana qui comprend sa prononciation – d'autant plus qu'un personnage Peut avoir un certain nombre de prononciations différentes.

En chinois ou en coréen, ou dans d'autres langues qui n'ont pas 3 alphabets différents (dont l'un est assez irrégulier), il serait probablement moins problématique.

Ceux-ci sont triés par valeur de code-valeur, ascendant. Cela n'a certainement pas de sens pour les lecteurs humains. Il n'est pas impossible de concevoir un schéma de tri sensible pour les Japonais, mais le tri des personnages chinois est difficile (en partie parce que nous ne savons pas nécessairement si nous regardons les Japonais ou les Chinois), et beaucoup de programmeurs sont punct vers cette solution.

Les fonctions de comparaison de chaînes normales dans de nombreuses langues de programmation sont conçues pour s'assurer que les chaînes peuvent être triées en un seul ordre, afin de permettre aux algorithmes comme la recherche binaire et la détection de duplication de fonctionner correctement. Pour trier les données d'une manière significative pour un lecteur humain, il faut savoir ce que représentent les données. Par exemple, dans une liste de titres de films anglais, "El Mariachi" classerait généralement sous "E", mais dans une liste de titres de films espagnols, il serait classé sous "M". La demande nécessitera des informations au-delà de celles contenues dans les chaînes elles-mêmes pour savoir comment les chaînes doivent être triées.

Les réponses au Q1 (pouvez-vous trier) et Q3 (est significatif) sont "oui" pour le chinois (du point de vue du continent). Pour Q2 (comment trier):

Tous les caractères chinois ont une prononciation définitive (certains sont polyphoniques) tels que définis dans la pinyine , et il est beaucoup plus fréquent (comme dans presque tous les dictionnaires chinois) de trier par pinyin, où il n'y a pas d'ambiguïté. Les caractères avec la même prononciation sont ensuite triés par ordre de trajectoire.

Les caractères polyphoniques posent un défi supplémentaire pour le tri, car leur pinyin dépend habituellement du mot dans lequel ils se trouvent (j'ai entendu des caractères japonais encore plus poilus). Par exemple, le caractère 阿 est prononcé a (1) dans 阿姨 (tonalité entre parenthèses), et e (1) en 阿胶. Donc, si vous devez trier des mots ou des phrases, vous ne pouvez pas simplement regarder un caractère à la fois de chaque élément.

Rappelez-vous que dans JavaScript, vous pouvez passer dans sort () une fonction dans laquelle vous pouvez implémenter vous-même, afin d'atteindre un genre qui importe pour les humains:

myarray.sort(function(a,b){

//return 0, 1, or -1 based on the comparison of the two strings

});