Algoritmo di rilevamento codifica caratteri

Question

Sto cercando un modo per rilevare i set di caratteri all'interno dei documenti. Ho letto l'attuazione di rilevamento set di caratteri Mozilla qui:

Universal Charset Detection

ho anche trovato un'implementazione Java di questa chiamata jCharDet:

JCharDet

Entrambi si basano su ricerca effettuata utilizzando un set di dati statici. Quello che mi chiedo è se qualcuno ha usato con successo qualsiasi altra implementazione e se sì cosa? Hai rotolato il tuo approccio e, in caso affermativo, qual è stato l'algoritmo che hai usato per rilevare il set di caratteri?

Qualsiasi aiuto sarebbe apprezzato. Io non sto cercando una lista di approcci esistenti tramite Google, né sono in cerca di un link per l'articolo Joel Spolsky - tanto per chiarire:)

UPDATE: ho fatto un po 'di ricerca in questo e finito per trovare un quadro chiamato cpdetector che utilizza un approccio plug al rilevamento dei caratteri, vedere:

CPDetector

Questo fornisce BOM, chardet (approccio di Mozilla) e plugin di rilevamento ASCII. È anche molto facile da scrivere. C'è anche un altro quadro, che fornisce il rilevamento carattere molto meglio che l'approccio di Mozilla/jchardet ecc ...

ICU4J

E 'abbastanza facile da scrivere il proprio plug-in per cpdetector che utilizza questo contesto per fornire un carattere più accurata algoritmo di rilevamento della codifica. Funziona meglio dell'approccio di Mozilla.

Answer 1

anni fa abbiamo rilevato il set di caratteri per un'applicazione di posta elettronica e abbiamo eseguito il rollover. L'app di posta era in realtà un'applicazione WAP e il telefono prevedeva UTF-8. C'erano diverse fasi:

universali

Potremmo facilmente rilevare se testo era UTF-8, in quanto v'è un modello specifico bit nei bit superiori del byte 2/3/ecc. Una volta che hai trovato quel modello ripetuto un certo numero di volte, puoi essere certo che era UTF-8.

Se il file inizia con un segno di ordine byte UTF-16, è probabile che il resto del testo sia la codifica. Altrimenti, rilevare UTF-16 non è semplice come UTF-8, a meno che non si riesca a rilevare il pattern di coppie surrogate: ma l'uso di coppie surrogate è raro, quindi di solito non funziona. UTF-32 è simile, tranne che non ci sono coppie surrogate da rilevare.

rilevamento regionale

successivo avremmo assumere il lettore era in una determinata regione. Ad esempio, se l'utente vedesse l'interfaccia utente localizzata in giapponese, potremmo quindi tentare di rilevare le tre principali codifiche giapponesi. ISO-2022-JP è di nuovo ad est per rilevare con le sequenze di escape. Se ciò fallisce, determinare la differenza tra EUC-JP e Shift-JIS non è così semplice. È più probabile che un utente possa ricevere il testo di Shift-JIS, ma c'erano caratteri in EUC-JP che non esistevano in Shift-JIS e viceversa, quindi a volte potresti ottenere una buona corrispondenza.

La stessa procedura è stata utilizzata per le codifiche cinesi e altre regioni.

Scelta degli utenti

Se questi non hanno fornito risultati soddisfacenti, l'utente deve scegliere manualmente una codifica.

Answer 2

Non esattamente quello che hai chiesto, ma ho notato che lo ICU project include una classe CharsetDetector.