La difficoltà principale è fare in modo di aver controllato che tutti i percorsi dati sono UTF-8 pulito:
è il vostro sito DB-backed? Se è così, dovrai convertire tutte le tabelle in UTF-8 o qualche altra codifica Unicode, quindi l'ordinamento e la ricerca del testo funzioneranno correttamente.
Il tuo sito utilizza un linguaggio di programmazione per i contenuti dinamici? (PHP, mod_perl, ASP ...?) Se è così, dovrai assicurarti che l'interprete di lingua che stai usando comprenda completamente qualche forma di Unicode, risolvendo le conversioni se non usa UTF-8 in modo nativo — UTF-16 è il successivo più comune — e controlla che sia configurato per utilizzare UTF-8 sul proprio output sul server web.
Il tuo sito ha una sorta di server di applicazioni back-end? Usa UTF-8 per le sue uscite di testo?
Ci sono almeno tre diversi posti in cui è possibile dichiarare il set di caratteri per un documento Web. Siate sicuri di loro tutto cambia:
- HTTP
Content-Type intestazione
- il
<meta http-equiv="Content-Type"> tag nel <head>
- il tag ai tuoi documenti
<?xml> nella parte superiore del documento, se si utilizza XHTML Strict
Tutto ciò deriva dalle mie esperienze di anni fa quando ho rintracciato alcuni dati Unicode tramite un'app N-tier moderatamente complessa e ho trovato catene rsion come:
Latin-1 → UTF-8 → Latin-1 → UTF-8
Così, anche se i dati finirono nel browser affermando di essere "UTF-8", l'app potrebbe ancora gestire solo il sottoinsieme comune con Latin-1.
Il motivo principale per queste strane catene di conversione era dovuto al supporto immaturo Unicode negli strumenti in quel momento, ma è ancora possibile trovarsi a fare brutti scherzi come questo se non si fa attenzione a rendere pulita la tubazione UTF-8 .
Per quanto riguarda i commenti relativi alla ricerca di caratteri Latin-1 e alla conversione di file uno per uno, non lo farei. Costruirò uno script attorno all'utilità iconv trovata su ogni moderno sistema Linux, alimentando ogni file di testo nel tuo sistema, convertendolo esplicitamente da Latin-1 a UTF-8. Non lasciare nulla di intentato.
fonte
2009-10-20 22:36:36
Stiamo utilizzando un CMS, scritto in PHP che gestisce la codifica. È in esecuzione su PostgreSQL. Nel CMS, posso solo cambiare la codifica, che cambierà le intestazioni del tipo di contenuto in tutte le pagine ... –
Scommetto che cambia solo il set di caratteri che il CMS dichiara di usare su mod_php, che controlla ciò che Apache riporta al browser. Certamente non mi aspetterei che possa migrare magicamente tutti i dati nel tuo DB. Probabilmente non convertirà i modelli esistenti che il CMS utilizza per creare pagine. Bottom line: test, test, test. Metti alcuni personaggi nel DB che provengono dall'esterno del set Latin-1 e vedi se sopravvivono al browser. Se è così, controlla di non avere conversioni ridondanti come ho mostrato sopra. In caso contrario, qualcosa sta ancora distruggendo UTF-8 in Latin-1. –
Pensato a un'altra area di rischio. Aggiunto alla lista numerata sopra. –