> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/de/ausfuhrliche-artikel/54-what-is-a-tex-token-list.md).

# Was ist eine TeX-Tokenliste

## Also, was genau ist eine "TeX-Tokenliste"?

In einer [vorheriger Artikel](/latex/de/ausfuhrliche-artikel/53-what-is-a-tex-token.md)— ebenfalls Teil davon [Reihe über low-level TeX-Feinheiten](/latex/de/ausfuhrliche-artikel/01-a-new-series-of-articles-tex-tokens-and-related-concepts-but-why-and-how.md)— wir haben die Prozesse untersucht, durch die TeX deine `.tex` Datei durchsucht, um neue Tokens zu erzeugen: Wir haben die grundlegende Natur eines TeX-Tokens und die Art untersucht, wie TeX sie erzeugt (siehe [Was ist ein „TeX-Token“?](/latex/de/ausfuhrliche-artikel/53-what-is-a-tex-token.md)).

In diesem Folgeartikel werfen wir einen Blick auf *Tokenliste*n: was sind sie und wie erzeugen/verwenden TeX-Engines sie? Das Verständnis von Tokenlisten kann schwierig sein, weil sie tief im Inneren von TeX gespeichert sind: Diese Details sind dem Benutzer verborgen — obwohl dies heute nicht immer zutrifft, wenn man fortgeschrittener mit LuaTeX programmiert. Aber fürs Erste kannst du Tokenlisten als TeXs Art betrachten, eine Reihe von Ganzzahlwerten zu speichern, wobei jede Ganzzahl ein Token ist, das aus einem Zeichen oder Befehl abgeleitet wurde, den TeX aus deiner Eingabedatei gelesen hatte.

Tokenlisten spielen eine entscheidende Rolle im inneren Betrieb von TeX, oft auf überraschende Weise, etwa beim internen Ablauf von Befehlen wie `\uppercase` und `\lowercase`. Eine besonders wichtige Verwendung von Tokenlisten ist das Speichern und Ausführen von Makros; dieses Thema werden wir als Teil eines zukünftigen Artikels dieser Reihe ausführlich untersuchen.

### TeX erhält seine Eingaben aus Dateien und Tokenlisten

TeX-Engines haben drei Eingabequellen — zwei davon kennst du vielleicht:

* physische Textdateien, die auf der Festplatte gespeichert sind;
* Text, den ein Benutzer ins Terminal (die Kommandozeile) eingibt;

aber es gibt auch eine dritte Art, Eingaben zu lesen/zu erhalten: Tokenlisten!

Tokenlisten sind in Wirklichkeit eine interne Datenspeichereinrichtung, die TeX als Teil seiner Operationen verwendet. Da TeXs Tokenlisten als „Speicher“ für zuvor erzeugte Tokens dienen, ist es sinnvoll, dass TeX sie als weitere Eingabequelle wiederverwenden kann. Wenn es nötig wird, seine nächste Eingabe aus einer bestimmten Tokenliste zu beziehen (oder TeX dazu angewiesen wird), beendet TeX vorübergehend das Lesen der Eingabe aus einer physischen Datei (d. h. das Erzeugen *neuer Tokens*) und wechselt dazu, seine Eingabe aus *bereits vorhandenen Tokens*: dem Speicherort im Speicher, an dem die Tokenliste abgelegt ist. Offensichtlich ist bei einer Tokenliste der Prozess des Scannens + Erzeugens von Tokens bereits erfolgt, also muss TeX nur jedes Token in der Liste betrachten und entscheiden, was mit jedem einzelnen zu tun ist.

Anhand eines kurzen Beispiels lässt sich der niedrige (TeX-Primitive) `\toks` Befehl verwenden, mit dem du eine Tokenliste erzeugen kannst, die TeX zur späteren Wiederverwendung im Speicher ablegt:

```latex
\toks100={Hello}
```

Um diese Tokens wieder abzurufen (also TeX mitzuteilen, dass es sie als nächste Eingabequelle behandeln soll), würdest du einen Befehl wie

```latex
\the\toks100
```

Dies veranlasst TeX, vom Erzeugen neuer Tokens aus deiner Eingabedatei dazu überzugehen, seine nächste Eingabe von dort zu beziehen, wo diese Tokens (erzeugt durch `\toks`) gespeichert sind — in einem sogenannten *Token-Register* , was einfach ein TeX bekannter interner Speicherort ist (hier ist es Register 100).

Außerdem können Tokenlisten intern und spontan von einer Reihe von TeX-Befehlen erzeugt werden. Ein Beispiel ist der Befehl `\jobname` der eine Reihe von Zeichen-Tokens erzeugt — ein Token für jedes Zeichen im Namen der Hauptdatei, die TeX gerade verarbeitet. Ein weiteres Beispiel ist der `\string` Befehl; zum Beispiel

```latex
\string\mymacro
```

erzeugt eine Reihe von Zeichen-Tokens für jeden Buchstaben im Namen `\mymacro`— einschließlich des anfänglichen `\` Zeichens. Am Ende dieses Artikels werfen wir einen genaueren Blick auf einige „Token-erzeugende Befehle“.

## Tokenliste: erklärt per Analogie

Wenn du keinen Programmierhintergrund und/oder keine Informatikkenntnisse hast, können „Tokenlisten“ ein etwas nebulöses und vielleicht ein wenig verwirrendes Konzept sein. Wenn du jedoch darin gut werden willst, TeX-/LaTeX-Makros zu schreiben, dann wird ein gutes Verständnis von Themen wie TeX-Tokens, Tokenlisten und Kategoriecodes (`\catcode`) äußerst nützlich sein.

In diesem Abschnitt verwenden wir eine Analogie, um die Kernideen/Grundprinzipien einer TeX-Tokenliste zu erklären/illustrieren: wie TeX Tokens im Speicher ablegt. Es lohnt sich, sich Zeit zu nehmen und dies durchzulesen, denn Tokenlisten sind ein *grundlegender* Aspekt von TeX und es lohnt sich, sie etwas genauer zu verstehen.

### Tokenlisten: Eine Analogie (Gedankenexperiment)

Wir werden ein „Gedankenexperiment“ durchgehen, um eine Grundlage zum Verständnis von TeX-Tokenlisten zu schaffen. Stell dir vor, du hättest Zugriff auf einen großen Vorrat an Behältern, etwa Hunderte von Blechdosen — wir können den Begriff „Box“ nicht verwenden, um unsere Behälter im Gedankenexperiment zu beschreiben, weil „Box“ natürlich in TeX eine ganz bestimmte Bedeutung hat, die mit unserer Diskussion hier nichts zu tun hat. Also nennen wir unsere Behälter „Dosen“, wobei jede Dose:

* eine eindeutige Identifikationsnummer hat, die außen aufgedruckt ist;
* intern in zwei Fächer unterteilt ist.

Diese beiden Fächer sind wie folgt gedacht:

* das linke Fach enthält den Gegenstand, den du in die Dose legen willst;
* das rechte Fach ist dafür gedacht, ein Stück Papier aufzunehmen, auf das du eine einzelne Zahl schreiben kannst: die Nummer einer anderen Dose.

![test](/files/bbaa091b2984dd21229c91489baec72584aea801)

Angenommen, du hast eine Sammlung von sagen wir 5 Gegenständen und möchtest diese Sammlung in diesen Dosen aufbewahren; aber leider kann jede Dose nur 1 Gegenstand des Typs aufnehmen, den du speichern willst.

Der Einfachheit halber nehmen wir an, wir wollten 5 farbige Kreise speichern:

![{{{alt}}}](/files/8a8e014b186d4ba818239199e4b2d61da31b845b)

Außerdem, wenn du später diese Gegenstände wieder aus deinem Speichersystem (den Dosen) abrufst, müssen diese Gegenstände *muss* in einer bestimmten Reihenfolge wiedergefunden/gelesen werden — nämlich in der Reihenfolge, in der sie gespeichert wurden: Diese Reihenfolge muss erhalten bleiben. Wie kannst du das erreichen?

Wir können uns zunutze machen, dass jede Dose:

* eine eindeutige Identifikationsnummer auf ihrer Außenseite trägt;
* 2 Fächer hat — nur eines davon verwenden wir, um unseren Gegenstand aufzunehmen; das andere enthält ein Stück Papier, auf das die Nummer einer anderen Dose geschrieben ist.

Wir nehmen an, jede Dose sei leer — aber es hindert dich nichts daran, eine beliebige Dose zu öffnen, um zu prüfen, ob sie leer ist; wenn nicht, nimm die nächste, bis du eine leere Dose findest.

Wir könnten Folgendes tun. Lege unseren ersten Gegenstand (dunkelgrüner Kreis) in eine unserer Dosen (z. B. Dose 124) und notiere dir die Nummer dieser ersten Dose — es spielt keine Rolle, welche Nummer diese erste Dose hat; wichtig ist nur, dass wir sie irgendwo aufschreiben und für später aufbewahren.

![{{{alt}}}](/files/f476cc28287314ef9334407deb754fc707e5b5ea)

Finde eine zweite Dose — irgendeine Dosenummer (z. B. Dose 432) — und notiere ihre Nummer. Schreibe die Nummer dieser zweiten Dose (432) auf ein Stück Papier und lege diese Notiz *in die erste Dose* (Dose 124). Wir legen unseren zweiten Gegenstand (hellgrüner Kreis) in die zweite Dose. Derzeit haben wir also folgende Situation:

* eine schriftliche Notiz — nicht in einer Dose gespeichert — die besagt, dass die erste Dose die Nummer 124 hat (sie enthält unseren ersten Gegenstand);
* in Dose 124 haben wir eine weitere Notiz hinzugefügt, die besagt, dass der nächste Gegenstand in Dose 432 zu finden ist.

Im Wesentlichen haben wir *verknüpft* unsere ersten beiden Dosen: Wir wissen, wo wir anfangen müssen (Dose 124) und dass eine Notiz in Dose 124 uns sagt, welche Dose den nächsten Gegenstand enthält (Dose 432).

![{{{alt}}}](/files/e854a2543670e77e3b95c9ba4666b4c944ed6b32)

Dann finden wir eine dritte Dose, schreiben ihre Nummer (z. B. Dose 543) auf ein Stück Papier und legen dieses in die *zweite* Dose (Nummer 432). Wir legen dann unseren dritten Gegenstand (roter Kreis) in die dritte Dose.

Jetzt haben wir drei Dosen in der Reihenfolge verknüpft: unser Startpunkt, Dose 124 (dunkelgrüner Kreis) → Dose 432 (hellgrüner Kreis) → Dose 543 (roter Kreis) →…

![{{{alt}}}](/files/3acf80927da31c1eb081309de6a123d2f51c626f)

Wiederhole diesen Vorgang für die letzten beiden Gegenstände (hellblauer und dunkelblauer Kreis) unter Verwendung von Dose 213 (hellblauer Kreis) und Dose 102 (dunkelblauer Kreis).

![{{{alt}}}](/files/a35b673224a9439f14f5f78596b71903eba1fc0b)

Jetzt haben wir alle 5 Dosen miteinander verknüpft (unter Verwendung der numerischen Kennung jeder Dose) und können alle gespeicherten Gegenstände in der richtigen Reihenfolge abrufen — einfach, indem wir jede Dose der Reihe nach besuchen, unseren Gegenstand herausnehmen und die Notiz betrachten, die uns sagt, welche Dose unseren nächsten Gegenstand enthält.

### Was ist mit dem letzten Gegenstand in unserer Liste (Dose 102)?

Warum sollten wir uns besonders um diesen kümmern? Bis jetzt haben wir jeden Gegenstand in einer Dose gespeichert, zusammen mit einer Notiz, die sagt, welche Dose den nächsten Gegenstand enthält: Was sollte diese Notiz für den letzten Gegenstand in unserer Liste sagen — denn es gibt keine nächste Dose.

Wenn wir beim letzten Gegenstand (bei der letzten Dose) ankommen, muss offensichtlich sein, dass diese Dose (die den letzten Gegenstand enthält) der letzte Gegenstand in unserer Liste ist — wir müssen keine weitere Dose suchen, denn es gibt keine. Eine Möglichkeit dafür besteht darin, in unserer letzten Dose (102) eine „besondere“ Dosenummer zu verwenden. Wir können jede Zahl verwenden, sofern wir eine eindeutige Zahl wählen, die nicht die Nummer einer tatsächlichen Dose ist — zum Beispiel „Dose -1“, „Dose 0“: Es spielt keine Rolle, solange wir wissen, dass „Dose -1“ oder „Dose 0“ usw. uns sofort sagt, dass wir aufhören sollen zu suchen: Wir müssen nicht nach weiteren Dosen suchen, denn dies ist die letzte und es gibt somit keine weiteren Gegenstände abzurufen.

### Von „Gegenständen“ und „Dosen“ zu Tokens und TeX

Nun müssen wir von unserer Analogie zu einer Beschreibung übergehen, die näher an TeXs Realität liegt. Zunächst sollte klar sein, dass wir statt verschieden farbiger Kreise in unseren imaginären Dosen auch an TeX-Tokens denken könnten: einfache Ganzzahlen. Das ist der leichtere Teil, wenn wir unsere Analogie in den Bereich der Software (TeX) übertragen. Aber was könnte das softwaretechnische Gegenstück zu unseren physischen nummerierten Dosen mit „Fächern“ sein?

Wir wollen nicht zu weit in Programmierkonzepte abdriften, aber du kannst dir unsere „Dosen“ als einige Bytes Computerspeicher vorstellen, die zu einer praktischen Speichereinheit „verpackt“ wurden. Die Verwendung einer numerischen Kennung für jede Dose kann als der Ort innerhalb des Computerspeichers betrachtet werden, an dem sich jedes kleine Speicherpaket befindet. In TeX selbst heißen diese kleinen Speichereinheiten „memory words“ — ein Begriff, der die Zeit/Ära widerspiegelt, in der TeX geschaffen wurde (1970er Jahre). Diese „memory words“ sind der grundlegende Baustein, der in TeX verwendet wird, aber wir müssen sie hier nicht weiter im Detail untersuchen — wer mehr wissen möchte, kann einen Artikel auf [dem persönlichen Blog des Autors](http://www.readytext.co.uk/?p=3537).

In der Programmiersprache gesprochen nennt man das, worüber wir gerade gesprochen haben, eine [*verkettete Liste*](https://en.wikipedia.org/wiki/Linked_list): Eine TeX-Tokenliste ist eine verknüpfte Liste, die aus TeXs Speicherbehältern aufgebaut ist, sogenannten *memory words* , wobei jedes memory word zum Speichern verwendet werden kann:

* a *Wert*: der Wert des Tokens (eine Ganzzahl);
* a *Verknüpfung*: der Speicherort des nächsten memory word, das das nächste Token in unserer Liste enthält.

## Wo verwendet TeX Tokenlisten?

Überall! Das stimmt, weil eine TeX-/LaTeX-Makrodefinition (z. B. ein LaTeX-Befehl) als (leicht spezialisierte) Form einer Tokenliste gespeichert wird — spezialisiert in dem Sinn, dass sie Tokens enthält, die du in „standardmäßigen“ Tokenlisten nicht siehst (bezogen auf das Abgleichen von Makroparametern usw.). Mach dir darüber keine Sorgen, denn wir werden auf diese Details in einem zukünftigen Artikel eingehen.

### Ein Beispiel für ein Makro

Ein Makro kann man sich als aus drei Teilen bestehend vorstellen:

```
\def\<Makroname><Parametertxt>{<Ersetzungstext>}
```

Beachte, dass anstelle von `\def` du auch verwenden könntest `\edef`, `\gdef` oder `\xdef`.

**Hinweis für LaTeX-Anwender**: Hier definieren wir Makros mit rohen, niedrigen TeX-Befehlen (genannt *Primitiven*). LaTeX-Anwender sind eher daran gewöhnt, Makros über LaTeXs `\newcommand` (das selbst ein Makro ist) zu erstellen.

Wenn du TeX darum bittest, ein Makro zu erzeugen (zu definieren), erstellt es ein Token, das die `<macro name>` und eine *Tokenliste* darstellt, welches die kombinierte `<parameter text>` und `<replacement text>`. TeX wird alles sorgfältig speichern, sodass das Token, das `<macro name>` darstellt, mit der Tokenliste verknüpft ist, die seine Definition repräsentiert (`<parameter text>` und `<replacement text>`).

Wenn wir zum Beispiel `\mymacro` es so verwenden:

```latex
\def\mymacro abc #1 defz{I typed "#1"!}
```

Wir können sehen, dass seine Bestandteile sind:

* `<macro name>` = `mymacro`
* `<parameter text>` = `abc #1 defz`
* `<replacement text>` = `Ich habe "#1" eingegeben!`

Zum Beispiel könntest du `\mymacro` es so verwenden:

```latex
\mymacro abc THIS TEXT defz
```

aufrufen, was zu `Ich habe "THIS TEXT" eingegeben!` gesetzt wird — `abc` und `defz` bei *nicht* wird nicht gesetzt. `abc` und `defz` sind Sequenzen von Zeichen-Tokens, die dazu verwendet werden, *abzugrenzen* den Makroparameter `#1` und werden absorbiert und verworfen, wenn dein Makroaufruf von TeX erfolgreich verarbeitet wurde.

Wenn du `\mymacro`definiert hast, dient das in der gespeicherten Form enthaltene Tokenmuster als „Vorlage“, anhand der TeX herausfinden kann:

* welche Tokens in deiner Eingabe die Trenn-Tokens sind;
* welche Tokens in deiner Eingabe tatsächlich den/die Parameter deines Makros bilden (hier das, was du für `#1` in deinem Aufruf von `\mymacro`).

Du musst `\mymacro` durch eine `<parameter text>` mit Trennzeichen aufrufen, die mit denen identisch sind, die zur Definition verwendet wurden — dazu gehört auch die Verwendung von Zeichen-Trennzeichen mit identischen Kategoriecodes. Wenn die Trennzeichen in `<parameter text>` zum Aufruf von `\mymacro` anders sind als die, die zur Definition verwendet wurden (die in der Erinnerung gespeicherte „Vorlage“), dann kann TeX ziemlich verwirrt werden — wenn es versucht, `\mymacro` zu verarbeiten, wäre es nicht in der Lage, die in seinem Speicher gespeicherte „Vorlage“ abzugleichen.

Wenn TeX sieht, dass du ein Makro aufrufst, durchsucht es deinen Eingabetext, um neue Tokens zu erzeugen, und versucht Token für Token, sie mit der als Teil der Makrodefinition gespeicherten Tokenliste `<parameter text>` Vorlage abzugleichen. Wenn die in deinem Eingabetext verwendeten Trennzeichen zu einer Reihe von Tokens führen, die nicht mit den in der „Vorlage“ gespeicherten übereinstimmen, wirft TeX normalerweise einen Fehler.

TeX ist sehr eigen — denke daran, dass Zeichen-Tokens eine Kombination aus Zeichenkodierung und Kategoriecode sind: Wenn du den Kategoriecode eines Zeichens änderst, erhältst du einen anderen Tokenwert, der aus diesem Zeichen resultiert.

Nehmen wir an, wir änderten den Kategoriecode von `z` auf zum Beispiel 12 — normalerweise ist er 11 — und versuchen, unser Makro so aufzurufen:

```latex
\catcode`z=12
\mymacro abc THIS TEXT defz more text here...
```

Diesmal wird es nicht funktionieren, weil der Kategoriecode von `z` geändert wurde. Du wirst einen Fehler wie diesen sehen:

```latex
Runaway argument?
THIS TEXT defz
! Absatz endete, bevor \mymacro vollständig war.
<wird erneut gelesen>
\par
l.22
```

Wenn TeX den `z` in `defz` liest und scannt, kann es ihn nicht als das Ende von `\mymacro`s `<parameter text>` erkennen, das in deiner Eingabedatei verwendet wurde. Bis zu dem fehlerhaften `z` hatte TeX die ersten 3 Zeichen korrekt abgeglichen `def` aber dieses `z` (mit Kategoriecode 12) bringt TeXs Scannen durcheinander. Nehmen wir an, `z` hatte einen Kategoriecode von 11, als wir *definiert* `\mymacro`haben: Das würde dazu führen, dass ein Tokenwert von 256×11 + 122 = 2938 als Teil der `\mymacro`s Definition gespeichert wird (d. h. als Teil der „Vorlage“ gespeichert). Mit Kategoriecode 12 jedoch `z` wird nun ein Tokenwert von 256×12 + 122 = 3194 erzeugen. Da der Tokenwert (für `z`) aus deiner Eingabe (Wert 3194) nicht mit dem `z`-Token übereinstimmt, das in der gespeicherten `<parameter text>` Tokenlisten-Vorlage (Wert 2938) enthalten ist, wird TeX deine Eingabe weiter scannen. TeX wird den Text, der nach deinem Makro folgt (*more text here* ...) weiter scannen, um zusätzliche Tokens zu suchen — dabei versucht es, die gespeicherte Vorlage mit den Tokens abzugleichen, die es in deiner Eingabe findet. Es wird wahrscheinlich nicht das richtige Muster von Tokens finden, und es kommt zu Fehlern, wenn TeX über dein Eingabestück „hinausschießt“ und fälschlicherweise zusätzlichen Text liest, um weitere Tokens zu erzeugen — diese zusätzlichen Tokens hätten zu diesem Zeitpunkt nicht gelesen werden dürfen und werden fast sicher einen Fehler erzeugen.

Wir werden später in einem zukünftigen Artikel genauer darauf eingehen.

## Weitere Verwendungszwecke von Tokenlisten

Weitere Befehle zum Erzeugen/Speichern von Tokenlisten sind:

```latex
\toks<n>={...}
\everypar={...}
\everymath={...}
\everydisplay={...}
\everyhbox={...}
\everyvbox={...}
\output={...}
\everyjob={...}
\everycr={...}
\errhelp={...}
```

Jeder dieser Befehle erzeugt aus den Zeichen und Befehlen innerhalb der Klammern ‚{...}‘ eine Tokenliste, und diese Tokenliste ist dafür gedacht, unter bestimmten Umständen wiederverwendet zu werden. Zum Beispiel `\everypar={...}` erzeugt und speichert einen Satz von Tokens (eine Tokenliste), die TeX kurz bevor es einen neuen Absatz beginnt in die Eingabe einfügt.

## Versteckte Verwendungen von Tokenlisten: Beispiele

In diesem letzten Abschnitt schauen wir uns einige praktische Beispiele dafür an, wie Tokenlisten auf eine Weise verwendet werden, die dich vielleicht überraschen.

### Beispiel 1: \uppercase{...} und \lowercase{....} — temporäre Tokenlisten

Zusätzlich zu expliziten Befehlen zum Erzeugen von Tokenlisten gibt es Umstände, unter denen TeX eine verborgene und temporäre interne Tokenliste erzeugt, um eine spezielle Verarbeitung durchzuführen. Denk daran: Wenn TeX deine Eingabezeichen/Befehle liest/verarbeitet, werden sie in Tokens umgewandelt — die grundlegenden Bausteine, mit denen TeX-Engines arbeiten.

Ein gutes Beispiel sind die Befehle `\uppercase{...}` oder `\lowercase{...}` denn ihre Funktionsweise kann auf den ersten Blick ziemlich verwirrend sein. Sobald du verstanden hast, was sie tun — tiefer im Inneren von TeX und für den Benutzer unsichtbar —, wird ihr Verhalten viel leichter verständlich.

Nehmen wir an, du hast eine einfache Reihe von Buchstaben, die du in Großbuchstaben umwandeln willst — z. B. abcde — und diese in ABCDE umwandeln möchtest. Nun, das ist mit TeXs `\uppercase` Befehl:

```latex
\uppercase{abcde}
```

veranlasst TeX, auszugeben `ABCDE`. Nun nehmen wir an, wir wollten unsere einfache Buchstabenreihe für später aufbewahren — d. h. wir wollen sie nicht sofort ausgeben, also verwenden wir TeXs einziges *internes* Mechanismus — nicht den externen (Datei-)Mechanismus — zum Speichern von Daten: Verwende eine Tokenliste. Das können wir tun, indem wir entweder ein Makro erstellen oder einen expliziten Tokenlistenbefehl verwenden:

```latex
\toks100={abcde}
\def\mychars{abcde}
```

Dann könntest du irgendwann beschließen, dass du deine Buchstabenreihe wiederverwenden möchtest, diesmal aber in Großbuchstaben; also versuchst du

```latex
\uppercase{\the\toks100}
```

und

```latex
\uppercase{\mychars}
```

Aber leider funktionieren beide nicht. Warum ist das so?

### Geheime Tokenlisten!

Um zu verstehen, wie die Befehle `\uppercase{...}` `\lowercase{...}` tatsächlich funktionieren, musste ich einen Blick in das Innenleben von TeX werfen, daher basiert die folgende Erklärung darauf.

Wenn TeX entweder `\uppercase{<Material>}` oder `\lowercase{<Material>}` in deiner Eingabe erkennt, ist das Erste, was TeX tut, eine (temporäre) interne Tokenliste aus dem `<Material>` zu erstellen, das zwischen den ‚{‘ und ‚}‘ steht, die nach den `\uppercase{...}` oder `\lowercase{...}` Befehlen folgen — diese temporäre Tokenliste gehört intern zu TeX.

Ein entscheidender Punkt, der zentral ist, um zu verstehen, wie `\uppercase{<Material>}` und `\lowercase{<Material>}` tatsächlich funktionieren, ist, dass alle Befehle oder Makros, die im `<Material>` nicht ausgeführt *expandiert*: Alles, was TeX tut, ist, Tokens aus Zeichen und Befehlen zu erzeugen, die zwischen `{...}`platziert werden. Während der Ausführung von `\uppercase{<Material>}` oder `\lowercase{<Material>}` wird nichts zwischen den Klammern ausgeführt: Es wird einfach in Tokens umgewandelt.

Nach den `<Material>` innerhalb der `{...}` in eine (temporäre) Tokenliste umgewandelt worden ist, betrachtet TeX anschließend jedes Token in dieser Liste erneut und prüft, ob es ein *Zeichen* Token oder ein *Befehl* Token ist (unter Verwendung des numerischen Werts des Tokens). Wenn TeX ein Zeichen-Token erkennt, verändert es dieses Token, um die Groß-/Kleinschreibung des Zeichens anzupassen (je nachdem, ob `\uppercase` oder `\lowercase` verarbeitet wird). TeX ignoriert einfach alle Befehls-Tokens und „schaut nicht in“ Befehls-Tokens hinein, um zu sehen, wofür sie stehen oder was sie enthalten (z. B. ein Makro, das Zeichen enthält) — sie werden einfach übersprungen: Nur Zeichen-Tokens werden bei Groß-/Kleinschreibungsoperationen tatsächlich verarbeitet/beeinflusst.

Wenn wir also zum Beispiel einen TeX-Befehl wie `\uppercase{abcde}` ausgeben, erstellt TeX eine Tokenliste aus `abcde` , die nur aus Zeichen-Tokens besteht: Sie werden alle angepasst, um eine Reihe von modifizierten Tokens zu erzeugen, die A, B, C, D und E darstellen. Diese modifizierten Tokens werden zurück in TeXs Eingabeprozessor eingespeist, was dazu führt, dass `ABCDE` gesetzt wird. Wenn wir jedoch unsere Zeichen *innerhalb eines Makros*gespeichert haben — zum Beispiel `\def\mychars{abcde}`— und versuchen, sie so in Großbuchstaben umzuwandeln:

```latex
\uppercase{\mychars}
```

dann schlägt es fehl und abcde wird gesetzt — nicht ABCDE, wie du vielleicht erwarten würdest. Wenn wir dann versuchen, unsere Zeichen in einer Tokenliste wie `\toks0={abcde}` speichern und `\uppercase{\the\toks0}` ausführen, dann `\uppercase` wird es wiederum fehlschlagen, weil die Tokenliste ausschließlich aus Tokens bestehen wird, die nicht von `\uppercase`.

Betrachten wir das Beispiel unseres Makros, `\mychars`, nachdem TeX `\uppercase` in der Eingabe erkennt, schaut TeX die Bedeutung von `\uppercase` nach und führt es aus, wobei es eine temporäre Tokenliste aus `{\mychars}`. Offensichtlich enthält diese temporäre Tokenliste nur ein Token, das kein Zeichen-Token ist, sondern eines, das unseren Makrobefehl `\mychars`: Daher wird dieses Token zum Zweck der Ausführung von `\uppercase`ignoriert —`\mychars` stellt kein Zeichen-Token dar. Wie oben angemerkt, nachdem `\uppercase` seine Arbeit getan hat, wird die temporäre Tokenliste (erzeugt durch die Aktion von `\uppercase`) zurück in TeXs vollständigen Eingabeverarbeitungs-(Scannen-)Mechanismus eingespeist. Wenn TeX diese Tokenliste erneut liest, erkennt es ein Token, das unser `\mychars` Makro darstellt, das TeX ausführt (expandiert) und eine Reihe von Zeichen erzeugt, die abcde setzen — weiterhin in Kleinbuchstaben, weil sie in einem Makro „eingepackt“ und daher für die Aktionen von `\uppercase`.

Sobald TeX die für `\uppercase{...}` oder `\lowercase{...}`erzeugte temporäre Tokenliste erneut untersucht und alle Zeichen-Tokens verarbeitet hat, wechselt es dann dazu, diese temporäre Tokenliste als Eingabequelle zu verwenden: das Setzen von Zeichen (verarbeitete Zeichen-Tokens) und das Ausführen von Befehlen und Makros.

### Wie lässt sich das beheben?

Da `\uppercase{...}` oder `\lowercase{...}` wird nur auf Zeichen-Tokens wirken, brauchen wir eine Möglichkeit, die „Verpackung“ der in unserem Makro `\mychars` enthaltenen Zeichen „aufzubrechen“ (oder in einem `\toks` Register enthaltenen Zeichen) bevor `\uppercase{...}` oder `\lowercase{...}` darauf wirkt. Mit „Aufbrechen der Verpackung“ meinen wir eigentlich TeXs Prozess des *Expansion*:

* Ersetzens eines TeX-/LaTeX-Befehls durch die *Folge* von Tokens *, aus denen dieser Befehl* (*z. B. ein Makro*) *besteht,* oder
* die Folge von Tokens zu erzeugen, die ein Befehl dazu bestimmt ist, *zu erzeugen*. Ein Beispiel für einen Befehl, der Tokens erzeugt, ist `\jobname`, der eine Reihe von Zeichen-Tokens erzeugt, die den Namen der gerade verarbeiteten Haupt-TeX-Datei darstellen.

#### Niedrigeres Niveau an Magie: scantoks(..., ...)

Hier dringen wir wirklich in einige dunklere Ecken von TeXs innerem Ablauf vor, also kannst du diesen Abschnitt ignorieren, wenn du die Details magst…

Nachdem TeX `\uppercase` oder `\lowercase` im Eingabestrom erkennt, führt es eine interne Funktion namens `scantoks(..., ...)` aus, deren Aufgabe es ist, die Tokenliste mithilfe der Einträge zwischen dem öffnenden ‚{‘ und dem schließenden ‚}‘ zu erzeugen — wie besprochen, wird diese Tokenliste anschließend untersucht, um etwaige Zeichen-Tokens zu erkennen (und dann anzupassen), damit die Groß-/Kleinschreibung der Zeichen wie erforderlich verändert wird. Beachte sorgfältig, dass wir uns hier auf `scantoks(..., ...)` als die interne Funktion beziehen, die in den Quellcode von TeX-Engines eingebaut ist — hier ist nicht der Name einer Steuersequenz gemeint.

Im Rahmen seiner Arbeit kann `scantoks(..., ...)` angewiesen werden, die Tokenliste, die es konstruiert, zu expandieren oder nicht zu expandieren, und für `\uppercase` und (`\lowercase`) expandiert es die Tokens nicht: Es erzeugt sie lediglich und legt sie in eine Tokenliste.

Eine der ersten Dinge, die `scantoks(..., ...)` tun muss, ist, nach einem öffnenden ‚{‘ (oder irgendeinem Zeichen mit `\catcode` 1) zu suchen, weil es sicherstellen muss, dass der Benutzer keinen Syntaxfehler gemacht und das öffnende ‚{‘ (oder irgendein Zeichen mit Kategoriecode 1) vergessen hat — denn ein Zeichen mit Kategoriecode 1 wird benötigt, um den Beginn einer zu tokenisierenden Liste von Einträgen abzugrenzen.

Und hier ist der Trick: Die Aufgabe, nach einem öffnenden ‚{‘ zu suchen, löst `scantoks(..., ...)` dazu aus, TeXs Erweiterungsprozess auszuführen, was bedeutet, dass die folgenden Beispiele funktionieren werden:

```latex
\let\ob={
\uppercase\ob abcde}
\def\obb{\ob}
\uppercase\obb xyz}
```

Nehmen wir das Beispiel von `\obb`, einem Makro, es wird als *expandierbarer Befehl* erkannt und von TeX (über die `scantoks(..., ...)` Funktion) beim Suchen nach einer öffnenden Klammer (jedes Zeichen mit Kategoriecode 1) ordnungsgemäß expandiert. Das bedeutet, dass wir den „`\expandafter` Trick“ verwenden können, um unser Ziel zu erreichen, unsere Zeichen aus den Grenzen unseres Makros „auszupacken“ — d. h. es zu expandieren. Beachte, dass `\expandafter` ebenfalls in die Kategorie eines *expandierbarer Befehl*fällt, also setzt TeX es hier ein und lässt es seine Arbeit tun, während nach einem öffnenden ‚{‘ (oder einem beliebigen Zeichen mit Kategoriecode 1) gesucht wird.

Also, wenn du definierst:

```latex
\toks0={abcde}
\def\mychars{abcde}
```

Und das hier tust:

```latex
\uppercase\expandafter{\mychars}
\uppercase\expandafter{\the\toks0}
```

wirst du in beiden Fällen jetzt ABCDE gesetzt sehen, weil das `\expandafter` das „Auspacken“ (die Expansion) von `\mychars` und `\the\toks0`veranlasst — beide führen dazu, dass `\uppercase` einen Strom von Zeichen-Tokens sieht, die sie verarbeiten können, um die Groß-/Kleinschreibung zu ändern.

### Beispiel 2: \string — mehr temporäre Tokenlisten

Intern ordnet TeX `\string` es als einen seiner sogenannten „convert“-Befehle ein: die Operation „in Text umwandeln“ auszuführen. Der `\string` Befehl ist dafür gedacht, ein Token in eine menschenlesbare Textversion umzuwandeln – d. h. die menschenlesbare Zeichenkette zu setzen, aus der dieses Token ursprünglich erzeugt wurde.

Zum Beispiel `\string\hello` erstellt eine temporäre Tokenliste, die die Zeichen \\, h, e, l, l, o enthält — ja, sogar einschließlich des anfänglichen ‚\‘. Sobald diese Tokenliste erstellt wurde, wird sie von TeX erneut eingelesen, und der Text des Befehls „`\hello`“ wird gesetzt — ja, einschließlich ‚\‘, wenn Sie die richtige Schrift wählen…

Sie fragen sich vielleicht, wie/warum TeX das Escape-Zeichen setzen kann, obwohl es gewöhnlich dazu verwendet wird, den Scanner von TeX dazu zu bringen, ein Befehls-Token zu erzeugen: Warum tut es das hier nicht? Die Antwort hat mit Kategoriencodes zu tun: Normalerweise hat ein ‚\‘-Zeichen die Catcode 0 (Escape-Zeichen), aber wenn `\string` es seine interne Tokenliste erzeugt, macht es etwas ein wenig anders. Wenn es eine Zeichen-Tokenliste erstellt, weist es allen Zeichen außer dem Leerzeichen den Kategoriencode 12 zu; dem Leerzeichen wird Catcode 10 zugewiesen — denken Sie daran, dass Zeichentokens aus 256 × Catcode + ASCII-Wert berechnet werden. Wenn TeX also die temporäre Tokenliste, die `\string` erzeugt wurde aus `\hello`, TeX *kein Escape-Zeichen sieht* weil das Token für ‚\‘ mit einem Catcode 12 und nicht 0 berechnet wurde: TeX behandelt ‚\‘ einfach als normales Zeichen und setzt es.

Genau genommen sollten wir wahrscheinlich anmerken, dass TeX beim Erkennen von Escape-Zeichen im Eingabestrom nicht tatsächlich ein Token für sie erzeugt. Sobald es ein Zeichen mit dem Kategoriencode 0 erkannt hat, wird dieses Zeichen lediglich dazu verwendet, das Erzeugen eines Kontrollsequenz-Tokens „auszulösen“: Sobald es TeX dazu veranlasst hat, hat das Escape-Zeichen seine Arbeit getan und wird nicht mehr berücksichtigt.

### Technischer Hinweis

Ein Befehl namens `\showtokens{...}` (eingeführt von der e-TeX-Engine) kann Tokenlisten anzeigen (in der Logdatei). Aus dem e-TeX-Handbuch:

> Der Befehl `\showtokens{<token list>}` zeigt die Tokenliste an und ermöglicht die Anzeige von Größen, die nicht angezeigt werden können von `\show` oder `\showthe`, z. B.:
>
> ```latex
> \showtokens\expandafter{\jobname}
> ```

## Abschließend

In Abschnitt 291 des TeX-Quellcodes (siehe Seite 122 von [TeX: The Program](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373)) beschreibt Knuth eine Tokenliste wie folgt:

> „Eine Tokenliste ist eine einfach verkettete Liste von Ein-Wort-Knoten im Speicher, wobei jedes Wort ein Token und einen Verweis enthält. Makrodefinitionen, Definitionen der Ausgaberoutine, Marken, `\write` Texte und einige andere Dinge werden von TeX in Form von Tokenlisten gespeichert, denen gewöhnlich ein Knoten mit einem Referenzzähler in seinem Feld „token\_ref\_count“ vorangestellt ist.“

Beim ersten Lesen war das vielleicht nicht leicht zu verstehen, aber hoffentlich ergibt es jetzt etwas mehr Sinn.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://overleaf-pro.ayaka.space/latex/de/ausfuhrliche-artikel/54-what-is-a-tex-token-list.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
