ho controllato juniversalchardet e ICU4J su alcuni file CSV, ed i risultati sono incoerenti: juniversalchardet ha avuto risultati migliori:
- UTF-8: Entrambi rilevato.
- Windows-1255: juniversalchardet rilevato quando aveva abbastanza lettere ebraiche, ICU4J pensava ancora che fosse ISO-8859-1. Con ancora più lettere ebraiche, ICU4J lo ha rilevato come ISO-8859-8 che è l'altra codifica ebraica (e quindi il testo era OK).
- SHIFT_JIS (giapponese): rilevato juniversalchardet e ICU4J ha pensato che fosse ISO-8859-2.
- ISO-8859-1: rilevato da ICU4J, non supportato da juniversalchardet.
Quindi si dovrebbe considerare quali codifiche con cui molto probabilmente dovrà occuparsi. Alla fine ho scelto ICU4J.
Si noti che ICU4J è ancora gestito.
Si noti inoltre che è possibile utilizzare ICU4J e, nel caso in cui restituisca null perché non è riuscito, provare a utilizzare juniversalchardet. O il contrario.
AutoDetectReader di Apache Tika fa esattamente questo - prima tenta di utilizzare HtmlEncodingDetector, quindi UniversalEncodingDetector (che si basa su juniversalchardet), e poi cerca Icu4jEncodingDetector (sulla base di ICU4J).
Nota che InputStreamReader.getEncoding() restituisce semplicemente la codifica trasmessa nel costruttore o la codifica predefinita della piattaforma, non fa nulla con i dati del flusso. –
Grazie! Ne sono consapevole. Ecco perché sono così desideroso di capire qual è il migliore. –
C'è anche Apache Tika, che sembra essere basato su ICU4J. –