utf8 - unicode

[bolle]

Hi,

mal eine Frage. Was genau ist der Unterschied zwischen utf-8 und unicode? Was bedeutet es, wenn eine Sprache, zb. Java, Unicode unterstützt? Was für eine, die es nicht unterstützt?

Ochs vor dem Berg

[Jens Holzkämper]

Tach,

mal eine Frage. Was genau ist der Unterschied zwischen utf-8 und unicode? Was bedeutet es, wenn eine Sprache, zb. Java, Unicode unterstützt? Was für eine, die es nicht unterstützt?

die Links in https://forum.selfhtml.org/?t=194142&m=1297607 sollten dir weiterhelfen.

mfg
Woodfighter

[Beat]

mal eine Frage. Was genau ist der Unterschied zwischen utf-8 und unicode?

Kanonisch heisst der charset UTF-8.

Unicode ist ein Numerierungsschema für Glyphen, bzw. deren semantische Beschreibung, welche vom Unicode Consortium betrieben wird.
UTF-8 ist ein ein Wert zum Feld Zeichensatz (eng. charset).
Ein Zeichensatz ist eine Tabelle, welche Bytes zu Unicodes mappt und wird also für Encoding und Decoding verwendet, welches der Vorgang ist Bytes so umzubauen, dass die Bedeutung nach Unicode erhalten bleibt.

Was bedeutet es, wenn eine Sprache, zb. Java, Unicode unterstützt? Was für eine, die es nicht unterstützt?

Es besagt, dass alle Charsets, welche eine Sprache oder eine Programm bei Encoding/Decoding berücksichtigt, auch den Unicode Standard mappen.
Da Unicode ein sich entwickelndes Sytsem ist, wäre eine richtige Aussage:
Programm X unterstützt Unicode Standard XY (den In Version XY beschriebenen Unicode Umfang).

Wichtiger ist in der Paxis, ob Programme oder Sprachen mut Multibyte Charsets umgehen können, wie zum Beispiel UTF-8.

mfg Beat

[bolle]

danke, Beat. Das war sehr aufschlussreich. Endlich mal eine gute Erklärung!

Gruss
bolle

[dedlfix]

Hi!

danke, Beat. Das war sehr aufschlussreich. Endlich mal eine gute Erklärung!

Im Gegenteil. Außer dass das Unicode Consortium sich um Unicode kümmert ist eigentlich nichts so richtig richtig, und auch das war nur die halbe Wahrheit, denn das Unicode Consortium arbeitet zusammen mit der IEC an diesem Standard.[1]

Schön wäre es gewesen, wenn du selbst erst einmal versucht hättest, dir diese Frage mit den allgemein bekannten Quellen (Online-Lexikon, Suchmaschine) zu beantworten. Wenn du das doch getan hast, so sag bitte konkret, was du nicht verstanden hast.

Um es kurz zu machen: Unicode ist ein Zeichensatz - eine Ansammlung von Zeichen - und damit ein eher theoretisches Gebilde. UTF-8 ist eine Zeichenkodierung - eine Abbildung der Codepoints von Unicode auf konkrete Bytes und Bytefolgen.

Wenn man sagt, ein System unterstütze Unicode, so muss man sich das eigentlich genauer ansehen. Einige, wie beispielsweise MySQL, unterstützen nur die ersten 65536 Zeichen. Bei der internen Verarbeitung ist es wichtig, dass das System mehr als nur 256 Zeichen voneinander unterscheiden kann. Im Idealfall sind das alle 1.1 Millionen Unicode-Zeichen manchmal aber eben nur 65536. Und damit diese Daten auch von und zu andere Systemen übertragen werden können, muss es Zeichenkodierungen wie UTF-8 lesen und schreiben können. Weiterhin ist von Bedeutung, dass nicht nur die Menge an Zeichen verarbeitet werden kann, sondern soweit notwendig auch diverse Eigenheiten der Zeichen und von Sprachen berücksichtigt werden, als da unter anderem wären: Schreibrichtung, Sortierreihenfolge und Kombinationen von Zeichen (´ + a = á).

Lo!

[Der Martin]

Hallo,

[...] sondern soweit notwendig auch diverse Eigenheiten der Zeichen und von Sprachen berücksichtigt werden, als da unter anderem wären: Schreibrichtung, Sortierreihenfolge und Kombinationen von Zeichen (´ + a = á).

wobei die Sortierreihenfolge meiner Ansicht nach überhaupt nichts bei den Spracheinstellungen verloren hat, sondern ausschließlich bei den User Preferences. Ob ich a,ä,á,à, ..., b,c sortieren will oder a,b,c ..., z, ä,á,à, oder gar a==ä==á==à..., b,c, hat für mich nichts mit der Sprache oder der dafür geeigneten Zeichencodierung zu tun, sondern ist einfach eine Frage der persönlichen Vorlieben.

So long,
 Martin

[dedlfix]

Hi!

wobei die Sortierreihenfolge meiner Ansicht nach überhaupt nichts bei den Spracheinstellungen verloren hat, sondern ausschließlich bei den User Preferences.

Ja, gut, du bist in der Hinsicht ja sowieso ein Extremfall :-) Die meisten lassen sortieren wie es in einer Sprache oder Region Standard ist. Und eigentlich hab ich auch noch kein System/Programm gesehen, bei dem man die Sortierreihenfolge so individuell festlegen kann. Wenn es hoch kommt, kann man grad noch zwischen einer Hand voll Systemen wählen.

Ob ich a,ä,á,à, ..., b,c sortieren will oder a,b,c ..., z, ä,á,à, oder gar a==ä==á==à..., b,c, hat für mich nichts mit der Sprache oder der dafür geeigneten Zeichencodierung zu tun, sondern ist einfach eine Frage der persönlichen Vorlieben.

Die Zeichenkodierung ist dafür auch nicht von Belang. Im Gegensatz zur IEC, das in ISO 10646 nur die Zeichen selbst auflistet, pflegt das Unicode Consortium zu jedem Zeichen auch noch Properties, die weiterführende Eigenschaften enthalten, wie eben die Sortierreihenfolge. Und die ist in der Regel abhängig von einer Sprache oder einer regionalen Variante davon.

Lo!

[ChrisB]

Hi,

wobei die Sortierreihenfolge meiner Ansicht nach überhaupt nichts bei den Spracheinstellungen verloren hat, sondern ausschließlich bei den User Preferences.

Ja, gut, du bist in der Hinsicht ja sowieso ein Extremfall :-)

In *der* Hinsicht? :-)

SCNR ChrisB

[Beat]

danke, Beat. Das war sehr aufschlussreich. Endlich mal eine gute Erklärung!

Im Gegenteil. Außer dass das Unicode Consortium sich um Unicode kümmert ist eigentlich nichts so richtig richtig, und auch das war nur die halbe Wahrheit, denn das Unicode Consortium arbeitet zusammen mit der IEC an diesem Standard.[1]

Naja, wer halt nicht verlinkt, nimmt das Risiko auf sich.

Um es kurz zu machen: Unicode ist ein Zeichensatz - eine Ansammlung von Zeichen - und damit ein eher theoretisches Gebilde. UTF-8 ist eine Zeichenkodierung - eine Abbildung der Codepoints von Unicode auf konkrete Bytes und Bytefolgen.

Sieh da, und wir haben ein lexikalisches Problem.
Für mich ist UTF-8 ein Zeichensatz, und so wird es auch benannt.
Zeichensätze kann ich austauschen. Unicode kann ich nicht austauschen. Denn es ist ein vermittelndes System, welches Beschreibungen von Zeichen mit Nummern mappt und so in Programmen adressierbar macht.

Encoding und Decoding ist für mich immer noch der Vorgang einer Übersetzung. Nämlich von einem Zeichensatz (dem einer Datei oder eines andere I/O Layers) in den Programm-internen Zeichensatz bzw. umgekehrt. Derer hat zum Beispiel Perl gleich zwei.

[ChrisB]

Hi,

Sieh da, und wir haben ein lexikalisches Problem.

Dann nimm ein Lexikon zur Hand, damit es Abhilfe schaffen kann.

Für mich ist UTF-8 ein Zeichensatz, und so wird es auch benannt.

UTF-8 ist kein Zeichensatz, sondern eine Zeichenkodierung.

MfG ChrisB

[Beat]

Sieh da, und wir haben ein lexikalisches Problem.
Dann nimm ein Lexikon zur Hand, damit es Abhilfe schaffen kann.
Für mich ist UTF-8 ein Zeichensatz, und so wird es auch benannt.
UTF-8 ist kein Zeichensatz, sondern eine Zeichenkodierung.

Ja. Das sehe ich sofort ein wenn ich
Content-type:text/html; charset=UTF-8
schreibe.

Vielleicht brauche ich ein Lexikon. Aber ich bin in guter Gesellschaft.

mfg Beat

[Jens Holzkämper]

Tach,

Ja. Das sehe ich sofort ein wenn ich
Content-type:text/html; charset=UTF-8
schreibe.

Vielleicht brauche ich ein Lexikon. Aber ich bin in guter Gesellschaft.

ja, auch die Autoren der HTTP-Spec haben es falsch gemacht; das ist bekannt. Kein Grund den Fehler zu wiederholen.

mfg
Woodfighter

[Beat]

Ja. Das sehe ich sofort ein wenn ich
Content-type:text/html; charset=UTF-8
schreibe.

Vielleicht brauche ich ein Lexikon. Aber ich bin in guter Gesellschaft.

ja, auch die Autoren der HTTP-Spec haben es falsch gemacht; das ist bekannt. Kein Grund den Fehler zu wiederholen.

Und die von der MIME-Specification auch...
Nein das hat nichts mit Wiederholung zu tun.

Schau. ich gebe das Charset an, das zum Document gehört.
Das Charset ist hier eine Analogie zur Sprache.
Im Browser kannst du das Encoding (Analogie = Übersetzung) definieren. Das heisst, übersetze Bytes zu Unicode als ob die Sprache so oder so sei.
Ein Document kann sich nicht selbst nach Unicode übersetzen. Es gibt lediglich durch das Charset seine Syntax, seine Sprache an, welche als ein Part in der Übersetzung zu wählen ist. Der andere Part ist die dem programm eigene Idee von Bytes zu Unicode. Ich habe schon gesagt. Perl verwendet zwei Charsets intern. Encoding und Decoding ist die Übersetzung der externen Ressource in diese interne Präsentation.

Ich hoffe das hilft zumindest jenen, die nicht schlauer als die Spec-Autoren sein wollen.

mfg Beat

[ChrisB]

Hi,

Content-type:text/html; charset=UTF-8

Schau. ich gebe das Charset an, das zum Document gehört.
Das Charset ist hier eine Analogie zur Sprache.

Die Sprache von Dokumenten ist Deutsch, Englisch, sonstwas.

Wenn die deiner Dokumente UTF-8 ist, frage ich mich, welche Leute deine Zielgruppe sind. In welchem Land wird UTF-8 gesprochen?

Im Browser kannst du das Encoding (Analogie = Übersetzung) definieren. Das heisst, übersetze Bytes zu Unicode als ob die Sprache so oder so sei.

Eben. Und deshalb ist das (UTF-8) eine Zeichen*kodierung*.

MfG ChrisB

[Beat]

Wenn die deiner Dokumente UTF-8 ist, frage ich mich, welche Leute deine Zielgruppe sind. In welchem Land wird UTF-8 gesprochen?

Du meinst, nur weil ISO-typen verlustfrei nach UTF-8 konvertierbar seien, sei UTF-8 die Sprache aller Sprachen?
Wow. ja, irgendwie gibt es manchmal so etwas wie ein Flächendeckendes Konzept, wenn auch orthogonal zu Landesgrenzen. Aber UTF-8 ist auch nur ein begrenztes, wenn auch in nächster Zeit ausreichendes Char-Speicher-Set

Im Browser kannst du das Encoding (Analogie = Übersetzung) definieren. Das heisst, übersetze Bytes zu Unicode als ob die Sprache so oder so sei.

Eben. Und deshalb ist das (UTF-8) eine Zeichen*kodierung*.

Auch ein Übersetzungsproblem. Es hilft nicht, ein en oder de wegzuscheiden.
Das Englische Äquivalent zu Zeichenkodierung ist Char-Encoding.
Leider ein dummes Wort- Häufiger Lese ich Charset-Encoding und Charset-Decoding.

UTF-8 nimmt Teil am Zeichenencoding.
Ich lasse durchaus über den Begriff Charset diskutieren. Unicode hat ja die historischen Charsets von der Beschreibung der Codepunkte entlastet. Die primäre Aufgabe ist es die Speicherordnung in Bytes zu regeln.
Aber Encoding ist eine Übersetzung. Charset ist ein Zustand, eine Information, die es von Übersetzung zu Übersetzung zu transportieren gilt.
Ein Charset ist existentieller Bestandteil jeder Textdatei. leider lassen nicht alle Textformate eine Angabe dieser Information zu.

Programm -> Encode  ->  Media (Charset)  ->  Decode -> Programm.
                      [storage or transport]
mfg Beat

[dedlfix]

Hi!

Aber UTF-8 ist auch nur ein begrenztes, wenn auch in nächster Zeit ausreichendes Char-Speicher-Set

Nein, UTF-8 ist weder Charset noch Char-Speicher-Set sondern eine Vorschrift, wie Codepoints in Bytes umgerechnet werden.

Und Unicode ist so angelegt, dass es nicht begrenzt ist. Jedes Zeichen befindet sich an einem Codepoint, der eine natürliche Zahl ist und damit nach oben unbegrenzt. Und wenn du so willst hat das UTF-8-Kodierprinzip zwar derzeit eine Grenze, aber ich sehe da durchaus noch genügend Potenzial um der Unendlichkeit ein gutes Stück näher zu kommen (das (Näherkommen) geht zwar im Prinzip rein technisch nicht, aber egal).

Ich lasse durchaus über den Begriff Charset diskutieren. Unicode hat ja die historischen Charsets von der Beschreibung der Codepunkte entlastet. Die primäre Aufgabe ist es die Speicherordnung in Bytes zu regeln.

Genau das ist eben nicht Unicodes Aufgabe, das ist Aufgabe der Kodierungen. Unicode-Codepoints haben keinen Bezug zu einer konkreten Abbildung. Das regelt die Kodiervorschrift.

Ein Charset ist existentieller Bestandteil jeder Textdatei.

Auch dem kann ich nicht zustimmen. Bestandteil einer Textdatei sind wie bei jeder anderen Datei auch die Bytes (in bytebasierenden Speichermedien). Zum Interpretieren ist es existentiell notwendig die Kodiervorschrift zu kennen. Leider ist die Angabe der Kodiervorschrift in kaum einem Dateisystem Bestandteil einer Datei oder ihrer Metadaten, ebensowenig wie in den einfacheren Dateiformaten - aber das ist ein anderes Thema. Das Charset selbst ist nur implizt von Interesse, weil es als theoretisches Gebilde nur über die Kodiervorschrift einen Bezug zum konkreten Gebilde "Datei" hat. Allenfalls sind zu den im Charset enthaltenen Zeichen Eigenschaften definiert, die zur weiteren Verarbeitung benötigt werden (Sortierung, Schreibrichtung), nicht aber für die Existenz des Dateiinhalts.

Lo!

[Beat]

Ich lasse durchaus über den Begriff Charset diskutieren. Unicode hat ja die historischen Charsets von der Beschreibung der Codepunkte entlastet. Die primäre Aufgabe ist es die Speicherordnung in Bytes zu regeln.

Genau das ist eben nicht Unicodes Aufgabe, das ist Aufgabe der Kodierungen. Unicode-Codepoints haben keinen Bezug zu einer konkreten Abbildung. Das regelt die Kodiervorschrift.

Ich hätte sagen sollen
A) "Die primäre Aufgabe von Charsets ist"

Wehe man lässt ein Wort aus. Man wird als dümmer verstanden als man ist.

mfg Beat

[dedlfix]

Hi!

Content-type:text/html; charset=UTF-8
ja, auch die Autoren der HTTP-Spec haben es falsch gemacht; das ist bekannt. Kein Grund den Fehler zu wiederholen.
Und die von der MIME-Specification auch...
Nein das hat nichts mit Wiederholung zu tun.

Hat es auch nicht, denn es ist ein und dasselbe. Bei http://de.selfhtml.org/xml/regeln/xmldeklaration.htm#zusatzangaben@title=XML hat man den Fehler nicht wiederholt, da heißt es encoding.

Die Verwendung von "charset" hat vor allem historisch Gründe beziehungsweise liegt in der nicht zwingend vorhandenen Notwendigkeit begründet, bei Zeichensätzen mit bis zu 256 Zeichen zwischen der Position eines Zeichens im Zeichensatz und der Kodierung dieser Position als Bytewert zu unterscheiden. Position 64 = Bytewert 64 (oder 40 in Hex) oder 1 Zeichen = 1 Byte. (Da war die Welt noch übersichtlich - und ziemlich klein. Der kalte Krieg zog seine Schützengräben und das Dahinter interessierte kaum. Außerdem war Speicher und Rechenleistung zu knapp, um unnötig Ressourcen für Schriftsysteme von anderen Provinzen dieser Welt zu reservieren.)

Schau. ich gebe das Charset an, das zum Document gehört.
Das Charset ist hier eine Analogie zur Sprache.

Der Empfänger soll einen Bytestrom interpretieren. Dazu benötigt er nicht den Zeichensatz sondern erst einmal die Kodierungsvorschrift, um aus den Bytewerten oder -sequenzen das passende Zeichen zu entnehmen. Es muss also nicht "Unicode" bekannt sein sondern "UTF-x" (x wie 8, 16, etc.).

Im Browser kannst du das Encoding (Analogie = Übersetzung) definieren. Das heisst, übersetze Bytes zu Unicode als ob die Sprache so oder so sei.

Der Browser benötigt das Wissen um die Encoding-Vorschrift, damit er das richtige Decoding anwenden kann, um letztlich das richtige Zeichen an das Ausgabemedium (z.B. Bildschirm) senden zu können. (Den Weg zurück zum Server können wir für diese Diskussion unbetrachtet lassen.)

Der Vergleich mit einer natürlichen Sprache hinkt sehr. Aber ich versuche es mal:

EDV                      - Sprache
-----------------------------------------
Zeichenkodierung (UTF-8) - Schallwellen
Zeichensatz              - Wörter
Zeichen                  - Begriff

Mit Zeichen und Begriff ist das gemeint, was man gemeinhin mit einem konkreten solchen assoziiert.
Zeichen "a" = Ein Buchstabe aus dem lateinischen Alphabet.
Begriff "Haus" = Das meist eckige Ding, das in der Landschaft rumsteht, das sich einige Lebewesen errichten, wenn nicht genug Höhlen zur Verfügung stehen (oder ihnen der Komfort einer solchen nicht zusagt).

Ein Document kann sich nicht selbst nach Unicode übersetzen. Es gibt lediglich durch das Charset seine Syntax, seine Sprache an, welche als ein Part in der Übersetzung zu wählen ist.

So richtig verstehe ich nicht, was du mir damit zu sagen versuchst.

Unicode ist nicht die Kodierung eines Dokuments sondern beschreibt nur den Vorrat aller Zeichen, die das Dokument nutzen kann, ohne konkret zu sagen, wie die Zeichen jeweils repräsentiert werden. Will man eines dieser Zeichen in einem real existierenden Medium abbilden, braucht es eine Kodiervorschrift. UTF-8 sagt, wie das Zeichen "sowieso" konkret in Bytes gegossen aussieht.

Der andere Part ist die dem programm eigene Idee von Bytes zu Unicode. Ich habe schon gesagt. Perl verwendet zwei Charsets intern.

Du meinst die Idee von Bytes (einer bestimmten Kodierung) zu einer internen Darstellung (zwecks Verarbeitung). Da Unicode nicht beschreibt, wie ein Zeichen im Speicher abzubilden ist, muss man sich hier eine eigene Kodierung erfinden oder eine der vorhandenen verwenden. UTF-8 ist zwar (sehr) gut für den Transport (von Dokumenten vorwiegend westlichen Inhalts) geeignet, aber aufrund der unterschiedlichen Bytesequenzlängen weniger gut für die interne Verarbeitung. Wenn man sich für Stringfunktionen nicht immer durch diese Sequenzen durchhangeln will, kommt man besser, wenn man gleichlange Strukturen zum Speichern der Zeichen verwendet, also 16 Bit wenn man nur die bis zu 65.536 Zeichen von Unicode 1.0 berücksichtigen will oder 21 Bit (sinnvollerweise gleich 3 oder 4 Byte) für alle 1.114.112 möglichen Zeichen ab Unicode 2.0. Mit diesen einheitlich langen Containern für die Zeichen kann man unter anderem schneller die Positionen der einzelnen Zeichen im Speicher berechnen (Position im Speicher = Position im String * Containerlänge).

Encoding und Decoding ist die Übersetzung der externen Ressource in diese interne Präsentation.

Die Begriffe Encoding und Decoding stehen ja nicht nur für das Hin- und Her zwischen Zeichensatz-Position und Bytewerten sondern auch allgemein für eine Umwandlung von einer Darstellung in eine andere und zurück.

Dass zwischen Perl-interner (vielleicht proprietärer) Repräsentation und einer genormten Form zwecks Austausch mit anderen Systemen en- und decodiert werden muss steht außer Frage. Aber das ist kein Grund zwischen Zeichensatz und Zeichenkodierung nicht richtig zu unterscheiden oder den "charset"-Fehler nicht als solchen zu bezeichnen.

Lo!

[Beat]

Unicode ist nicht die Kodierung eines Dokuments sondern beschreibt nur den Vorrat aller Zeichen, die das Dokument nutzen kann, ohne konkret zu sagen, wie die Zeichen jeweils repräsentiert werden.

Unicode ist eine Verschwörung. Es geht darum, dass eine Behörde/Consortium whatever zuständig ist, Zeichen zu beschreiben und diesen zeichen einen Universellen Zahlencode zuzuweisen. Einerseits um Wildwuchs zu dämmen, einem Bedürfnis nach Interoperabilität entgegenzukommen, und nicht zuletzt, um die Alten System von dieser Aufgabe zu entlasen.
Das was diese Behörde wirklich macht ist das Codifizieren von Zeichen.
Interessant.
One Code that fits all.

Will man eines dieser Zeichen in einem real existierenden Medium abbilden, braucht es eine Kodiervorschrift. UTF-8 sagt, wie das Zeichen "sowieso" konkret in Bytes gegossen aussieht.

Alle Zeichensütze, verzeih für einmal, befassen sich nicht mehr mit einzelnen Zeichen. Genau das ist ja durch Unicode obsolet geworden. Die ehemaligen Tabellen dürfen statt dessen durch Algorythmen ersetzt werden, um von den Bytes zu einem Unicode-Punkt zu gelangen.
Aber interessant ist nun das. Du sagst 'gegossen' und irgendwo rauscht wohl noch der Bleisatz rum als Echo. ich kann mit dem Wort 'setzen' immer noch leben im Sinn von 'a set of Bytes'. Das Wort Charset gibt den Sachverhalt nicht richtig wieder. Aber an einem anderen Ende werde ich dir zeigen, dasss wen von Charcode die Rede ist, Bytes gar keine Rolle mehr spielen.

Dass zwischen Perl-interner (vielleicht proprietärer) Repräsentation und einer genormten Form zwecks Austausch mit anderen Systemen en- und decodiert werden muss steht außer Frage. Aber das ist kein Grund zwischen Zeichensatz und Zeichenkodierung nicht richtig zu unterscheiden oder den "charset"-Fehler nicht als solchen zu bezeichnen.

OK. Encoding geschieht nicht nur zwischen charsets, sondern notwendigerweise zwischen Transportlayern. Manche mögen auch Escaping borziehen, wenn vom PercentEncoding für URLs die Rede ist.

Ich möchte dir aber nahe legen, wo und wie vor allem von Charcodes die Rede ist.
alert( String.fromCharCode(4256) )
Die Zahl repräsentiert einen Unicode Punkt, kein UTF-8 und keine anderen Bytes. Charcode ist zutiefst mit Unicode-Punkten sprachlich verbandelt, heute. So, wenn von Zeichenkodierung und Zeichenkodifizierung die Rede ist, denke ich zuerst an die Tätigkeit des Unicode-Consortiums.

Wenn wir einen "charset" Fehler haben, so willst du ihn offenbar durch einen "charcode"-Fehler verbessert wissen.

Möglicherweise brauchen wir ein anderes Wort für charset. Aber charcode ist schon belegt. charbyteorder würde wohl der Sache am nächsten kommen.
Aber Definition eines Wortes ist nicht mein Anliegen
Genug für heute.

mfg Beat

[dedlfix]

Hi!

Unicode ist eine Verschwörung.

Oh oh, das gibt schonmal satte Minuspunkte in der Diskussion.

Es geht darum, dass eine Behörde/Consortium whatever zuständig ist,

Man kann nachlesen, wer Mitglied vom Unicode Consortium ist und wer da Mitglied werden kann.

Alle Zeichensütze, verzeih für einmal, befassen sich nicht mehr mit einzelnen Zeichen. Genau das ist ja durch Unicode obsolet geworden.

Diese Aussage verstehe ich so, dass du sagst, ein Baum bestehe nicht mehr aus Zweigen und Blättern und die Biologie müsse nur noch den Baum aber nicht mehr dessen Blätter betrachten. Erscheint mir nicht zweckdienlich. Natürlich muss man manchmal abstrahieren und etwa von einem höheren Standpunkt aus betrachten, der Details weglässt. Trotzdem verliert der Baum seine Blätter nicht (abgesehen von den jahreszeitlichen Spielchen der Natur).

Die ehemaligen Tabellen dürfen statt dessen durch Algorythmen ersetzt werden, um von den Bytes zu einem Unicode-Punkt zu gelangen.

Unicode hat inzwischen mehr Zeichen aufgenommen als jemals in irgendwelchen Codetabellen enthalten waren. Umrechnungsvorschriften zwischen bisherigen Tabellen und Unicode haben rein praktische Gründe, um Inhalte von einem System in ein Unicode-basierendes zu übertragen. Wenn man gleich und ausschließlich mit Unicode angefangen hätte, wäre das nicht notwendig gewesen. Diese Beziehungen zu anderen Systemen bringen uns jedenfalls nicht zum Kern der Ausgangsfrage.

Aber interessant ist nun das. Du sagst 'gegossen' und irgendwo rauscht wohl noch der Bleisatz rum als Echo.

Das kannst du dir so vorstellen, als dass ein nicht greifbares Etwas, weil es ein abstraktes, theoretisches Gebilde ist, in eine konkrete Form gebracht wird, die "fassbaren" Bytes.

ich kann mit dem Wort 'setzen' immer noch leben im Sinn von 'a set of Bytes'.

Also "setzen" im Sinne von "zusammensetzen" und nicht "hinstellen". Aber nicht Bytes. Noch einmal: wenn der Zeichensatz betrachtet wird, spielen Bytes keine Rolle, nur die Zeichen und vielleicht noch deren Beziehungen zueinander. Die Zeichen von Unicode sind Codepoints zugeordnet und nicht Bytes. Das macht dann erst eine der Kodierungen (UTF).

Das Wort Charset gibt den Sachverhalt nicht richtig wieder. Aber an einem anderen Ende werde ich dir zeigen, dasss wen von Charcode die Rede ist, Bytes gar keine Rolle mehr spielen.

Welchen Sachverhalt meinst du nun? Unicode als Zusammenstellung von Zeichen oder den zu deren Abbildung in realen Medien notwendigen Vorgang oder alles beides zusammengefasst?

Das Wort "Charcode" ist nicht einmal in der englischen Wikipedia als Stichwort enthalten. Bleiben wir doch lieber bei allgemein anerkannten Begriffen. Codepoint als Position in der Zeichenansammlung namens Unicode und Bytes oder Bytesequenz als eine Form der konkreten Abbildung. Charcode oder Zeichencode ist zu allgemein und lässt viele Interpretationen offen. Codes, die mit einem Unicode-Zeichen in Zusammenhang stehen wären Codepoint und die Kodierungen in Byteform. Charcode kann sowohl das eine als auch das andere bezeichnen, also ist es als Begriff untauglich, wenn man den Unterschied zwischen beiden beschreiben soll.

Codepoints sind zwar eine Art der Kodierung - ein Zeichen wird repräsentiert von einem Integerwert - aber der Vorgang dieser Kodierung interessiert uns als Praktiker nicht mehr, der ist vom U.C. erledigt worden. Wir benötigen nur eine Möglichkeit, diesen Integerwert in Bytes darzustellen, damit wir unsere Dokumente in eine computerlesbare Form bringen können, deswegen ist bei "Kodierung" nur dieser Vorgang gemeint (jedenfalls in diesem Zusammenhang. Anderswo wird der Begriff "Kodierung" ebenfalls verwendet).

OK. Encoding geschieht nicht nur zwischen charsets, sondern notwendigerweise zwischen Transportlayern. Manche mögen auch Escaping borziehen, wenn vom PercentEncoding für URLs die Rede ist.

Escaping ist eine komplett andere Baustelle. Dass man dazu eine Kodierung braucht, also eine Abbildung von einem Ding in eine für ein anderes Medium verwendbare Form, ist zwar ein gleichartiger Vorgang wie das Abbilden von Unicode-Zeichen mit Bytes, doch das spielt bei unserer Betrachtung keine Rolle.

Ich möchte dir aber nahe legen, wo und wie vor allem von Charcodes die Rede ist.
alert( String.fromCharCode(4256) )

Hier hat man vielleicht unbewusst eine zu allgemeine Formulierung verwendet oder grade auf sie gesetzt, weil diese Funktion möglicherwiese für mehrere Systeme anwendbar sein soll, die den Begriff Codepoint nicht verwenden. Ich tippe auf ersteres, weil im Javascript-Umfeld selbst die Zeichenkodierung keine Rolle mehr spielt, die hat der der Browser schon von der Dokumentkodierung in eine interne auf Unicode basierende Form gebracht. Javascript als abstrakte Sprache verwendet Unicode als abstrakten Zeichenvorrat. Die konkrete Implementation in den Browsern interessiert uns als außenstehende Anwender in der Regel nicht, weswegen die konkrete Abbildung im Speicher und die dabei verwendete Konkretisierung in Bytes (oder was auch immer der Browser verwendet) hier nicht von Belang ist.

Möglicherweise wird die Geschichte verständlicher, wenn ich versuche, sie à la OSI-7-Schichten-Modell darzustellen (nur angelehnt, ohne exakt die Bedeutung der Schichten zu berücksichtigen).

Anwender beschäftigt sich mit Text.
Text besteht aus Zeichen.
Unicode definiert zu den Zeichen CodePoints.
UTF-x bringt CodePoints in eine Byteform.
Bytes stehen in Dateien.
Dateien ... usw.

Verglichen mit ISO-8859-1 wäre der dritte und vierte Satz wie folgt:
ISO-8859-1 definiert zu den Zeichen eine Position (nummeriert von 0 und 255).
Die Positionen ensprechen jeweils einem Bytewert.

Die Zahl repräsentiert einen Unicode Punkt, kein UTF-8 und keine anderen Bytes.

Einen Unicode-Codepoint also, eine mehr oder weniger erst einmal abstrakte Integerzahl, die ein Zeichen repräsentiert.

Charcode ist zutiefst mit Unicode-Punkten sprachlich verbandelt, heute.

Ich sehe das im Moment nur als ein Funktionsname in der Javascript-Welt. Von "zutiefst" im allgemeinen Sprachgebrauch kann ich da nichts sehen.

So, wenn von Zeichenkodierung und Zeichenkodifizierung die Rede ist, denke ich zuerst an die Tätigkeit des Unicode-Consortiums.

Als Mitglied des U.C. kannst du daran denken. Als außenstehender Anwender spielt diese Tätigkeit keine Rolle, da brauchen wir nur eine Möglichkeit vom Ergebnis dieser Tätigkeit, also den Codepoints in eine Byteform zu gelangen. Dafür hat das U.C. in einer "Nebentätigkeit" die Kodiervorschriften UTF-8 usw. erstellt.

Wenn wir einen "charset" Fehler haben, so willst du ihn offenbar durch einen "charcode"-Fehler verbessert wissen.

Nein, "Charcode" ist ein Begriff, den ich nicht verwende. Verbessern (im Sinne von darauf hinweisen) möchte ich nur, dass man weiß, dass der Parametername (siehe RFC 2616 - 3.7) für den Content-Type statt charset besser encoding hieße, weil er die konkrete Kodierungsvorschrift von Codepoints (allgemein: Position in einem abstrakten Gebilde namens Zeichensatz) in Byteform meint.

Möglicherweise brauchen wir ein anderes Wort für charset. Aber charcode ist schon belegt. charbyteorder würde wohl der Sache am nächsten kommen.

Nein, das mischt zwei zu trennende Vorgänge zusammen und ist noch uneindeutiger (wenn ich mal so steigern darf) als das Wort Charset momentan wirkt. Charset ist nur deshalb so missverständlich, weil es zu oft falsch verwendet wird - es war eben in der Vergangenheit nicht direkt notwendig zwischen den Begrifflichkeiten zu trennen. Hinzu kommt, dass es mitunter auch noch für Schriftart / Font verwendet wird. Wann immer man ein System nicht von Anfang an sauber aufsetzt und bezeichnet hat man man in alle Ewigkeit (jedenfalls ziemlich lange) an den Folgen der Unbrauchbarkeit und Missverständlichkeit zu leiden.

Aber Definition eines Wortes ist nicht mein Anliegen

Meins auch nicht, sonst schlüge ich Charpool und Enbyteing vor, mach ich aber nicht.

Charpool ist noch unverbraucht und schön unkonkret. Die Zeichen schwimmen darin herum, ein jedes aber mit einem eindeutigen aber kurzen Identifikationsmarkmal. Ich glaube, fortlaufende Nummern haben sich dafür recht gut bewährt (vom Wasser gebremst können sie auch nicht allzu schnell fortlaufen). Enbyteing ist aber schon wieder zu konkret, weil man sicher auch andere Formen als Bytes zum konkreten Darstellen verwenden will.

Mit diesem nicht ganz ernst gemeinten Abschluss kündige ich meinen alsbaldigen Ausstieg aus der Diskussion an. Meine Argumente habe ich vorgebracht, ich würde sie nur anders formuliert wieder bringen, solange ich nicht so widerlegt werde, dass ich es auch verstehe und akzeptieren kann. Letztlich bleibt es dem Leser überlassen, wie er sich seine Meinung zu dem Thema bildet.

Lo!

[Beat]

Mit diesem nicht ganz ernst gemeinten Abschluss kündige ich meinen alsbaldigen Ausstieg aus der Diskussion an. Meine Argumente habe ich vorgebracht, ich würde sie nur anders formuliert wieder bringen, solange ich nicht so widerlegt werde, dass ich es auch verstehe und akzeptieren kann. Letztlich bleibt es dem Leser überlassen, wie er sich seine Meinung zu dem Thema bildet.

Mein Schlusspunkt, und dann lassen wir ruhen:

Immerhin habe ich den Eindruck, dass in der Tat ein lexikalisches Problem besteht, das nicht zu lösen ist. Man wird die Sache nicht mit einfachen Begriffen erklären können, sondern muss halt schon expliziter Beispiele geben.
Wir werden weiter damit leben, dass der Feldbezeichner im Content-type charset heisst, und dass der Wert zu diesem Feld (ISO-8859-n, UTF8, UTF16 etc...) einen umstrittenen Klassennamen hat. Wichtiger ist es, die Aufgabe dieser Werte im Vorgang zu erklären.
Wenn ich in meiner anfänglichen Antwort schrieb
"UTF-8 ist ein ein Wert zum Feld Zeichensatz (eng. charset).
Ein Zeichensatz ist eine Tabelle, welche Bytes zu Unicodes mappt und.."

So darf von mir aus jeder seinen eleganteren Bogen vom ersten zum zweiten Satz wagen. Für mich besteht diese Notwendigkeit nicht, weil ich keinen Vorteil darin sehe, eine Ambiguität durch eine andere zu ersetzen.

Danke für deine Diskussion.

mfg Beat

[Gunnar Bittersmann]

@@Beat:

nuqneH

Wir werden weiter damit leben, dass der Feldbezeichner im Content-type charset heisst, und dass der Wert zu diesem Feld (ISO-8859-n, UTF8, UTF16 etc...) einen umstrittenen Klassennamen hat.

Wir werden auch weiter damit leben, dass der Feldbezeichner im HTTP-Header "Referer" heißt.

Wir werden auch weiter damit leben, dass die CSS-Pseudoklasse ':link' heißt.

Und auch damit, dass die HTML-Entity "sbquo" heißt.

Wenn ich in meiner anfänglichen Antwort schrieb
"UTF-8 ist ein ein Wert zum Feld Zeichensatz (eng. charset).
Ein Zeichensatz ist eine Tabelle, welche Bytes zu Unicodes mappt und.."

Wie ich letztens erst sagte: Wann immer von "charset" die Rede ist, ist „character encoding“, also „Zeichencodierung“ gemeint.

Beide Male wäre „Zeichencodierung“ statt „Zeichensatz“ korrekt gewesen.

Qapla'

[Der Martin]

Hallo,

Für mich ist UTF-8 ein Zeichensatz, und so wird es auch benannt.
UTF-8 ist kein Zeichensatz, sondern eine Zeichenkodierung.

stimmt, und es hat mich auch lange Zeit gekostet, das zu begreifen. Gut finden muss ich es nicht.
Zwischen Zeichensatz und Zeichencodierung zu trennen und zu unterscheiden, macht dieses ohnehin schon verzwickte Thema meiner Ansicht nach noch komplizierter.

Früher[tm] verstand man unter "Zeichensatz" die gesamte Abbildung vom numerischen Code eines Zeichens bis zum Bitmuster, das dazu auf dem Bildschirm erschien. Da war das Thema noch intuitiv.
Mit dem Siegeszug von graphischen Oberflächen koppelte man die Schriftart (Font) als rein graphische Komponente davon ab.
Später betrachtete man auch noch die interne technische Repräsentation (Bytefolge) eines bestimmten Zeichens (Zeichencodierung) als eigenes Thema.

Welche Abstraktionsstufe kommt als nächste? Phoneme?

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

Zwischen Zeichensatz und Zeichencodierung zu trennen und zu unterscheiden, macht dieses ohnehin schon verzwickte Thema meiner Ansicht nach noch komplizierter.

Au contraire, mon capitaine! Die Unterscheidung zwischen Zeichensatz und Zeichencodierung macht das Vertehen dieses dann gar nicht mehr so verzwickten Themas erst möglich.

Früher[tm] verstand man unter "Zeichensatz" die gesamte Abbildung vom numerischen Code eines Zeichens bis zum Bitmuster, das dazu auf dem Bildschirm erschien. Da war das Thema noch intuitiv.

Jaja, früher[tm] war die Welt noch in Ordnung.

Qapla'

[Wolfgang]

Hi,

was genau ist der Unterschied zwischen utf-8 und unicode?

Also Unicode ist eine international gültige Zeichentabelle, die auch heute noch ausgebaut wird und mit dem Ziel geschaffen wurde, alle druckbaren Zeichen, Buchstaben und Zahlen in eine Codetabelle zu integrieren.

Das Ding hat derzeit über 70.000 Zeichen und es ist klar, bzw sollte klar sein, dass "unicode-untertützung" nicht automatisch alle Sprachen meint.

Besonders deutlich sieht man das an Zeichen, die nicht zu einer Sprache gehören. Die hier gezeigten technischen Symbole gehören zum Unicode-Zeichensatz und konnten auf der Webseite nicht dargestellt werden. Was ich hier damals diskutiert hatte, das war eine mangelnde Möglichkeit für den Webserver zu ermitteln, ob die Zeichen vorhanden sind, oder nicht.

utf-8 jedenfalls ist eine bestimmte Darstellung dieser Codepage, zwei andere ebenfalls nach dieser Norm gültige sind utf-16 und utf-32. Das sogenannte utf-7 ist kein Unicode, das ist etwas, das sich Microsoft ausgedacht hat, um die Welt komplizierter zu machen.

Dabei sind die Inhalte von utf-8, uft-16 und utf-32 identisch und jederzeit ineiander umrechenbar. Es ist völlig gleich, welche Entscheidung man trifft (utf-8, uft-16 oder utf-32=, man kann immer die gleichen Infomationen abspeichern. Eine Fehlentscheidung macht die Dateien maximal um den Faktor 4 größer.
Wenn du nach dem "Unterschied" fragst, dann wahrscheinlich, weil ein Editor einmal unter "Unicode" abspeichert und einmal unter utf-8. In diesem Fall dürfte entweder utf-16 gemeint sein oder utf-32. Das muss man dann aber probieren.

Was bedeutet es, wenn eine Sprache, zb. Java, Unicode unterstützt? Was für eine, die es nicht unterstützt?

In einer Sprache, die kein unicode unterstützt, sondern nur nicht-Unicode Codetabellen kann man maximal 128 verschiedene Zeichten verarbeiten. So kann mit iso-8859-1 keine russischen und keine hebräischen Zeichen - und viele andere auch nicht - verarbeiten.

Herzliche Grüße
Wolfgang