Formati files durevoli

[Luma]

Considerato che le applicazioni si evolvono frequentemente e non sempre mantengono la compatibilità con il formato delle versioni precedenti, mi stavo chiedendo: quali siano i formati file più durevoli nel tempo, nel senso che assicurano la leggibilità dei contenuti indipendente dalla loro formattazione.

Per i testi/word processor credo sia il .txt, mentre per i fogli elettronici e database esistono altri formati?

[Matty90]

Ciao Luma,
purtroppo la domanda che fai non credo abbia una risposta corretta.

Ti spiego meglio: come forse saprai, l'estensione dei file è molto spesso proprietaria dello sviluppatore del software che ne fa uso. Un esempio classico i files di adobe illustrator (.ai), ma anche i vari formati di excel o microsoft word (.doc, .docx, .xls, .xlsx).

Questi formati di fatto possono essere aperti e letti correttamente solamente usando le suite da cui sono stati creati. E' però vero che gli stessi, possono essere letti anche con software di terze parti, senza perderne il contenuto, anche se spesso vengono persi formattazione e altre features particolari.

Per i testi credo anche io che un classico file .txt possa essere letto più o meno da qualsiasi editor. Per fogli di calcolo e database dipende sempre da che fogli di calcolo e database sono.

[Luma]

Ciao Matty, grazie per la risposta.

Forse sono stato troppo conciso o forse non mi sono spiegato bene.
La mia domanda è finalizzata ad identificare quei formati files che permettono di salvare i contenuti di files di testo, database, fogli elettronici ecc. per garantire una maggiore fruibilità e longevità dei dati nel tempo, indipendentemente dalla formattazione.

Per farti un esempio concreto, pochi giorni fa mi sono reso conto di avere conservato scrupolosamente dei backup di 30 anni fa ma una parte di questi files sono divenuti illeggibili perchè le applicazioni che li ha generati (MS Works) sono state abbandonate già da una decina di anni.
Fortunatamente, grazie ad un vecchio notebook con Windows XP ed un vecchio CD del '98, ancora funzionante, con Works 4.5 riuscirò ancora ad aprire quei files e salvarli in altri formati più longevi, come ad esempio il .txt, .dbf ecc.

Aprendo questo thread, chiedevo ai più esperti quali sono i formati files che possono garantire una maggiore fruibilità e longevità dei contenuti, indipendentemente dalla loro formattazione.

[Matty90]

Proprio per questo ti ho scritto:

Ti spiego meglio: come forse saprai, l'estensione dei file è molto spesso proprietaria dello sviluppatore del software che ne fa uso. Un esempio classico i files di adobe illustrator (.ai), ma anche i vari formati di excel o microsoft word (.doc, .docx, .xls, .xlsx).

Un file lo potrai leggere solo se ci sarà qualcuno che ne garantisce il supporto in futuro. Purtroppo file con estensioni perpetue non credo ne esistano.

Dipende sempre anche da cosa serve. Se hai bisogno di un database e con precise funzionalità, al momento della progettazione sceglierai ad esempio tra MongoDB, MySQL, MS SQL o altri. Non è detto che tra 30 anni la compatibilità sia la stessa, proprio perchè cambieranno le necessità e le aziende stesse non hanno utilità a continuare a sviluppare cose vecchie.

[pgfiore]

Temo che sia a tuo carico portarti "avanti" i vari file via via. Il tuo Works avresti dovuto convertirlo a metti MS Words anni fa incomma. Per altro qualunque suppoorto tu usasti, dopo 30 anni leggerlo sarà ben oltre le caratteristiche ufficiali.
C'è da dire che molti formati tendono a standardizzarsi, vedi i citati recenti "x" version di Microsoft; questo permette comunque di ricostruirne un visualizzatore in qualunque momento.
Tutto molto teorico comunque; ho un reel-to-reel a 1/2 pollice scritto da OS/400 circa 25 anni fa con routine in cobol... come lo leggo?

[Luma]

Ricordo male o il formato .txt è sempre lo stesso dagli anni del DOS, o sbaglio?
Se noi avessimo sempre salvato i nostri files di testo anche in txt, oggi avremmo tutti i contenuti perfettamente leggibili da tutti i WP a cominciare dal blocco note di Windows.

Anche le tabelle dei DB e dei fogli elettronici sono sempre state esportabili nello stesso formato txt, con valori separati da virgole, tabs ecc.

E' ovvio che si tratta di un compromesso, nel senso che possiamo salvare i contenuti ma non la loro formattazione.
Però fra il non poter più leggere nulla o poter leggere almeno i contenuti, mi pare preferibile questa seconda ipotesi.

Temo che sia a tuo carico portarti "avanti" i vari file via via. Il tuo Works avresti dovuto convertirlo a metti MS Words anni fa incomma. Per altro qualunque suppoorto tu usasti, dopo 30 anni leggerlo sarà ben oltre le caratteristiche ufficiali.

Ciao pgfiore.
Infatti tutte le informazioni che servivano, sia che fossero in formato txt, dbf o works, sono state gradualmente convertite nei nuovi formati, fino ad oggi. Nel contempo mi sono reso conto che una parte di files non sono mai stati convertiti.
Tranquillo di poter accedere a tutti i miei archivi, da quando iniziai a fare i backup, pochi giorni fa ho scoperto che una parte di quei files non erano più leggibili con gli strumenti software che utilizzo oggi.

Per quanto concerne i backup e i supporti sono sempre stato previdente, rinnovandoli di anno in anno, per cui i files dovrebbero essere tutti perfettamente integri. Non mi è mai successo di non poter recuperare un file perchè danneggiato, anche perchè i backup li faccio sempre in due o tre copie.

C'è da dire che molti formati tendono a standardizzarsi, vedi i citati recenti "x" version di Microsoft; questo permette comunque di ricostruirne un visualizzatore in qualunque momento.
Tutto molto teorico comunque; ho un reel-to-reel a 1/2 pollice scritto da OS/400 circa 25 anni fa con routine in cobol... come lo leggo?

Non conosco gli "x" version di Microsoft, da te citati.

Non ho mai pensato che i contenuti di ogni genere di file debbano essere leggibili per l'eternità.
Ho invece chiesto se i contenuti di un file di testo, delle tabelle di un BD o di un foglio elettronico, oggi possono essere convertiti e salvati in formati standard.

[Matty90]

Il problema è proprio quello, i formati standard, che non esistono.

O meglio, esistono ora, ma come indicato giustamente da pgfiore il loro "aggiornamento" e di conseguenza versionamento spetta al proprietario.

Se tu vuoi un formato che ti renda possibile leggere i contenuti, puoi esportarlo come credi. I file txt che citi, sono file csv, e possono essere importati più o meno ovunque. Non è detto però che tra 10 anni questa funzionalità non sia stata superata o rimpiazzata da altro, e quindi saresti comunque punto e a capo.

[pgfiore]

Scusate, scrittura veloce e poco editing... le versioni "x" dei file di Office sono i vari docx pptx xlsx che sono stati accettati come standard. cfr.
OOXML https://it.wikipedia.org/wiki/Office_Open_XML

Comunque penso che si si sia capiti... convertire o pedale!

TRa parentesi, da vecchio geek, non dimentichiamoci della codifica! Siamo così abituati ai personal computer che ci dimentichiamo che comunque esiste un altro mondo intorno e forse tra n anni la codifica ASCII (*) sarà incomprensibile a tutti e i ns bei TXT come carta straccia.
Chi sa ancora cosa significa x'F1F2F3'? O, molto simile, x'123C'?

(*) mero esempio, ci sono hardware che considerano il semibyte di destra come "più importante". per dire. cfr. high nibble & Most significant bit

[Luma]

Il problema è proprio quello, i formati standard, che non esistono.

Temevo proprio questa risposta, che puntualmente è arrivata.

Bene, ora sappiamo che al momento possiamo contare solo su pochi formati, che di fatto sono degli standard, oltre a qualche driver/interfaccia come ODBC.

Quello che cercavo evidentemente non c'è ancora.

[pgfiore]

ODBC? Se non è morto sopravvive male :-D
Come tutta la programmazione Client/Server! Per altro già una decina d'anni fa ho visto una migrazione andate male a causa di ODBC di cui i driver erano schifosamente raffazzonati in una società di Vado a Savona che gestisce il reefer per un prodotto giallo, sterile, d'importazione con un marchio blu, per dire
C'entrava Linux e boh forse PostgreSQL... ma lo dico io, che sono figlio (non riconosciuto) di Microsoft!