Riconoscere Charset (o codepage) di un file di testo

[progAnd]

Ciao a tutti! Devo lavorare con dei file di testo (dei CSV per la precisione) che possono provenire da piattaforme diverse e quindi che hanno una codifica di caratteri diversa (UTF-8, Unicode, ISO-8859-15, Windows-1252 detto anche ANSI, CP437, CP850, eccetera). Dovrei dunque leggere la giusta codifica e riscrivere nella giusta codifica. E qui sorge il problema: benché Java supporti molti Charset e supporti la possibilità di indicargli un Charset da usare, non ha modo di identificare il tipo di codifica di un file di testo (presuppone sempre che sia quella del sistema). Ho cercato su Internet delle librerie che mi permettessero questo, ma sia cpdetector che ICU4J non mi supportano tutte le codifiche (falliscono su molte). Conoscete un qualcosa che sia in grado di determinare la codifica?

Ciao
PS: Già che ci sono: sapete se esiste un modo per riconoscere il tipo di "a capo" di un file di testo?

[valia]

Originariamente inviato da progAnd
Ciao a tutti! Devo lavorare con dei file di testo (dei CSV per la precisione) che possono provenire da piattaforme diverse e quindi che hanno una codifica di caratteri diversa (UTF-8, Unicode, ISO-8859-15, Windows-1252 detto anche ANSI, CP437, CP850, eccetera). Dovrei dunque leggere la giusta codifica e riscrivere nella giusta codifica. E qui sorge il problema: benché Java supporti molti Charset e supporti la possibilità di indicargli un Charset da usare, non ha modo di identificare il tipo di codifica di un file di testo (presuppone sempre che sia quella del sistema). Ho cercato su Internet delle librerie che mi permettessero questo, ma sia cpdetector che ICU4J non mi supportano tutte le codifiche (falliscono su molte). Conoscete un qualcosa che sia in grado di determinare la codifica?

Ciao
PS: Già che ci sono: sapete se esiste un modo per riconoscere il tipo di "a capo" di un file di testo?

scusa è naturale perché lavoro da tempo sulle codepage e quando le sento nominare parte la risata isterica.

detto questo, andiamo a noi.
Non ricordo tutte le possibili codifiche (qui ne hai dette solo alcune), ma quelle che vedo hanno un sottoinsieme comune. Considera che ICU4J è tra le più complete che esistano (vedi se la tua codepage non è presente sotto altro nome), quindi davvero non vedo il problema.

Ci sono diverse soluzioni e diverse considerazioni da fare. Prima: i file devono viaggiare in rete?? Secondo: vuoi che tutti possano modificarli?? Terzo chi genera questi file??

In generale non hai modo dato il carattere di dedurre la codepage: es. 0x20 (lo spazio) ha la stessa codifica in ASCII UTF-8 e ISO-8859,quindi quale prendi?
Altre deduzioni si potrebbero fare tenuto conto dell'endianità dei byte in arrivo, ragion per cui è lato utente che in genere ci si accorda sulla codepage (ecco le domande di cui sopra).
Riguardo al carattere di fine riga: tipicamente (e ci sono casi particolari) hai 3 combinazioni:

\n
\n\r
\r\n

quindi non è difficile dedurne il comportamento, ma anche qui adottare uno standard non è una cattiva abitudine.

banalmente \n indica un file generato su unix, o anche su windows (se il tuo editor di note è stato istruito con fine riga unix-like)

[progAnd]

Originariamente inviato da valia
Considera che ICU4J è tra le più complete che esistano (vedi se la tua codepage non è presente sotto altro nome), quindi davvero non vedo il problema.

ICU4J non riconosce la Windows-1252 (detta anche ANSI): lo standard del Blocco Note di Windows...

Ci sono diverse soluzioni e diverse considerazioni da fare. Prima: i file devono viaggiare in rete??

No

Secondo: vuoi che tutti possano modificarli??

Non proprio: ho bisogno che aprendolo si possa continuare a leggere quello che vi è scritto e non salti tutto

Terzo chi genera questi file??

Gli utenti usando un po' di tutto: Blocco Note, Word, GEdit, Kate, OpenOffice, Excel, eccetera

In generale non hai modo dato il carattere di dedurre la codepage: es. 0x20 (lo spazio) ha la stessa codifica in ASCII UTF-8 e ISO-8859,quindi quale prendi?

Difatti bisognerebbe analizzare il file alla ricerca di eventuali caratteri che identifichino la codepage necessaria.

Altre deduzioni si potrebbero fare tenuto conto dell'endianità dei byte in arrivo

Giusto: c'è anche questo di problema

Riguardo al carattere di fine riga: tipicamente (e ci sono casi particolari) hai 3 combinazioni:

\n
\n\r
\r\n

quindi non è difficile dedurne il comportamento, ma anche qui adottare uno standard non è una cattiva abitudine.

Il problema è sempre lo stesso: se mi mandano un file scritto in Windows ed io produco il risultato in Linux, gli "a-capo" saltano quando apri il file in Windows... Il problema non è la lettura: Java legge correttamente il file indipendentemente dall'"a-capo" (a differenza della codepage); il problema è la scrittura: usa gli "a-capo" della piattaforma in cui si trova (da cui il problema menzionato).

Grazie

Ciao

[valia]

il problema è che per certe cose tu devi imporre dei paletti, altrimenti non ne esci.
Un generico file è visto come sequenza di byte, che questi siano testo o mp3 o altro non importa. Il fatto che tu abbia il file "pippo.txt" è una convenzione, mediante la quale l'estensione (.txt) indica che quella sequenza di byte che è il file deve essere interpretata come file di testo. Nessuno ti vieta di prendere un mp3 e rinominalo in .txt, la sequenza di byte non cambia!!!
Se vuoi metterti a comprendere in che codepage sei, ti riscrivi la ICU (e non ha senso).

Tornando a noi, provato con windows CP1252?? guarda qui

Il file non va in rete (quindi teoricamente non hai problemi che si parlino un pc in giappone e uno in italia).
Il file deve essere gestito in maniera opportuna da te (gestendo un po' la politica permessi/utenti) e la creazione devi imporre requisiti che devono essere rispettati.
Infine, sul carriage return: o ti fai un sistema di sostituzione automatico, o lasci quello di sistema. anche lì si apre un mondo (perché cmq tu presupponi l'esistenza di un carattere di terminazione e che questo sia \0)