Das Video kommt von YouTube: erst beim Abspielen verbindet sich die Seite mit YouTube (Google).

2025 - Unicode für Anfänger

Name: 2025 - Unicode für Anfänger
Uploaded: 2025-08-16T19:16:35+00:00
Duration: 56 min 55 s
Channel: Free and Open Source Software Conference (FrOSCon) e.V.
Description: Computer verarbeiten Zahlen, Menschen Zeichen; deshalb braucht Text Zeichencodierungen. Der Baudot-Code nutzte fünf Bit und Umschaltzeichen, um …

Free and Open Source Software Conference (FrOSCon) e.V.56:55 75 Aufrufe veröffentlicht 16. Aug. 2025 Auf YouTube

Das Wichtigste aus dem Video

Tipp auf eine Zeit – das Video springt genau dorthin.

Transkriptautomatisch erstellt · 372 Zeilen

Herunterladen

Hallo, vielen Dank. Schön, dass ihr es so zahlreich geschafft hat. Ich habe irgendwie den Slot hier draußen riecht man schon das Angrillen. Nebenanläuft
State of the Union. Deswegen ist das hier mal State of the Unicode. Ähm eigentlich angekündigt als Unicode für Anfänger, aber ähm die Folie habe ich
dann eben noch kurz eingebaut. So eine Stunde Vortrag führt für den es fühlt sich für die Zuschauer immer ein bisschen seltsam an. Das habe ich heute
ein paar mal erlebt, dass die Talks dann doch so 10 Minuten länger haben und ich dachte mir, das ist so ein kleines Thema, da bin ich in 20 Minuten fertig
und dann sind es doch Stoff für eine Stunde, die hoffentlich gefüllt ist. Ich hoffe, ich b ich hoffe, ich langweile euch nicht. Schön, dass ihr da seid.
Ähm, ich erzähle euch heute ein bisschen was über Zeichencodierungen, wie man das früher gemacht hat. Dann erzähle ich euch, wie dann erzähle ich euch, wie wie
man das heute macht und ähm dann erzähle ich euch, wie man es transportiert und dann haben wir ein bisschen Spaß miteinander, wie man sortiert,
vergleicht, normalisiert. Ähm und zum Schluss, wenn dann noch Zeit ist, erzähle ich euch, wie es zu diesem Vortrag gekommen ist. Ähm, früher hat
man immer gesagt, wenn du dir bei irgendeinem Thema nicht hundertprozentig sicher bist, schreibst im Internet, irgendeiner wird dich korrigieren. Ähm,
heute halte ich einen Vortrag und hoffe, dass mich irgendeiner korrigiert, wenn ich Unsinn erzähle. Ähm, ich bin Mark Haber, Diplominformatiker. Das Netz
kennt mich als Zschluss mit nur einem S. Ich wohne in St. Ilgen bei Heidelberg. Ich bin ein bisschen älter, verheiratet, vier Katzen. Ich arbeite als freier
IT-Berater. Ähm, mit Linux und Netzwerken bleib mir weg mit Microsoft und Apple. Ähm, ich bin Debian Developer seit 2001
und ich würde auch gerne mal wieder mit Debien arbeiten. Ich habe Kapazitäten frei. Also, wenn irgendjemand ähm denkt, ich könnte bei Ihnen was helfen, dann
mache ich das gerne. Computer verarbeiten Zahlen, Menschen verarbeiten Buchstaben. Das muss man irgendwie miteinander verheiraten,
ansonsten wird das langweilig. Deswegen müssen wir Dinge codieren. Und damit hat man schon 1901 angefangen. Da gab es diesen Bordo Mö Code, der für den Telex
benutzt wurde. Das war das damals übliche Speichermedium. Ähm und das Ding hat, wie man sieht,
eine Spur für den Takt und 5 Bit. 5 Bits sind 32 mögliche Codierungsmöglichkeiten. Wir haben 26 Buchstaben und 10 Zahlen.
Schon das passt nicht. Deswegen hat man damals einen Trick gemacht. Es gibt im Bodocode zwei verschiedene Leerzeichen, die nicht nur einen Leerschritt
auslösen, sondern auch eine Umschaltung vornehmen. Das war wirklich damals eine Umschaltung. hat sich also im Telex Gerät die ähm der Korb mit den Typen um
ein Stück nach oben verschoben. Daraufhin hat dann der untere hat hat dann die untere Hälfte von den von den Typenhebeln ans Farband gehauen und ähm
so konnte man dann zweichen abdrucken plus die beiden inklusive der beiden Leerzeichen, also eigentlich nur 62 Zeichen. Das hat zumindest für
Kleinbuchstaben und Ziffern und ein paar Sonderzeichen gereicht. Spulen wir mal 60 Jahre vor. Wir haben uns inzwischen zweimal weltweit die welt
weltweit die Köpfe eingeschlagen und dann kam 1963 der American Standard Code for Information Interchange. Das ist das, was wir noch als ASKI kennen. Ähm,
das Ding hat 7 Bit pro Zeichen, sind 128 Zeichen. Da haben wir Platz für Großbuchstaben, Kleinbuchstaben, Ziffern und ein paar Sonderzeichen und ein paar
Steuerzeichen, aber immer noch keinen Platz für internationale Umlaute. Deswegen heißt das American Standard Code for Information Interchange. Die
haben das einfach nicht. M im ASKIC Code waren dafür geschweifte Klammern in senkrechterstrich in Backslash eckige Klammern drin. Die haben die anderen
Länder dann durch ihre Sonderzeichen ähm durch durch ihre Sonderzeichen ersetzt relativ schnell, also auch noch 1963. Das Ganze wurde dann international
standardisiert als ISO 646 und dieser Ersatz von den Umlauten durch Klammern sehen wir heute noch. Ich habe das glaube ich letzte Woche mal gesehen in
dem Laden, wo in dem Kundendisplay ein Artikelname angezeigt wurde, der eigentlich ein Umlut hätte enthalten müssen.
Stattdessen stand da eine geschweifte Klammer auf. Ähm, wir haben 2025, wir haben das immer noch. Ähm, man hat dann 1987 angefangen
das achte Bit zu benutzen in einem Bite. Plötzlich hatte man 256 Möglichkeiten. Es hat aber immer noch nicht gereicht. Deswegen hat der ISO Standard 8859
verschiedene Unterstandards. Wir kennen den ISO 88591 für die westeuropäischen Sprachen, wo halt die gängigen Umlaute drin sind. Es gibt den 885915, da kam
dann 1999 das Eurozeichen dazu. Ähm, andere Sprachfamilien haben andere ISO 8859 Standards. Die 15 kommt nicht, die hat man nicht gewürfelt, sondern da sind
14 andere davor. Ähm und es gibt auch eine, wo so eine Strichgrafik, wo so einfache Strichgrafikzeichen drin sind. Ähm, wenn das nicht richtig ausgewählt
wurde, es hat man immer dran gesehen, dass so Tools wie Tri oder PS3 eben keine Linien gemalt haben, sondern Umlaute.
Ähm, dann muss ich noch ähm ein paar Exoten erwähnen, nämlich zum einen ähm zum
einen Epsidic IBMs Rache. Ähm, das findet man eigentlich nur noch in Großrechnern, ähm also außerhalb von Banken und Versicherungen nicht mehr.
Ähm, wenn man sich das Ding anguckt in so einer Tabelle, versteht man auch, wie die Codierung gemacht ist, aber es ist so absurd, dass
da da kann man nicht mal anständig vergleichen drin. Aber Codierungen, in denen man nicht vergleichen kann, die kriegen wir heute noch genug. Dann gab's
noch dieses Windows 1252 und die Code Pages 850 und 437, die in Windows, glaube ich, bis heute noch benutzt werden. Ähm und dann gibt es für
jenseits des eisernen Vorhangs, die konnten natürlich keinen amerikanischen Standard benutzen, damals gab es KI8 für kürillisch geschriebene Sprachen. Gibt's
heute noch, aber wir benutzen es glücklicherweise nicht mehr überall. 1991 kam dann Unicode. Ähm, das wurde von einer Nonprofice Organization in in
den USA entworfen, dem dem Unicode Konsortium. Die haben das Heere Ziel Text in allen digitalisierbaren Schriften zu unterstützen.
Ähm, inzwischen ist das bei Version 16 von 2024, das wird also immer mal wieder fortgeschrieben. Wir haben knapp über 150.000 Zeichen und 168 verschiedene
Schriften, die in Unicode abgebildet werden können. Ein Skript will ich jetzt mal als eine Schrift bezeichnen. Eigentlich ist es eine
Sammlung von Buchstaben und anderen Zeichen zur Repräsentation von Texten in einem oder mehreren Schreibsystemen. ähm
Beispiel die lateinische Schrift, die wir sie hier benutzen, aber auch arabische und asiatische Sprachen, die nicht in Buchstaben, sondern in Silben
oder in ganzen Wörten denken. Ähm, es gibt Formelzeichen, Emoticons, Grafikelemente. Was es noch nicht gibt, ist klingonisch.
Das ist in Arbeit, kommt vermutlich nach Unicode 17. Ähm, das Ganze wurde auch international standardisiert. Das ist die ISO 10646.
Wir erinnern uns, die 646 war der ASKI Code und jetzt sind wir bei 10646. Ähm, das ist natürlich nicht genau Unicode, sondern die Abweichungen sind da, aber
sie sind minimal. Ähm, Unicode können wir seit etwa der Jahrtausendwende ernsthaft benutzen. Es hat eine Weile gedauert.
Wir in der freien und Open Source Community haben, glaube ich, sogar damit angefangen. Ähm und inzwischen ist es so, dass diese ganzen Altcodierungen
eher so als Altlast gelten, was natürlich nicht heißt, dass die einem immer noch über den Weg laufen, wie z.B. mein Erlebnis letzte Woche im
Supermarkt. Ähm ein Unicode Zeichen hat natürlich sein Aussehen, aber es hat auch Eigenschaften. Es kann Uppercase sein,
ein Großbuchstabe, es kann Lower Case sein, ein Kleinbuchstabe, wenn das verwendete Skript davon überhaupt eine Idee hat. Es gibt ja Sprachen, in denen
gibt's das gar nicht. Es kann eine Zahl sein, es kann ein Steuerzeichen sein, es kann ein Sonderzeichen sein und es gibt auch Operationen. Ich kann z.B. einen
kleinen Buchstaben in einen Großbuchstaben umwandeln oder andersrum. Ich kann vergleichen A kleiner B, ich kann sortieren.
Mark kommt vor Reiner. Ähm, aber ich kann die Dinge auch verwechseln. Es gibt die sogesannten
Confusibles, die haben sogar ihren Weg in einen RFC gefunden. Es gibt die 1, das kleine L, das große I. Das muss man voneinander unterscheiden können. Es
gibt die Null, es gibt das große O. Das muss man auch voneinander unterscheiden können und das ist sicherheitsrelevant, weil es gibt schon, weil es gibt ja
durchaus ähm E-Mails, die einen auf microsoft.com locken sollen und wenn man genauer hinguckt, ist das nicht Microsoft, sondern Micrull Soft.
Ähm und dann gibt es die gesamten die sogenannten Homoglyphen. Sind die Zeichen, die gleich aussehen, aber eine
unterschiedliche Bedeutung haben. Das A gibt es im Lateinischen, im kyrillischen. Im Griechischen gibt es ein Alpha, das groß geschrieben
praktischerweise genauso aussieht wie wie unser lateinisches A. Römische Zahlen sehen aus wie MCI
X. Und ähm dann gibt es noch so nette Dinge wie das nordische O, das auf der einen Seite ein Buchstabe ist und auf der
anderen Seite die Einheit, eine Längeneinheit und zwar eine ziemlich kurze. Es gibt Zeichen, die zusammengesetzt
sind. Damit hat man aber erst relativ spät angefangen, obwohl die Schreibmaschine das ganz genauso macht. Das E mit
Aconenton gibt es in Unicode als einen eigenen Codeepoint, aber man kann es auch aus dem E und aus dem Acon kombinieren. Und damit es noch nicht
richtig gemein genug ist, ist die Reihenfolge egal. In oste in in manchen osteuropäischen Sprachen ist es noch viel schlimmer. Da
gibt es z.B. das Touch, das ungarische Feuer, das hat zwei Akzente auf dem U. Das kann man in Unicode als U mit einem Akzent und noch einem Akzent darstellen.
Ähm, es gibt Modifikationen, die wirksam sind, die also wirklich den Buchstaben anders machen und es gibt welche, die nicht wirksam sind. Und das ist auch
noch netterweise auch noch in jeder Sprache anders. Es gibt also Buchstaben, die unterschiedlich aussehen, die gleiche Bedeutung haben und in der
anderen Sprache unterschiedlich aussehen und nicht die gleiche Bedeutung haben. Es gibt Whitespace in verschiedenen Breiten bis hin zu einem Whitespace mit
Breite Null und es gibt Richtungswechsel, weil es gibt ja auch Sprachen, die von die die von rechts nach links geschrieben werden. Das muss
man alles berücksichtigen. Dann gibt es unterschiedliche Ansichten über Zeichen. Es gibt Schriften, die Buchstaben haben. Es gibt Schriften, die
ganze Silben beschreiben und es gibt Schriften, die ganze Worte beschreiben pro Zeichen. Ähm, unvollständige Fonds sind alltäglich, weil wir haben über
150.000 Zeichen. Welcher Fond enthält alle 150.000 Zeichen? Ähm, gerade so, wenn man ein bisschen grafisch anspruchsvoller unterwegs ist und so
hübsche Fonts benutzen möchte, dann findet man teilweise Fonds, in denen nicht mal Umlauter enthalten sind. Ähm,
aber das was man so von Microsoft und Google aus dem Webterladen kann für seine Webseiten ist eigentlich relativ gut. Aber
natürlich sind auch da nicht alle 150.000 Zeichen drin, die wir die wir im Unicode definiert haben. So, wie wird das geschrieben?
Ähm, ein Zeichen, das nennt sich Codepoint in Unicode, wird als U+ und eine Hexziffer geschrieben. Und wir codieren in
wir codieren aktuell von U + 4 x 0 bis U + 10 FFF. Wer da ein bisschen genauer hinguckt, kann sehen, dass Unicode ursprünglich
mit vier Ziffern spezifiziert war, also mit 16 Bit. Das hat nicht gereicht. Also hat man es einfach hat man es einfach vergrößert. Ähm
inzwischen sind wir bei etwas über 1 000 Code Points in Unicode. Stimmt das? Ja, das muss stimmen. Ähm oder mir ist eine eins zu viel
reingerutscht. Ähm und da wir nicht immer die Codepoints ausschreiben wollen, gibt es eine Art der Codierung. Das nennt sich
Transportcodierung. Ähm und ich habe damals in der Uni gelernt, dass man ähm einen Transport sowohl von A nach B über das Netz
definieren kann, als auch den Transport über die Zeit. Weil wenn ich etwas in wenn ich etwas in eine Datei reinschreibe und das in zwei Tagen
wieder auslese, kommuniziere ich mit mir selbst. Das ist auch ein Transport. Deswegen ist der Begriff Transportcodierung an der Stelle
richtig. Das ist das Unicode Transformation Format UTF. Davon gibt es ein paar Varianten. Die wichtigsten möchte ich euch jetzt vorstellen. Die
allerwichtigste ist natürlich UTF8. Das ist das, was wir benutzen. Das ist dominant für alle Sprachen und Länder. Alle Sprachen, alle Standards benutzen
es. Es ist oft die einzige Codierung, die man benutzen darf. Es wird eigentlich von allen modernen Systemen unterstützt.
Ähm, es gibt einen Standard dazu, den RFC 3629. Der ist also auch schon einige Zeit alt. Ähm, und was an UTF8 ganz besonders sexy ist, es ist rückwärts
kompatibel zu 7 Bit ASKI. Die ersten 128 Zeichen sind identisch. Sie werden in UTF8 codiert mit einem einzigen Bitprzeichen
und das ist die gleiche binäre Repräsentation. Das heißt, wenn ich einen Text habe, der nur amerikanische Zeichen enthält, dann ist der in UTF8
identisch zu dem Text in ASKI und das ist unser Glück. Ansonsten hätten wir noch viel mehr Spaß. Was äh nicht in den 7 Bit
ASKI Code reinpasst, wird länger codiert. Da brauchen wir dann zwei, drei oder vier Bitte pro Zeichen. Je höher die Codebund die Codepunktnummer,
desto länger ist die Codierung. Und hier sieht man auch gleich den ersten Spaß, weil die, weil das ISO 8859 mit dem ersten gesetzten Bit, das ist
nicht identisch mit Unicode. Und wir werden heute noch ein paar Fehler sehen, wo genau das passiert, wo man einen 8 Bit ASKI oder ISO 8859 als Unicode sich
anguckt. Aber ich erzähle euch erstmal, wie UTF8 funktioniert. Die ja, den Zeiger sieht man sehr schön. Ähm
und die ersten 7 Bit, also Codepoint 0 bis 7F sind identisch. Da hat man eine Null vorne dran im in dem einzigen Bitte, dann die 3 Bit, die von dem
ersten Nibel übrig bleiben und die vier Bit, die vom zweiten Nibel übrig bleiben. Von 80 bis 7 FF sieht das ganz ähnlich aus. Hier hat man aber das
erste die erste Hexziffer, die zweite Hexziffer ist schon verteilt auf die zwei Bites und die dritte Hexziffer ist
zum Schluss. Das geht dann weiter für die Codepoints von 800 bis FFF, die in 3 Bytes codiert werden und die ganz oben liegenden werden in 4 Bytes codiert. Ähm
hier unten ist noch ein Beispiel, wie z.B. das W codiert wird. Ein Zeichen, das aussieht wie ein B. Aber kein B ist, sonst wäre es ja weiter
vorne. Ähm, ein japanisches Zeichen und was ist das vierte? Ein sehr weit oben liegender Codepoint, wo dann wirklich vier UTF8 codierte
Bites rauskommen. UTF8 ist für westliche Sprachen Speicherplatze effizient, weil die meisten unserer Zeichen, die
wir benutzen, in einem Bitte dargestellt werden können. Nur was nicht in den ASKCode reinpasst, braucht mehr als ein Bitte. Die Sonderzeichen, die wir
verwenden in unseren westlichen Sprachen, die kommen eigentlich alle mit zweibit aus. Ähm und gebissen sind natürlich mal wieder
die arabischen und asiatischen Sprachen, die mit drei oder die mit drei und vier bitcodierten Zeichen arbeiten müssen. Das ist aber immer noch besser als für
jedes Zeichen vier Zeich beit zu verbraten. UTF8 ist Längenvariabel. Das heißt, wenn ich das, wenn ich ein bestimmtes Zeichen
aus einem String rausziehen möchte, dann muss ich trotzdem vom Anfang an den String den den String lesen. Ich kann also nichts rechnen, wenn ich sage, ich
möchte jetzt das fünfte Zeichen von diesem String. Es könnte ja ein Zeichen vorne dran sein, das länger codiert ist und ich weiß auch nicht, wie ich muss
also immer von vorne anfangen. Ähm und dazu kommen wir später noch. Das Bite Order Mark in einem UTF8 Text ist optional.
Und damit wir richtig Spaß dabei haben, nicht alle Bitsequenzen sind valides UTF8. Ähm und dieses Verhalten hier kommt
allerdings auch vor, wenn der Fond in den das in den der Text dargestellt wird unvollständig ist.
Der nächste Spaß, der uns mit UTF8 auf auftreten kann, ist das sogenannte Moji Bake. Das kommt eigentlich aus dem Japanischen. Das kann man aber auch mit
einer Das kann man aber auch mit einem westeuropäischen Text ähm haben. Wer von euch liest das flüssig und weiß genau, was das eigentlich hätte
heißen sollen? Da hätte ich jetzt eigentlich mehr als zwei Hände. Gut, da kommen jetzt ein paar mehr.
Das kennen wir schon. Dieses Problem entsteht, wenn ich einen UTF8 codierten Text noch mal durch den UTF8 Encoder durchschiebe.
Eine Anwendung, die Unicode und insbesondere UTF8 Texte verarbeitet, muss ich immer im klaren sein, wie ein String, den ich gerade
handhabe, codiert ist. Ähm eigentlich ist man gut beraten, alles was reinkommt direkt mal nach UTF8 oder nach einem anderen UTF Format zu konvertieren und
dann muss man sich innerhalb seines kurz keinen Gedanken mehr machen, wie der drin gerade codiert ist. Wenn man das nicht weiß und man sicherheitshalber
noch mal codiert, dann kommt das raus, was wir eben gesehen haben. Ähm, weil sich bereits UTF8 Codes Drinks noch einmal UTF8 codieren lassen. Das Üttin 1
hat den hat die Darstellung Hex FC. In UTF8 wäre das C3BC. Das ist das A mit der mit der Tilde oben drüber und das ein und die ein Ligatur.
Wenn ich das als UTF8 decodiere, das C3BC, dann kriege ich wieder das Ü raus. Wenn ich es noch mal UTF8 codiere, nehme ich
das C3, was das A mit der Tilde ist, erzeuge daraus Unicode C383 und dann nehme ich mir die ein Ligatur BC inletin 1 umcodiert den Unicode ist
C2 BC. Da kommt dann da kommt dann in Mojibake eben diese 4B Codierung raus und am Ende sieht das so aus, wie es unten dargestellt wird. Manche Leute
nennen das Double UTF8, was man dann im Deutschen als WTF8 bezeichnen könnte, aber den Witz kann man eigentlich nicht
machen, weil WTF8 gibt es. Ähm, man kann durch diese Umformungsregeln,
die ich euch eben gezeigt habe, einen UTF8 Text Standardkonform codieren, der aber länger ist als die eigentliche Standardcodierung.
Ähm, dummerweise können die meisten Libraries mit diesen Encodings umgehen, aber auf diese Weise kann man die kann man die Software angreifen. Man kann
also einen String generieren, der genauso aussieht und der sich auch auf die gleichen Zeichen dekodieren lässt, der aber bei naivem Vergleich ungleich
ist und das möchte man eigentlich nicht. Also eigentlich möchte man in einer Software, wenn man einen String aus einer nicht vertrauenswürdigen Quelle
einliest, gucken, ob das UTF8 nicht nur von der verwendeten Library ordentlich decodiert werden kann, ob er das auch keine Overlong Encodings drin sind, weil
ansonsten kommt, weil ansonsten passiert das da. Dann wird mal gekratzt. Die zweithäufigste
Codierung, die man sieht, ist UTF 32. Die nennt sich auch UCS4. Die hat vier Bitte pro Zeichen und zwar immer. Das ist die einzige UTF Codierung mit fixer
Länge pro Zeichen. Es hat den Vorteil, wenn ich den wenn ich das fünfte Zeichen haben möchte, rechne ich 4 x 5, bekomme 20 raus, greift beim Index 20 in meinen
Ray rein und habe das fünfte Zeichen. Ähm, die Repräsentation ist die ist identisch mit der Codeepointummer. Das heißt, ich muss da auch nichts
umrechnen. Das ist nicht Speicherplatzeffizient und damit es zu wenig ähm und damit wir auch damit Spaß haben, gibt es das als Big Indian und
Little Indian. Und die Kennzeichnung mit Bitte Ordermk ist möglich, aber optional und wird deswegen selten verwendet. Auch hier muss man sich wissen, was man
da speichert, übers Netz schickt. Und es kann durchaus sein, dass wenn man das, wenn ein Big Indian und ein Little Indian System über das Netz miteinander
reden, dass die beide von UTF32 die unterschiedliche Meinung haben und und dann kommt am Ende nur Salat raus. Ähm UCF
im UTF 32 wird dort verwendet, wo es schnell sein muss und wenn man genug Speicher hat. Ähm neueres Python z.B. benutzt UTF32, sobald es in einem String
den ersten nicht 7 Bit 18 ähm den ersten nicht 7 Bit ASKY Character sieht. Das kriegt man aber nicht mit. Das muss man sich nicht mitschreiben.
Das macht der Python, das macht der Python Interpreter für euch. Ähm das finde ich sehr praktisch. Ähm, ich muss jetzt noch erwähnen, dass
es auch UTF16 gibt. Ähm, das war eine Codierung mit fester Länge bis zu dem Punkt, wo der erste Codepoint vergeben wurde, der eben nicht mehr in 16 Bit
reingepasst hat. Heute vereinigt das nur noch die Nachteile von UTF8 mit den Nachteilen von UTF32. Wir haben eine variable Länge. Wir sind nicht
Speicherplatzeffizient. Ähm, es hätte eigentlich das hätte eigentlich deated gehört, als man angefangen hat Zeichen jenseits der 16
Bitgrenze zu vergeben. Das wird dementsprechend selten benutzt. Man sollte es bitte nicht neu verwenden. Und Martin,
das ist auf der nächsten Folie. Das ist selten benutzt. Man sollte es bitte nicht neu verwenden, aber natürlich wird es doch benutzt. Ähm
Windows kennt das Konzept eines White Characters, das wird z.B. in Filnamen benutzt, JavaScript benutzt ist. Ähm und damit es nicht so ganz schwierig ist,
hat man dann um die Jahrtausendwende rum das Format WTF8 definiert. Ähm wo aber schon im Standard steht, dass das bitte nur intern zu verwenden ist. Und damit
und um klar zu machen, dass das wirklich so gemeint ist, das ist der Satz aus dem Standard must not be used. So klar ist ein Standard selten
in JavaScript z.B. in meistens so internen Repräsentationen. Das weißt du vermutlich mehr als ich, weil du mehr,
weil du mehr Entwickler bist als ich. Ich habe es in der Praxis noch nicht gesehen. Ich bin da auch nur bei der Vorbereitung dieses Vortrages drauf
gestoßen, weil ich den Witz mit dem WTF8 machen wollte und musste dann feststellen, schade, ich kann ihn nicht machen, weil es gibt's schon.
Ähm, ich habe eben schon das Bite Order Mark erkannt. Ähm, das funktioniert so, dass man seinen Unicode Dring mit einem nullbreiten
nichtbrechenden Leerzeichen beginnt. Das ist der Codepoint FEF. Und die ganzen UTF Codierungen, auch die, die ich jetzt
nicht erwähnt habe, sind so gebaut, dass man aus der Art, wie dieses FEFF codiert wird, ablesen kann, wie welche Codierung zur verwenden
verwendet ist und welche Variante davon, also insbesondere welche ist im im UTF 32. Und weil das so praktisch ist, wird es deswegen selten verwendet.
Es ist außer bei Bank recht gerne für Online Banding und ich hab schon gewundert FF dran stand.
Genau. Der fast normal der Zwischenwurf war der Zwischenwurf war das wird bei Banken gerne verwendet. Es es gibt Software es gibt Software,
die es benutzt. Ähm, aber es ist leider sehr, sehr selten. Es wäre sehr praktisch, es ist optional und ich wäre dafür, dass wir versuchen,
es mehr zu verwenden. Kommen wir jetzt zum Sortieren. Ein Sortieren, eine Sortierung bringt Elemente in eine bestimmte Ordnung.
Mathematisch gesagt ist das eine Halbordnung bezüglich der binären Relation kleiner oder gleich. Das ist schon innerhalb eines Skripts,
also innerhalb einer Schrift herausfordernd. Im Deutschen ist die Konvention, das genauso sortiert wird, als wäre es ein
A. Im Schwedischen steht das O hinter dem Z, die anderen Umlaute auch. Ähm und wenn ich verschiedene Sprachen
habe und die dann miteinander sortieren muss, dann geht der Spaß richtig los. Es ist jetzt ein griechisches Alpha, größer oder kleiner als ein lateinisches A. Was
ist mit dem kyrdischen A, das praktischerweise noch in groß und klein genauso aussieht wie das lateinische A? Wie behandel ich das, wenn ich Case
insensitiv sortieren möchte, weil das griechische Alpha klein geschrieben anders aussieht als unser A, das große aber nicht.
Und was ist mit Trans mit mit Transliterationen? Eine Transliteration ist der Versuch eine Schrift zu benutzen, ohne diese
Schrift zu haben. Das hast du insbesondere, wenn so griechische Namen übersetzt sind. Da hast du in dem griechischen Personalausweis einmal die
griechisch geschriebene Variante und dann die transliterierte Variante. Das gibt es auch in den Personaldokumenten von Ländern, die kürillische Buchstaben
benutzen. Ähm zum Sortieren muss ich vergleichen. Es gibt Zeichen, die gleich aussehen, aber unterschiedliche Bedeutungen haben.
Das habe ich vorhin schon mal erwähnt, das OR und die Längeneinheit, das Angströmen. Ähm, es gibt Zeichen, die gleich
aussehen, aber aus unterschiedlichen Skripts sind, z.B. das A im Lateinischen und das A im Kyrillischen. Die Franzosen schreiben bei ihren Großbuchstaben gerne
den Axon nicht drauf, aber der Buchstabe bleibt natürlich trotzdem akzentuiert, weil wenn du das in Lowcase umwandelst, möchtest du den Axon wieder darstellen.
Und alle diese Zeichen haben in Unicode unterschiedliche Code insbesondere gibt es oft Codepoints für Einheiten. Es gibt das Ongström, es gibt das Omen, was
dann aussieht wie das griechische Omega, aber aber ein anderes Zeichen ist. Da wird also in die Zeichencodierung schon Semantik hineingelegt. Das finde ich
hochpraktisch, aber man muss drauf achten. Ähm, wenn man nach etwas sucht, möchte man den Vergleich vielleicht ein
bisschen relaxen, weil wenn ich nach Angstström suche, wenn ich in mein Suchfeld ähm Angstström eingebe, möchte ich auch den ONGström oder eine
Zahl, eine Größe in der Einheit finden. Akzent.
Ja, komme ich später noch dazu. Ja. Ja, das ähm der Zwischenwurf war ähm, dass es auch den E mit Axon als eigenes Zeichen gibt und dass man es auch noch
kombinieren kann. Da habe ich noch drei Folien zu dem Thema, glaube ich, weil das ist nicht so ganz einfach. Ähm, wenn ich Usernamen vergleiche,
kann ja sein, dass mir irgendjemand irgendwas versucht unterzuschieben. Ich habe ich kann einen Klaus Onström haben und irgendeinen Angreifer, der mir den
Klaus Onström ein zweites Mal in meine Useratenbank geschrieben hat, diesmal mit dem Engströmzeichen im Nachnamen drin. Das sieht gleich aus. Ich möchte
das ganz sicher unterschiedlich unterschiedlich behandeln. Insbesondere möchte ich dem zweiten Klaus Angström keine Rechte geben, die der eine hätte.
Ähm, man muss sich also beim Vergleich wirklich an jeder Stelle, wo man einen vergleicht, wo man zwei Strings miteinander vergleicht, darüber im klar
sein, was will ich da überhaupt gerade machen, was ist mein Ziel an dieser Stelle? Ein Vergleich ist nicht gleich ein Vergleich.
Wer hatten noch nicht genug Spaß mit Unicode? In Unicode gibt es verschiedene Positionen eines Zeichens. Man kann sie drehen. Es gibt Zeichen im Kreis, es
gibt Zeichen im Quadrat, es gibt Zeichen mit unterschiedlicher Breite. Ich habe heute schon gehört, die Verwendung eines Mdhes ist ein Zeichen dafür, dass der
Text aus KI kommt, weil das kein Mensch so tippt. Ähm, wir haben Indizes, wir haben Potenzen, wir haben Brüche, wir haben Ligaturen und ich glaube, damit
habe ich noch nicht alle Eigenschaften, die ein Unicode Zeichen, wie ich ein Unicode Zeichen modifizieren kann, ähm aufgezählt. Ähm, es gibt einen sehr
schönen Wikipedia Artikel zum Thema Unicode Equivalence. Es gibt einen Standard zu dem Thema, das ist der Unicode Andex anx Nummer 15. Der
hat überschaubare 36 Seiten, den kann man also schon mal lesen. Ähm und der definiert, wie man Zeichen darstellt, wie man Zeichen codiert, wie
Zeichen äquivalent sind. Das hier sind jetzt nur ein paar Beispiele für die kanonische Äquivalenz. Ich kann die ich kann das C mit der CD kombinieren aus
einem CD oder ich kann gleich das den Codeepoint nehmen, der das C mit der CD darstellt. Ich kann mehrere Kombinationen darstellen. Ich kann das Q
mit einem Punkt oben und einem Punkt unten drunter kombinieren. Das ist äquivalent zu dem Punkt mit einem Punkt dem Q mit einem Punkt unten
drunter und einem Punkt oben drunter oben drüber. Man beachte die unterschiedliche Reihenfolge. Ähm in asiatischen Sprachen gibt es das sehr
häufig, dass so Zeichen kombiniert werden. Die gibt es dann in Unicode auch meistens in den beiden Kombinationen jeweils als eigenen Code und in den
beiden Komponenten einzeln. Ähm und es gibt die Zeichen, die gleich aussehen, aber doch nicht gleich sind, wie z.B. das Omega und das Ohm.
Es gibt die kompatible Äquivalenz, das ist ein bisschen lockerer. Da sieht man z.B. das H in Lateinisch, in Altdeutsch, in der Doppel in der Doppel
Strichschrift, wie wir reelle Zahlen, ganze Zahlen etc. kombinieren. Es gibt verschiedene Space in verschiedenen Breiten mit mit verschiedenen
Funktionen. Es gibt Zahlen mit dem Kreis drumrum. Es gibt gedrehte Klammern für ein bisschen kompliziertere Formeln. Ich kann ein Subscript, ich kann ein
Superscript definieren. Ähm, ich kann einen Bruch als Dreizichen oder als Ligatur darstellen und ich kann ähm hm, was will der uns denn jetzt damit
sagen? Es ist other. Ähm, dieser Standard unterscheidet zwischen der kanonischen
und der kompatiblen Äquivalenz. Das hatten wir eben schon. Kanonische Äquivalenz ist gleiches Aussehen, gleiche Bedeutung.
Das möchte man beim Sortieren und Vergleichen gleich behandeln. Man kann die auch beliebig untereinander austauschen. Bei der kompatiblen
Äquivalenz kann das Zeichen anders aussehen und es hat möglicherweise die gleiche Bedeutung. Das heißt, man kann es nicht unbedingt gleich behandeln, man
kann es nicht unbedingt substituieren, aber wenn zwei Zeichen kanonisch äquivalent sind, sind sie auch kompatibel äquivalent.
Beispiel, das A mit Axon ist kanonisch äquivalent zu der Kombination aus A und dem Axon und auch unabhängig davon, in welcher Reihenfolge das steht. Das Oh
ist kanonisch äquivalent zum griechischen Omega. Das Leerzeichen ist kompatibel äquivalent zum geschützten Lehrzeichen,
an dem keine Zeilen gebrochen werden dürfen. Das R mit Doppelstrich ist kompatibel äquivalent zu einem normalen R und I² ist kompatibel äquivalent zu
dem Buchstaben I und der Ziffer 2. Der Standard definiert vier verschiedene Normalisierungsformeln äh Formen, nämlich einmal kanonisch und
einmal kompatibel und einmal die Dekomposition und einmal die Komposition. Äh dazu habe ich Beispiele.
Ähm ich habe hier das Ongströmzeichen, den Codepoint 2128.
Das ist in der einen Normalisierung das A und der das A und der Kreis. Und in der anderen Normalisierung das A mit Kreis. Man beachte hier die Codierung C5
und hier 212B. Auf der anderen Seite habe ich hier das Zeichen A mit Kreis or C5. Das ist hat die gleichen beiden Normalisierungs das
hat die gleichen beiden Normalisierungen. 4130A und C5. Genauso kann ich hier das Omega in beiden
kanonischen Normalisierungsformen das Umzeichen in beiden kanonischen Normalisierungsformeln auf das Omega abbilden. Und hier das einfache, das O
mit Circumflex kann ich kann ich darstellen auch als Kombination und als einzelnes. Ähm
und hier sind auch noch mal zwe drei weitere Beispiele, die halt die Punkte darstellen.
Wenn ich etwas kompatibel normalisiere, dann habe ich da mehr Freiheiten. Hier habe ich die Ligatur aus F und I. Die darf ich in der
dekomposiert ähm die die darf ich in der kompatiblen Form nicht verändern. In der kanonischen Form darf ich sie verändern. Genauso hier die 2 hoch5 kann ich einmal
als 2 hoch 5 darstellen und einmal als 2 und 5. Da merkt man, das bietet sich an, die eine Variante ist gut zum Anzeigen, die andere Variante ist besser zum
Sortieren. Ähm, die Normalisierung Form C, das ist die kanonische Dekomposition gefolgt von kanischer Komposition. Das
heißt, ich nehme das Zeichen erstmal auseinander und dann baue ich es wieder zusammen. Ähm, das löst das Problem Akzent und das
Problem Einheiten, weil wir kommen dann auf jeden Fall beim kombinierten Zeichen wieder raus, bei dem emarson und beim Omega.
Aber das lateinische A und das kyrdische A sind auch in der Normalisierungsform C noch unterschiedliche Zeichen.
Wir lernen daraus, die Normalisierung ist nicht notwendigerweise umkehrbar, weil ich in dem Moment, wo ich z.B. das Angström in das A mit Kreis umwandel,
die Information verloren habe, dass wä es hier mit einer physikalischen Einheit zu tun haben. Ich verliere also aus der Information, das ist eine physikalische
Länge von 10ström. Die Information verliere ich. Danach ist es nur noch die Zahl 10 gefolgt vom Buchstaben O. Ähm, wie will ich das sortieren?
Ist Ampere kleiner Angstö kleiner Celsius oder will ich da doch lieber auf die Zahl gucken, die da vorne dran steht
oder lasse ich es bleiben? Normalisierung verliert Information. Das heißt, eine Applikation muss sich entscheiden, wie sie einen String
abspeichert. normalisiert oder nicht normalisiert und wie sie ihn verarbeitet. Da gibt's verschiedene Möglichkeiten. Ich kann jetzt den String
unnormalisiert abspeichern und die Normalisierung immer wieder machen, wenn ich wenn ich ihn vergleichen möchte, wenn ich es vergleichen oder sortieren
möchte. Das frisst Rechenzeit. Ich kann es normalisiert speichern, dann verliere ich Information. Ähm, ich kann es auch in beiden
Varianten speichern. Das ist sicherlich für CPU Zeit die einfachste Variante, aber das frisst Speicher.
Sucht euch euer Gift aus. Ähm, der Standard enthält Tabellen zur Normalisierung. Das ist also nicht immer durch Programm
durch Programmierung lösbar. Die volle Abdeckung ist aber nicht garantiert. Es gibt Fälle, wo Dinge ähnlich oder gleich aussehen, die aber trotzdem nicht
eininander zugeordnet sind. Das geht bei über das geht bei über bei über 150.000 Zeichen auch nicht anders. Ähm leider ist es trotzdem sicherheitsrelevant. Das
heißt, man möchte an sicherheitsrelevanten Stellen sich vielleicht doch ein bisschen Gedanken machen, ob man jetzt den kompletten
Unicode Sprachraum akzeptieren möchte oder ob man da doch sagt, ich habe jetzt Kunden aus der ganzen Welt, aber ich muss trotzdem nur die Zeichen erlauben,
die weltweit in irgendwelchen Namen im Einsatz sind. Also große Auswahl wirgt große Verantwortung.
Ähm damit bin ich jetzt mit meinem eigentlichen Vortrag durch. Ich habe noch ein bisschen Zeit und habe auch noch Zeit für Q&A. Dann erzähle ich euch
jetzt, wie dieser Vortrag entstanden ist. Ähm, ich habe vorhin schon erzählt, ich bin DBN Developer und ich maintaine
unter anderem so unwichtige Programme wie Adduser oder Sudo, die ähm auf sehr vielen Systemen installiert die auf sehr vielen Systemen installiert installiert
sind. Und letztes Jahr habe ich Adduser ein bisschen sicherer gemacht. Ähm, Adduser benutzt User Ad als Lowlevel Tool unten drunter und ich habe nachdem
nach dieser Sicherheitsveränderung ein Bugreport bekommen aus Osteuropa. Es ist eine es ist eine Regression. Ich kann meinen Namen nicht mehr als
Usernamen nehmen. Mein erster Gedanken war, aber ich habe doch gar nichts geändert. ähm geändert hatte sich User Ad und das
ist durch meine Sicherheitsveränderung rausgekommen. Da konnte man nämlich plötzlich nur noch ASKI Zeichen in Usernamen benutzen. Das will man ja auch
eigentlich so war so meine erste Idee. Ähm, aber andererseits habe ich mich gefragt, wie arrogent sind wir Europäer eigentlich? Warum nehmen wir Asiaten,
Russen und anderen Leuten, die keine lateinische Schrift benutzen, die Möglichkeit, ihren Usernamen als ihren Usernamen als ihren Namen als Usernamen
zu benutzen? Das ging doch früher auch schon die ganze Zeit. Ähm, das habe ich dann, wie ich brav bin, ein bisschen mit meinen anderen Developern ausdiskutiert.
Ähm, die Reaktion war Unisono, das ist Unsinn, lass das. Und ähm das stand dann auch eine Woche später in der Linux Wikly News und das hat mich dann dazu
veranlasst, dass ich ein bisschen Standards und Dokumentation gelesen habe.
Ich kam zu dem Ergebnis, okay, das ist aufwendig, aber wir haben Libraries. Es gibt die Lip Unicode, die diese Frage mit mit Vergleichen und mit
Vergleichen und sortieren relativ gut erledigt. Aber Adduser ist Top 5 in Popcorn. Es ist auf ziemlich vielen Systemen
installiert und es ist dem Installer. Der Installer möchte klein sein. Ähm, also ist Adduser so gebaut, dass Libraries
nur benutzt werden, wenn es wirklich überhaupt nicht anders geht. Ähm, ich habe dann glücklicherweise eine Ausrede gefunden, nämlich den den RFC 8265
Preparation Enforcement and Comparison of Internationalized Strings Preise. Und da steht praktischerweise drin für Usernamen, für Usertifier nehmen wir
USaskey und noch ein paar wenige Sonderzeichen und bitte nicht mehr. Also haben wir es gelassen mit den UTF8 Usernamen.
Posix. Also die Frage war, was sagt denn POSX? POSIX sagt auch nur ASKI und ein paar Sonderzeichen. System D hat auch eine eigene Regel. Das ist die schärfste
von allen. Ähm, aber nach aber an Posex interessieren sich nicht mehr so viele Leute.
Noch weitere Fragen? Der Kollege kommt gleich mit dem Genau. Ja. Äh Mikrofon. Erstmal großen Applaus an Mark
[Applaus] und wir haben noch ungefähr 20 Minuten für Q&A. Das heißt, ihr könnt euch
richtig gönnen. Und draußen wird schon gegrillt. Vielen Dank für diesen fantastischen Vortrag. Äh, ich habe eine Frage. Gibt
es bei UTF8 irgendwie ein Anfangsbit, das sagt so, pass mal auf, für das nächste Zeichen verwende ich jetzt die und die Breite. Äh, vielleicht habe ich
das überhört, dass man sagt, also wenn das von einem bis vier Bitte möglich ist, dann könnte man ja sagen, also ich habe bin UTF8 und erwarte für das
kommende Zeichen bitte zwei Bitte und das und diese Information muss ich ja auch irgendwo lassen. Das ist diese Definition hier oben. Ähm,
alles was mit einer Null anfängt ist ein Beit. Alles was mit 10 anfängt ist sind zwei Bites. Alles mit alles was mit 10 100 anfängt sind dreit. Und alles, was
mit vier ein und einer null anfängt sind vier Bit. Danke schön. Vielen Dank. Da hinten noch. Ja,
genau. Beantworte du bitte einmal. Ja, war schon richtig. Du bist dran und wenn du fertig bist, bitte an den Menschen hinter dich
weitergeben. Ähm, es heißt aber auch, dass ich eigentlich
jede Anwendung, also auch die uralten Unix Tools updaten müsste, um damit auch umzugehen, weil na ja, früher hat man auf dem Char Array
rumeriert und hat gedacht, na ja, reicht ja. Und was würdest du oder Frage
selber implementieren gar nicht mehr? Also benutzt eine Library oder? Das würde ich so sagen. Ja, das ist ein ultra kompliziertes Thema. Ich glaube
nicht, dass ich glaube nicht, dass du das hinbekommst, wenn du das nur nebenbei in einem anderen Entwicklungsprojekt machen möchtest. Das
ist zumindest die Entscheidung, die ich für Adduser und mich getroffen habe. Ähm, ich habe noch andere Hobbys als UTF8 zu implementieren, wo es die
Library schon gibt, aber die Library zu groß ist. Ähm und die zweite Frage, ähm wie viele Tools gibt's eigentlich noch
in dem aktuellen Debien, die nicht um damit umgehen können mit mit ordentlich mit UTF8, sondern immer noch der Meinung sind, na ja,
ähm eben die die 8 Bit Codierung ist völlig ausreichend. Spontan würde ich sagen sehr sehr viele,
weil weil weil in den meisten Fällen funktioniert es ja. kaputt. Mm.
Bei Cut kann man halt z.B. nicht mehr sagen, gib mir mal die Spalten 12 bis 15, wenn da vorne ein UTF8 Zeichen dran stehen könnte.
Ja, danke. Ähm, wenn der naive Programmierer für um zwei Zeichen zu vergleichen, den Vergleichsoperator kleiner benutzt, z.
Beispiel er macht sich ja normalerweise gar keine Gedanken, dass abhängig von seiner Umgebung, Betriebssystem, Programmier Umgebung und so weiter die
Bedeutung eine beliebige ist. Das heißt, die Portabilität ist da überhaupt nicht gegeben. Und was so Vergleichbarkeit anbetrifft, glaube ich, da können wir
ruhig auch Fatalisten sein, weil wir können transformieren, wie wir wollen. Wir kommen nicht dran an die Komplexität, die für das Sortieren von
den guten alten Telefonbüchern gefordert war, in z.B. Müller und Söhne mal Müller mit UE mal mit Ü und das und mal als Kaufmanns und mal als ausgeschrieben und
wenn das so hinter wie soll das überhaupt sortiert werden? Ich glaube die die Regeln dazu heißen ABC Regeln sind glaube ich über eine Vornorm nie
hinausgekommen. Und noch kleine Anekdote, die Österreicher, die hatten sich es früher einfach gemacht. Die hatten im Telefonbücher, Telefonbüchern
die Umlaute einfach hinter hinter dem Z an ansortiert. Die haben anscheinend eine ganz primitive Sortierung gemacht, ohne sich groß Gedanken zu machen.
Das wird vermutlich sogar die naive die naive Sortierung auf elektronischer Art und Weise gewesen sein, weil die Umlaute stehen ja in den 8859
Zeichensätzen auch ganz hinten und in Schweden ist das heute noch so, also dass man ein A wie ein R sortiert, das ist noch nicht rel das ist glaube ich in
Deutschland noch nicht so lange so. Ähm, ansonsten würde ich erwarten, dass die LIP UUTF8 mir einen funktionierenden
kleiner Gleichoperator bereitstellt, der natürlich nicht mit UE und Ü umgehen kann, weil das ist ein deutscher Sonderfall, dass sowas um dass sowas
umschrieben wird. Ich glaube, das macht man nur in Deutschland, aber auch das wäre auch etwas, was man in der Library eigentlich eigentlich abbilden könnte.
Ich kenne nur keine davon. Ich weesprochen werden oder als
kann ja auchen. Ja, aber also der Einwurf war der der Einwurf war, dass es das E in verschiedenen in verschiedenen Varianten
gibt, nämlich einmal als Umlaut E und einmal als Dehnungse. Das gibt's ja auch als Iogrävenbruch. Ähm, aber ich glaube, das ist jetzt
Aussprache. Ich glaube, man sortiert Grevenbruch nicht anders, als würde man es Grevenbräuch sprechen. Also, ich meine, dass es in Unicode
Collations gibt, die man angeben kann und da gibt's meine ich auch für Deutsch äh verschiedene, damit man halt verschiedene Varianten hat, wie man die
S einsortiert und die muss man dann halt auswählen. Deswegen kann man auch teilweise, ich meine bei Java angeben, wie man die ganze Sortierung haben will,
nach welchem nach welcher Sprache sozusagen und da eventuell auch noch mal ob nach Telefonbuch oder nach anderen Konventionen.
Na, dann ist ja alles gut. Ich dachte immer ist halt sau kompliziert dann, man muss das richtige angeben, kann auch nicht
alle Fälle dann abdecken, aber ich dachte immer die Collations, die man ja auch bei Datenbanken beim Anlegen von Feldern oder beim Anlegen von äh von von
Tabellen angeben muss, dass das im Wesentlichen auch anzeigt, ob man jetzt 8859 irgendwas oder UTF8 benutzen möchte, aber das ist innerhalb von
fahren fahren fahren UTF8 auch noch andere Varianten gibt, die solche alltäglichen Probleme angehen. finde ich gut. Wusste ich auch noch nicht.
Und auch lower. Ja, also Collations unterscheiden auch, ob es CAS sensitiv oder nicht Kensitiv
vergleicht und sortiert. Ja, wie ist es denn bei Suchen und Regular Expressions? Wenn ich jetzt irgendwie da etwas angebe, wie ein
großes A, würde ich vielleicht nicht unbedingt erwarten, dass Alpha und das kurillische da A gefunden werden. Andererseits ist es aber vielleicht
sinnvoll, wenn ich ein kleines S angebe, dass wenn Texte mit langem S da sind, was ja ein anderer Codeband ist, die dann schon mit ausgewählt werden. Wie
wird das gehandhabt und was erwartet man da eigentlich? Also in vielen Tools passen sich die passen sich die regulären Ausdrücke an das gesetzte
Local an. Das macht dann den Unterschied, ob du deedde oder DEede.f8 gesetzt hast. Dann ähm und ich würde erwarten, dass in dass ähm wenn ich ein
deutsches Lokell gewählt habe, das A bis Z auch die Umlaute umfasst und zwar egal, ob es größer oder kleiner ist. Mir fällt gerade noch was ein zu dem Einwurf
aus der Ecke von vorhin. Ähm in Python muss man sich die muss man sich diese Gedanken nicht machen. Python macht es richtig, aber soweit ich weiß gibt es
keine andere Programmiersprache, wo man das nicht zumindest mal einschalten muss, die UTF8 Behandlung. Ich könnte mir vorstellen, dass Pearl es auch
richtig macht, wenn man gesagt hat, use UTF8. Ähm ob C das richtig macht, da bin ich mir fast sicher, das nicht. In C++ könnte ich mir vorstellen, dass der
kleiner, dass der kleiner Operator für die Stringklasse entsprechend überladen ist, dass es da auch irgendwelche Settings gibt, aber dazu bin ich zu
wenig Entwickler, um das jetzt beurteilen zu können. Ja, warte, ich komme zu dir.
Nur noch eine kleine Anekdote. Äh, du hast ja auch noch von Epstick von IBM berichtet, das war ja keine Norm, sondern nur ein Industriestandard. Äh,
dummerweise wurde dieser Standard nicht nur von IBM benutzt, sondern von auch einer von einer deutschen Firma in die in Erlangen beheimatet ist. äh und die
hatte deren SSD Codierung hatte deutliche Änderungen gegenüber sie gegenüber habe ich mich versprochen gegenüber IBM
natürlich und die haben es fertig gebracht äh auf unterschiedliche Zeichenbelegung zu haben auf Tastatur, Bildschirm und
Drucker und alle drei Komponenten waren vomselben Hersteller. Man kann es hinkriegen, man kann Inkompatibilitäten hinkriegen, wenn man
sich nur genügend Mühe gibt. Man kann den Firmennamen auch als Akronym lesen, das mache ich jetzt aber nicht im Stream.
[Musik] Alles klar? Gibt's noch weitere Fragen? Anmerkungen oder so da vorne noch? Moment. äh könnt man rechnen.
Ja, noch mal mal zu der äh Reduktion der erlaubten Zeichen äh für Usernamen. Ähm trifft das dann in gleicher Ebene auch für die Passwörter
zu? Äh nein, absichern will. Die darf ich dann voll mit einem
Da würde ich davon ausgehen, das ist ja nicht sicherheitsrelevant. Da ist das Schlimmste, was du was passiert ist, dass die Authentifikation ist, dass du
dich nicht einloggen kannst. Das wird dich jetzt als Ingenieur mal ähm als Versagen zur sicheren Seite annehmen. Ähm
alles klar. Noch weitere Fragen oder war da noch was? Ach, da ist noch einer. Sehr gut.
Das kommt drauf an, wie du die Sicherheit siehst. Nicht funktionierendes System ist sicher, weil nichts passiert.
Der sicherste Computer ist in einem Betonklotz eingegossen mehr versenkt ohne Schnittstellen nach draußen und ohne Strom.
Dass man den dass man ihn dann nicht mehr benutzen kann, ist manchen Sicherheitsabteilungen in Konzernen noch nicht so ganz klar, aber wir wissen das.
Aber was ich auch noch mal eben noch mal sagen wollte, ist wahrscheinlich ist es dann besser. Ja, also wenn man Sicherheit
machen will, gerade sowas wie Benutzernamen und solche Vergleiche, dass man sich dann, sag mal, das Problem delegiert und
sagt, okay, ich benutze Sicherheit delegere ich an was auch immer an entsprechendes System und das soll mir dann gefällig bitte einen richtigen
Usernamen geben und eben ich mache das ein Problem anderer Leute, nicht, dass ich die Sicherheit selber machen will. Beispielsweise schon mal ähm ist sind
die Usernamen identisch. Und ich hoffe mal, dass diese Leute ähm eben die ganzen Probleme von UTF 8 und oder Unicode im generellen kennen, dass ich
das nicht selber machen will. Ich glaube, es war schon immer eine gute Idee, die Sicherheit nicht selber machen zu wollen.
In der Praxis, insbesondere bei größeren Installationen, wirst du deine Usernamen in deine Usernamen in irgendeinem
Verzeichnisdienst haben und der wird dir auch nicht den Usernamen und den Passworth hash geben, sondern du wirst ihn fragen, ich habe hier den User, der
versucht sich so zu identifizieren. Ja, nein, vielleicht. Und ähm damit ist das Problem
auch das. Ja, auch das geht natürlich, aber wie gesagt, bei mir ist das in Adduser entstanden. Da bin ich der Verzeichnisdienst bzw. ich konfiguriere
den Verzeichnisdienst ETC PasswD auch ein Verzeichnisdienst. Okay, noch mehr Fragen, noch mehr Anmerkung. Jetzt ist eure Chance. Ah,
sehr gut. Ja, auch von meiner Seite noch mal vielen Dank für ein Vortrag, Mark. Ich
habe am Anfang gedacht, na ja, wie kompliziert kann es denn sein, ne? Aber schlimmer geht immer, ne? Das bewahrheitet sich. Ähm
man kann damit jede Menge Spaß haben für passende Werte von Spaß. Ja. Ähm noch mal zum Verständnis eine Geschichte. Das heißt, wenn ich jetzt
drei Zeichen hintereinander habe, also ein ein A, ein Axon und ein E, dann weiß ich nicht, zu welchem der Zeichen des Axor gehört. Also, ob es zum A gehört
oder zum E. Das ist eine gute Frage. Eigentlich müsstest du das wissen. Da müsste man noch mal nachlesen. Eventuell ist das doch ist das doch gezeichnet,
dass der dass der dass der Acent immer dass der Modificator, dass es eine Eigenschaft gibt. Dieses Zeichen ist ein Modificator und das bezieht sich dann
entweder auf das Zeichen vorne und und auf das Zeichen hinten. Also ich würde Unicode zutrauen, dass es unterschiedliche
Modifikatoreigenschaften für den vorderen und für den hinteren Buchstaben hat, aber natürlich ist das nicht ganz frei,
weil dann, weil dann ist es ja mehrdeutig. Vielen Dank. Ja. Ja. Okay.
Alles klar. Ihr habt noch ungefähr vier Minuten. Das heißt, wenn euch noch was auf der Seele brennt, re jetzt euch hält keiner hier. Es ist
also von mir aus können wir zum Grillen gehen. Genau. Echt jetzt oder? Okay, gut.
Aber einen kleinen habe ich noch. Ähm, genau. Eine eine ist noch gekommen und zwar ähm wenn ich jetzt ein ich habe eine Datei und habe keine Ahnung,
welches äh welche Codierung verwendet worden ist. Gibt's ein gutes Tool oder eine gute Bibliothek, in die ich das reinwerfen
kann und die mir von mir aus auch mit Wahrscheinlichkeiten, man weiß wo welches Zeichen steht und so weiter, also die mir relativ gut erkennt, was es
denn hätte sein müssen wahrscheinlich. Ich glaube, es gibt dann nur Höristiken. Freiel sagt dir, es ist ein UTF8 Text oder es ist ein 8 Bit ASK.
Aber das kann vermutlich die das das wird vermutlich die unterschiedlichen 8859 Varianten nicht voneinander unterscheiden können. Ähm, was man
feststellen kann, ja, das ist valides UTF8 und damit ist klar, dass es nichts anderes ist. Ähm, wenn es nicht valides
UTF8 ist, dann kann man im Wesentlichen nur noch würfeln. eine,
also ich hatte das Vergnügen schon mal, es gibt da vom IBM eine Library ICEU und die gibt's dann noch für Java ICU for J, die ist riesig. Ich glaube irgendwie 46
Megb Textdata Referenzmaterial. Da schiebt man dann seine Daten rein und dann kriegt man eine Prognose, was es denn sein könnte und dann kann man äh
schauen, wie sicher ist sich die Library für jeden Trefferm und äh wenn einem das dann reicht, kann man dann die den Treffer mit der
höchsten Wahrscheinlichkeit annehmen und dann den Text halt dann in UTF8 beispielsweise für Java dann was da verwendet wird, dann rumakodieren.
Das stimmt. Lip ECU sehe ich manchmal in irgendwelchen Security Updates aufpoppen, dass die geupdatet wird. Kein Spaß, macht jede Anwendung riesig und
das Ergebnis ist halt auch nur gut. Ich kann mir ehrlich gesagt auch nicht vorstellen, dass das irgendwie ohne Wörterbücher abgeht.
Wir kriegen gerade signalisiert Times ab. Vielen Dank. Genau. Noch mal ein großer Applaus. Danke für Vortrag.
[Applaus]

Zum Nachlesen

UTF-8UTF-8 (Abkürzung für 8-Bit UCS Transformation Format, wobei UCS wiederum Universal Coded Character Set abkürzt) ist die am weitesten verbreitete Kodierung … Unicode[ ˈjuːnikoːt]) legt fest, wie Schrift elektronisch gespeichert werden kann, z. B. auf einem Computer oder Telefon. Der durch den Standard festgelegte … ZeichenkodierungEine Zeichenkodierung (englisch character encoding, kurz encoding) erlaubt die eindeutige Zuordnung von Schriftzeichen (i. A. Buchstaben oder Ziffern) und … American Standard Code for Information InterchangeDer American Standard Code for Information Interchange (ASCII, alternativ US-ASCII, ausgesprochen [ˈæski], deutsch „Amerikanischer Standard-Code für den …