nicht angemeldet
Hi!
Das werde ich etwas genauer erläutern, aber nicht so tief gehend wie Tom sich das vorstellt.
Du sollst auch nicht bei Adam und Eva anfangen, sondern lediglich bildlich machen, warum es da zu Unterscheidungen kommt.
Zeichenkodierung möchte ich wirklich aus diesem Artikel raushalten. Das füllt locker einen eigenen. Denn bei Zeichenkodierung spielt nicht nur der sichtbare Code im Editor eine Rolle sondern auch noch die versteckte Konfiguration zur Kodierung beim Speichern. Das Thema ist schon reichhaltig genug. Wenn ich da auch noch die Unwägbarkeiten des Editors in die Erläuterung aufnehme, wird mir das zu viel Stoff für das angestrebte Publikum, weil ich dann wirklich die Bytesequenzen zur Veranschaulichung heranziehen müsste.
Wesentlich ist doch die Konsistenz der Rohdaten und die spiegeln sich nun mal in der Datenhaltung wieder. Setzt man voraus (was auch nicht selbstverständlich ist), dass die Datenhaltung im Wesentlichen byteorientiert funktioniert heute, dann wäre das die gemeinsame Basis für alle weiteren Handlungen.
Ich setze für diesen Artikel eine Zeichenorientierung als unterstes technisches Level voraus.
Es muss möglich sein, von den Rohdaten über die Übertragungsstrecke, auf der dann die Kontextwechsel stattfinden, wieder zu den Rohdaten zu gelangen.
Deswegen bereite ich sie zeichenorientiert für den passenden Kontext auf. Ob die Übertragungsstrecke sie in Byte oder was anderes zerlegt, ist mir als Anwender egal. Ich hab sie ordnungsgemäß dem Transporteur übergeben, die Gefahr geht damit auf den Käufer über ... ups, falscher Kontext :-)
Eine grafische Darstellung sollte auch in der Lage sein klarzustellen, dass man nicht jeden Transformationsschritt irgendwann machen darf und nicht jede Hilfsmaßnahme irgendwann ergreifen darf (Escaping für eine Schnittstelle), sondern diese in einer wohlüberlegten reihenfolge stattfinden müssen.
Das hab ich doch auch ohne grafische Darstellung schon in den Abschnitten zu geschachtelten Kontexten drin? Und die Reihenfolge ergibt sich aus der Schachtlung. Sie von innen nach außen aufzulösen, habe ich erwähnt.
Ich muss für den Eintrag von Daten in eine Datenbank keine Tags ziehen, vorausgesetzt, sie gehören zu den Rohdaten. Ich muss auch kein addslashes() für eine MySQL-Text-Schnittstelle benutzten. Das passt nämlich nicht zusammen. usw.
Benutzen müssen muss man addslashes() nicht, aber völlig unpassend ist es nun auch wieder nicht. Es behandelt alle für MySQL-Strings wirklich kritischen Zeichen: ", ', \ und für Binärdaten das Null-Byte. Der Rest ist nice-to-have: "(Striktly speaking, ...)"
Lo!
Auge