> 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/no/dybdeartikler/53-what-is-a-tex-token.md).

# Hva er et «TeX-token»?

## Motivasjon for en serie om TeX-tokens og beslektede konsepter

Motivasjonen og metodikken som brukes for å lage en serie artikler om TeX-tokens og beslektede konsepter, diskuteres i denne artikkelen [En ny artikkelserie: TeX-tokens og beslektede begreper—men hvorfor (og hvordan)?](https://www.overleaf.com/blog/521-a-new-series-of-articles-tex-tokens-and-related-concepts-but-why-and-how) Som nevnt i den artikkelen bygger vi gjennom hele denne serien diskusjonene og forklaringene våre på innsikter vi har fått gjennom en egenkompilert versjon av Knuths opprinnelige TeX-program—som brukes til å produsere en serie artikler som har som mål å gi enkle beskrivelser og lettfattelige forklaringer av sentrale TeX-begreper.

## Innledning: hva er målet vårt?

I denne artikkelen finner vi ut nøyaktig hva en TeX-token er ved å følge prosesseringsreisen fra tegn i inndatafilen til den faktiske opprettelsen av TeX-tokens. I praksis er det ganske komplekst, så vi har redusert prosessen til dens kjerneessens, med mål om å gjøre den enkel å følge og forstå samtidig som den tekniske nøyaktigheten bevares.

Vi begynner med å introdusere noen viktige interne TeX-begreper: *primitivene*, *kommandokoder* og *kommandomodifikatorer*. Derfra bruker vi et veldig enkelt makroeksempel for å se nøyaktig hvordan TeX prosesserer kommandoen `\def` og den resulterende tokenen som TeX oppretter for å representere den kommandoen.

Vi avslutter med en kort titt på hvordan TeX oppretter tokens for å representere tegn, og hvordan et tegns `\catcode` blir faktisk permanent knyttet til en tegn-token—noe som ofte nevnes i bøker om TeX, men her ser vi nøyaktig hvordan det oppnås.

Følgende grafikk viser reisen vi skal oppsummere—fra inndatatekst til TeX-tokens:

![Reisen fra TeX-inndata til TeX-token.](/files/7879d9299f994f22f05d1e7bf4fd3231cf46a939)

## Men først: primitiver og kommandokoder

Hver TeX-motor (Knuthian TeX, pdfTeX, XeTeX, LuaTeX) forstår en rekke innebygde kommandoer: de såkalte *primitivene*—de grunnleggende byggekloss-kommandoene som ligger til grunn for TeXs programmerbarhet. De kalles «primitive» fordi de, i motsetning til brukerdefinerte makroer, ikke er konstruert av andre kommandoer og ikke kan brytes ytterligere ned til enklere instruksjoner. I Knuths TeX finnes det omtrent 320 primitiver—selv om vi bør merke at andre TeX-motorer som pdfTeX, XeTeX og LuaTeX alle har lagt til nye kommandoer til Knuths opprinnelige program og vil inneholde primitiver som ikke finnes i Knuths TeX-programvare.

Internt tildeler TeX en numerisk *kommandokode* til alle kommandoer—enten de er brukerdefinerte makroer eller innebygde primitiver. Disse kommandokodene er ikke tilgjengelige for TeX-brukeren; de er ganske enkelt en del av den interne mekanikken i TeXs prosessering, men det er nyttig å kjenne til dem for senere diskusjon av TeX-tokens.

Grupper av kommandoer med beslektet funksjonalitet deler samme kommandokode. For eksempel har de `\def`, `\gdef`, `\edef` og `\xdef` primitive kommandoene alle brukes til å definere makroer og deler kommandokoden 97 (i Knuths TeX). Tydeligvis oppretter disse fire makrodefinisjonskommandoene hver sin makro på litt forskjellige måter; følgelig trenger TeX under prosesseringen en måte å skille mellom dem på.

En kommandokode alene (som 97) kan ikke fortelle deg hvilken makroopprettelseskommando det er snakk om; så, som du kanskje forventer, blir hver TeX-kommando tildelt en ekstra opplysning kalt dens *kommandomodifikator* (se eksemplene nedenfor).

### Kommandomodifikatorer: to typer

Kommandomodifikatorer faller i to kategorier som vi vil omtale som «Type 1» og «Type 2»—TeX bruker ikke denne terminologien, det er bare praktisk å gjøre det slik her:

* **Type 1**: Enkle heltallsverdier som TeX, om nødvendig, kan bruke til å skille mellom kommandoer som deler samme kommandokode.
* **Type 2**: En heltallsverdi som er en numerisk plassering i TeXs minne og forteller TeX hvor det må gå for å slå opp informasjon om den kommandoen. For eksempel gjelder dette brukerdefinerte kommandoer (makroer), der kommandomodifikatoren forteller TeX hvor makrodefinisjonen er lagret i minnet.

#### Type 1-kommandomodifikatorer (et eksempel)

Som nevnt har de fire primitive kommandoene for å definere makroer i Knuths TeX: `\def`, `\gdef`, `\edef`, `\xdef` alle kommandokoden 97: de skilles fra hverandre gjennom kommandomodifikatorene sine, som er oppført i følgende tabell:

| Kommando | <p>Kommando<br>kode</p> | <p>Kommando<br>modifikator</p> |
| -------- | ----------------------- | ------------------------------ |
| `\def`   | 97                      | 0                              |
| `\gdef`  | 97                      | 1                              |
| `\edef`  | 97                      | 2                              |
| `\xdef`  | 97                      | 3                              |

Som et andre eksempel bestemte Knuth seg for å implementere kommandoene `\openout`, `\write`, `\closeout`, `\special`, `\immediate` og `\setlanguage` som «utvidelser» til TeX, kun for å vise hvordan du kan legge til nye primitiver i TeX. I dette tilfellet deler ikke disse kommandoene egentlig «lignende funksjonalitet» bortsett fra at Knuth bestemte seg for å gruppere dem sammen for å forklare hvordan TeX kan utvides. Disse seks kommandoene klassifiseres som «utvidelser» og grupperes sammen med kommandokodeverdien 59, men hver av dem har en passende kommandomodifikator for å skille den fra de andre:

| Kommando       | <p>Kommando<br>kode</p> | <p>Kommando<br>modifikator</p> |
| -------------- | ----------------------- | ------------------------------ |
| `\openout`     | 59                      | 0                              |
| `\write`       | 59                      | 1                              |
| `\closeout`    | 59                      | 2                              |
| `\special`     | 59                      | 3                              |
| `\immediate`   | 59                      | 4                              |
| `\setlanguage` | 59                      | 5                              |

#### Type 2-kommandomodifikatorer (en kort forklaring)

Selv om alle kommandomodifikatorer er heltall, trenger Type 2-modifikatorer litt mer forklaring. Disse kommandomodifikatorene omtales i TeX som «pekere» fordi de peker til en plassering i minnet hvor TeX kan finne tilleggsinformasjon for den kommandoen. Dette kan høres litt vagt ut, men måten TeX bruker disse pekerne til å slå opp informasjon på er ganske variert, og en fyldigere forklaring ville avlede fra hovedmålet med denne artikkelen. Ett eksempel kan hjelpe: makroer. Når en makrokommando er definert, må TeX lagre erstatningsteksten et sted i minnet. Som vi skal se nedenfor, har brukerdefinerte makroer kommandokoder mellom 111 og 114, med en kommandomodifikator som er en peker inn i minnet og forteller TeX hvor erstatningsteksten (makrodefinisjonen) er lagret.

### Kommandokoder: ekspanderbare og ikke-ekspanderbare

I Knuths kildekode til TeX varierer kommandokodene fra 0 til 120—merk at noen koder innenfor dette området kun er for spesialisert intern bruk og ikke er tildelt kommandoer som er tilgjengelige for brukeren. Det er verdt å merke seg at andre TeX-motorer som pdfTeX, XeTeX og LuaTeX alle har lagt til nye kommandoer i Knuths opprinnelige sett og vil inneholde flere primitiver og tilsvarende kommandokoder; prinsippene som skisseres her er imidlertid grunnleggende for alle TeX-baserte motorer som er avledet fra Knuths kildekode.

Samlingen av kommandokoder er delt inn i to hovedsett:

* *ikke-ekspanderbare kommandoer*: har kommandokoder mindre enn eller lik 100;
* *ekspanderbare kommandoer*: har kommandokoder større enn 100, opptil en maksimalverdi på 120. Området 101 til 120 inkluderer brukerdefinerte makroer pluss kommandoer som `\csname`, `\expandafter` og `\the`.

Ikke-ekspanderbare kommandoer utfører vanligvis tildeling av en verdi til en intern parameter eller produserer direkte materiale som kan settes. Ekspanderbare kommandoer «injiserer» vanligvis en strøm av tokens inn i TeXs aktuelle prosesseringsaktivitet eller endrer rekkefølgen på tokenbehandlingen.

Som nevnt ovenfor får alle makroer (brukerdefinerte kommandoer) kommandokoder mellom 111 og 114: de ulike verdiene gjenspeiler om makroen ble definert som `\long`, `\outer`, begge deler eller ingen av delene. Her er et eksempel:

| Makrotype             | Eksempel                       | Kommentar                  |
| --------------------- | ------------------------------ | -------------------------- |
| Ikke-lang, ikke-ytter | `\def\ohyeah{....}`            | `\ohyeah` kommandokode=111 |
| Lang, ikke-ytter      | `\long\def\ohyeah{....}`       | `\ohyeah` kommandokode=112 |
| Ikke-lang, ytter      | `\outer\def\ohyeah{....}`      | `\ohyeah` kommandokode=113 |
| Lang, ytter           | `\long\outer\def\ohyeah{....}` | `\ohyeah` kommandokode=114 |

Som en påminnelse om kommandomodifikatorer: når en makro er definert, vil TeX lagre makroens definisjon på et sted i minnet; denne plasseringen (en peker) blir kommandomodifikatoren for makrokommandoen, som vil bli lagret med en kommando mellom 111 og 114 avhengig av hvordan den ble definert. Selve navnet som tildeles en brukerdefinert makro spiller egentlig ingen rolle: etter at inndata er prosessert, vil de alle få tildelt en kommandokode som varierer fra 111–114, og til slutt blir alle kommandoer som TeX leser fra inndataene dine, enten de er primitiver eller brukerdefinerte makroer, til slutt konvertert til en numerisk representasjon kalt en *tokenet*.

## Reisen fra inndatatekst til TeX-tokens

I denne delen bruker vi et veldig enkelt makroeksempel for å se nøyaktig hvordan TeX prosesserer kommandoen `\def` for å opprette en token som representerer `\def` kommandoen. TeXs detaljerte prosesseringsaktivitet kan være ekstremt kompleks, så vi bruker ikke makroparametere eller skilletegn fordi det ville legge til kompleksitet og avlede fra reisen vår.

Anta at TeX-inndatafilen din inneholder følgende linje:

```latex
\def\ohyeah{Overleaf is cool!}
```

Når TeX begynner å prosessere denne linjen med inndata, sjekker det `\catcode` for hvert tegn og ser at det første tegnet er `\` (første tegn i `\def`). Den oppdager (slår det opp i en intern tabell) at `\` har `\catcode` 0, noe som betyr at det innleder starten på en *kontrollsekvens*. Selvfølgelig kan du omdefinere ethvert tegn til å ha `\catcode` 0, men vi antar at konvensjonelle definisjoner av plain TeX eller LaTeX brukes.

Strengt tatt har begrepet *kontrollsekvens* to underkategorier: *kontrollord* og *kontrollsymbol*:

* *kontrollord*: en sekvens av tegn med `\catcode` bokstav (11);
* *kontrollsymbol*: et enkelt tegn hvis `\catcode` er *inneholder* bokstav (11).

På dette tidspunktet har den `\` tegnet gjort jobben sin og er nå ferdig med den. Ved å oppdage et escape-tegn er TeXs respons å begynne å lese alle påfølgende tegn i inndataene med sikte på å oppdage et kontrollord eller et kontrollsymbol.

Etter det innledende `\`oppdager TeX umiddelbart den `d`: et tegn hvis `\catcode` er 11, noe som forteller TeX at det har funnet den første bokstaven i et *kontrollord*. Det fortsetter å skanne påfølgende tegn til det til slutt oppdager et tegn som *ikke* har `\catcode` bokstav (11). Alle påfølgende tegn (etter den innledende `\`) med `\catcode` 11 (bokstav) anses å danne navnet på et kontrollord: dvs. navnet på en kommando—kanskje en makro eller en primitiv, men TeX vet ennå ikke hvilken type kommando det er. På dette tidspunktet er det ganske enkelt en tegnstreng.

Så, i vårt eksempel skanner TeX fornøyd videre og sjekker hvert tegn, helt til det når den innledende `\` på `\ohyeah` som også har `\catcode` 0. TeX erkjenner at det har skannet for langt og returnerer høflig den `\` tilbake til tekststrømmen slik at den blir det neste tegnet som sees ved videre skanning av teksten. På dette tidspunktet har TeX identifisert en streng (`def`den innledende `\catcode` 11 (`d`, `e` og `f`). Det TeX nå må gjøre er å finne ut hva `def` betyr: hva gjør det? Som du kanskje har gjettet, trenger TeX å finne kommandokoden og kommandoidentifikatoren for `def` slik at det kan finne ut hva det skal gjøre med denne kommandoen.

## Å lage en hash av det

Etter å ha oppdaget et kontrollord (`def`), er det første TeX gjør å «konvertere» tegnstrengen (`def` i vårt eksempel) til et heltall ved å bruke noe som kalles en hashfunksjon. Vi trenger ikke bekymre oss for detaljene; en oversikt holder. I praksis ser TeX på hvert tegn i kontrollordet det nettopp har oppdaget og bruker ASCII-kodeverdien (eller Unicode-verdien for XeTeX/LuaTeX) til hvert tegn for å beregne et tall kalt en hashverdi: det er bare et enkelt heltall.

Som en del av denne hashberegningsprosessen vil TeX også sjekke om tegnstrengen i det nyoppdagede kontrollordet allerede er kjent for det. Den lesbare teksten til alle kommandoer, enten de er primitiver eller brukerdefinerte makroer, lagres i et internt lagringsområde kalt *strengpoolen*. TeX må gjøre dette fordi det kan trenge å skrive ut det lesbare navnet på en kommando—for eksempel når TeX trenger å rapportere en feil og oppgi navnet på den aktuelle kommandoen. For eksempel vil makroen vår `\def\ohyeah{Overleaf is cool!}` definerer en ny kommando kalt `\ohyeah` og TeX vil (på et senere stadium) ikke bare måtte beregne en hashverdi for `ohyeah` (*uten* den innledende `\` tegnet) men også lagre tekststrengen (lesbar form) i tilfelle den trenger å bruke den til feilrapportering (eller andre oppgaver).

Hvis du vil ha mer detaljer om TeXs prosesser for strenghåndtering, har jeg skrevet om dette på min [personlige bloggside](http://www.readytext.co.uk/?p=3590).

Det endelige resultatet er at tegnstrengen som representerer kommandoen `def` blir gjort om til den numeriske verdien 1218 (det er den faktiske verdien TeX beregner). På dette tidspunktet er de enkelte tegnene `d`, `e` og `f` ikke lenger en del av hovedhistorien—de er lest fra inndataene og har gjort jobben sin: fra nå av handler alt om heltall og *tokens*—vi skal snart se hva en token faktisk er! Internt omtaler TeX disse hashverdiene som *gjeldende kontrollsekvens* men i kildekoden forkortes dette til en variabel kalt `curcs`. TeXs kildekode er full av veldig korte, ofte ganske kryptiske, variabelnavn.

Men hva gjør TeX *egentlig* med denne nybakte heltallsverdien 1218? Hvordan finner TeX ut at den opprinnelige strengen `def`, nå representert ved heltallet 1218, faktisk viser til en instruksjon om å definere en makro? Svaret er at TeX har et slags internt «arkivskap» der det lagrer den gjeldende betydningen og verdien til hver kommando det for øyeblikket kjenner til—enten kommandoen er en brukerdefinert makro eller en innebygd primitiv. Grunnen til at TeX tok seg bryet med å konvertere `def` til hashverdien 1218 (nå lagret i variabelen kalt `curcs`) er å bruke den til oppslag i *betydning* på `def`. TeX vil selvfølgelig gjenta denne hashberegningsøvelsen for alle kontrollord det oppdager i inndataene—selvfølgelig gir ulike kontrollord forskjellige heltallsverdier fra hashfunksjonen: det er hele poenget.

TeXs interne «arkivskap» kalles *ekvivalenstabellen* og er temaet for neste seksjon.

### Oppslag i ekvivalenstabellen

La oss oppsummere og se hva vi har lært så langt:

* `\` innleder starten på en kontrollsekvens (enten en *kontrollsymbol* eller en *kontrollord*).
* Hvis det første tegnet etter `\` har `\catcode` 11 (bokstav), er det starten på et *kontrollord*.
* For *kontrollord* TeX skanner for å kontrollere alle påfølgende inndatategn som har `\catcode` 11, og vil stoppe skanningen så snart det finner det første tegnet som ikke *inneholder* har en `\catcode` verdi på 11.
* Tegnstrengen i inndataene (etter `\`) som har `\catcode` 11 anses å være et *kontrollord* som brukeren har skrevet: en kommando som ber TeX om å «gjøre noe».
* For å begynne prosessen med å «gjøre noe» konverterer TeX tegnstrengen i kontrollordet til et heltall. Det gjør dette ved hjelp av en såkalt hashfunksjon som gir et heltall som utdata.
* Heltallet (den beregnede hashverdien) omtales som *gjeldende kontrollsekvens*gjeldende kontrollsekvens `curcs`.
* I vårt eksempel blir kontrollordet `def` omgjort til verdien 1218—som lagres i en variabel kalt `curcs`: dvs., `curcs=1218`.

TeX må nå finne ut hva den nyoppdagede *gjeldende kontrollsekvens* egentlig betyr—hva gjør TeX med den?

#### En merknad om gruppering: behovet for å lagre og gjenopprette informasjon

Her tar vi en liten avstikker for å minne oss selv om at TeX har evnen til å lagre og gjenopprette informasjon: dvs. det har en form for innebygd «hukommelse».

Alle som har skrevet selv den enkleste makro bør være klar over TeXs grupperingsmekanisme—for eksempel ved å bruke `\def` for å opprette makroer innenfor en gruppe. Med mindre du bruker `\global` prefikset `\def`-opprettede makroer definert innenfor en gruppe, varer verdien eller betydningen av den makroen bare innenfor den gruppen (og undergruppene under den): definisjonen går tapt når gruppen er avsluttet. For eksempel, hvis du definerer en enkel makro inne i en gruppe, slik:

```latex
{\def\foo{Hello}}
```

og prøver å bruke `\foo` utenfor gruppen

```latex
{\def\foo{Hello}}% \foo definert innenfor en gruppe (merk: ingen bruk av \global)
\foo %<--- ikke lenger definert, nå udefinert
```

får vi den velkjente feilen: `Undefined control sequence`. `\foo` har bare betydning innenfor gruppen (og undergruppene) den ble definert i. Videre, når du omdefinerer en makro inne i en gruppe, kan den nye verdien gå tapt når gruppen avsluttes, og den tidligere betydningen (som eksisterte utenfor gruppen) blir gjenopprettet.

```latex
\def\foo{Goodbye}
\foo\par% Gir Goodbye
{\def\foo{Hello}% Omdefinert innenfor en gruppe:
{Innenfor gruppe på 2. nivå: \foo\par}}% Brukt innenfor gruppe på 2. nivå: \foo gir Hello
Utenfor gruppen er den gamle verdien gjenopprettet: \foo\par% Gir Goodbye
```

Formålet med disse enkle eksemplene er å peke på at TeX har en slags «lagringsmekanisme» eller «hukommelse» som lagrer/gjenoppretter kommandoers «betydning»—og det gjør det, selvfølgelig. Vi antydet dette i forrige avsnitt: den «lagringsmekanismen» eller det «arkivskapet» er en stor intern tabell kalt *ekvivalenstabellen*. Det er der TeX lagrer den nåværende betydningen eller verdiene til alle kommandoene det for øyeblikket kjenner til—de innebygde primitiver og brukerdefinerte makroene.

### Ekvivalenstabellen: ved analogi

For å forklare ekvivalenstabellen går vi frem ved analogi. Vi fortsetter å bruke forestillingen om et arkivskap med tusenvis av små skuffer, hver merket med et unikt heltall. På dette stadiet i prosesseringen sier TeX i praksis:

«OK, jeg har denne heltallsverdien 1218 som jeg nettopp beregnet og lagret i en variabel kalt `curcs`. Jeg må nå finne ut hva den betyr: for å gjøre det går jeg og ser i skuff nummer 1218 i arkivskapet mitt for å se hva som står der.»

TeX bruker 1218 til å finne riktig skuff, og der finner det en liten lapp som inneholder tre opplysninger med navnene som brukes i TeXs kildekode:

* **`eq_level:`** grupperingsnivået denne oppføringen ble definert på (nivå 1 = globalt definert). Vi så virkningene av grupperingen i aksjon ovenfor: her i ekvivalenstabellen er det denne informasjonen om grupperingsnivå som lagres;
* **`eq_type:`** kommandokoden for denne oppføringen;
* **`equiv:`** gjeldende «verdi» for denne oppføringen—den kan være et enkelt heltall som kommandomodifikatoren nevnt ovenfor, eller en peker til et område i minnet; for eksempel minneplassen for samlingen av tokens som representerer en makrodefinisjon.

Så, vår hashverdi på 1218 (lagret i variabelen `curcs`) har i praksis blitt brukt som *nøkkelen* for å få tilgang til en skuff som inneholder den nåværende betydningen og verdien av kommandoen vi opprinnelig skrev inn som tegnstrengen `\def`.

Innen kildekoden til TeX-programmet blir `eq_type` for enhver kommando lagret ved hjelp av en variabel kalt `curcmd` og verdien av `equiv` lagres i en variabel kalt `curchr`.

### Hva sier ekvivalenstabellen om def?

Som nevnt lagres hashverdien som beregnes for enhver kommando i en variabel kalt `curcs`; dermed for `def` har vi `curcs=1218`. Ved å se på plassering 1218 i ekvivalenstabellen vil TeX finne følgende informasjon:

* `curcmd`=97. Dette er kommandokoden for `\def`;
* `curchr`=0. Dette er kommandomodifikatoren for `\def`.

`\def` er en primitiv (innebygd) TeX-kommando, og med mindre den har blitt omdefinert et sted, bør den tredje og siste opplysningen være `eq_level=1` som indikerer at betydningen av `\def` er definert globalt og ikke begrenset til et lavere grupperingsnivå. Internt spiller verdien av `eq_level` knyttet til en kommando en ekstremt viktig rolle i TeXs grupperingsmekanisme, men vi skal ikke gå nærmere inn på dette.

Følgende grafikk oppsummerer forklaringen vi har gått gjennom:

![Reisen fra TeX-inndata til TeX-token.](/files/7879d9299f994f22f05d1e7bf4fd3231cf46a939)

## TeX-tokens for kommandoer

Etter å ha jobbet oss gjennom forklaringene ovenfor, viser selve beregningen av TeX-tokens for kontrollsekvenser seg å være svært enkel. TeX bruker verdien av `curcs` (1218) fra hashfunksjonen for å lage et enkelt heltall som det kaller en *tokenet*token. `curcs` er:

```c
curtok = 4095 + curcs
```

TeX lagrer verdien av den aktuelle tokenen (den som nylig er beregnet) i en variabel kalt `curtok`.

Så, som konklusjon, er TeX-tokenen som representerer `\def` kommandoen er `4095 + 1218 = 5313`. Og det er alt for TeX-tokens som representerer kommandosekvenser: de er ganske enkelt et heltall som er beregnet fra en hashtabellverdi pluss 4095.

## TeX-tokens for tegn

Når TeX trenger å opprette en token som representerer et tegn, bruker det følgende, like enkle, beregning:

```c
curtok = 256*catcode + (ASCII-verdien til tegnet)
```

Merk at noe forskjellige beregninger brukes for Unicode-bevisste motorer som LuaTeX.

For eksempel er TeX-tokenen som representerer et mellomromstegn med `\catcode` catcode 10 og ASCII-verdi 32 er:

```c
256*10 + 32 = 2592
```

### Tokenlister som inneholder tegn

Når du oppretter en enkel tokenliste med for eksempel,

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

vil TeX opprette følgende liste over tokens og lagre dem i minnet for senere bruk:

* H→ 256 × 11 + 72 = 2888
* e→ 256 × 11 + 101 = 2917
* l→ 256 × 11 +108 = 2924
* l→ 256 × 11 +108 = 2924
* o→256 × 11 + 111 = 2927

Merk at disse tokensene kombinerer hvert tegns ASCII-kode og verdien av dets `\catcode`catcode på det tidspunktet de blir gjort om til tokens (tokenisert). Når tegn er blitt konvertert til tegn-tokens, er `\catcode` verdien som er knyttet til dem, permanent og lagres i tokensene for senere bruk når brukeren for eksempel sier, `\the\toks100`.

Som nevnt beregnes en tegn-token fra `256*catcode + (ASCII-verdi)` mens en kontrollsekvens-token beregnes fra `4095 + curcs` der `curcs` er hashverdien til kontrollordet (tekststrengen til en kommando skrevet inn av brukeren) som TeX oppdager i inndataene. Det er verdt å merke seg at tegn-tokens alltid er mindre enn 4095. Derfor kan TeX lett avgjøre om en bestemt token representerer en kontrollsekvens (en kommando) eller et tegn, og deretter finne ut hvilken kontrollsekvens eller hvilket tegn, og `\catcode` par som er kodet inn i den tokenen.


---

# 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/no/dybdeartikler/53-what-is-a-tex-token.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.
