> 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/da/dybtgaende-artikler/51-unicode-utf-8-and-multilingual-text-an-introduction.md).

# Unicode, UTF-8 og flersproget tekst: En introduktion

## Unicode og OpenType: tegn og glyffer

Moderne TeX-motorer, dvs. XeTeX og LuaTeX, har udviklet sig fra Knuths oprindelige TeX-motor i høj grad på grund af behovet for at holde trit med udviklingen i det teknologiske landskab, især Unicode (for tekst) og OpenType (for skrifttyper). I dag kan LaTeX-brugere gennem brugen af pakker som [fontspec](https://ctan.org/pkg/fontspec?lang=en) og [unicode-math](https://ctan.org/pkg/unicode-math?lang=en), kan LaTeX-brugere få adgang til ekstremt sofistikerede sætningsevner, som OpenType-skrifttyper giver—herunder avanceret flersproget sætning og OpenType-baseret matematiksætning ([pioneret af Microsoft](https://blogs.msdn.microsoft.com/murrays)).

Men for at få det fulde udbytte af at bruge OpenType-skrifttyper med XeTeX/LuaTeX kan det være nyttigt at blive fortrolig med en række baggrundsemner/koncept­er—især hvis man skal fejlfinde problemer eller bane vejen for mere avanceret/komplekst arbejde. For eksempel kan man læse om, at XeTeX- og LuaTeX-motorerne bruger “UTF-8-input”, eller at de er “Unicode-bevidste”, og yderligere læsning om OpenType-skrifttyper kan handle om eller nævne emner som “Unicode-kodning”, OpenType-“skriftfunktioner”, “glyffer”, “glyf-id’er”, “glyfnavne” og så videre. Vores mål er at give en introduktion til disse begreber/emner og samle en grundlæggende ramme, der viser, hvordan de hænger sammen og forhåbentlig giver støtte til videre arbejde eller problemløsning.

De emner, vi sigter mod at dække, falder ret pænt ind i to hovedområder: *Unicode* som i praksis lever i tekstens/tegnenes og tekstkodningens verden og *OpenType* hvis verden er en af skrifttyper og glyffer; men naturligvis er de to verdener forbundne, og der er noget overlap, selv i denne første artikel.

### Hvilke emner skal vi diskutere?

Hovedfokus i denne artikel er nogle Unicode-relaterede emner: vi starter med en diskussion af, hvad der menes med et “tegn”, og går videre til at introducere skrifter/sprog, Unicode-kodning og UTF-8—sammen med et eksempel på arbejde med flersprogede tekstfiler. En opfølgende artikel vil bygge videre på dette stykke for at dække baggrundsemner relateret til OpenType-skrifttype-teknologi. Det er klart, at det inden for rammerne af et blogindlæg ikke er muligt at forsøge et “dybt dyk” ned i alle de områder, vi håber at diskutere: vores erklærede mål er at give den overordnede ramme, der viser, hvordan nogle få nøglebegreber hænger sammen og fungerer sammen. Vi begynder med det mest grundlæggende begreb: det *tegn*.

## Tegnet: en grundlæggende byggesten

En grundlæggende idé/begreb, som er kernen i vores diskussioner (og i Unicode), er betydningen af et “tegn”: det er et af de ord, hvis betydning ofte “tages for givet” gennem dets brug i dagligdags arbejde og samtaler. Men set fra Unicode, sætning og skrifttype-teknologiers perspektiv er vi nødt til at være lidt mere præcise og definere, hvad der menes med “et tegn”. For eksempel kan det være helt naturligt for os at tænke på **a** og *a* som forskellige “tegn”: “fed a” og “kursiv a”. Men nej: de er blot forskellige visuelle gengivelser af det samme grundlæggende tegn, som Unicode giver det officielle navn [LATIN SMALL LETTER A](http://unicode.org/charts/PDF/U0000.pdf).

Unicode [definerer et tegn](http://www.unicode.org/glossary/#character) som:

> “Den mindste komponent i det skrevne sprog, der har semantisk værdi; henviser til den abstrakte betydning og/eller form, snarere end en specifik form...”

som tydeligt skelner mellem et tegns specifikke *visuelle udseende* form *betydning*.

Man kan tænke på et tegn som den grundlæggende enhed eller byggesten i et sprog eller, mere korrekt, en *skriftsystem*skrift—a topic we discuss below. Hvad et tegn faktisk ser ud som, når det vises med en bestemt skrifttype, er ikke relevant for Unicode’s definition af et tegn: kun den *betydning* er virkelig af interesse her: *rolle og formål* for hvert tegn som en af en række byggesten, hvorfra skrifter/sprog i sidste ende konstrueres.

### Skrift og sprog

Det er værd kort at nævne to vigtige begreber: *skrifter* og *sprog*. Unicode-webstedet giver en nyttig [definition af en skrift](https://www.unicode.org/standard/supported.html):

> “Unicode-standarden koder skrifter snarere end sprog. Når skriftsystemer for mere end ét sprog deler sæt af grafiske symboler, der historisk har beslægtede afledninger, behandles foreningen af alle disse grafiske symboler som en enkelt samling af tegn til kodning og identificeres som en enkelt skrift.”

Ved at bruge et [eksempel fra Wikipedia](https://en.wikipedia.org/wiki/Script_\(Unicode\))består den latinske skrift af en bestemt [samling af tegn](http://unicode.org/charts/) som bruges på tværs af flere sprog: engelsk, fransk, tysk, italiensk og så videre. Selvfølgelig bruges ikke alle tegn, der er defineret inden for den latinske skrift, af alle sprog, der bygger på den latinske skrift—for eksempel indeholder det engelske alfabet ikke de accenttegn, som findes i andre europæiske sprog som fransk eller tysk.

### OpenType-skrifttyper: skrifter og sprog

På dette punkt krydser vi fra Unicode over til OpenType-skrifttyper, fordi begreberne skrift og sprog også spiller en yderst vigtig rolle inden for OpenType-skrifttype-teknologi.

Et sæt sprog, der bruger den samme [skriftsystem](http://www.unicode.org/glossary/#script) kan hver især have forskellige typografiske traditioner, når det gælder visning (sætning) af tekst skrevet på et bestemt sprog. Et godt eksempel findes i tyrkisk og [adfærden for det prikløse i](https://en.wikipedia.org/wiki/Dotted_and_dotless_I) (se den sidens noter om ligaturer). Typografiske “regler” vedrørende skrifter/sprog er indbygget i OpenType-skrifttypers funktionalitet gennem brugen af såkaldte skrift- og sprog *mærker* tags, som bruges til at identificere regler, der skal gælde for bestemte skrift-/sprogs-kombinationer. Naturligvis vil sættet af skrifter/sprog, som understøttes af hver OpenType-skrifttype, variere alt efter de valg, som skrifttypens skabere har truffet, og formålet med at fremstille den. Sofistikeret sætningsteknologi, såsom XeTeX eller LuaTeX, kan udnytte disse regler (indbygget i OpenType-skrifttyper) ved at lade brugerne selektivt anvende dem på inputteksten, når tekst sættes på et bestemt sprog—for eksempel ved at bruge LaTeX [fontspec-pakken](https://ctan.org/pkg/fontspec?lang=en).

#### Se ind i en OpenType-skrifttype: skrifter/sprog

For at gøre dette klarere er her et skærmbillede, der viser den gratis [Scheherazade OpenType-skrifttype](http://software.sil.org/scheherazade/download/) åbnet i den (også gratis) [Microsoft VOLT](https://www.microsoft.com/en-us/Typography/volt.aspx) skrifttype-redigeringssoftware. På dette billede kan du se de skrifter, sprog og typografiske funktioner, der er indbygget i Scheherazade—ved hjælp af VOLT kan du tilføje ekstra funktioner og funktionalitet til Scheherazade, men det ligger langt uden for denne artikels rammer!

![Scheherazade OpenType-skrifttypen (TrueType-varianten) åbnet i Microsoft VOLT](/files/2182d3699714c8e1d8df30b7871694d3c9e4e79e)

Ud fra dette skærmbillede kan du se, at Scheherazade understøtter den arabiske og den latinske skrift og giver yderligere specialiseret støtte til flere sprog, der bruger den arabiske skrift—ved hjælp af såkaldte OpenType-funktioner, som er anført i feltet med grøn kant ovenfor. Vi går ikke ind i detaljerne om disse funktioner, men budskabet her er, at OpenType-skrifttyper af høj kvalitet har en masse intelligens indbygget, klar til brug for sætningsteknologi, der kan udnytte de typografiske regler, der er indbygget i skrifttyper.

Den interesserede læser kan gennemse OpenType-tagregisteret for at se [skrift-tags](https://www.microsoft.com/typography/otspec/scripttags.htm) og [sprog-tags](https://www.microsoft.com/typography/developers/opentype/languagetags.aspx) der i øjeblikket bruges inden for OpenType-specifikationen.

### Tilbage til tegn: forskellige tegnroller

Det sæt af tegn, som udgør de grundlæggende elementer i en skrift (eller et sprog), har ikke alle den samme rolle. For eksempel er der i de fleste sprog tegn for *tegnsætning*samt tegn til numeriske *cifre* såvel som de tegn, vi tænker på som *bogstaver* i alfabetet, som for nogle skrifter også findes i store og små bogstavsformer. Begrebet tegn er ret bredt, og Unicode-standarden omfatter specialtegn, som *ikke er beregnet til at blive vist* men hvis opgave er “at styre fortolkningen eller visningen af tekst”. For eksempel kan du, når du sætter noget arabisk tekst, ønske at tvinge eller forhindre sammenføjningsadfærden for bestemte tegn; Unicode-standarden giver særlige kontroltegn til dette: de såkaldte [ZERO WIDTH JOINER](https://en.wikipedia.org/wiki/Zero-width_joiner) og [ZERO WIDTH NON-JOINER](https://en.wikipedia.org/wiki/Zero-width_non-joiner). Disse tegn er ikke beregnet til visning og bliver “absorberet” af software under behandlingen af teksten for at producere deres tilsigtede visuelle effekter.

Alle tegn, der er specificeret inden for Unicode-standarden, tildeles et sæt egenskaber, som i praksis beskriver rollen og formålet med hvert tegn i Unicode-kodningen—tegnnavne, såsom LATIN SMALL LETTER A, er blot ét element i et tegns egenskabsliste. Disse egenskaber beskrives fuldt ud i [Unicode Character Database (UCD)](http://www.unicode.org/reports/tr44/) og anvendes i vid udstrækning i computeriserede tekstbehandlingsoperationer såsom søgning, sortering, stavekontrol og så videre. Datafiler, der opregner Unicode-tegnegenskaber, er også [tilgængelige til download](http://www.unicode.org/Public/UCD/latest/).

Blandt de egenskaber, der tildeles hvert tegn, er den vigtigste for vores diskussion en *numerisk identifikator* tildelt af dens Unicode-kodning, et emne vi nu vender os mod.

### Tegn: tal og kodninger

Det er en selvfølge, men computere og andre digitale enheder arbejder med at lagre og behandle numeriske data: så hvordan hænger det sammen med tekst? Når du skriver tekst ved hjælp af et computer-tastatur eller ved at trykke på skærmen på en mobilenhed, bliver dine tastetryk omsat til tal, som repræsenterer den tegnstreng, du skriver.

På et tidspunkt vil du måske ønske at overføre den tekst (en række tal) via e-mail, en tekstbesked eller via onlinekommunikation som et Tweet eller et opslag på en form for sociale medier. Det er klart, at den enhed, som du skrev teksten på, og den eller de enheder, som modtageren eller modtagerne bruger, på en eller anden måde må være enige om, hvilke tal der repræsenterer hvilke tegn. Hvis ikke, vises din tekst måske ikke korrekt på modtagerens enhed.

For at nutidens globale kommunikation kan fungere, har afsendende og modtagende enheder brug for en slags “gensidigt aftalt konvention”, hvor et bestemt sæt tal repræsenterer et specifikt sæt tegn. Denne konvention kaldes en *kodning*: et sæt tal, der bruges til at repræsentere et bestemt sæt tegn, og Unicode-kodningen er nu den *de facto* globale standard.

## Unicode: bits og bytes til lagring af tekst

Unicode er en enorm standard, som dækker meget, meget mere end blot tekstkodning, men her fokuserer vi kun på den kodning, den giver.

#### Bits, bytes og hvor mange tegn?

Vi nævnte, at enheder lagrer og repræsenterer tekst som tal—nærmere bestemt vil tegn blive lagret som heltal: hele tal. For at forstå implikationerne af dette for Unicode-kodning, er vi nødt til at have en *meget* kort, *meget* grundlæggende gennemgang af, hvordan computere lagrer heltal (vi har ikke til hensigt at bevæge os ind i datalogi).

For at gøre en meget lang historie kort lagrer nutidens stationære eller håndholdte enheder heltal i diskrete “klumper”, som kan være 1, 2, 4 eller 8 bytes lange. Hver af disse lagerenheder kan lagre heltal op til en maksimal positiv værdi baseret på det samlede antal bits, der er indeholdt i hver lagerenhed:

* 1 byte (8 bits): den maksimale positive heltalsværdi er 255;
* 2 bytes (16 bits): den maksimale positive heltalsværdi er 65535;
* 4 bytes (32 bits): den maksimale positive heltalsværdi er 4.294.967.295;
* 8 bytes (64 bits): den maksimale positive heltalsværdi er 18.446.744.073.709.551.615.

I praksis bruger Unicode-standarden tal i området 0 til 1.114.111 til at kode alle verdens tegn, hvilket betyder, at den kun behøver 21 bits for at kode hele området. Dette kan vi se ved at bemærke, at lagerenheder, der indeholder n bits, kan repræsentere ethvert positivt heltal fra 0 op til en maksimal værdi på $$2^n -1$$; følgelig:

* den maksimale værdi, der kan lagres i 20 bits, er $$2^{20} -1 = 1,048,575$$ (for lille);
* den maksimale værdi, der kan lagres i 21 bits, er $$2^{21} -1 = 2,097,151$$ (stor nok).

Vi har bemærket, at computere lagrer data (tal) i enheder på 1, 2, 4 (eller 8) bytes, så hvor stor skal lagerenheden være, hvis vi skal lagre værdier op til den maksimale Unicode-værdi på 1.114.111? Det er klart, at en byte-stor lagerenhed kan indeholde en maksimal værdi på 255 og 2 bytes kan lagre 65535: ingen af disse er tilstrækkelige til at lagre hele det sæt af tegn, der er kodet af Unicode. Den næste tilgængelige mulighed er lagerenheder, hvis størrelse er 4 bytes, som kan lagre heltal op til en maksimal værdi på 4.294.967.295, hvilket er langt mere, end vi faktisk ville have brug for. Så hvis vi valgte 4 bytes som vores lagerenhed, har vi bestemt mere end rigelig plads til at lagre alle Unicode-værdierne, hvor hvert tegn lagres som et heltal, der kræver 4 bytes (32 bits). Men at bruge 4 bytes til at lagre alt er meget pladssøgende, fordi selv de største Unicode-værdier kun behøver maksimalt 21 bits—which, hvis de lagres ved hjælp af 32 bits, ville betyde, at 11 af de 32 bits aldrig ville blive brugt.

**Bemærk**: Selvom Unicode-området spænder fra 0 til 1.114.111, er ikke alle værdier i dette område faktisk i brug: af tekniske årsager betragtes nogle værdier som ugyldige til faktisk brug som Unicode-tegn.

### Så hvad er UTF-8?

Hvis du læser om XeTeX eller LuaTeX, vil du næsten helt sikkert støde på forklaringer, der siger, at disse TeX-motorer læser tekst og LaTeX-inputfiler i “UTF-8-format”. Så hvad er “UTF-8-format”, og hvordan hænger det sammen med Unicode? I Unicode-terminologi kaldes hver af dets 1.114.112 værdier (fra 0 til 1.114.111), som bruges til at kode verdens tegn, en [kodepunkt](http://www.unicode.org/glossary/#code_point).

Vi har set, at *i teorien*ville vi skulle lagre al vores Unicode-kodede tekst ved at bruge 4 bytes pr. tegn for at kunne repræsentere hele spektret af Unicode’s code points. I praksis opfandt nogle ret smarte mennesker dog en enkel måde at repræsentere et enkelt Unicode-tal (code point) som en *sekvens* af mindre tal, og hvert af disse mindre tal lagres i en enkelt byte: en proces, som *transformerer* et enkelt (større) heltal til en række mindre (byte-store) heltal. På grund af denne transformation repræsenteres tegnene i vores tekstfil ikke længere hver af et enkelt numerisk værdien: hvert tegn bliver en *flerbyte-sekvens*—alt fra 1 til 4 (sammenhængende) bytes i tekstfilen kan repræsentere et enkelt individuelt Unicode-tegn (dvs. dets code point-værdi).

UTF står for *Unicode Transformation Format* og nøgleordet her er *Transformation*. I bund og grund kan man tænke på UTF-8 som en “opskrift” eller algoritme til at omdanne (transformere) en enkelt Unicode code point-værdi til en sekvens af 1 til 4 byte-store dele. Efterhånden som værdien af Unicode code point stiger, stiger også antallet af enkelte bytes, der kræves for at repræsentere den i UTF-8-format.

Der er tekniske og historiske grunde til at skabe UTF-8, og historien bag opfindelsen af UTF-8 er [beskrevet i en fascinerende e-mail fra 2003](https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt), som nær begyndelsen af e-mailen indeholder linjen:

> “Det er ikke sandt. UTF-8 blev designet for øjnene af mig på en dækkeserviet på en diner i New Jersey en aften i september eller deromkring 1992.”

#### Et eksempel: det arabiske bogstav ل

Lad os tage et eksempel med det arabiske bogstav ل (Unicode-navn ARABIC LETTER LAM), som er tildelt Unicode code point-værdien 1604 (decimal) eller 0644 (hexadecimal): dets repræsentation i UTF-8 er den *to-byte* sekvens D9 84 (hex) eller, i decimal, 217 132. Når UTF-8 bruges som format til lagring af tekst, bliver det i stedet for en tekstfil, der indeholder det ene tal 1604 til at repræsentere ل, omdannet til to byte-store værdier: 217 og 132—tegnet ل gemmes som en *to-byte-sekvens*. Læsere, der ønsker at udforske UTF-8-algoritmen mere detaljeret, kan finde en dybdegående forklaring og C-kode på min [personlige blogside](http://www.readytext.co.uk/?p=1284).

Når et stykke software (f.eks. XeTeX eller LuaTeX) læser tekst i UTF-8-format, skal den pågældende software bestemme Unicode-værdien for hvert tegn, der findes i filen, så den bruger en algoritme til at *vende om* omvendte UTF-8-transformationsprocessen. Gennem denne “omvendte algoritme” kombineres de to bytes (217 og 132) for at danne heltallet 1604, som derefter kan genkendes som Unicode code point-værdien for det arabiske bogstav ل.

Så som konklusion er UTF-8 egentlig blot et mellemformat til lagring og transmission af Unicode-kodet tekst.

**Bemærk**: Nogle systemer vælger at lagre tekst ved hjælp af 32 bits pr. tegn, dette kaldes [UTF-32](https://en.wikipedia.org/wiki/UTF-32)—der er også [UTF-16](https://en.wikipedia.org/wiki/UTF-16) men UTF-8 er den mest almindelige måde at lagre Unicode-kodet tekst på.

## Flersprogede TeX-filer: XeTeX og LuaTeX

Både XeTeX og LuaTeX er i stand til meget sofistikeret flersproget sætning, selvom deres mekanismer til at opnå dette er ret forskellige og afspejler hver motors design-/udviklingsfilosofi. Vi vil ikke udforske dette i dybden, men blot bemærke, at XeTeX-motoren indeholder softwarekomponenter (indbygget i dens eksekverbare fil), som ikke findes i LuaTeX—især software til en proces kaldet *OpenType-formgivning* (f.eks. via et bibliotek kaldet [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)).

LuaTeX derimod anvender en anden tilgang: i stedet for at bygge faciliteter direkte ind i den egentlige TeX-motor, stiller LuaTeX en ekstremt rig samling af kommandoer (TeX-primitiver) og en meget kraftig [Lua-baseret API](/latex/da/dybtgaende-artikler/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md) til rådighed, hvorigennem udviklere kan konstruere lige så avancerede løsninger til flersproget sætning. Selvom LuaTeX-filosofien kan indebære ekstra arbejde for LaTeX-pakkeudviklere, giver den en stor grad af yderligere fleksibilitet, fordi løsningerne ikke er “hardcodede” ind i selve LuaTeX-motoren, men konstrueres af TeX- og Lua-kode—eller plugins skrevet i C/C++.

**Sidebemærkning**: Læsere, der ønsker at udforske den fascinerende, men komplekse, verden af OpenType-formgivning yderligere, kan være interesserede i at læse om det fremragende open source-bibliotek kaldet [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)—brugt af mange programmer, herunder Firefox, Chrome og LibreOffice og naturligvis af XeTeX. Forfatteren til denne artikel har brugt HarfBuzz til at skabe [LuaTeX-plugins til at lave arabisk sætning](http://www.readytext.co.uk/?p=3186).

Det er nu almindeligt (f.eks. på sociale medier) at overføre tekst, som indeholder tegn fra flere sprog, og en UTF-8-tekstfil, der gemmer flersproget tekst, kan let indeholde tegn, hvis repræsentation i UTF-8 er 1, 2, 3 eller 4 bytes lang. Så i praksis er en UTF-8-tekstfil blot en strøm af enkelte bytes, men hvert egentligt tegn i filen kan være alt fra 1 til 4 bytes langt: de enkelte tegn er blevet *flerbyte-sekvenser*.

For at udforske nogle centrale aspekter af at arbejde med (sætning af) flersproget tekst vil vi bruge et eksempel, der indeholder den arabiske skrift, fordi arabisk giver os mulighed for at behandle flere begreber.

#### Sidebemærkning: den arabiske skrift

Den [arabisk skrift](https://en.wikipedia.org/wiki/Arabic_script) skrives i en kursiv stil, som læses og skrives fra højre mod venstre. Hvert arabisk bogstav kan potentielt antage en af 4 forskellige former afhængigt af:

* om det vises som et enkelt, selvstændigt (isoleret) tegn (ikke sammenføjet med noget andet);
* om det forekommer inde i et ord—i begyndelsen, midten eller slutningen af et ord: kaldet *initiale*, *mediale* og *final* former henholdsvis.

Hvert tegn i den arabiske skrift har sit eget sæt af sammenføjningsregler og kan, eller kan ikke, ændre form/udseende, når det har et andet tegn til venstre, til højre eller til både venstre og højre. Læsere, der ønsker at udforske dette yderligere, kan finde en [fuld liste på Wikipedia](https://en.wikipedia.org/wiki/Template:Arabic_alphabet_shapes/joining).

#### Eksempel: arabisk og engelsk tekst i UTF-8

Antag, at vi opretter en UTF-8-tekstfil, der indeholder en enkelt linje med engelsk og arabisk tekst: This is العَرَبِيَّة text!

Denne tekstlinje indeholder 3 mellemrumstegn, 11 engelske (latinske skrift-)tegn og 12 arabiske tegn (selvom det måske ikke er umiddelbart indlysende/tydeligt). Når den gemmes som en UTF-8-tekstfil, optager den 38 bytes lagerplads, hvilket skyldes følgende:

* **Latinsk skrift**: mellemrum plus engelsk tekst: 14 ✕ 1-byte-tegn = 14 bytes;
* **arabisk skrift**: 12 arabiske tegn ✕ 2 bytes pr. tegn = 24 bytes.

I alt 14 + 24 = 38 bytes.

#### Graver dybere

Hvis vi gemmer vores eksempeltekst i en UTF-8-fil kaldet `arabic.txt` og åbner den i en hexadecimal editor, kan vi undersøge den for at se de faktiske bytes, den indeholder. Ud fra studiet af følgende kommenterede skærmbillede kan du se, at den arabiske tekst er gemt som 2 bytes pr. tegn:

![En UTF-8-tekstfil, der indeholder engelsk og arabisk tekst, åbnet i en hex-editor.](/files/34c38cf59367daef919236213a2235f92f682297)

En UTF-8-tekstfil, der indeholder engelsk og arabisk tekst, åbnet i en hex-editor. Du kan tydeligt se, at tegn fra den latinske skrift kræver en enkelt byte, mens tegn fra den arabiske skrift er gemt ved hjælp af to bytes pr. tegn.

Du kan gøre et par observationer ud fra dette skærmbillede:

* den arabiske tekst er gemt i en venstre-mod-højre-sekvens, og tegnene er de rå, uformede (isolerede) versioner af de arabiske bogstaver og vokaler;
* der er ingen yderligere information efter den latinske tekst “This is ”, som fortæller nogen software, der læser denne fil, at det næste tegn er i den arabiske skrift.

Hvis du sætter et flersproget dokument (f.eks. med engelsk og arabisk), skal XeTeX eller LuaTeX under læsning/behandling af inputtekstfilen (som en strøm af bytes) kunne registrere begyndelsen og slutningen af hvert tegn og læse det korrekte antal bytes, der kræves for at vende UTF-8-transformationen og generere den tilsvarende Unicode code point. Det er selve UTF-8-algoritmen, som gør det muligt for software at gøre dette: den muliggør registrering af den første byte i hvert enkelt tegn og hvor mange bytes der skal læses for at beregne den tilsvarende Unicode code point. UTF-8 er nem at bruge, men virkelig ganske genial.

#### Logisk rækkefølge, visningsrækkefølge og OpenType-formgivning

Hvis du kigger nøje på det arabiske ovenfor (العَرَبِيَّة), kan det være svært at se, at vores tekstfil faktisk indeholder 12 enkelte arabiske tegn—særligt hvis du ikke er fortrolig med den arabiske skrift! Men hvis du omhyggeligt tæller de arabiske tegn, der vises i højre side af skærmbilledet ovenfor, kan du se, at der er 12 i alt.

For komplekse skriftsprog, såsom arabisk, er det, vores tekstfil *gemmer* og det, du *ser på skærmen* tydeligt *meget* forskelligt! Det, du ser, når du ser den tekst, for eksempel i en browser, er (afhængigt af den anvendte skrifttype):

![Billede af sat arabisk tekst](/files/0d2389d4482e55031ffcef1feae7b71de6a370b7)

Men som skærmbilledet ovenfor viser, er det, UTF-8-tekstfilen faktisk indeholder, dette:

![Billede af ikke-sat arabisk tekst (isolerede tegn)](/files/7d2b21b65591c98651ef6efb26e42d89cac8d640)

Selv hvis du ikke er fortrolig med den arabiske skrifts kursivnatur, kan du tydeligt se, at “noget” er sket under overførslen af arabiske tegn, der findes i en tekstfil, til sætning og/eller visning på skærmen (som glyffer). Hvis du er vant til at bruge TeX/LaTeX med enkle skriftsprog, for eksempel latinsk-baserede sprog, kan dette virkelig være meget forvirrende!

Nogle vigtige begreber er på spil her, fordi Unicode-tekstfiler arbejder med at lagre… ja, tekst (Unicode), og sætning og visningssystemer arbejder med at bruge skrifttyper og glyffer (OpenType):

* tekstfilen gemte de arabiske tegn i en venstre-mod-højre-rækkefølge, men arabisk læses/vises fra højre mod venstre: tekstfiler lagrer tekst i såkaldt *logisk rækkefølge*;
* tekstfilen indeholder enkelte tegn, der ser meget anderledes ud end den faktiske visning, der præsenteres på skærmen: tekstfilen indeholder de arabiske tegn i deres isolerede, ikke-sammenføjede form.

#### Hvad foregår der?

Inde i en tekstfil lagres arabisk som en venstre-mod-højre-sekvens af tegn i isoleret form: hvis du tænker over det, lagrer tekstfilen den arabiske tekst i den rækkefølge/sekvens *i hvilken den blev skrevet* (det *logisk rækkefølge*). Det er kun, når denne tekst behandles til visning eller sættes op, at den vises i sin korrekte læserækkefølge, ofte omtalt som den *visuelle rækkefølge* eller *visningsrækkefølge*; derudover bliver de isolerede former af de arabiske tegn *formgivet* til deres typografisk korrekte visningsversioner. En måde at tænke på dette er, at en simpel tekstfil er nødt til at lagre tekst (Unicode-tegn) i den mest grundlæggende form, der er mulig: rå, uformede, enkelte teksttegn—det er systemsoftwarens opgave at gengive disse tegn til visning baseret på det operativsystem, de skrifttyper og den sætning/rendering-software, der er tilgængelig på visningsenheden.

Når den arabiske tekst i den fil sættes/vises, gennemgår den en proces kaldet *formning*. De enkelte arabiske tegn omdannes til formede glyffer, som korrekt repræsenterer den variant af hvert tegn, der kræves i henhold til de sammenføjningsregler, som gælder for den arabiske skrift og skriftsystemet. Derudover vil sætningsteknologi af høj kvalitet (ved brug af gode OpenType-skrifttyper) tilføje yderligere behandling ved at anvende ekstra typografisk raffinement gennem en proces kaldet *OpenType-formgivning*—en proces, der omfatter en lang række typografiske operationer, som kan inkludere:

* at erstatte flere enkelte glyffer med en enkelt kompleks ligatur-glyf (meget almindeligt med arabisk), eller
* placeringsoperationer, der f.eks. justerer placeringen af arabiske vokaler afhængigt af, hvilken glyf de står over eller under.

![Billede, der viser den omdannelse, som arabisk tekst gennemgår, når den sættes typografisk](/files/dc313ab96f77d83b15089378c17db7e7a1e0a5dc)

Forskellen mellem logisk rækkefølge og visuel (visnings-)rækkefølge. I denne grafik kan du se, at arabiske tegn, der er gemt i en tekstfil, gennemgår omrokering og formgivning, når de vises eller sættes typografisk.

Designere og skabere af avancerede OpenType-skrifttyper investerer meget betydelig tid og ekspertise i at levere de sofistikerede typografiske muligheder, der er indbygget i deres skrifttyper.

For at slå den formgivning fra, der anvendes på den arabiske tekst, kan vi bruge den fremragende, gratis, [BabelPad](http://www.babelstone.co.uk/Software/BabelPad.html) Unicode-teksteditor (kun til Windows), som lader dig deaktivere formgivningen for at se de rå, enkelte, ikke-forbundne (uformede) tegn, der faktisk er til stede i tekstfilen — se den nederste halvdel af dette kombinerede skærmbillede:

![Billede, der viser BabelPad-teksteditorens evne til at slå OpenType-formgivning fra](/files/7f42368f71991cc02fed781c343df39356c3d932)

Brug af Unicode-teksteditoren BabelPad til at slå OpenType-formgivning til (øverste figur) eller fra (nederste figur). At slå OpenType-formgivning fra gør det langt lettere at redigere arabisk tekst.

Begreberne logisk rækkefølge og visningsrækkefølge, sammen med processerne ved formgivning, kan være ret forvirrende, når man først støder på dem under redigering eller typografisk sats af flersprogede tekstfiler, der indeholder komplekse skriftsystemer som arabisk: forhåbentlig har ovenstående hjulpet med at undgå en del indledende forvirring.


---

# 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/da/dybtgaende-artikler/51-unicode-utf-8-and-multilingual-text-an-introduction.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.