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!