javascript - que - ¿Qué significa ordenar en idiomas no alfabéticos(es decir, asiáticos)?
que significa js en ingles (9)
¿Un personaje de doble byte realmente se compara con el otro en una función de ordenación?
El tipo de String nativa en JavaScript se basa en unidades de código UTF-16, y eso es lo que se compara. Para los personajes en el plano multilingüe básico (que son todos estos), esto es lo mismo que los puntos de código Unicode.
El término "doble byte" como en codificaciones como Shift-JIS no tiene ningún significado en un contexto web: las cadenas DOM y JavaScript son originalmente Unicode, los bytes originales en la página codificada recibidos por el navegador han desaparecido.
¿El resultado de tal tipo significa algo en absoluto?
Pequeño. Los puntos de código Unicode no pretenden ofrecer ningún pedido en particular ... para uno, porque no hay un pedido aceptado globalmente. Incluso para el caso más básico de caracteres latinos ASCII, los idiomas no están de acuerdo (por ejemplo, si v y w son la misma letra, o si la mayúscula de i es I o İ ). Y CJK se pone mucho más enérgico que eso.
El bloque Unicode CJK Unified Ideographs principal se ordena por radical y número de golpes (orden del diccionario Kangxi), que puede ser vagamente útil. Pero use caracteres de cualquiera de los otros bloques de extensión CJK, o mezcle algo de kana, o romaji, y no habrá un orden significativo entre ellos.
El Consorcio Unicode intenta definir algunas reglas generales de ordenamiento, pero es complejo y generalmente no se intenta a nivel de lenguaje. Los sistemas que realmente necesitan capacidades de clasificación sensibles al lenguaje (por ejemplo, sistemas operativos, bases de datos) tienden a tener sus propios esquemas de intercalación.
Esto es diferente del orden del silabario japonés
Sí. Por encima y más allá de los problemas de intercalación en general, es una tarea enormemente difícil manejar kanji con precisión por sílaba, porque tienes que adivinar la pronunciación. JavaScript no puede saber de manera realista que con ''藤 本'' se quiere decir ''Fujimoto'' y no ''touhon''; este tipo de cosas requiere profundos diccionarios incorporados y heurísticas aún no fiables ... no es el tipo de cosas que desea construir en un lenguaje de programación.
Tengo un código que ordena columnas de tabla por propiedades de objeto. Se me ocurrió que en japonés o chino (idiomas no alfabéticos), las cadenas que se envían a la función de clasificación se compararían de la misma manera que lo haría un lenguaje alfabético.
Tome por ejemplo una lista de apellidos japoneses:
寿拘 (Suzuki)
松坂 (Matsuzaka)
松井 (Matsui)
山田 (Yamada)
藤本 (Fujimoto)
Cuando ordeno la lista anterior a través de Javascript, el resultado es:
寿拘 (Suzuki)
山田 (Yamada)
松井 (Matsui)
松坂 (Matsuzaka)
藤本 (Fujimoto)
Esto es diferente del orden del syllabary japonés, que organizaría la lista fonéticamente (de la forma en que lo haría un diccionario japonés):
寿拘 (Suzuki)
藤本 (Fujimoto)
松井 (Matsui)
松坂 (Matsuzaka)
山田 (Yamada)
Lo que quiero saber es:
- ¿Un personaje de doble byte realmente se compara con el otro en una función de ordenación?
- ¿Qué sucede realmente en ese tipo?
- (Crédito extra) ¿El resultado de ese tipo significa algo en absoluto? ¿El concepto de clasificación realmente funciona en idiomas asiáticos (y otros)? Si es así, ¿qué significa y para qué se debe esforzar para crear una función de comparación para esos idiomas?
ADDENDUM PARA RESUMIR RESPUESTAS Y DIBUJAR CONCLUSIONES:
Primero, gracias a todos los que contribuyeron a la discusión. Esto ha sido muy informativo y útil. Gritos especiales para bobince , Lie Ryan , Gumbo , Jeffrey Zheng y Larry K , por sus profundos y reflexivos análisis. Le concedí la marca de verificación a Larry K por señalarme una solución que mi pregunta no pudo prever, pero acerté cada respuesta que encontré útil.
El consenso parece ser que:
Las cadenas de caracteres chinas y japonesas están ordenadas por puntos de código Unicode, y su orden puede basarse en una lógica que puede ser de alguna manera inteligible para los lectores conocedores, pero que probablemente no sea de gran valor práctico para ayudar a los usuarios a encontrar la información que buscan. buscando.
El tipo de función de comparación que se requeriría para hacer que un tipo sea semánticamente o fonéticamente útil es demasiado engorroso como para considerarlo, especialmente porque los resultados probablemente serían menos que satisfactorios, y en cualquier caso los algoritmos de comparación tendrían que cambiarse para cada idioma. Lo mejor es permitir que el género proceda sin siquiera intentar una función de comparación.
Probablemente estaba haciendo la pregunta incorrecta aquí. Es decir, estaba pensando demasiado "dentro de la caja" sin considerar que la verdadera pregunta no es cómo hago que la clasificación sea útil en estos idiomas, sino cómo proporciono al usuario una forma útil de encontrar elementos en una lista. Los occidentales automáticamente piensan en clasificar para este propósito, y yo era culpable de eso. Larry K me señaló un artículo de Wikipedia que sugiere que una función de filtrado podría ser más útil para los lectores asiáticos . Esto es lo que planeo seguir, ya que es al menos tan rápido como ordenar, desde el lado del cliente. Mantendré la clasificación de columnas porque se entiende bien en los idiomas occidentales, y porque los hablantes de cualquier idioma encontrarían útil la clasificación de fechas y otros tipos de datos numéricos. Pero también agregaré ese mecanismo de filtrado, que sería útil en largas listas para cualquier idioma.
Esos están ordenados por valor de punto de código, ascendente. Esto sin duda no tiene sentido para los lectores humanos. No es imposible idear un esquema de clasificación sensato para los japoneses, pero clasificar los caracteres chinos es difícil (en parte porque no necesariamente sabemos si estamos viendo japonés o chino), y muchos programadores se lanzan a esta solución.
Las cadenas se comparan carácter por carácter donde el valor del punto de código define el orden :
La comparación de cadenas utiliza un orden lexicográfico simple en secuencias de valores de valores de puntos de código. No se intenta utilizar las definiciones más complejas, orientadas semánticamente, de la igualdad de caracteres o cadenas y el orden de clasificación definido en la especificación Unicode. Por lo tanto, las cadenas que son canónicamente iguales según el estándar Unicode podrían probarse como desiguales. En efecto, este algoritmo supone que ambas cadenas ya están en forma normalizada.
Si necesita más que esto, necesitará usar una comparación de cadenas que pueda tener en cuenta las intercalaciones.
Las funciones normales de comparación de cadenas en muchos lenguajes de programación están diseñadas para garantizar que las cadenas se puedan clasificar en un orden único, para permitir que algoritmos como la búsqueda binaria y la detección de duplicados funcionen correctamente. Para ordenar los datos de una manera significativa para un lector humano, uno debe saber qué representan los datos. Por ejemplo, en una lista de títulos de películas en inglés, "El Mariachi" típicamente ordenaría debajo de "E", pero en una lista de títulos de películas en español se ordenaría en "M". La aplicación necesitará información más allá de la contenida en las cadenas para saber cómo deben ordenarse las cadenas.
Las respuestas a Q1 (puede ordenar) y Q3 (es algo significativo) son "sí" para los chinos (desde una perspectiva continental). Para Q2 (cómo ordenar):
Todos los caracteres chinos tienen pronunciación definida (algunos son polifónicos) como se define en pinyin , y es mucho más común (como en casi todos los diccionarios chinos) ordenar por pinyin, donde no hay ambigüedad. Los personajes con la misma pronunciación se ordenan por orden de trazo.
Los caracteres polifónicos plantean un desafío adicional para la clasificación, ya que su pinyin generalmente depende de la palabra en la que se encuentran (he oído que los caracteres japoneses pueden ser aún más peludos). Por ejemplo, el carácter 阿 se pronuncia a (1) en 阿姨 (tono entre paréntesis) y e (1) en 阿胶. Entonces, si necesita clasificar palabras u oraciones, no puede simplemente mirar un carácter a la vez de cada elemento.
Otros han respondido a las otras preguntas, voy a tomar esta:
¿Qué debería esforzarse para crear una función de comparación para esos idiomas?
Una forma de hacerlo es que deberá crear un programa que pueda "leer" los caracteres; es decir, capaz de asignar caracteres hanzi / kanji a su "sonido" (lectura de pinyin / hiragana). En el nivel más simple, esto significa una base de datos que mapea los sonidos hanzi / kanji. Por supuesto, esto es más difícil de lo que parece (juego de palabras no intencionado), ya que muchos personajes pueden tener diferentes pronunciaciones en diferentes contextos, y los chinos tienen muchos dialectos diferentes para considerar.
Otra forma es ordenar por orden de trazo. Esto significa que debería haber una base de datos que mapee los hanzi / kanji con sus trazos. Otro problema: chino y japonés escribe en diferentes órdenes de trazo. Sin embargo, aparte de las diferencias entre japoneses y chinos, el uso de patrones de trazos es mucho más consistente dentro de un solo texto, ya que los caracteres hanzi / kanji casi siempre se escriben usando el mismo orden de trazo, independientemente de lo que signifiquen o cómo se lean. Una idea similar es ordenar por radicales en lugar de órdenes de trazo simple.
La tercera forma es ordenar por puntos de código Unicode. Esto es simple y siempre da un orden indiscutiblemente consistente; sin embargo, el problema es que el orden de clasificación no tiene sentido para el ser humano.
La última es repensar la necesidad de un ordenamiento absoluto, y simplemente usar alguna heurística para clasificar por relevancia para las necesidades del usuario. Por ejemplo, en un software de carrito de compras, puede ordenar según los hábitos de compra del usuario o por precio. Esto evita el problema, pero la mayoría de las veces funciona (excepto si está compilando un diccionario).
Como notará, los primeros dos métodos requieren la creación de una gran base de datos de mapeo de uno a muchos, pero aún así no siempre dan un resultado útil. El tercer método también requiere una gran base de datos, pero muchos lenguajes de programación ya tienen esta base de datos integrada en el lenguaje. La última forma es un poco de heurística, probablemente la más útil, sin embargo, están condenados a nunca dar órdenes consistentes (mucho peor que los primeros dos métodos).
Podría implementar el Algoritmo de intercalación Unicode en Javascript si desea algo mejor que el ordenamiento JS predeterminado para las cadenas. Podría mejorar algunas cosas. Aunque como dice el documento Unicode:
La intercalación no es uniforme; varía de acuerdo con el idioma y la cultura: alemanes, franceses y suecos clasifican los mismos caracteres de manera diferente. También puede variar según la aplicación específica: incluso dentro del mismo idioma, los diccionarios pueden ordenar de forma diferente que las guías telefónicas o los índices de libros. Para los scripts no alfabéticos, como los ideogramas de Asia oriental, la intercalación puede ser fonética o basada en la apariencia del personaje.
El artículo de Wikipedia señala que, dado que la intercalación es tan difícil en los guiones no alfabéticos, hoy en día la respuesta es hacer que sea muy fácil buscar información ingresando caracteres, en lugar de buscar en una lista.
Sugiero que hable con usuarios finales verdaderamente conocedores de su aplicación para ver cómo les gustaría que se comporte. El problema de ordenar caracteres chinos no es exclusivo de su aplicación.
Además, si no desea implementar la intercalación en su sistema, otra solución sería crear un servicio Ajax que almacene los nombres en un MySql u otra base de datos, luego buscará los datos con una declaración de orden.
Recuerda que en JavaScript, puedes pasar a sort () una función en la que puedes implementar Sort yourself, para lograr un género que le importe a los humanos:
myarray.sort(function(a,b){
//return 0, 1, or -1 based on the comparison of the two strings
});
Sí, los personajes se comparan. Sin embargo, generalmente se comparan en función de sus puntos de código Unicode, que son bastante diferentes entre hiragana y kanji, lo que hace que el género sea potencialmente inútil en japonés. (Kanji tomado prestado del chino, pero el orden en que aparecerían en chino no corresponde al orden del hiragana que representaría el mismo significado). Hay intercalaciones que podrían hacer que algunos de los personajes sean "iguales" para fines de comparación, pero no sé si hay alguno que considere que un kanji es equivalente al hiragana que comprendería su pronunciación, especialmente si se trata de un personaje. puede tener varias pronunciaciones diferentes
En chino o coreano u otros idiomas que no tienen 3 alfabetos diferentes (uno de los cuales es bastante irregular), probablemente sería un problema menor.