2010-09-21 12 views
30

Dopo certo rilievo, io vengo a scoprire che ci sono un progetto di rilevamento di codifica pochi al mondo java, se il getEncoding in InputStreamReader non funziona:Qual è il rilevatore di codifica più preciso?

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

Tuttavia, ho davvero non so quale sia il migliore tra tutti. Qualcuno con esperienza pratica può dirmi qual è il migliore in Java?

+3

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. –

+0

Grazie! Ne sono consapevole. Ecco perché sono così desideroso di capire qual è il migliore. –

+3

C'è anche Apache Tika, che sembra essere basato su ICU4J. –

risposta

1

Ho usato personalmente jchardet nel nostro progetto (juniversalchardet non era disponibile al momento) solo per verificare se un flusso era UTF-8 o meno.

È stato più facile integrarsi con la nostra applicazione rispetto agli altri e ha dato ottimi risultati.

3

ho trovato una risposta in linea:

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

Si dice qualcosa vealuable qui:

La forza di un rilevatore di codifica dei caratteri si trova in se o non il suo obiettivo è quello di analisi statistiche o META HTML e scoperta prologo XML. Se stai elaborando file HTML con META, utilizza cpdetector. In caso contrario, la soluzione migliore è monq.stuff.EncodingDetector o com.sun.syndication.io.XmlReader.

Ecco perché sto utilizzando cpdetector ora. Aggiornerò il post con il risultato di esso.

+1

Ti interessano solo i file che sono già codificati con il set di caratteri tramite XML o META? Quel test è molto, molto sospetto (tanto che l'ho eseguito io stesso). I file di test che utilizza non sono contenuti reali, ma sono tabelle di codici. Ad esempio, non sono "testo nella codifica X" ma "testo in inglese con una lista dei punti di codice nella codifica X". Tuttavia, tutti i file di test sono contrassegnati con la codifica. Un confronto dovrebbe essere fatto, ma non con questi file di test. –

+2

Ulteriori test: ho eseguito il test case in quel blog con gli stessi rilevatori (ultime versioni) su dati senza tag. SOLO icu rilevato: euc-jp, iso-2022-jp, koi8-r, iso-2022-cn iso-2022-kr .... Rilevati solo ICU e Mozilla jchardet: shift-jis, gb18030, big5 ... I campioni usati da http://source.icu-project.org/repos/icu/icu/trunk/source/extra/uconv/samples/ e dalla directory utf-8 (alcuni convertiti da file nella codepage di destinazione). –

9

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).

Problemi correlati