Computer sind für Daten austauschen darauf angewiesen, dass diese eindeutig Kodiert sind, weil sonst jemand seine Daten an anderem Ort als etwas anderes erscheinen. Selten als etwas verwertbares, vielleicht noch halbwegs erkennbar, aber oft komplett zerstückelt. Sowas ist als Digitale Brüchigkeit bekannt.
Binäre Datenformate sind am schlimmsten betroffen, zerbrechen zumeist komplett sobald nicht mehr kompatibel erweitert, sind aber zum Glück grossteils auf Multimedia limitierbar (Photo, Audio, Video), und so nicht sonderlich schwer funktionskritisch, wenn auch nervend wenn kaputt. Solange reiner Text lesbar bleibt, und damit auch getippte Kommunikation via Web und Mail, sollte alles trotzdem halbwegs gut gehen.
Nur ist inzwischen selbst das von Featurefetischisten sabotiert worden, welche ihrer bedingunglosen "mehr ist besser" Ideologie folgen, in Form von Unicode! Dieses war wieder einmal ein Versuch eine eierlegende Wollmilchsau zu erzeugen, um damit alle anderen Textformate durch ein einzelnes weltweit universelles zu ersetzen. Wieder einmal ist solches Verlangen wegen groben Designdefekten und Nebenwirkungen gnadenlos gescheitert, und hat statt dessen nur bleibend Inkompatibilität erzeugt und Unlesbarkeit erhöht.
Nebenbei: Sie waren sich anfangs nicht mal in der Anzahl Bits pro Zeichen einig. Die Fernschreiber Leute verwendeten anfangs 5bit und später 7bit. (Das 5bit System definierte die Buchstaben QWERTYUIOP als geschiftete Ziffern 1..9 und 0=10, also nicht linear nummeriert!) Die 8/16/32/64bit Computer Leute verwenden 8bit Bytes/Zeichen, aber die in den 1960ern verbreiteteren 12/18/24/36/48/60bit Computer verwendeten 6bit Bytes. Ein 36bit Hersteller erlaubte sogar wahlweise 5/6/7/8/9bit, 1* 36bit aufgeteilt in Bytes als (1+)7*5 oder 6*6 oder (1+)5*7 oder (4+)4*8 oder 4*9!
Benutzer wollen aber mit Leuten mit anderem Computersystem Daten austauschen. Bei n Systemen dazu n² Konvertierprograme schreiben wurde zu aufwendig (und war bei seltenen Systemen schlicht nicht vorhanden). Also wurde ein Austauschformat standardisiert, mit pro Rechnertyp nur noch 2 Konvertierer zu/von diesem Format nötig, insgesammt 2*n davon (und auch seltene Systeme nur ihre 2 brauchend). Als Basis nahm man den ohnehin bereits definierten 7bit Fernschreibercode, weil Telekommunikation von NAtur aus Datenaustausch ist, und so auch zwischen Geräten verschiedener Hersteller gehen muss, weltweit. Dazu kam, dass einige Computer Hersteller Fernschreiberinterfaces anboten, um solche als Drucker und/oder Tastatur zu benutzen. Das resultierende Format heisst ASCII, was "American Standard Code for Information Interchange" heisst, übersetzt "Amerikanischer Standard Code für Daten Austausch".
Nebenbei: Dieser umfasst als Codierung: Zeichen 0 = Nichts/Platzhalter, 1..31 sind Steuerzeichen (darunter 13 zurück zu Zeilenanfang und 10 vorlauf zu Neuzeile), 32 ist Leerzeichen, 33..126 sind 94 graphische/druckbare Zeichen (darunter 48..57 Ziffern 0..9 und 65..90 Grossbuchstaben A..Z und 97..122 Kleinbuchstaben a..z, sowie insgesammt 32 Satzzeichen), 127 ist Ausradiert/Gelöscht. (ASCII wurde dann Teil des Internets, als Basis von den Telnet (remote Login) und FTP (Daten zwischen Rechnern kopieren) Protokollen, sowie von dort her in viele neuere übernommen (inlusive SMTP, POP3, IMAP4, NNTP, und HTTP).)
In den 1970ern/80ern haben die vielen neu entstandenen 8bit Mikrocomputer und Homecomputer und Personalcomputer Firmen kurzerhand ASCII zu ihrem nativen Code genommen, und sich so den Aufwand von Konvertierer erspart. Zumal 7bit Text problemlos in 8bit Prozessoren passt. Aber sie hatten alle 8bit, und ASCII nutzt nur 7bit davon. In den 1970ern war der normale Gebrauch vom achten Bit im Videospeicher inverse Darstellung und bei Textverarbeitung Endemarkierung.
In den 1980ern mit besserer Videohardware, mit separatem Attributspeicher für Darstellungsformat steuern, wurde das achte Bit wieder frei und konnte für erweiterte Zeichensätze genutzt werden. Darunter auch jegliche wegen ASCII amerikanisch sein darin fehlenden akzentierte Zeichen (inklusive Umlaute). Bei Textverarbeitung mussten diese alle auch mit rein, weshalb bald eine 0 als separate Endemarkierung verwertet wurde.
Nebenbei: Der ISO-646 Standard, von dem ASCII schlicht die USA Untervariante ist, erlaubt auch Umlaute in 7bit, aber auf Kosten von 12 unwichtigere der 32 Satzzeichen des ASCII ersetzen (diese sind # und $ sowie @ und [ \ ] ^ sowie ` und { | } ~). Was als NRCS ("National Replacement Character Set", übersetzt "Nationaler Ersatz Zeichen Satz") bekannt ist. In der britischen Variante wird # zu £ (und dessen Platz ist überall weltweit entweder # oder £, ebenso ist $ stets dies oder ¤). In der deutschen Variante werden die @ und [ \ ] sowie { | } und ~ zu § und Ä Ö Ü sowie ä ö ü und ß. Wer sicher lesbar sein will, verwendete nur den invarianten restlichen ISO-646 Umfang, ohne diese 12.
Nebenbei: Dies wurde analog selbst für nicht-lateinische Zeichen benutzt, die in ISO-646 ohnehin fakultativen Kleinbuchstaben ersetzend, für ebenfalls nur Grossbuschstaben, von Griechisch und Kyrillisch (mit bei letzterem wegen mehr als 26 Zeichen auch die ` und { | } ~ ersetzend) und Hebräisch. Wer selbst bei Kommunikation mit diesen Ländern sicher lesbar sein will, verwendete nur Grossschrift. (Dies war eine Anwendung der ShiftLock bzw CapsLock Taste, damals noch die echte welche alles zu Gross machte, auch wenn mit Shift zusammen, nicht dann zu Klein machte.)
Logisch war auch alles 8bit mit anfangs jeder Hersteller seine eigene Codierung erfinden, alle inkompatibel versteht sich. Text von einem Rechner erschien auf anderen mit allem 7bit ASCII richtig, aber 8bit Umlaute (und Symbole und Liniengraphik und Blockgraphik) wurden durch irgendetwas ersetzt, was der zweite Rechner gerade auf deren Nummern setzte. Dieser Effekt wurde als Zeichensalat bekannt. Benutzer wollten daher wieder einen Standard, also wurde ISO-8859 geschaffen. Dabei sind ASCII ihre 128 Zeichen stets voll vorhanden, inklusive allen 94 graphischen/druckbaren, aber es kommen nun 128 weitere nach ISO-8859 hinzu, inklusive 96 mehr graphische/druckbare.
Nebenbei: Dabei sind 128..159 weitere Steuerzeichen, 160..255 sind weitere graphische/druckbare, davon 160 zumeist als Leerzeichen dargestelt aber von Trennprogrammen nicht als solches erkannt und getrennt, was es zu nichttrennbarem Teil eines Mehrfachwortes macht. Letztere analog zu ASCII in 160..191 weitere Satzzeichen bzw Zahlenartige und 192..243 akzentierte Grossbuchstaben und 244..255 akzentierte Kleinbuchstaben. Für letztere beiden Gruppen gilt bei lateinisch wieder eine NRCS-artige Logik, teils stets bleibend (darunter alle Umlaute), teils ersetzbar (für Osteuropa statt Westeuropa). Wer sicher lesbar sein will, verwendet wieder bei Kommunikation mit anderen Ländern nur den bei allen ISO-8859 Versionen invariant bleibenden Teil.
Nebenbei: Wer nicht weiss wozu Steuerzeichen sind. Diese kommen bei den alten ISO-646 ihren 1..31 vom Fernschreiber her, so Sachen wie Druckkopf bewegen, Tabulator, Papiervorschub, Farbband umschalten, Signalglocke pingen. Sowie bei den ISO-8859 ihren 128..159 von Terminals Bildsteuerung, so Sachen wie Cursor positionieren, Zeichen/Zeilen/Bild löschen bzw einfügen, Farben setzen, Font laden und schalten. (Was mit nur ISO-646 mit zwei Zeichen gemacht wurde, 27 gefolgt von 64..95, hier einfach nur das zweite als 128+(64..95)-64=128..159).
Nebenbei: Bei nicht-latein gilt Ersatz wie bei ISO-646, nun aber mit ASCII für volles lateinisch Gross+Klein, und ISO-8859 Gross+Klein akzentiert ersetzen für nicht-lateinisch Gross+Klein. Wer selbst dort sicher lesbar sein will, verwendet nur ASCII ohne Akzente. Selbst nicht ISO-646 kompatibles geht vergleichbar, Arabisch musste Gross+Klein ersetzen für genug Zeichen, hat die jetzt in ISO-8859. Japanisch (nur Katakana) hatte Gross+Ziffern+Satz ersetzt, mit jetzt analog zu ISO-8859 dessen Gross+Zahlenartige+Satz. (Wobei zumeist ohnehin der Benutzer die jeweilige Fremdsprache lesen ein weit grösseres Problem ist als Rechner deren Fremdzeichensatz anzeigen!)
Im Gegensatz zu ASCII, wo alle Mikrocomputer und Homecomputer und Personalcomputer erst nach dessen Einfühung entstanden, kam hier ISO-8859 nachdem diese schon eigene 8bit Zeichensätze hatten. Es verbreitete sich trotzdem zum Standard bei PCs. Weil Microsoft beim grossen Wechsel von DOS zu Windows den PC Standard IBM CP437 durch ein erweitertes ISO-8859 namens Windows-125x ersetzte (mit in 128..159 weitere graphische/druckbare Zeichen addiert). Dann kam Linux, welches als Unix Variante von nur-ASCII direkt zu ISO-8859 ging. Schliesslich MacOS X, welches als eingekaufte Unix Variante das selbige machte, dabei Apples MacOS vor-X benutztes eigenes Mac Roman ersetzend. Bei Mails sah man von 1995 bis 2005 wie der Zeichensalat nach und nach verschwand.
Wie wurde das angerichtet? Die Firma Xerox hatte in 1970(!) Angst vor dem papierlosen Büro und zusammenbrechendem Photokopierer Verkauf. Sie wollten daher in die alles ersetzende Computertechnik einsteigen. Dazu gründeten sie das Palo Alto Research Centre (PARC), eine Spielwiese für Computerwisssenschaftler, mit Auftrag heute den Computer der Zukunft zu bauen, der in 10 Jahren bezahlbar sein wird, um dann damit ihr Einkommen zu machen. Logisch war in dieser professionellen Spielumgebung Kompatibilität zu bestehenden Standards schlicht irrelevant, auch zu bestehenden Zeichensätzen. (Etwa 10 Jahre später gab Xerox eine Serie von Workstations heraus, als Dokumentsysteme bezeichnet, sauteuer, die sich deswegen nie gross verkauften, in der Rechnerhistorik eine Randnotiz sind.)
Dabei merkten die Xerox Leute, dass sie mit nur einem 8bit Zeichensatz nirgendswo hinkommen werden. Mehrere 8bit mit umschalten war ihnen aber "nicht Zukunft genug". Also haben sie einen universellen 16bit Zeichensatz entwickelt. So weit so gut, solange das nur ein interner Satz ihrer Dokumentsysteme blieb. Nur wollten sie dann etwas mit der Restwelt kommunizierbares, und spannten dazu mit Apple zusammen. Leider eine weitere Firma welche nicht gerade auf kompatibel zu bestehenden Standards sein achtet, wiederholt ihren Kunden einen Totalersatz beschert, sobald etwas noch geileres erfunden wird, was man ja als Ersatz verkaufen kann.
Daher haben die beiden "vergessen", dass die Restwelt nun mal seit Jahrzehnten in 8bit editiert und speichert und kommuniziert, mit dabei ISO-646 konforme Zahlenwerte als teils Steuercodes und teils Zeichen benutzen. Weshalb Dateiformate und Diskformate und Netzprotokolle oft 8bit sind, obigen Konventionen folgend, sowie verbreitete Programmiersprachen und Systemlibraries von 8bit Zeichen ausgehen, wieder diesen folgend. Die ganzen nicht-Apple Benutzer hatten auch keine Lust all ihre Rechner und Software und Daten zu ersetzen bzw umcodieren!
Ebenso "vergassen" sie, dass die Restwelt einzelne Bytes mit Wert 0 als Markierer einsetzt. 16bit Zahlen (und Zeichencodes) werden aber zu 2*8bit zerlegt, von denen bei allen Zahlen 0..255 das erste Byte 0 wird und bei allen 256..65535 welche durch 256 teilbar sind das zweite Byte! 16bit Zeichen führen damit bei Telekommunikation zu Datenfehlern oder gar Abstützen, wenn Software auf unerwartete 0-Bytes aufläuft. Vergleichbares wiederholt sich neben 0 Nichts/Platzhalter für alle Steuercodes 1..31 und Ausradiert/Gelöscht 127.)
Das wäre alles problemlos vermeidbar gewesen! Aber dazu hätten diese zwei USA Firmen, welche sich beide als "die Zukunft" und damit "besser als andere" anschauen, bei den anderen Leuten der Restwelt nachschauen gehen müssen, wie diese das handhaben. Von denen haben manche 1000e Jahre Vergangenheit an Erfahrung mit 10000en Zeichen an Schriften, und inzwischen auch Jahrzehnte davon diese in Rechnern zu benutzen. Also die Chinesen und Japaner, bzw ihre Schriften Hanzi und Kanji. Logisch waren diese auch in das 16bit werden zu 2*8bit Problem hineingelaufen, und hatten es bereits bestens kompatibel gelöst!
Das Ergebnis davon war der ISO-2022 Standard, der zu ISO-646 kompatibel ist. Dieser definiert Bytes als: 0..31 Steuerzeichen "C0", 32 Leerzeichen, 33..126 graphische/druckbare 94 "GR", 127 Gelöscht, 128..159 Steuerzeichen "C1", 160..255 graphische/druckbare 96 "GL" (mit allenfalls 160 und 255 von "C1" unbenutzt für nur 94 wie bei "C0*). (Wem dies alles bekannt vorkommt: ISO-8859 ist logischerweise zu ISO-2022 kompatibel, mit alle 96 "GL" nutzend. Erst das neuere Unicode ist inkompatibel mit allem.) Wie kommen nun die 10000e Zeichen in ISO-2022 hinein? Durch die 2 Bytes der 16bit als 94*94 Zonen*Punkte aufteilen, als Zonen 1..94 mit in jeder Punkte 1..94, was 94²=8836 Zeichen Platz gibt und DBCS (Double/Doppel Byte Character/Zeichen Set/Satz) heisst. (Will man noch mehr ist auch 24bit als 3 Byte definiert, was 94³=830584 Zeichen Platz gibt und TBCS (Tripple/Dreifach Byte Character/Zeichen Set/Satz) heisst.)
Leider haben Xerox und Apple all diese sinnvollen Erkenntnisse ignoriert, und einfach 16bit als Zeichen 0..65535 definiert, und losgelegt, mit alles in Blöcken von n*16 Bytes aufgeteilt, sehr oft als 8*16=128er Blöcke vergeben, damit zu den 94er Zonen komplett inkompatibel. Block 0..127 ist ASCII, Block 128..255 ist ISO-8859-1. Das wurde aber wegen den unvermeidlcihen 0-Bytes total inkompatibel zu allem anderen, schlechtes Design, hätte daran sterben sollen. Die Welt wäre ohne dies besser gewesen, mit Platz für einen zu ISO-646 und ISO-2022 kompatiblen Standard. Leider haben Apple und die inzwischen bei Unicode eingestiegene Microsoft (noch eine Firma ohne Respekt vor solider zuverlässiger Technologie) Unicode als Zukunft angeschaut und zur internen Basis von neueren MacOS X und Windows NT Versionen gemacht. Zumal sie ja die ganze neue alles ersetzende Software verkaufen werden!
Dazu wurde ein Flick produziert, namens UTF-8. Dieser belässt 0..127 als ASCII als 1 Byte, aber alles darüber wird in abgestufte 2 bis 6 Byte Sequenzen "verpackt". (Strikte reichen 6 Bytes für 31bit verpacken, altes 16bit Unicode (UCS-2) passt in max 3, heutiges erweitertes 21bit Unicode (UCS-4) in max 4.)
Nebenbei: Die Verwendung von UTF-8 erlaubte auch mehr als 16bit. Was die Unicode Leute wiederum ausnutzen, um den inzwischen bereits zu klein gewordenen 16bit Umfang zu erweitern! Logisch gab dies Ärger mit schon auf UTF-8-loses 16bit Unicode umgestellten Systemen. Also wurden diese mit einem weiteren Flick namens UTF-16 erweitert, welches ebenfalls mehr als 16bit erlaubt, aber in 16bit statt 8bit verpackt. Dieses limitiert seither auf (1+16)*65536=1'114'112 Zeichen, also 17/32 von obigen 21bit.
Zuerst das kleinste Problem: UTF-8 ist trotz als Flick erzeugt ebenfalls nicht zu ISO-2022 kompatibel! Es benutzt bei Zeichen oberhalb von 127 zwar 192..255 als erstes Byte (und zugleich Anzahl Bytes Angabe), aber alle weiteren Bytes sind im Bereich 128..191 statt nur 160..191 kodiert. Wodurch jedes System welches die "C1" Steuerzeichen benutzt zerdeppert wird. Dabei wäre selbiger Codiertrick mit weniger gierig 5 statt 6 Nutzbits in den Folgebytes setzen auch zu ISO-2022 kompatibel machbar gewesen, mit alle weiteren Bytes nur im Bereich 160..191 kodiert! UTF-8 macht ebenfalls nicht den Eindruck mit Sorgfalt designt worden zu sein, oder zumindest nicht mit Respekt für alles was historisch gewachsen ist, und daher bei Benutzern im Betrieb sein könnte. Dies trotz ein Flick für inkompatibel sein, der somit selber wieder inkompatibel ist. Wie passend zur Denkweise vom Resten von Unicode!
Dann ein grösseres Problem: Im Gegensatz zu allen DBCS Varianten von ISO-2022, welche prinzipiell nur mit 16bit fähiger Software laufen, wo nur Leute welche diese Varianten nutzen wollen solche Software haben müssen, welche auch richtig mit diesen umgeht, kann nun UTF-8 wegen variabler Anzahl 8bit Bytes auf den ersten Blick auch mit 8bit Software laufen. Dies aber nur solange man lediglich die 7bit Codes 0..127 benutzt! Weshalb Leute in den USA, welche keine Form von 8bit benutzt haben, ohne Unterschied zu sehen umstellen konnten (und dies wegen politisch Korrekt denken plus kostenlos auch machten). Erst der Rest der Welt bekam den neuen Zeichensalat zu sehen, sobald manche neue Software UTF-8 statt ISO-8859 benutzte. Willkommen zurück wieder in der Situation mit Zeichenssalat, wie vor ISO-8859 sich verbreiten!
Aber diesmal mit einem noch grösseren Problem: Die variable Anzahl Bytes als solches! Spätestens wenn Mails wegen auf einer Mailliste diskutieren durch verschiedenste Rechner gehen, mit verschiedener Software, teils UTF-8 kennend oder nicht, teils das Format erkennend oder nicht, teils Fehler reparieren versuchend oder nicht, dabei teils scheitern. Dabei geschieht schlimmeres: Zeichen mutieren. Dabei kann jedes 8bit Zeichen, egal ob als ISO-8859 oder UTF-8 angefangen, durch UTF-8 entpack oder verpack Routinen missverstanden werden. Dabei können Bytes fallen gelassen oder dupliziert oder auf zwei Zeichen aufgespalten werden oder zwei zu einem zusammengelegt. Das bei jeder Mailantwort wiederholt auftretend, mit je mutierter etwas schon ist, umso eher missverstanden und wahrscheinlicher weiter mutierend, zumeist zu immer längeren Müllbytesequenzen!
Als Beispiel: Zuerst war es nur ein ISO-8859 Umlaut, dann in ein UTF-8 Umlaut verwandelt, dann als 2 ISO-8859 Zeichen angeschaut/ausgegeben (oder gar eines plus ein "C1" Steuerzeichen), dann wurde eines gelöscht (vielleicht das "C1"), oder weiter verdoppelt, oder danach gelöscht, oder wegen ungütiger UTF-8 Kombination sogar zwei gelöscht, oder nur ein Teil gelöscht und danach der Resten gemergt, oder diese wegen ungütig gelöscht, oder gar diese durch spezielle "unbekanntes Zeichen" Bytesequenzen ersetzt, oder was auch immer gerade die aktuelle Form der Byteserie in Kombination mit dem lokalen Rechner seiner Software macht. Das ergibt weit intensiveren Zeichensalat als je zuvor, von Rechner zu Rechner mutierende Mails, wie mit Krebsbefall! Dies besonders schlimm, wenn jede einzelne Mailzeile anderst kodiert sein kann, je nach wie viele Generationen von älterem (und allenfalls teilweise konvertiertem) Material sie enthalten, wieder immer längere Bytesequenzen als Tumore. (Man beachte: Traditioneller Zeichensalat war stets konsistent 1 Byte pro Zeichen, nur falsch dargestellt, aber immer unverändert durchgereicht, und damit auf Rechnern mit gleichem Zeichensatz wieder richtig dargetellt, sowie auf allen anderen konsistent identisch falsch.)
Nebenbei: Diese mutierte Form von Zeichen wird inzwischen Mojibake genannt, japanisch für Zeichentransformation, weil die Japaner dieses Problem schon vor UTF-8 abbekommen hatten. Dies wegen mehreren Zeichensätzen benutzen, zuerst ein ISO-8859 artiges 8bit (mit nur Romaji/Latein+Katakana) namens JIS-0201, dann ein ISO-2022-basiertes DBCS 16bit (mit alle Katakana+Hiragana+Kanji+Romaji/Latein) namens JIS-0208, und dann ein aus beiden gemischtes namens Shift-JIS. Letzteres ist aber ein Gemisch von 8bit und 16bit, und daher muss die Software von Zeichen zu Zeichen dessen Sorte/Länge erkennen. Bereits durch ein einzelnes gekipptes Bit kann die Synchronisation von diesem Aufspalter ausreissen, gefolgt von nicht nur das Zeichen missverstanden werden, sondern wegen Sorte/Länge mischen auch das nächste Zeichen und so weiter, bis zufällig eine entstehende Serie von Fehlern wieder auf synchron aufaddiert!
Aber es hat ein nochmals grösseres Problem: Solche Mutanten als neue Bugkategorie bringen mit sich sogar eine neuen Kategorie von Sicherheitslöchern! Jegliche Software welche Tests auf gefährliche Zeichen in Texten macht, wie um JavaScript in Kommentaren zu eliminieren gegen Cross Site Scripting, kann unterlaufen werden durch die variable Anzahl Bytes ausnutzen. Ein Test auf nur die offiziell zu erzeugende minimal lange verpackte Form eines Gefahrenzeichens versagt dabei in andere absichtliche überlange Kombinationen zu erkennen, welche nach entpacken aber zu selbiger Gefahr der Sabotage werden! Dumm wenn die testende Software nur in 8bit arbeitet, statt eine komplette UTF-8 zu UCS-4 Umwandlung machen. Dumm wenn sie das macht und dabei an ISO-8859 scheitert.
Nebenbei: In der Rechnersicherheit gibt es ein zentrales Prinzip, dass jeder Missbrauch auf ausnutzen von ungewollten Seiteneffekten basiert, und daher die Chancen von solchen minimiert werden sollte. Die Mathematik besagt, dass bei n Elementen mit n*(n-1)/2 Interaktionen zu rechnen ist. Jeder Angreiffer wird versuchen, in diesen einen ausnutzbaren Seiteneffekt zu finden. Daher ist die Menge n reduzieren wichtig. UTF-8 tut nun genau das n Elemente erhöhen. (All dies ist wiederum nur ein Sonderfall von der uralten generellen Ingenieursregel von "Behalte es simpel, Dummkopf", weil nur einfache zu fehlerfreier und somit robuster und davon zuverlässiger Technologie führen kann.)
Die offizielle Antwort besteht inzwischen darin, einfach alle überlange Kombinationen zu illegale Sequenzen zu erklären und zu verwerfen statt zu konvertieren. Real werden sie je nach Software und Version davon verworfen, oder durch "unbekanntes Zeichen" Bytesequenz ersetzt, oder gar alle möglichen 128..255 Bytewerte durch 128 verschiedene "ungültiges Zeichen" Bytesequenzen. Was aber alles noch mehr Mojibake ergibt, erst recht wenn ein Rechner diese Konvertiten nicht darstellen kann. Dumm wenn ISO-8859 dabei für UTF-8 gehalten wird, aber mit ungültigen fehlenden Folgebytes, dann von dieser "Sicherung" ungültiger Bytes her in Mojibake verwandelt werden. Sehr dumm wenn UTF-8 für ISO-8859 gehalten wird, die zwei Zeichen dann doch durchkommen. (Dies erst recht wenn jemand auf einem UCS-2 System volle UCS-4 Zeichen als UTF-16 codiert, und ohne sie zu entpacken direkt zu UTF-8 macht. Strikte illegal, aber immerhin genug verbreitet, dass dies sogar einen Namen hat, CESU-8.)
Bonuspunkte, dass der Unicode Standard inzwischen offiziell erkennen von Bytesequenz = UTF-8 aber Einzelbyte = ISO-8859 verbietet, nur separat mitgelieferte Metadaten zum Dateityp auswerten erlaubt. Was aber scheitert, weil komplett legitime alte Software aber keine Metadaten liefert, und weil sie alles durchreicht ohne weiteres zeilenweise zwischen ISO-8859 oder UTF-8 wechselnde Textdaten erzeugen kann. Also ist mit obigem Standard nun vorgeschrieben Mojibake zu erzeugen! Noch schlimmer kann in der Einführungsphase von UTF-8 manche Software versuchen Metadaten zu erzeugen, aber diese in Kombination mit Bugs in der komplexen Umwandlung. Und manche Benutzer meiden inzwischen Updates, wenn diese zu moderne Benutzerinterfaces haben, was genau um die Zeit herum ausartete.
Dann kommt die grosse Menge an Zeichen, welche bestehende Fontformate unzureichend machte, und neben neuen Formaten auch nach neuer Software verlangt, welche diese versteht, und sie von den alten unterscheiden kann. Praktisch alle Software muss für Unicode benutzen ersetzt werden! Willkommen bei Updates und wegen komplex immer mehr Librarybloat und Bugs. (Letztere inklusive UTF-8 entpacken Sicherheitslöchern. Bonuspunkte, wenn erst diese Updates neu alle ilegale UTF-8 verwerfen, und dabei noch mehr Mojibake erzeugen!)
Die grosse Menge an Zeichen macht aber auch einen einzelnen Font mit allen Zeichen darin unpraktisch. Das erst recht wenn man graphisch verschiedene Fontsorten haben will, weil je nach Schriftsystem man andere Darstellung will. Also müssen die Zeichen aus mehreren Teilfonts geholt werden, was nach neuer Software verlangt, welche Zeichen aus Fonts zusammensuchen kann, mitsammt Prioritäten welcher Font in welcher Reihenfolge dran kommt! (All dies auswerten trifft zudem nicht nur reine Textdateien, inklusive Webpages und Mails, sondern auch alle anderen Dateien welche Textschnipsel beinhalten können, sei dies EDIF Metadaten in Photos, Titelnamen in Musik, Untertitel in Filmen, selbst Benutzerinterface Definitionen von Software.)
Weiter geht es mit Texten in Schriftsystemen welche von rechts nach links geschriebenen Zeichen haben. Bisher waren diese Sprachen und ihre Fonts ein separater Markt für Software mit diesem Feature. Mit Unicode kann nun jeder Text solche beinhalten. Also muss jedes System diese rendern können, als Bidirektional, weil jeder Browser oder gar (Mail-)Leser/Editor jetzt mit solchen Daten rechnen muss. Das verlangt nicht nur neue Software, sondern auch weit komplexere. Willkommen bei weniger Softwareauswahl und noch mehr Updates und Librarybloat und Bugs. (Hier wegen immer mehr Formen von Schriften ihre Anforderungen auch noch addieren.)
Nebenbei: Inzwischen wurde dies nochmals schlimmer: Japan weigerte sich Unicode bei Email zu übernehmen (was bei ihnen anstelle von SMS benutzt wird), weil manche dort sich Emoji benutzen angewöhnt haben, weit mehr als nur die westlichen ASCII-basierten Smileys, und diese mit Unicode nicht mehr liefen! Nun aber mit 21bit über eine Million Zeichen erlaubend wurden diese addiert. Damit wurde aber ein Fass ohne Boden aufgemacht. Plötzlich will jede Interessengruppe auch ihre Emojis drin haben. Je mehr zugelassen werden umso noch mehr, denn die anderen haben ja auch ihre. Inzwischen läuft dies darauf hinaus, als Teil vom Zeichensatz definieren eine ganze neue Symbolsprache analog zu den Hieroglyphen zu entwicklen! Und Fonts mit all diesen generieren, willkommen bei Bloatfonts. Und diese wachsenden Fonts alle dauernd Updaten, sonst versagt Texte mit neueren Emojis lesen. Es soll inzwischen sogar Leute geben, welche nur wegen neueren Emoji bekommen ganze Systemupdates machen. Oder gar wegen solcher ältere aber ansonsten einwandfrei funktionierende Geräte ersetzen! (Bitte ignoriert den einstigen Fortschritt, Worte in einen kleinen Satz an Buchstaben zu zerlegen, welche man selber zu beliebigen neuen Worten anordnen kann, ohne alle neuen Kombinationen konsumieren zu müssen, ohne Bloatfonts, ohne Updates. Bitte ignoriert auch die Umwelt, egal ob steigenden Rohstoffverbrauch oder immer mehr Elektroschrott, diese ist ja zum aufbrauchen da. Egal was, neue Emojis sind wichtiger.)
Nebenbei: Ach ja, manche Emoji haben Gesichter drin, nicht nur abstrahierte Smiley Linien, sondern comic-artige. Schon gibt es Beschwerden von Politidioten, dass diese wegen üblicherweise Textfarbe Linien (oft schwarz) auf Hintergrund (oft weiss) rassistisch seien! Einfach Textfarben reversieren war den Featurefreaks zuwenig, oder einfach einen alternativen Emoji Font mit reverser Graphik nutzen. Also "braucht" es diese Emoji in allen Hautfarben. Das wird aber selbst die 21bit Zeichennummern aufbrauchen, also gibt es neu Zeichen und separaten Farbmodifikator. Fonts brauchen dazu jetzt mehrere Versionen des selbigen Zeichens, je nach welcher Modifikator aktiv ist. Was nach nochmals neuen Fontformaten verlangt. Software muss diese unterschieden, noch mehr Bloat und Bugs! Aber wart mal, bisher waren Fonts farblos, der sie nutzende Text gab vor welche Farbe zu nehmen, die Font Software hat nur dessen Anordnung benutzt. Jetzt haben Fonts selber Farbwünsche drin. Software muss diese jetzt gegen die Textfarben abwägen. Noch mehr Bloat und Bugs. All dies verbraucht zudem mehr Prozessor, bremst ansonsten einwandfrei funktionierende Geräte weiter aus, also ebenfalls ersetzen. (Da verbleibt nur noch ein Hinweis zu "Wehret den Anfängen"!)
Leute welche inzwischen UCS-2/UTF-16 oder UTF-8 Daten erzeugt haben wollen diese aber ebenso lesen, also ist kein Unicode abschaffen machbar, kein zurück zur robusten Einfachheit. Nur schon UCS-2/UTF-16 loswerden geht nicht, wegen darin gespeicherten Daten. Auch UTF-8 loswerden und nur UCS-2 geht auch nicht, wegen gespeicherten Daten, und UCS-2 mit 8bit inkompatibel sein. Unicode nachträglich zu ISO-2022 kompatibel machen bringt auch nichts mehr, weil das zu UCS-2/UTF-16 und UTF-8 inkompatibel wäre, nur ein vierter neuer Fall!
Also gibt es kein Zurück oder Vorwärts, nur am Ort bleiben, wo nun alle bunt gemischt bestand haben werden müssen. Damit gibt es keine Welt ohne Mojibake mehr. Die Situation ist somit inzwischen unrettbar zerfahren, jeglicher Standard vernichtet auf immer, unreparierbarer Schaden. Nur dass Computer auf inkompatibel weit schlimmer reagieren als Leser auf bei 8bit felsch dargestellt, bei UCS-2/UTF-16 auf 8bit bis zu Absturz, sowie bei UTF-8 mit Umlaute zu Mojibake verschrotten. Also wurde die Welt in die Ecke gepinselt, kein Ausweg existiert mehr, weiterer Schritt in den zu erwartenden technologischen Absturz durch Richtung unendlich aufsammelnde Komplexität und Fehlfunktionen.
Dagegen kann nur bewusste Einfachheit wirken. Genau daher gilt bei mir konsequent nur noch fast überall lesbares 7bit ASCII erzeugen, keine 8bit jeglicher Art mehr! Im Web ergibt dies, inklusive diesem Text, nur ASCII mit Umlaute als HTML Entities. In Mail und Notizen nur reines ASCII, auch wenn Leute sich über umlautlose ae oe und ue in Mails beschweren (aber schnell Ruhe geben wenn ich HTML Entities versenden als standardkonforme aber potthässliche Alternative "anbiete"). (Was alles wieder mal einen Fall ergibt von statt Illusion von mehr Features (16/32bit) real weniger Funktion bekommen (wieder nur noch 7bit statt 8bit)!)
Lokal kann man gerade noch Emoji Bloatfonts weglassen, aber die komplexen Librarygebirge werden bleiben, mit all ihrem Prozessorverbrauch und Bugs. Jeder Update wird mehr davon bringen, weil die Libraryschreiber jeden neuen Unsinn auch mit abdecken wollen, so die immer schiefere Ebene hinabrutschend bis sie unten aufschlagen.
Das beste was man daher noch machen kann, ist diesen Bloat auf den Browser zu limitieren. Oder sogar bei alten Browsern bleiben, welche den Librarybloat noch nicht derart maximal hinter sich herziehen. Bei vielem anderen kann man reine ASCII Programme verwenden, inklusive für Mail. (Womit man sich auch noch gleich alle Viren fernhält.) Selbst wenn mehr gewollt ist, sollte man abstufend die geringstaufwendige noch ausreichende Variante nutzen, ASCII falls es geht, sonst lokal passendes ISO-8859, und nur wo das nicht mehr ausreicht Unicode und UTF-8. Sicher nicht letzteres als Standard.
Aber die Auswahl an solcher simplen Software verschwindet immer mehr, weil "nicht modern". Und selbst die vorhandene nutzen wird immer inkompatibler mit Leuten, welche der Bloatware gefolgt sind, und diese bei allen anderen gedankenlos voraussetzen. Solche beschweren sich auch noch, wenn alte Mailer mangels neuer Metadaten ihre UTF-8 Kaputtheit aufzeigen, nachdem ihre neuen Mailer allen erzeugten Schrott vor sie versteckt haben. Oder Websites schliessen alte Browser aus durch inkompatibel werden, egal ob mit JavaScript Zwang oder HTTPS Zwang.
Diese Seite ist von Neil Franklin, letzte Änderung 2025.04.02