Thema: unicode
-
JavaScript-Textversätze: UTF-16-Einheiten, Codepoints und sichtbare Zeichen unterscheiden
An jeder Editor- oder API-Grenze die Versatzeinheit benennen und vor dem Zerschneiden von Text gezielt umrechnen.
-
Unicode vor dem Vergleich von Bezeichnern normalisieren
Eine Normalisierungsrichtlinie für menschenlesbare Bezeichner wählen, ohne opake Tokens zu verändern oder optisch ähnliche Zeichen gleichzusetzen.
-
Unsichtbarer und umgeordneter Text: bidirektionale Steuerzeichen, Tag-Zeichen und Verwechslungszeichen in Code und Prompts
Unicode erlaubt es, dass Text Zeichen enthält, die eine prüfende Person nicht sehen kann, oder die das Angezeigte umordnen. Bidirektionale Steuerzeichen können bewirken, dass Quellcode sich anders liest, als er kompiliert; Tag-Zeichen können Anweisungen verbergen, die ein Modell dennoch empfängt, und Verwechslungszeichen ahmen Bezeichner nach. Erkennung bedeutet, die Codepoints zu scannen, nicht die Darstellung.
-
Fallstricke bei SMS: GSM-7 versus UCS-2-Codierung und Nachrichtensegmente
Eine SMS trägt 140 Byte: 160 GSM-7-Zeichen oder 70 UCS-2-Zeichen. Ein einziges Zeichen ausserhalb von GSM-7 (ein typografisches Anführungszeichen, ein Emoji) schaltet die gesamte Nachricht auf UCS-2 um; längere Nachrichten werden in Segmente zu 153 oder 67 Zeichen aufgeteilt, die Anbieter typischerweise getrennt abrechnen. Vor dem Versand Segmente zählen und Satzzeichen normalisieren.
-
Kollationen in PostgreSQL: libc, ICU und der eingebaute Provider, und warum ein Bibliotheks-Upgrade einen Index beschädigen kann
Eine Kollation entscheidet, wie Text sortiert und verglichen wird; PostgreSQL bezieht sie von einem Provider (libc, ICU oder die eingebauten Code-Point-Ordnungen C und C.UTF-8), legt den Standard pro Datenbank bei deren Erstellung fest und erlaubt Overrides pro Spalte oder Ausdruck. Sprachkollationen aus libc oder ICU ändern sich, wenn sich die Bibliothek ändert, was B-Tree-Indizes auf Text ungültig macht; den Provider daher bewusst wählen und nach Betriebssystem- oder ICU-Upgrades neu indexieren.
-
MIME-Struktur einer E-Mail: multipart/alternative, der Klartextteil und Kodierungen
Eine Nachricht mit Text- und HTML-Teil ist ein multipart/alternative, dessen Teile vom einfachsten zum reichhaltigsten geordnet sind (text/plain zuerst, text/html zuletzt); Bodys mit Nicht-ASCII-Bytes verwenden quoted-printable oder base64, Header verwenden RFC-2047-Encoded-Words. Den Textteil aus denselben Daten wie das HTML erzeugen, Variablen escapen und Zeilenlängengrenzen einhalten.
Maschinenlesbar: JSON