377
Stefano Monti
AppleScript e AppleScript Studio, Sviluppo, linguaggi e ambienti, Formato file e Interscambio dati, Terminal e sottosistema BSD
http://faqintosh.com/faq/377.xml - XML della Faq: http://faqintosh.com/faq/377-data.xml
387 giorni, 13 ore, 31 minuti
Per chi abbia necessità di convertire singoli documenti o interi siti, creati su piattaforma Windows, da una codifica ad un'altra, in semplice testo oppure in HTML o codice PHP, esistono molte alternative su Versiontracker o altri siti, ad esempio Cyclone, che contiene anche molti script di applescript per automatizzare le operazioni ripetitive.
D'altro canto MacOSX contiene già tutto quanto necessario. Nel terminale infatti è possibile usare iconv, per convertire documenti di testo da un formato ad un'altro. Così puro però è un po duretto :-)
Diciamo subito che la materia è complessa e richiede una certa conoscenza di tutto un background di fattori che non vado a disquisire qui, limitandomi a ignorare quello che sta dietro a tutto il problema delle codifiche e dei vari programmi che le supportano. Semplicemente mi limiterò a fornire alcuni strumenti a chi è già avvezzo della cosa, parlando della necessità mia e di alcuni amici divenuta esperienza. Per chi invece volesse approfondire l'argomento e determinare i vari fattori in gioco, consiglio qualche lettura interessante come www.phpwact.org/php/i18n/charsets, htmlpurifier.org/docs/enduser-utf8.html.
Per informazioni sull'uso di iconv, nel terminale digitare
Nel mio caso la necessità è stata quella di usare tutto un flusso di codifica per avere pagine statiche e dinamiche in Unicode, partendo da Apache 2 passando per PHP 5 arrivando a MySQL e infine, il punto dolente, le pagine e i contenuti.
Dopo giorni di duro lavoro passati ad installare i sorgenti di questi programmi per spremere anche il singolo bit in più di potenza e funzionalità, ritrovarsi con contenuti WEB dissociati tra loro è sconfortante :-(
Mentre per i 'motori' sopraccitati si possono inserire delle specifiche preferenze per ottenere ottimi risultati, questo non è sempre vero per tutti i contenuti del sito. Molte pagine WEB scritte con codifiche standard richiedono tag HTML specifici per visualizzare correttamente tutti i linguaggi. Questo può essere problematico quando alcuni di questi dati devono andare a finire dentro un database ed essere successivamente usufruiti sotto diverse forme.
Mi sono così visto costretto ad esaminare tutti i contenuti del sito per ottenere un flusso di codifica identico. Questo perché se volevo mantenere il sito con la codifica scelta tutti gli elementi in gioco devono poter usare lo stesso sistema, pena l'incompatibilità e quindi un risultato vano e indecente.
Posta questa premessa è chiaro che se alcune pagine del sito ( statiche o dinamiche ), sono state create magari su Windows con la codifica Windows Latin e altre su un vecchio Mac in US-ASCII o ISO-8859-1 vedrò le mie accentate e altre simbologie diverse da pagina a pagina ( soprattutto in certe pagine fatte male, dove la codifica è data per scontata ). Per fare un esempio pratico ipotizziamo di usare Wordpress per il blog del proprio sito in UTF-8, poi il commercio elettronico con pagine codificate in Windows Latin, ma senza che vi sia specificata la codifica, la sezione Stats in ISO-8859-1 anche qui senza specifica del charset, alcune pagine statiche di vari formati, dai sopraccitati a US-ASCII, nella più varia miscellanea delle combinazioni sopra esposte.
Viene il momento di guardare come unificare il tutto e scopro che Mac OS contiene il potente iconv.
Purtroppo però la mia scarsa conoscenza della shell bash mi impedisce di riuscire a fargli esaminare tutto il sito ed effettuare le dovute modifiche in modo automatico.
Per cui ho scritto l'utility allegata che consente di selezionare una cartella di pagine e contenuti ( oppure di trascinargliela sopra ) ed effettuare la conversione da un formato ad un'altro, senza rischi di perdita di dati e con una velocità sorprendente.
Una volta avviata l'utility vi verrà chiesta la codifica di origine, lo so è una scocciatura doverla identificare perché come scrivevo prima il charset non è sempre specificato, ma non ho trovato un metodo certo per fare questo in modo automatico a meno di non usare uno strumento particolare Fileinfo che richiede una installazione e quindi il suo codice e la sua verifica non ho incluso nell'utility.
Comunque, se può essere di aiuto, all'inizio ho provato ad usare TextEdit con il comando apri... non è poi male per un numero esiguo di documenti...
| Google+ | |
|---|---|
|
|
|