Die falschen Schriften in deiner Bio sind keine Schriften: Was diese Zeichen wirklich sind
Veröffentlicht am 26.9.2025 · 12 Min. Lesezeit · Text- & Sprach-Tools
Daniel Okonkwo — Front-end-Entwickler und Tech-Redakteur bei OneKitly
Web-Performance · Dateiformate
Anhand von 5 Quellen geprüft
Die Generatoren, die hundert Schriften für dein Profil versprechen, ändern keine einzige Schrift. Sie tauschen jeden Buchstaben gegen ein anderes Zeichen, das zufällig in einem anderen Stil gezeichnet ist. Schickt man das Wort OneKitly durch einen Fett-Generator, erhält man die Codepunkte U+1D400 U+1D425 U+1D425 U+1D422 U+1D427 — keiner davon ist der Buchstabe A, l, l, i oder n. Es sind MATHEMATICAL BOLD CAPITAL A und seine Nachbarn, Zeichen, die der Unicode-Standard aufgenommen hat, damit ein Physikaufsatz einen fetten Vektor von einem kursiven Skalar unterscheiden kann. Weil es andere Zeichen sind, hört alles auf zu funktionieren, was Text vergleicht: "OneKitly".includes(fett) liefert false, toLowerCase() rührt sie nicht an, /\w/ und /[a-zA-Z]/ erkennen sie nicht, und Number("𝟏𝟐𝟑") ist NaN. Ein Satz aus 33 Zeichen wächst von 33 auf 117 UTF-8-Bytes. Hilfstechnik liest den Puffer, den sie bekommt, und diese Zeichen tragen keine Aussprache: Eine so geschriebene Bio wird falsch angesagt oder übersprungen. Der Block hat außerdem 28 Lücken, wo Buchstaben schon anderswo kodiert waren, weshalb jeder Generator eine Flicktabelle mitbringt. NFKC-Normalisierung faltet alles zurück auf reines ASCII, sodass eine Plattform, die normalisiert, den Effekt stillschweigend löscht.
Ein fett wirkendes 𝐀 ist nicht der Buchstabe A in Fettschrift, sondern U+1D400, ein eigenes Zeichen, das für die Mathematik erfunden wurde. Wir haben die Codepunkte ausgegeben, die Kosten in Bytes gemessen, damit Suche, Sortierung und Wortzählung zerbrochen und den Block nach seinen 28 Lücken durchsucht.
Was der Generator tatsächlich tut
Eine Schrift ist eine Datei. Sie enthält Umrisse und ordnet dem Buchstaben A eine Form zu. Eine fette Schrift zu wählen ändert nicht den Buchstaben A, sondern wie der Buchstabe A gezeichnet wird. Jeder Stil, den ein Bio-Generator anbietet, arbeitet umgekehrt: Der Buchstabe wird ersetzt, und die Zeichnung ist die, die die Schrift der Plattform für den Ersatz ohnehin hatte.
Gibt man die Codepunkte aus, ist der Austausch offensichtlich. Das Wort OneKitly im Fettstil ist U+1D400 U+1D425 U+1D425 U+1D422 U+1D427; als Doppelstrich U+1D538 U+1D55D U+1D55D U+1D55A U+1D55F; dicktengleich U+1D670 U+1D695 U+1D695 U+1D692 U+1D697. Fünf sichtbare Buchstaben, fünf Codepunkte, keiner davon im ASCII-Bereich. In JavaScript meldet die Zeichenkette .length 10, weil jedes dieser Zeichen zwei UTF-16-Einheiten braucht.
Sie kosten auch mehr Speicher. Der Satz „Building tools for six languages.“ hat 33 Zeichen und 33 UTF-8-Bytes, weil er reines ASCII ist. Derselbe Satz im Fettstil hat weiterhin 33 Zeichen, aber 61 UTF-16-Einheiten und 117 UTF-8-Bytes — dreieinhalbmal so viel Nutzlast für dieselben Wörter. Auf einer Plattform, die eine Bio in Bytes statt in Zeichen misst, ist das der Großteil des Budgets für nichts.
Alles, was Text vergleicht, findet nichts mehr
Die Teilstringsuche scheitert zuerst. "OneKitly".includes(fett) liefert false, umgekehrt ebenso, denn kein einziger Codepunkt ist gemeinsam. Eine Sitesuche, das Suchen-auf-der-Seite des Browsers, eine LIKE-Klausel in der Datenbank und ein Hashtag-Index laufen auf denselben Vergleich hinaus, und alle gehen fehl. Steht dein Anzeigename in mathematischem Fett, findet dich niemand, der deinen wirklichen Namen ins Suchfeld tippt.
Die Umwandlung der Groß- und Kleinschreibung bewirkt nichts. fett.toLowerCase() liefert dieselbe Zeichenkette zurück, denn Unicodes Case-Mappings für die mathematischen Alphanumerika bilden jedes Zeichen auf sich selbst ab. Eine Suche ohne Beachtung der Groß- und Kleinschreibung, die beide Seiten kleinschreibt, scheitert also trotzdem. Was funktioniert, ist die Sortierung: Intl.Collator("en", { sensitivity: "base" }).compare("𝐀", "A") liefert 0, weil ICUs Kollationstabellen die stilisierten Buchstaben auf ihre Grundbuchstaben falten. Das ist wichtig zu wissen, denn es erklärt, warum dieselbe Zeichenkette in einem Produkt auffindbar und in einem anderen unsichtbar ist — es hängt allein davon ab, ob der Suchpfad über einen Kollator oder über Zeichenkettengleichheit lief.
Zeichenklassen widersprechen einander. /[a-zA-Z]/.test("𝐀") ist falsch, /\w/u.test("𝐀") ist falsch, aber /\p{L}/u.test("𝐀") ist wahr — das Zeichen ist nach Unicodes eigener Hauptkategorie sehr wohl ein Buchstabe (Lu für den Großbuchstaben, Ll für den Kleinbuchstaben), nur eben kein ASCII-Buchstabe. Ziffern verhalten sich genauso: /\d/u.test("𝟏") ist falsch, /\p{Nd}/u.test("𝟏") wahr, und Number("𝟏𝟐𝟑") ist NaN, obwohl dieselbe Zeichenkette nach NFKC als 123 gelesen wird. Zwei Prüfroutinen zweier Teams fällen also gegensätzliche Urteile über dieselbe Bio.
Die Sortierung teilt die Differenz. Ein blankes Array.prototype.sort() vergleicht UTF-16-Einheiten, sodass ["𝐁rown", "Adams", "Clark"] als Adams, Clark, 𝐁rown herauskommt — der stilisierte Name wird ans Listenende verbannt, weil U+1D400 numerisch größer ist als jeder ASCII-Buchstabe. Mit localeCompare ergeben dieselben drei Adams, 𝐁rown, Clark, was ein Leser erwartet. Keines ist falsch; sie beantworten verschiedene Fragen, und ein Verzeichnis, das die schnelle Variante nutzt, führt dich unter gar nichts.
Die Kosten für die Zugänglichkeit, schlicht benannt
Ein Bildschirmleser sieht deine Bio nicht. Er bekommt die Zeichenfolge, die die Plattform gespeichert hat, und reicht sie an eine Sprachsynthese weiter, die jedes Zeichen in einem Aussprachewörterbuch nachschlägt. Dieses Wörterbuch ist für die Buchstaben gemacht, mit denen man schreibt. U+1D400 gehört nicht dazu. Die Synthese hat drei Möglichkeiten: den Unicode-Namen des Zeichens vorlesen, einen allgemeinen Platzhalter vorlesen oder es überspringen. Alle drei kommen in der Praxis vor, und welche man bekommt, hängt vom Leseprogramm, der Stimme und der Ausführlichkeitsstufe ab — nicht von etwas, das die Autorin steuert.
Die Kosten werden leicht unterschätzt, weil der Fehler für die Verursacherin unsichtbar ist. Du siehst einen schicken Namen. Eine blinde Leserin hört womöglich dreißig Zeichennamen hintereinander, oder der Name deines Kontos verschwindet ganz und übrig bleibt eine Karte mit Bild und ohne Titel. Es gibt keine Einstellung, mit der sie das reparieren könnte, denn für die Maschine steht dort wirklich etwas anderes. Das ist das ganze Argument; es braucht keine Moral obendrauf.
Eine Familie ist schlimmer als die übrigen. Die eingekreisten und negativ eingekreisten Sätze — Ⓐ U+24B6, 🅐 U+1F150 — sind überhaupt keine Buchstaben: Deine Hauptkategorie ist So, Symbol/sonstiges. Software, die ein Feld auf Buchstaben und Leerzeichen filtert, wirft sie weg, und Software, die Buchstaben zählt, zählt null.
Die 28 Lücken im Block und warum jeder Generator eine Flicktabelle hat
Der Block Mathematical Alphanumeric Symbols reicht von U+1D400 bis U+1D7FF, das sind 1.024 Codepunkte. Durchsucht man ihn nach zugewiesenen Zeichen, findet man 996; 28 Plätze sind also leer. Übrig bleiben 652 lateinische Buchstaben (dreizehn Stile zu 52, minus der fehlenden), 294 griechische und verwandte Zeichen sowie 50 Ziffern in fünf Stilen.
Vier der 28 sind bloße reservierte Füllung: U+1D6A6 und U+1D6A7 liegen zwischen dem kursiven punktlosen j und dem fetten großen Alpha, U+1D7CC und U+1D7CD zwischen dem fetten kleinen Digamma und der fetten Ziffer null. Die anderen 24 sind Buchstabenplätze, die absichtlich frei blieben, weil genau dieses Zeichen Jahre zuvor schon im Block Letterlike Symbols bei U+2100–U+214F kodiert worden war.
Die Liste ist kurz genug, um sie ganz anzugeben. Das kursive h fehlt, weil es schon als U+210E PLANCK CONSTANT vorhanden war. Der Schreibschrift fehlen B, E, F, H, I, L, M, R (sie sitzen bei U+212C, U+2130, U+2131, U+210B, U+2110, U+2112, U+2133, U+211B) sowie die Kleinbuchstaben e, g, o (U+212F, U+210A, U+2134). Der Fraktur fehlen C, H, I, R, Z (U+212D, U+210C, U+2111, U+211C, U+2128). Der Doppelstrichschrift fehlen C, H, N, P, Q, R, Z (U+2102, U+210D, U+2115, U+2119, U+211A, U+211D, U+2124) — die Mengenlehre-Buchstaben, die jede Mathematikerin ohnehin schon hatte.
Deshalb verrät sich der Block. Ein Generator, der Buchstaben durch einfache Arithmetik abbildet — den Codepunkt von A nehmen und den Stilversatz addieren — erzeugt für diese 24 Buchstaben unzugewiesene Codepunkte, und ein unzugewiesener Codepunkt erscheint als leeres Kästchen. Ein sorgfältiger Generator führt die Flicktabelle mit. Ein schneller nicht, weshalb Schreibschrifttext so oft genau dort ein Loch hat, wo ein E oder ein R stehen müsste.
Wo diese Zeichen die richtige Antwort sind
Nichts davon macht diese Zeichen zu einem Fehler. Sie existieren, weil in der Mathematik der Stil die Bedeutung ist. Ein fettes R und ein kursives R sind nicht dasselbe Symbol auf zwei Arten gelesen, sondern zwei Symbole. ℝ sind die reellen Zahlen, R kann ein Ring sein, und ein fetter Vektor ist nicht der Skalar mit demselben Buchstaben. Die Stile als eigene Zeichen zu kodieren ist genau das, was eine Formel überleben lässt, wenn man sie aus einem Aufsatz in eine E-Mail kopiert.
Das ist zugleich der Test dafür, ob man sie gut einsetzt. Trägt der Stil Information, die ohne ihn verloren ginge, ist das Zeichen das richtige Werkzeug. Ist der Stil Zierde auf gewöhnlicher Prosa, dann sind normale Buchstaben plus echte Formatierung — das Fett, das dein Editor erzeugt und das den Buchstaben A den Buchstaben A sein lässt — das richtige Werkzeug, und das einzige, mit dem Bildschirmleser, Suchindex und Sortierroutine gleichermaßen umgehen können.
NFKC und die Plattformen, die den Effekt kommentarlos löschen
Unicode definiert für jedes dieser Zeichen eine Kompatibilitätszerlegung: Der Standard selbst hält fest, dass U+1D400 eine Formatierungsvariante von A ist. Die Normalisierungsform NFKC wendet diese Zerlegungen an und setzt danach wieder zusammen, sodass fett.normalize("NFKC") auf unserem Testsatz das reine ASCII-Original zurückgibt, Zeichen für Zeichen — wir haben beide Zeichenketten verglichen, sie sind gleich. Dasselbe geschieht mit Text voller Breite (U+FF21 wird A), mit eingekreisten Buchstaben (U+24B6 wird A) und mit hochgestellten Modifikatorbuchstaben (U+1D2C wird A).
Viele Dienste normalisieren beim Eingang, meist damit nicht zwei Konten gleich aussehende Namen tragen. Wenn sie das tun, ist der eingefügte Stil beim Speichern schon weg, und nichts sagt es dir: Du schickst eine schicke Bio ab und bekommst eine schlichte zurück. Nichts ist kaputt; die Plattform hat schlicht die Zeichendatenbank gefragt, was dein Text wirklich sagt, und diese Antwort gespeichert.
Zwei Familien überstehen NFKC, und es lohnt zu wissen, welche. Die Kapitälchenbuchstaben — ᴀ ist U+1D00 LATIN LETTER SMALL CAPITAL A — sind phonetische Buchstaben aus den IPA-Erweiterungen ganz ohne Kompatibilitätszerlegung, gehen also unverändert durch die Normalisierung. Ebenso die negativ eingekreisten Buchstaben, 🅐 U+1F150 und Verwandte. Für den Standard sind sie keine stilistischen Varianten von A, sondern eigene Zeichen. Das macht sie haltbarer und nicht lesbarer, und genau dieser Tausch trägt die ganze Kategorie.
Eine praktische Regel für ein Profil
Halte die Felder, nach denen gesucht wird, in gewöhnlichen Buchstaben: deinen Namen, dein Kürzel, die Wörter, die jemand eintippen würde, um dich zu finden. Dort kostet der Austausch etwas Messbares. Wenn du eine Verzierung willst, setze sie dorthin, wo niemand abfragt — ein Trennzeichen, ein einzelnes Schmuckzeichen — und lass die Wörter drumherum schlicht.
Und bewahre eine Kopie der schlichten Fassung auf. Weil die Umwandlung eine Nachschlagetabelle ist, ist der Rückweg ebenfalls eine: Mit NFKC normalisieren stellt für die mathematische, die vollbreite, die eingekreiste und die hochgestellte Familie das Original exakt wieder her. Für Kapitälchen und negativ eingekreiste Buchstaben brauchst du eine Umkehrtabelle, denn die Normalisierung nimmt sie dir nicht ab.
| Zeichen | Codepunkt | Unicode-Name | Kategorie | Nach NFKC |
|---|---|---|---|---|
| A | U+0041 | LATIN CAPITAL LETTER A | Lu (Buchstabe) | A (unverändert) |
| 𝐀 | U+1D400 | MATHEMATICAL BOLD CAPITAL A | Lu (Buchstabe) | A |
| 𝔸 | U+1D538 | MATHEMATICAL DOUBLE-STRUCK CAPITAL A | Lu (Buchstabe) | A |
| A | U+FF21 | FULLWIDTH LATIN CAPITAL LETTER A | Lu (Buchstabe) | A |
| Ⓐ | U+24B6 | CIRCLED LATIN CAPITAL LETTER A | So (Symbol, kein Buchstabe) | A |
| ᴀ | U+1D00 | LATIN LETTER SMALL CAPITAL A | Ll (Buchstabe) | ᴀ (bleibt) |
Häufige Fragen
- Schadet eine Bio in Pseudoschrift meiner Reichweite?
- Sie nimmt dich für diese Wörter aus der Textsuche, was messbar und von jedem Ranking-Algorithmus unabhängig ist. "OneKitly".includes(fett) ist falsch, eine Abfrage nach deinem schlichten Namen kann einen stilisierten also nicht per Teilstring treffen. Ob eine bestimmte Plattform das ausgleicht, hängt davon ab, ob sie vor dem Indizieren normalisiert oder kollationiert, und das veröffentlichen Plattformen nicht. Die vorsichtige Lesart: Jedes Wort, unter dem du gefunden werden willst, gehört in gewöhnliche Buchstaben.
- Warum erscheinen manche Buchstaben als leere Kästchen?
- Zwei verschiedene Gründe, die gleich aussehen. Entweder hat der Generator einen der 28 unzugewiesenen Codepunkte des Blocks ausgegeben — meist einen Schreibschrift-, Fraktur- oder Doppelstrichbuchstaben aus der Liste der 24 Lücken — oder das Zeichen existiert, doch die Schrift auf dem Gerät der Leserin hat keine Glyphe dafür. Der erste Fall ist ein Fehler des Generators und zeigt sich bei allen; der zweite hängt vom Gerät ab, weshalb dieselbe Nachricht auf deinem Telefon gut und auf einem anderen kaputt aussieht.
- Wie wandle ich stilisierten Text zurück in normale Buchstaben?
- Für die mathematische, die vollbreite, die eingekreiste und die hochgestellte Familie genügt ein Aufruf: text.normalize("NFKC"). Wir haben geprüft, dass ein ganzer Satz exakt zurückkommt — der normalisierte Fettsatz ist gleich dem ASCII-Original. Kapitälchen und negativ eingekreiste Buchstaben haben keine Kompatibilitätszerlegung und überstehen die Normalisierung, brauchen also eine ausdrückliche Umkehrtabelle. Ein Umwandlungswerkzeug bringt beide Wege mit; ein einzeiliges normalize deckt die Mehrheit ab.
- Gibt es einen Stil, der unbedenklich ist?
- Nicht im Sinne von unsichtbar für Software — jeder von ihnen ändert die Codepunkte, und genau das ist der Mechanismus. Was sich unterscheidet, ist, wie viel man verliert. Ein Schmuckzeichen zwischen zwei normalen Wörtern kostet fast nichts. Einen ganzen Anzeigenamen zu ersetzen kostet Suche, Sortierung und die Lesbarkeit für Hilfstechnik. Der Schaden wächst mit der Zahl der ersetzten Buchstaben: also zeichenweise einsetzen, nicht satzweise.
- Warum kommt mein stilisierter Text nach dem Speichern manchmal schlicht zurück?
- Der Dienst hat ihn normalisiert. NFKC ist der Standardweg, um zu entscheiden, ob zwei Zeichenketten „derselbe Text“ sind, und Plattformen wenden ihn auf Anzeigenamen und Kürzel an, um Verwechslungsbetrug zu verhindern. Einmal angewandt, wird aus U+1D400 ein A, und es bleibt nichts zum Rückgängigmachen. Nichts ist kaputt und keine Fehlermeldung erscheint, denn aus Sicht der Plattform wurde genau das gespeichert, was du getippt hast — nach der Definition von „was du getippt hast“, die die Zeichendatenbank liefert.
- Zählen diese Zeichen gegen ein Zeichenlimit?
- Das hängt ganz davon ab, was das Limit zählt, und das ist das übliche Problem von Zeichenlimits. Nach Codepunkten sind es in unserem Testsatz beide Male 33. Nach UTF-16-Einheiten — was JavaScripts .length meldet und was viele Formularprüfungen verwenden — sind es schlicht 33 und fett 61. Nach UTF-8-Bytes 33 gegen 117. Ein Formular, das 33 schlichte Zeichen zulässt, nimmt vielleicht nur 16 stilisierte an, und der Zähler neben dem Feld erklärt nicht, warum.
Artikel, die dich interessieren könnten
Alle Ratgeber →Ähnliche Tools
Quellen
- Unicode Consortium — The Unicode Standard — Mathematical Alphanumeric Symbols (U+1D400–U+1D7FF) code chart
- Unicode Consortium — UAX #15: Unicode Normalization Forms (NFC, NFD, NFKC, NFKD)
- Unicode Consortium — UTS #39: Unicode Security Mechanisms — confusables and identifier restrictions
- Mozilla — MDN Web Docs — String.prototype.normalize()
- W3C — Web Content Accessibility Guidelines (WCAG) 2.2 — Readable and Text Alternatives
Hast du einen Fehler in diesem Artikel entdeckt?