Qualcosa che da tempo mi ha confuso è che così tanto software usa i termini "charset" e "encoding" come sinonimi.
Quando le persone si riferiscono a una "codifica" unicode, intendono sempre una serie di regole per rappresentare i caratteri unicode come una sequenza di byte, ad esempio ASCII o UTF-8. Questo sembra ragionevole e intuitivo; l'idea è di "codificare" quei caratteri come byte usando il set di regole specificato.
Dato che questi set di regole a volte forniscono solo la possibilità di "codificare" alcuni sottoinsiemi di tutti i caratteri unicode, potresti immaginare che un "set di caratteri" - abbreviazione di "set di caratteri" - significherebbe semplicemente un set di caratteri unicode - senza alcun riguardo per come questi caratteri sono codificati. Una codifica implicherebbe quindi un charset (una codifica come ASCII, che ha solo regole per codificare 128 caratteri, sarebbe associata al set di caratteri di quei 128 caratteri) ma un set di caratteri non deve implicare una codifica (per esempio, UTF-8, UTF -16 e UTF-32 sono tutte diverse codifiche ma possono codificare lo stesso set di caratteri).
Eppure - ed ecco il punto cruciale della mia domanda - l'uso del mondo reale della parola "charset" non corrisponde a ciò che implicherebbe la costruzione della parola. È quasi sempre usato per "codifica".
Ad esempio:
- Viene utilizzato l'attributo
charset
in HTML per specificare una codifica -
Charset
s in Java sono codifiche -
charset
s echaracter sets
in MySQL sono, ancora una volta, codifiche
Quanti anni ha questo curioso (ab) uso del linguaggio, e come è nata questa contro-intuitiva definizione di "charset"? Ha forse origine da un tempo in cui era veramente, in pratica, un mapping uno-a-uno tra le codifiche in uso e gli insiemi di caratteri che supportavano? O c'era qualche standard o specifica particolarmente influente che dettava questa definizione della parola?