2010-09-21 18 views
30

Después de cierta encuesta, llego a descubrir que hay un proyecto de detección de codificación pocos en el mundo Java, si el getEncoding en InputStreamReader no funciona:¿Cuál es el detector de codificación más preciso?

  1. juniversalchardet
  2. jchardet
  3. cpdetector
  4. ICU4J

Sin embargo, realmente no sé cuál es el mejor entre todos. ¿Alguien con experiencia práctica puede decirme cuál es el mejor en Java?

+3

Tenga en cuenta que InputStreamReader.getEncoding() simplemente devuelve la codificación pasada en el constructor, o la codificación predeterminada de la plataforma, no hace nada con los datos de la secuencia. –

+0

Gracias! Soy consciente de ello. Es por eso que estoy ansioso por descubrir cuál es el mejor. –

+3

También hay Apache Tika, que parece estar basado en ICU4J. –

Respuesta

1

He utilizado personalmente jchardet en nuestro proyecto (juniversalchardet no estaba disponible en ese momento) solo para comprobar si una transmisión era UTF-8 o no.

Fue más fácil de integrar con nuestra aplicación que la otra y produjo excelentes resultados.

3

encontré una respuesta en línea:

http://fredeaker.blogspot.com/2007/01/character-encoding-detection.html

Dice algo vealuable aquí:

La fuerza de un detector de codificación de caracteres radica en si es o no su atención se centra en el análisis estadístico o Descubrimiento de prólogos HTML META y XML. Si está procesando archivos HTML que tienen META, use cpdetector. De lo contrario, su mejor opción es monq.stuff.EncodingDetector o com.sun.syndication.io.XmlReader.

Así que es por eso que estoy usando cpdetector ahora. Actualizaré la publicación con el resultado.

+1

¿Solo le importan los archivos que ya están etiquetados con el juego de caracteres a través de XML o META? Esa prueba es muy, muy sospechosa (tanto que la ejecuté yo mismo). Los archivos de prueba que utiliza no son contenido real, pero son gráficos de códigos. Es decir, no son "texto en codificación X" sino "texto en inglés con una lista de los puntos de código en la codificación X". Sin embargo, todos los archivos de prueba están etiquetados con la codificación. Se debe hacer una comparación, pero no con estos archivos de prueba. –

+2

Pruebas adicionales: ejecuté el caso de prueba en ese blog contra los mismos detectores (últimas versiones) en datos no etiquetados. SÓLO icu detectado: euc-jp, iso-2022-jp, koi8-r, iso-2022-cn iso-2022-kr .... Solo ICU y Mozilla jchardet detectados: shift-jis, gb18030, big5 ... I Se utilizaron muestras de http://source.icu-project.org/repos/icu/icu/trunk/source/extra/uconv/samples/ y del directorio utf-8 (algunas convertidas desde archivos en la página de códigos de destino). –

9

He comprobado juniversalchardet y ICU4J en algunos archivos CSV, y los resultados son inconsistentes: juniversalchardet tuvo mejores resultados:

  • UTF-8: Tanto detectado.
  • Windows-1255: juniversalchardet detectado cuando tenía suficientes letras hebreas, ICU4J aún pensaba que era ISO-8859-1. Con aún más letras hebreas, ICU4J lo detectó como ISO-8859-8, que es la otra codificación hebrea (por lo que el texto estaba bien).
  • SHIFT_JIS (japonés): se detectó el juniversalchardet e ICU4J pensó que era ISO-8859-2.
  • ISO-8859-1: detectado por ICU4J, no compatible con juniversalchardet.

Por lo tanto, uno debe considerar qué codificaciones va a tener que tratar. Al final elegí ICU4J.

Observe que ICU4J todavía se mantiene.

También tenga en cuenta que es posible que desee utilizar ICU4J, y en caso de que devuelva nulo porque no tuvo éxito, intente utilizar juniversalchardet. O lo opuesto.

AutoDetectReader de Apache Tika hace exactamente esto - en primer lugar intenta utilizar HtmlEncodingDetector, entonces UniversalEncodingDetector (que se basa en juniversalchardet), y luego trata Icu4jEncodingDetector (basado en ICU4J).

Cuestiones relacionadas