Unicode sembra che diventi sempre più onnipresente in questi giorni se non lo è già, ma devo chiedermi se ci sono dei domini in cui Unicode non è la scelta migliore per l'implementazione. Ci sono lingue o script che Unicode non funzionerà bene o non funzionerà affatto? Esistono motivi tecnici per utilizzare completamente un sistema diverso (diverso dal lavorare con i sistemi legacy)? Naturalmente, suppongo che la risposta sia sempre usare Unicode. Mi sbaglio?
L'unica volta che eviterei Unicode è in un sistema embedded in cui i requisiti specificano specificamente che il sistema deve supportare solo una singola code page (o ASCII).
Il software è quasi troppo facile da riutilizzare. Sia che si tratti di un progetto pubblico che verrà utilizzato in modi che l'autore è consapevole o che non immagina, o di progetti aziendali rielaborati in qualche modo, non si sa mai quando e dove il software verrà riutilizzato. Con le nostre persone Internet globali di tutte le lingue potrebbe essere utile per il tuo software, e dovrebbe supportare linguaggi come il cinese che sono ampiamente utilizzati e richiedono che Unicode funzioni bene.
I sistemi incorporati (una categoria in cui NON includo gli smartphone) sono l'unico dominio a cui posso pensare che possa resistere alla tendenza del software utilizzato in diversi luoghi.
Modifica: mi sono appena reso conto che non ho davvero specificato il motivo per cui avrei evitato Unicode in quelle situazioni, anche se la risposta è abbastanza ovvia. Mentre alcune combinazioni di caratteri e codifiche possono occupare lo stesso spazio di un carattere a 8 bit (ad esempio UTF-8 inglese), non tutte lo saranno. Questo può aumentare lo spazio, specialmente quando si usano caratteri che devono necessariamente usare più byte (ad esempio cinese, parlato da miliardi di persone). Inoltre, decodificare Unicode e trasformarlo in un glifo su un'interfaccia utente richiede un codice aggiuntivo per il quale un sistema incorporato potrebbe non avere memoria. Se dovessi sviluppare una routine per trasformare i caratteri ASCII in glifi sarebbe probabilmente una tabella di ricerca piuttosto piccola, e non implicherebbe la decodifica di un carattere a lunghezza variabile in un piano di codice con migliaia di glifi.
ASCII generalmente utilizza meno memoria di Unicode e non richiede codifiche speciali. Immagino che, se stai costruendo un piccolo sistema embedded per un utente inglese, dove la quantità di memoria è vincolata, allora Unicode potrebbe effettivamente essere un impedimento.
Unicode è destinato a sistemi più grandi in cui è possibile che si desideri rendere successivamente possibile modificare il software per altri linguaggi e set di caratteri umani.
Protocolli di rete. Sono quasi sempre definiti in ASCII a 7 bit. Suppongo che cada sotto "sistemi legacy".
Se ti fa sentire meglio, immagina che i comandi HELO, EHLO, DATA di SMTP siano binari. Hanno una lunghezza di 4 caratteri per un motivo.
HTTP GET e l'URL e tutte le intestazioni HTTP sono anche in ASCII.
DNS è sicuramente ASCII.
Quasi tutti i protocolli di rete sono implementati prima in C e destinati a un'elaborazione molto veloce. I motivi tecnici per evitare Unicode qui sono che i processi di comunicazione sono in realtà solo lo scambio di dati binari non elaborati. Le "parole" nel protocollo servono solo a renderlo leggibile per le persone con uno sniffer di rete e in modo che le persone possano eseguire test di base usando telnet o netcat.
In queste situazioni la conversione Unicode è quasi sempre una perdita di tempo.
Praticamente l'unico posto in cui posso pensare che Unicode sarebbe utile per qualcosa come server web e proxy è una regola di riscrittura insensibile alle maiuscole e minuscole. Le regole sensibili al maiuscolo / minuscolo non contano perché UTF-8 corrisponde perfettamente senza decodifica.
Personalmente, non credo nell'elaborazione senza distinzione tra maiuscole e minuscole nei server di rete o nei file system. Se la richiesta non riesce a trovare una risorsa, rimbalzarla su uno script di gestore degli errori e può gingillarsi cercando di indovinare a cosa l'utente era veramente dopo. Ciò mantiene le cose veloci e molto semplici nel caso comune.
Vorrei chiedere "Definiresti un nuovo protocollo di rete per utilizzare Unicode?" tranne io temo di conoscere la risposta. Vedo persone che scrivono "protocolli" JSON e XML sgradevoli e cattivi tutto il tempo. E chiunque abbia deciso di trasferire dati binari all'interno di XML nella codifica Base64 dovrebbe probabilmente essere girato, disegnato, squartato, annegato e poi seppellito vivo. "Oooh, reti gigabit! Mi limiterò a espandere tutto e rendere impossibile l'uso di zero-copia!" Punti bonus per poi comprimere l'XML per il trasferimento. Gonfiala, comprimila in modo che tu possa disimballarla e rimuoverla. Mentre si eseguono tre copie, alcune delle quali stanno espandendo i dati XML e Base64 in "caratteri larghi" a 32 bit UCS-4. Probabilmente in Java, quindi puoi utilizzare un gig di RAM extra solo perché.
Leggi altre domande sui tag unicode character-encoding