Perché Java utilizza UTF-16 per la rappresentazione di stringhe interne?

Immagino che il motivo sia stato veloce, come una matrice come l'accesso al personaggio all'indice, ma alcuni caratteri non si adattano a 16 bit, quindi non funzionerebbe ...

Quindi, se devi comunque gestire casi speciali, perché non usare solo UTF-8?

java strings unicode

— mrpyo
fonte

Qualcosa da chiedere ai designer Java, non alla comunità in generale. Votare per chiudere come non costruttivo.

— Oded,

@Oded: assolutamente ingiustificato, come mostra la risposta di DeadMG.

— Michael Borgwardt,

Sono confuso: ero abbastanza sicuro che a questa domanda fosse già stata data una risposta (sia qui che su SO), ma non riesco a trovare i duplicati.

— Joachim Sauer,

Per l'uva passa isterica. Vedi utf8everywhere.org

— Pavel Radzivilovsky,

Risposte:

Perché era UCS-2 , che era un bel 16 bit a lunghezza fissa. Naturalmente, 16 bit si è rivelato non essere sufficiente. Hanno retrofittato UTF-16 in cima.

— DeadMG
fonte

Ecco una citazione dalle domande frequenti Unicode :

Originally, Unicode was designed as a pure 16-bit encoding, aimed at representing all modern scripts. (Ancient scripts were to be represented with private-use characters.) Over time, and especially after the addition of over 14,500 composite characters for compatibility with legacy sets, it became clear that 16-bits were not sufficient for the user community. Out of this arose UTF-16.

Al momento della versione Java UTF-16 non era ancora apparso e UTF-8 non faceva parte dello standard Unicode.

— Malcolm,

UCS-2 è un termine tecnico, non una parola d'ordine.

— DeadMG

Per la parte principale, per motivi di chiarezza e semplicità a prova di futuro. Se fosse una ragione sbagliata e il modo sbagliato di farlo è una domanda diversa.

Puoi vedere alcuni motivi dietro alcune delle loro decisioni di progettazione in questo documento sul passaggio 2004 a Java 5 e UTF-16, che spiega anche alcune delle carenze: Caratteri supplementari nella piattaforma Java e vedi Perché l'ecosistema Java utilizza codifiche diverse in tutto il loro stack? .

Per maggiori dettagli sulle insidie dell'utilizzo di UTF-16 e perché UTF-8 è probabilmente un'opzione migliore in generale, vedere UTF-16 dovrebbe essere considerato dannoso? e il manifesto UTF-8 Everywhere .

— haylem
fonte

+1 per il collegamento a "UTF-16 deve essere considerato dannoso?" domanda. Di recente ho scoperto il manifesto UTF-8 Everywhere e credo di essere ora abbastanza convinto. Per quello che vale, sebbene Java abbia sbagliato, sono abbastanza convinto che Windows abbia fatto molto peggio.

— Daniel Pryden,

Bene, non è una sorpresa che Windows abbia sbagliato di più : hanno fatto il passaggio a Unicode prima, quindi avevano meno scelte corrette e meno esperienza. Java ha avuto più tardi, ha capito meglio , ma ancora in qualche modo sbagliato. Ora entrambi devono convivere con API vecchie, errate in senso generale, che devono continuare a supportare.

— Joachim Sauer l'

Questa è la vita nel mondo del software, devi fare delle scelte senza avere tutti i dati e quando sbagli puoi vivere con le conseguenze per molto tempo. :-)

— Brian Knoblauch,

Mi chiedo quali sarebbero state le implicazioni in termini di prestazioni della creazione di stringun tipo "speciale" in Java (molto simile a quello di Array), piuttosto che Stringessere una classe "ordinaria" che contiene un riferimento a un array "ordinario" contenente i caratteri effettivi. A seconda di come viene generata una stringa, UTF-8, UTF-16 o persino UTF-32 possono essere il modo più efficiente di memorizzarla. Non credo che ci sia un modo particolarmente efficiente per una classe "ordinaria" Stringdi gestire più formati, ma un tipo "speciale" con supporto JVM potrebbe.

— supercat,

@supercat: Non ho una risposta precisa per questo, ma ho una risposta SO correlata per questo. :) In realtà non affronta l'approccio del tipo speciale, ma discute il potenziale guadagno di avere stringhe semplificate.

— haylem,