Uso la libreria iconv per interfacciare da una moderna sorgente di input che utilizza UTF-8 in un sistema legacy che utilizza Latin1, alias CP1252 (superset di ISO-8859-1).Perché iconv può convertire la forma precomposta ma non la forma scomposta di "É" (da UTF-8 a CP1252)
L'interfaccia non è riuscita a convertire la stringa francese "Éducation", dove "É" è stato codificato come esadecimale 45 CC 81
. Si noti che la codifica della destinazione ha un carattere "É", codificato come C9
.
Perché iconv non è in grado di convertire "É"? Ho verificato che lo strumento da riga di comando iconv disponibile con MacOS X 10.7.3 indica che non può essere convertito e che anche il modulo iconv PERL non funziona.
Questo è ancora più sconcertante che la forma precomposta del carattere "É" (codificata come C3 89
) converta perfettamente.
Si tratta di un bug con iconv o mi sono perso qualcosa?
Nota che ho anche lo stesso problema se provo a convertire da UTF-16 (dove "É" è codificato come 00 C9
composto o 00 45 03 01
decomposto).
Grazie. Ciò non risponde alla domanda perché iconv mappa il carattere precomposto alla codifica di destinazione, ma non il carattere (chiaramente distinto) decomposto. Perché non entrambi? Perché non il secondo invece del primo? Per uno strumento/libreria di conversione, si tratta di un errore, se non di un bug. –
@ Jean-Denis Muys, perché la forma precomposta è un carattere Unicode, che è rappresentabile nella codifica di destinazione secondo le tabelle di mappatura, mentre la forma scomposta è di due caratteri Unicode e quest'ultima non è rappresentabile in windows-1252 (CP1252) . La corrispondenza tra queste forme non esiste al livello delle codifiche dei caratteri; è un problema di protocollo di livello superiore (ed è un'equivalenza di un tipo specifico, non di identità). –
Si è effettivamente errati. Non c'è motivo per non mappare un personaggio scomposto nel suo equivalente CP-1252.Se "É" sta usando una rappresentazione o l'altra, può - e dovrebbe - essere mappata al carattere "É" del CP-1252. –