Le codifiche dei caratteri oltre a UTF-8 (e forse UTF-16 / UTF-32) saranno deprecate?

Dato che hai citato PostgreSQL, posso dire con una certa autorità che il motivo principale per cui le codifiche non-UTF8 lato server sono supportate in modo così dettagliato è che i giapponesi ne hanno bisogno. Apparentemente, la conversione di andata e ritorno identica tra Unicode e le varie codifiche "legacy" giapponesi non è sempre possibile e in alcuni casi le tabelle di conversione sono persino diverse tra i fornitori. È davvero sconcertante, ma è apparentemente così. (L'ampio supporto per i set di caratteri è anche uno dei motivi per cui PostgreSQL è così popolare in Giappone.)

Dato che stiamo parlando di un sistema di database, uno dei compiti principali è quello di essere in grado di archiviare e recuperare i dati in modo affidabile, così come definito dall'utente, quindi la conversione dei set di caratteri a volte non volerà. Se tu avessi a che fare con un browser web, diciamo, dove tutto ciò che conta davvero è se il risultato sembra OK, allora potresti probabilmente cavartela con meno codifiche, ma in un sistema di database hai extra requisiti.

Anche alcuni degli altri motivi citati in altre risposte si applicano come argomenti di supporto. Ma fino a quando il giapponese ha posto il veto su di esso, il supporto per l'impostazione dei caratteri non può essere ridotto.

Due ovvi motivi: a seconda dei dati che stai memorizzando, la conversione in un formato diverso potrebbe richiedere un po 'di tempo e spazio extra. Se stai archiviando 400 megabyte di informazioni, raddoppiare i requisiti di archiviazione non è un grosso problema, ma se stai memorizzando 400 terabyte inizia a significare un po 'di più. La conversione di 400 terabyte di dati da (diciamo) da Shift-JIS a UTF-x potrebbe richiedere anche un po 'di tempo.

Questo diventa particolarmente difficile se hai (per esempio) garanzie di uptime che dicono che il database sarà disponibile per tutti tranne, ad esempio, 10 minuti di un dato anno, e hai un database che viene aggiornato diverse centinaia di volte al secondo . Intendiamoci, è ancora possibile gestire grandi conversioni in una situazione del genere, ma è non qualcosa da intraprendere alla leggera. In alcuni casi, potrebbe facilmente richiedere anni di pianificazione per prepararsi a tale conversione.

Se si stava iniziando con un database che (per esempio) supportava solo ASCII, potrebbe essere una buona ragione per discutere se avesse senso aggiungere supporto per tutte quelle codifiche - ma se si già li sostengono, c'è poco da guadagnare dal loro supporto.

Nota, in particolare, che probabilmente non otterrai quasi nulla nel modo di semplificare il codice, o qualcosa del genere. Avrebbero comunque bisogno di tutte le routine di conversione per gestire le conversioni tra client e server. Di conseguenza, l'eliminazione del supporto significherebbe abbandonare una (minore) chiamata di funzione nei percorsi "write to disk" e "read from disk", ma poco (se non altro). Se avessi supportato anche le due codifiche su disco, non avresti nemmeno ottenuto questo - avresti comunque la chiamata di funzione lì, quindi tutto ciò che avresti davvero sarebbe restringere la gamma di codifiche supportate da quella funzione.

Almeno se stavo progettando questo, probabilmente scriverei il nucleo del database per lavorare in UCS-4, e poi ho routine di conversione tra il core e il disco, e tra il core e l'utente. Io userei lo stesso set di routine in entrambi i casi, quindi il percorso più semplice sarebbe consentire all'archiviazione su disco di usare esattamente lo stesso set di codifiche che i client erano autorizzati a utilizzare.

Ci sono un paio di problemi con la sola memorizzazione di UTF-8 sul server:

1. Qual è il limite di una colonna VARCHAR(20) ? Sono 20 byte o 20 "caratteri" (e in Unicode, che cos'è un "personaggio" quando prendi in considerazione la combinazione di caratteri, legature e così via?). Peggio ancora, che dire di CHAR(20) dove in realtà deve riservare l'intero spazio possibile: credo in MySQL, riserva 4 volte il numero di byte per una colonna codificata UTF-8 (quindi 80 byte per CHAR(20) ) solo per gestire nel peggiore dei casi.
2. È necessario eseguire conversioni di codifica costante tra la codifica del server e la codifica del client. Si potrebbe sostenere che si desidera smettere di supportare più codifiche client, ma a meno che non lo facciate, tutte le stringhe devono essere continuamente convertite. Se è possibile far corrispondere la codifica del server e la codifica del client, le conversioni non sono necessarie.
3. Come altri hanno sottolineato, UTF-8 è abbastanza efficiente per l'archiviazione del testo inglese, ma è molto inefficiente per altre lingue, in particolare le lingue dell'Asia orientale. Suppongo che tu possa consentire l'uso di UTF-16 o UTF-8. O comprimi il testo, ma questo rende l'indicizzazione e la ricerca inefficienti.

Detto questo, sono d'accordo con te: le codifiche legacy sono per lo più inutili e Unicode è generalmente la migliore codifica da utilizzare per tutte le nuove applicazioni. Se stessimo scrivendo un server di database da zero, supporterei solo Unicode e non supporterei alcuna codifica legacy.

La differenza è che PostgreSQL e la maggior parte degli altri server di database in uso oggi erano intorno a prima l'Unicode era un'opzione praticabile. Quindi avevano già il supporto per le codifiche legacy (non erano legacy allora, ovviamente) e non ha molto senso strappare tutto quel codice per ragioni largamente ideologiche.

Le codifiche non universali (e in particolare a byte singolo) hanno il loro posto: su sistemi che:

• Non ha memoria sufficiente per memorizzare il database dei caratteri Unicode.
• Avere un font a byte singolo hard-coded nella ROM.
• Non hai accesso a Internet per fornire una fonte di file con codifica diversa.

Questo è vero oggi per alcuni tipi di dispositivi embedded. Ma sul desktop, e nella stanza del server, le codifiche non Unicode dovrebbero essere lunghe ormai obsolete.

UTF-8 è il migliore per te egocentrico ¹ oratore inglese. Se fossi giapponese, circa il 99% dei tuoi personaggi impiegherebbe 3-4 byte invece di due in UTF-16.

I dialetti non latini soffrono davvero di UTF-8 a livello di dimensioni. Non dimenticare che entro pochi anni, la maggior parte dei tuoi clienti potrebbe essere cinese e la scrittura cinese ha milioni di caratteri. Non è possibile sostenerlo in modo efficiente con UTF-8.

Altrimenti, lo odio quando ho documenti di testo che non sono in UTF- qualcosa . Spesso vado fuori dai piedi se ho bisogno di avere una corretta codifica. Nel mio libro, le codifiche non Unicode sono morte.

_{1. Non prendere la parte egocentrica personalmente. Volevo fare un'illustrazione colorata e non lo intendo davvero.}

Unicode è fondamentalmente rotto ed è improbabile che sia mai stato risolto. Deve essere sostituito da qualcosa di meglio, qualcosa di veramente universale. Se qualcosa ha bisogno di essere deprecato, è Unicode.

Problemi di esempio con Unicide:

• UTF8 è un hack ragionevole, ma la maggior parte del software basato su UTF16 è rotto. La maggior parte delle applicazioni Windows che supportano Unicode utilizzano UTF16, incluso il sistema operativo stesso. Il problema più comune non è supportare più del piano di base, ovvero caratteri a più parole.

• L'unificazione di Han è un disastro assoluto. È impossibile combinare testo giapponese / cinese / coreano in un singolo documento senza metadati aggiuntivi e difficile da individuare quale tipo di carattere deve essere utilizzato.

• I personaggi combinati sono un altro disastro. Schemi di codifica più sensibili mappano un carattere in un codice, il che rende l'elaborazione delle stringhe relativamente sana. Unicode no. Unicode non è nemmeno coerente - I caratteri Han sono per lo più combinazioni, ma non sono codificati come tali, dove sono caratteri combinatori europei.

• I nomi di alcune persone non possono essere scritti correttamente in Unicode, o sono molto inclini a essere rappresentati in modo errato a causa dei problemi menzionati sopra. Questo può avere gravi conseguenze, ad es. quando provi a salire a bordo di un aereo con un passaporto che non corrisponde a quello che è (erroneamente) stampato sul biglietto.

A causa di questi problemi e molto altro, molti software non inglesi non possono usare Unicode e si affidano alle codifiche dei caratteri locali. Questo è particolarmente comune con il software giapponese e cinese.

Idealmente, Unicode dovrebbe essere deprecato. La codifica dei caratteri TRON è un sostituto piuttosto buono per Unicode e ampiamente compatibile con software esistenti che non verranno aggiornati.

Forse per scrivere, ma non per leggere.

C'è un sacco di contenuti esistenti che usano queste codifiche e alcune codifiche come base64 non vanno da nessuna parte perché alcuni protocolli di testo impongono tali metodi come metodi per incorporare dati binari.

Un vero problema è il rilevamento automatico delle codifiche che porta a dei buchi di sicurezza. Non mi dispiacerebbe vedere alcune codifiche oscure come UTF-7 semplicemente scomparire.

Anche il rilevamento automatico tende ad avere un impatto negativo con il contenuto prodotto dalla concatenazione ingenua di stringhe di byte.

Posso convenire che la codifica dei caratteri default per i database e le nuove applicazioni debba essere una sorta di variante UTF. Personalmente opterei per UTF-16 in quanto sembra essere un compromesso ragionevole in termini di spazio e complessità (più che UTF-8). Detto questo, alcune codifiche dei caratteri hanno ancora senso in alcuni casi.

• Se stai memorizzando / trasferendo il testo base64, hai solo bisogno di ASCII e puoi anche farla franca con i protocolli codificati a 7 bit come la posta elettronica. L'overhead aggiuntivo di UTF-8 non è necessario.
• Diversi file e dati esistenti sono costruiti su codifiche di caratteri precedenti, la possibilità di leggerli è importante.

Si noti che esistono 4 algoritmi di normalizzazione UTF standard. Se si è preoccupati per i caratteri con più codici, è possibile utilizzare uno dei due algoritmi di normalizzazione che li collassa nel carattere equivalente a codice unico. La differenza tra loro ha a che fare con l'equivalenza logica con l'equivalenza fisica dei caratteri.