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).
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. –
Gracias! Soy consciente de ello. Es por eso que estoy ansioso por descubrir cuál es el mejor. –
También hay Apache Tika, que parece estar basado en ICU4J. –