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

# Unicode, UTF-8 og flerspråklig tekst: en introduksjon

## Unicode og OpenType: Tegn og glyfer

Moderne TeX-motorer, dvs. XeTeX og LuaTeX, har utviklet seg fra Knuths opprinnelige TeX-motor i stor grad på grunn av behovet for å holde tritt med utviklingen i teknologilandskapet, særlig Unicode (for tekst) og OpenType (for fonter). I dag kan LaTeX-brukere, gjennom bruk av pakker som [fontspec](https://ctan.org/pkg/fontspec?lang=en) og [unicode-math](https://ctan.org/pkg/unicode-math?lang=en), få tilgang til ekstremt avanserte satsingsmuligheter levert av OpenType-fonter — inkludert avansert flerspråklig sats og OpenType-basert matematisk sats ([pionerarbeid av Microsoft](https://blogs.msdn.microsoft.com/murrays)).

Men for å få mest mulig ut av å bruke OpenType-fonter med XeTeX/LuaTeX, kan det være nyttig å bli kjent med en rekke bakgrunnstemaer/-begreper — særlig for å feilsøke problemer eller for å bane vei for mer avansert/komplekst arbeid. Du kan for eksempel lese om at XeTeX- og LuaTeX-motorene bruker «UTF-8-input» eller at de er «Unicode-bevisste», og videre lesning om OpenType-fonter kan diskutere eller nevne temaer som «Unicode-koding», OpenType «fontfunksjoner», «glyfer», «glyf-ID-er», «glyfnavn» og så videre. Målet vårt er å gi en innføring i disse begrepene/temaene og sette sammen et grunnleggende rammeverk som viser hvordan de henger sammen og, forhåpentligvis, gir støtte til videre arbeid eller problemløsning.

Temaene vi ønsker å dekke, faller ganske ryddig inn i to hovedområder: *Unicode* som i praksis befinner seg i tekstens/tegnenes og tekstkodingens verden, og *OpenType* som har fontenes og glyfenes verden; men naturligvis er disse to verdenene sammenkoblet, og det er noe overlapp, selv i denne første artikkelen.

### Hvilke temaer skal vi diskutere?

Hovedfokuset i denne artikkelen er noen Unicode-relaterte temaer: vi begynner med en diskusjon av hva som menes med et «tegn», og går deretter videre til skriftsystemer/språk, Unicode-koding og UTF-8 — sammen med et eksempel på arbeid med flerspråklige tekstfiler. En oppfølgingsartikkel vil bygge videre på dette og dekke bakgrunnstemaer knyttet til OpenType-fontteknologi. Det er åpenbart ikke mulig, innenfor rammen av et blogginnlegg, å forsøke en «dykk ned i dybden» i alle områdene vi håper å diskutere: vårt uttalte mål er å gi det overordnede rammeverket som viser hvordan noen sentrale begreper henger sammen og virker sammen. Vi starter med det mest grunnleggende begrepet: *tegnet*.

## Tegnet: En grunnleggende byggestein

En grunnleggende idé/begrep som står i sentrum for diskusjonene våre (og for Unicode), er betydningen av et «tegn»: det er et av de ordene hvis betydning ofte blir «tatt for gitt» gjennom bruken i daglig arbeid og samtaler. Men fra perspektivet til Unicode, satsing og fontteknologi må vi være litt mer presise og definere hva som menes med «et tegn». For eksempel kan det være ganske naturlig for oss å tenke på **a** og *a* som forskjellige «tegn»: «fet a» og «kursiv a». Men nei: de er bare ulike visuelle representasjoner av det samme grunnleggende tegnet, som Unicode gir det offisielle navnet [LATINSK LITEN BOKSTAV A](http://unicode.org/charts/PDF/U0000.pdf).

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

> «Den minste komponenten i skriftspråk som har semantisk verdi; viser til den abstrakte betydningen og/eller formen, snarere enn en spesifikk form...»

som tydelig skiller mellom et tegns spesifikke *det visuelle utseendet* og dets *betydning*.

Du kan tenke på et tegn som den grunnleggende enheten, eller byggesteinen, i et språk eller, mer korrekt, en *skriftsystemet*—et tema vi diskuterer nedenfor. Hvordan et tegn faktisk ser ut når det vises med en bestemt font, er ikke relevant for Unicodes definisjon av et tegn: bare *betydning* er av virkelig interesse her: *rollen og formålet* til hvert tegn som ett av et sett med byggesteiner som skriftsystemer/språk til syvende og sist er konstruert av.

### Skrift og språk

Det er verdt å kort nevne to viktige begreper: *skrifter* og *språkene*. Unicode-nettstedet gir en nyttig [definisjon av en skrift](https://www.unicode.org/standard/supported.html):

> «Unicode-standarden koder skrifter snarere enn språk. Når skriftsystemer for mer enn ett språk deler sett med grafiske symboler som historisk har beslektede avledninger, behandles foreningen av alle disse grafiske symbolene som én enkelt samling av tegn for koding og identifiseres som én enkelt skrift.»

Ved å bruke et [eksempel fra Wikipedia](https://en.wikipedia.org/wiki/Script_\(Unicode\)), består det latinske skriftsystemet av en bestemt [samling av tegn](http://unicode.org/charts/) som brukes på tvers av flere språk: engelsk, fransk, tysk, italiensk og så videre. Selvfølgelig brukes ikke alle tegn som er definert innenfor det latinske skriftsystemet av alle språk basert på det latinske skriftsystemet — for eksempel inneholder ikke det engelske alfabetet de aksentuerte tegnene som finnes i andre europeiske språk som fransk eller tysk.

### OpenType-fonter: skrifter og språk

På dette punktet går vi over fra Unicode til OpenType-fonter fordi begrepene skrift og språk også spiller en ekstremt viktig rolle innenfor OpenType-fontteknologi.

Et sett med språk som bruker den samme [skriftsystemet](http://www.unicode.org/glossary/#script) kan hver ha ulike typografiske tradisjoner når det gjelder visning (sats) av tekst skrevet på et bestemt språk. Et godt eksempel finnes i det tyrkiske språket og [atferden til den prikkfrie i-en](https://en.wikipedia.org/wiki/Dotted_and_dotless_I) (se notatene på den siden om ligaturer). Typografiske «regler» knyttet til skrifter/språk er bygget inn i funksjonaliteten til OpenType-fonter gjennom bruk av såkalte skrift- og språktagger *tagger* som brukes til å identifisere regler som skal gjelde for bestemte skrift/språk-kombinasjoner. Naturligvis vil settet av skrifter/språk som støttes av hver OpenType-font variere etter valgene som er gjort av fontens skapere og årsaken til å produsere den. Avansert satsprogramvare, som XeTeX eller LuaTeX, kan dra nytte av disse reglene (innebygd i OpenType-fonter) ved å la brukerne selektivt anvende dem på inndata-teksten når tekst satses på et bestemt språk — for eksempel ved å bruke LaTeX [fontspec-pakken](https://ctan.org/pkg/fontspec?lang=en).

#### Se nærmere på en OpenType-font: skrifter/språk

For å gjøre dette klarere, er her et skjermbilde som viser den gratis [Scheherazade OpenType-fonten](http://software.sil.org/scheherazade/download/) åpnet i den (også gratis) [Microsoft VOLT](https://www.microsoft.com/en-us/Typography/volt.aspx) fontredigeringsprogramvaren. I dette bildet kan du se skriftene, språkene og typografiske funksjonene som er innebygd i Scheherazade — ved hjelp av VOLT kan du legge til ekstra funksjoner og funksjonalitet til Scheherazade, men det er langt utenfor rammen av denne artikkelen!

![Scheherazade OpenType-fonten (TrueType-variant) åpnet i Microsoft VOLT](/files/5595f53088a6a1420f426bc022e284d13ccbb2bd)

Av dette skjermbildet kan du se at Scheherazade støtter de arabiske og latinske skriftene og gir ytterligere spesialisert støtte for flere språk som bruker det arabiske skriftsystemet — ved hjelp av såkalte OpenType-funksjoner, som er listet i boksen med grønn kant ovenfor. Vi går ikke inn på detaljene i disse funksjonene, men budskapet her er at OpenType-fonter av høy kvalitet har mye intelligens bygget inn i seg, klar til bruk av satsingsprogramvare som kan dra nytte av typografiske regler som er innebygd i fonter.

Den interesserte leseren kan bla gjennom OpenType-taggregisteret for å se [skriftsystemtaggene](https://www.microsoft.com/typography/otspec/scripttags.htm) og [språktaggene](https://www.microsoft.com/typography/developers/opentype/languagetags.aspx) som for øyeblikket brukes i OpenType-spesifikasjonen.

### Tilbake til tegnene: Ulike roller for tegn

Sett av tegn som utgjør de grunnleggende elementene i en skrift (eller et språk) har ikke alle samme rolle. For eksempel finnes det i de fleste språk tegn for *tegnsetting*, tegn for numeriske *sifre* samt tegnene vi oppfatter som *bokstaver* i alfabetet, som for noen skriftsystemer også finnes i både store og små former. Begrepet tegn er ganske bredt, og Unicode-standarden inkluderer spesialtegn som *ikke er ment å vises* men hvis oppgave er «å kontrollere tolkningen eller visningen av tekst». For eksempel, når du setter noe arabisk tekst, kan det være ønskelig å tvinge frem eller forhindre sammenbindingsatferden til visse tegn; Unicode-standarden gir spesielle kontrolltegn for dette: de såkalte [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 tegnene er ikke ment for visning og blir «absorbert» av programvaren mens teksten behandles, for å produsere de tiltenkte visuelle effektene.

Alle tegn som er spesifisert i Unicode-standarden tildeles et sett med egenskaper som i praksis beskriver rollen og formålet til hvert tegn i Unicode-kodingen — tegnnavn, som LATINSK LITEN BOKSTAV A, er bare ett element i et tegns egenskapsliste. Disse egenskapene er fullt beskrevet i [Unicode Character Database (UCD)](http://www.unicode.org/reports/tr44/) og brukes mye i datastyrte tekstbehandlingsoperasjoner som søking, sortering, stavekontroll og så videre. Datafiler som lister opp Unicode-tegnegenskaper er også [tilgjengelige for nedlasting](http://www.unicode.org/Public/UCD/latest/).

Blant egenskapene som tildeles hvert tegn, er den viktigste for vår diskusjon en *numerisk identifikator* tildelt av Unicode-kodingen, et tema vi nå går videre til.

### Tegn: Tall og kodinger

Det er en selvfølge, men datamaskiner og andre digitale enheter driver med lagring og behandling av numeriske data: så hvordan henger dette sammen med tekst? Når du skriver tekst med et datatastatur, eller ved å trykke på skjermen på en mobil enhet, blir tastetrykkene dine gjort om til tall som representerer tegnrekken du skriver.

På et tidspunkt kan du ønske å overføre denne teksten (en tallrekke) via e-post, en tekstmelding eller via nettbasert kommunikasjon som en Tweet eller et innlegg på en form for sosiale medier. Det er åpenbart at enheten du skrev teksten på og enheten(e) som mottar den, på en eller annen måte må være enige om hvilke tall som representerer hvilke tegn. Hvis ikke, kan teksten din ikke vises korrekt på mottakerens enhet.

For at dagens globale kommunikasjon skal fungere, trenger sende- og mottaksenheter en slags «gjensidig avtalt konvensjon» der et bestemt sett med tall representerer et bestemt sett med tegn. Denne konvensjonen kalles en *koding*: et sett med tall som brukes til å representere et bestemt sett med tegn, og Unicode-kodingen er nå den *de facto* globale standarden.

## Unicode: biter og byte for lagring av tekst

Unicode er en enorm standard som dekker langt, langt mer enn bare tekstkoding, men her fokuserer vi bare på kodingen den gir.

#### Biter, byte og hvor mange tegn?

Vi nevnte at enheter lagrer og representerer tekst som tall — mer presist blir tegn lagret som heltall: hele tall. For å forstå implikasjonene av dette for Unicode-koding, trenger vi en *svært* kort, *svært* grunnleggende gjennomgang av hvordan datamaskiner lagrer heltall (vi har ikke tenkt å gå inn i informatikk).

For å kutte en veldig lang historie kort: dagens stasjonære eller håndholdte enheter lagrer heltall i diskrete «blokker» som kan være 1, 2, 4 eller 8 byte lange. Hver av disse lagringsenhetene kan lagre heltall opptil en maksimal positiv verdi basert på det totale antallet biter i hver lagringsenhet:

* 1 byte (8 biter): maksimal positiv heltallsverdi er 255;
* 2 byte (16 biter): maksimal positiv heltallsverdi er 65535;
* 4 byte (32 biter): maksimal positiv heltallsverdi er 4 294 967 295;
* 8 byte (64 biter): maksimal positiv heltallsverdi er 18 446 744 073 709 551 615.

I praksis bruker Unicode-standarden tall i området 0 til 1 114 111 for å kode alle verdens tegn, noe som gjør at den bare trenger 21 biter for å kode hele området. Dette kan vi se ved å merke oss at lagringsenheter som inneholder n biter kan representere ethvert positivt heltall fra 0 opp til en maksimal verdi på $$2^n -1$$; følgelig:

* den maksimale verdien som kan lagres i 20 biter er $$2^{20} -1 = 1,048,575$$ (for liten);
* den maksimale verdien som kan lagres i 21 biter er $$2^{21} -1 = 2,097,151$$ (stor nok).

Vi har notert at datamaskiner lagrer data (tall) i enheter på 1, 2, 4 (eller 8) byte, så hvor stor må lagringsenheten være hvis vi må lagre verdier opp til den maksimale Unicode-verdien på 1 114 111? Det er åpenbart at en lagringsenhet på én byte kan inneholde en maksimal verdi på 255 og 2 byte kan lagre 65535: ingen av disse er tilstrekkelige til å lagre hele spekteret av tegn kodet av Unicode. Det neste tilgjengelige alternativet er lagringsenheter på 4 byte, som kan lagre heltall opp til en maksimal verdi på 4 294 967 295, noe som er langt mer enn vi faktisk trenger. Så hvis vi valgte 4 byte som lagringsenhet, har vi definitivt mer enn nok plass til å lagre alle Unicode-verdiene, med hvert tegn lagret som et heltall som krever 4 byte (32 biter). Men å bruke 4 byte til å lagre alt er veldig sløsing med plass, fordi selv de største Unicode-verdiene bare trenger maksimalt 21 biter — noe som, hvis det lagres med 32 biter, ville bety at 11 av disse 32 bitene aldri ville bli brukt.

**Merk**: Selv om Unicode-området strekker seg fra 0 til 1 114 111, brukes ikke hver verdi i dette området faktisk: av tekniske grunner anses noen verdier som ugyldige for faktisk bruk som Unicode-tegn.

### Så, hva er UTF-8?

Hvis du leser om XeTeX eller LuaTeX, vil du nesten garantert møte forklaringer som sier at disse TeX-motorene leser tekst og LaTeX-inndatafiler i «UTF-8-format». Så hva er «UTF-8-format», og hvordan henger det sammen med Unicode? I Unicode-terminologi kalles hver av de 1 114 112 verdiene (som går fra 0 til 1 114 111) som brukes til å kode verdens tegn, en [kodepunkt](http://www.unicode.org/glossary/#code_point).

Vi har sett at *i teorien*ville vi måtte lagre all Unicode-kodet tekst med 4 byte per tegn for å kunne representere hele spekteret av Unicode-kodepunkter. Men i praksis fant noen ganske smarte mennesker en enkel måte å representere ett enkelt Unicode-tall (kodepunkt) som en *sekvensen* av mindre tall, og hvert av disse mindre tallene lagres i én byte: en prosess som *transformerer* ett enkelt (større) heltall til en sekvens av mindre (byte-store) heltall. På grunn av denne transformasjonen blir tegnene i tekstfilen vår ikke lenger representert av én enkelt numerisk verdi hver: hvert tegn blir en *flerbyte-sekvens*—alt fra 1 til 4 (påfølgende) byte i tekstfilen kan representere ett enkelt Unicode-tegn (dvs. kodepunktverdien).

UTF står for *Unicode Transformation Format* og nøkkelordet her er *Transformation*. I bunn og grunn kan du tenke på UTF-8 som en «oppskrift» eller algoritme for å konvertere (transformere) ett enkelt Unicode-kodepunkt til en sekvens av 1 til 4 byte-store deler. Etter hvert som verdien til Unicode-kodepunktet øker, øker også antallet enkelte byte som kreves for å representere det i UTF-8-format.

Det finnes tekniske og historiske grunner til å lage UTF-8, og historien bak oppfinnelsen av UTF-8 er [nedtegnet i en fascinerende e-post fra 2003](https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt), som nær begynnelsen av e-posten inneholder linjen:

> «Det er ikke sant. UTF-8 ble designet, foran øynene mine, på en papirduk i en diner i New Jersey en natt i september eller så i 1992.»

#### Et eksempel: den arabiske bokstaven ل

La oss ta et eksempel med den arabiske bokstaven ل (Unicode-navn ARABIC LETTER LAM), som er tildelt Unicode-kodepunktverdien 1604 (desimal) eller 0644 (heksadesimal): dens representasjon i UTF-8 er den *to-byte* sekvensen D9 84 (hex) eller, i desimal, 217 132. Når UTF-8 brukes som format for lagring av tekst, lagres ikke en tekstfil som inneholder det enkelte tallet 1604 for å representere ل; i stedet blir det konvertert til to byte-store verdier: 217 og 132 — tegnet ل lagres som en *to-byte-sekvens*. Lesere som ønsker å utforske UTF-8-algoritmen mer detaljert kan finne en grundig forklaring, og C-kode, på min [personlige bloggside](http://www.readytext.co.uk/?p=1284).

Når et program (f.eks. XeTeX eller LuaTeX) leser tekst i UTF-8-format, må programmet fastslå Unicode-verdien for hvert tegn som finnes i filen, så det bruker en algoritme for å *reversere* UTF-8-transformasjonsprosessen. Gjennom den «omvendte algoritmen» settes de to byteene (217 og 132) sammen igjen for å generere heltallet 1604, som deretter kan gjenkjennes som Unicode-kodepunktverdien for den arabiske bokstaven ل.

Så, til slutt, UTF-8 er egentlig bare et mellomliggende dataformat som brukes til lagring og overføring av Unicode-kodet tekst.

**Merk**: Noen systemer velger å lagre tekst ved å bruke 32 biter per tegn, dette kalles [UTF-32](https://en.wikipedia.org/wiki/UTF-32)—det finnes også [UTF-16](https://en.wikipedia.org/wiki/UTF-16) men UTF-8 er den vanligste måten å lagre Unicode-kodet tekst på.

## Flerspråklige TeX-filer: XeTeX og LuaTeX

Både XeTeX og LuaTeX er i stand til svært avansert flerspråklig sats, selv om mekanismene for å oppnå dette er ganske forskjellige og gjenspeiler design- og utviklingsfilosofien til hver motor. Vi går ikke i dybden på dette, men merker oss bare at XeTeX-motoren inneholder programvarekomponenter (bygget inn i kjørbarfilen) som ikke finnes i LuaTeX — særlig programvare for en prosess kalt *OpenType-forming* (f.eks. via et bibliotek kalt [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)).

LuaTeX, derimot, tar en annen tilnærming: i stedet for å bygge funksjonalitet direkte inn i selve TeX-motoren, tilbyr LuaTeX en ekstremt rik samling av kommandoer (TeX-primitiver) og et svært kraftig [Lua-basert API](/latex/no/dybdeartikler/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md) gjennom hvilket utviklere kan konstruere like avanserte løsninger for flerspråklig sats. Selv om LuaTeX-filosofien kan innebære ekstra arbeid for LaTeX-pakkeutviklere, gir den stor tilleggsfleksibilitet fordi løsninger ikke er «hardkodet» inn i selve LuaTeX-motoren, men konstrueres av TeX- og Lua-kode — eller plug-ins skrevet i C/C++.

**Sidebemerkning**: Lesere som ønsker å utforske den fascinerende, men komplekse, verdenen av OpenType-forming nærmere, kan være interessert i å lese om det fremragende åpen kildekode-biblioteket kalt [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)—brukt av mange applikasjoner, inkludert Firefox, Chrome og LibreOffice og, selvfølgelig, av XeTeX. Forfatteren av denne artikkelen har brukt HarfBuzz til å lage [LuaTeX-plugins for å gjøre arabisk sats](http://www.readytext.co.uk/?p=3186).

Det er nå vanlig (f.eks. på sosiale medier) å overføre tekst som inneholder tegn fra flere språk, og en UTF-8-tekstfil som lagrer flerspråklig tekst kan lett inneholde tegn hvis representasjon i UTF-8 er 1, 2, 3 eller 4 byte lang. Så i praksis er en UTF-8-tekstfil bare en strøm av enkeltbyte, men hvert faktiske tegn i filen kan være alt fra 1 til 4 byte langt: de enkelte tegnene har blitt *flerbyte-sekvenser*.

For å utforske noen viktige sider ved arbeid med (satsing av) flerspråklig tekst vil vi bruke et eksempel som inneholder det arabiske skriftsystemet, fordi arabisk gir oss rom for å ta opp flere begreper.

#### Sidebemerkning: det arabiske skriftsystemet

Den [Det arabiske skriftsystemet](https://en.wikipedia.org/wiki/Arabic_script) skrives i en kursiv stil som leses og skrives fra høyre mot venstre. Hver arabisk bokstav kan potensielt anta én av 4 forskjellige former i henhold til:

* om den vises som et enkelt, selvstendig (isolert) tegn (ikke koblet til noe annet);
* om den forekommer i et ord — i starten, midten eller slutten av et ord: omtalt som *initiale*, *mediale* og *final* former henholdsvis.

Hver bokstav i det arabiske skriftsystemet har sitt eget sett med sammenbindingsregler og kan, eller kan ikke, endre form/utseende når den har en annen bokstav til venstre, til høyre eller både til venstre og høyre. Lesere som ønsker å utforske dette nærmere kan finne en [fullstendig liste på Wikipedia](https://en.wikipedia.org/wiki/Template:Arabic_alphabet_shapes/joining).

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

Anta at vi lager en UTF-8-tekstfil som inneholder én enkelt linje med engelsk og arabisk tekst: This is العَرَبِيَّة text!

Denne tekstlinjen inneholder 3 mellomromstegn, 11 engelske tegn (latinsk skrift) og 12 arabiske tegn (selv om det kanskje ikke er umiddelbart åpenbart). Når den lagres som en UTF-8-tekstfil, opptar den 38 byte lagringsplass, som følger av det følgende:

* **Latinsk skrift**: mellomrom pluss engelsk tekst: 14 ✕ 1-byte-tegn = 14 byte;
* **Det arabiske skriftsystemet**: 12 arabiske tegn ✕ 2 byte per tegn = 24 byte.

Til sammen 14 + 24 = 38 byte.

#### Ser nærmere

Hvis vi lagrer eksempltekstene våre i en UTF-8-fil kalt `arabic.txt` og åpner den i en heksadesimal redigerer, kan vi undersøke den for å se de faktiske byteverdiene den inneholder. Av studiet av det følgende kommenterte skjermbildet kan du se at den arabiske teksten er lagret som 2 byte per tegn:

![En UTF-8-tekstfil som inneholder engelsk og arabisk tekst åpnet i en hex-redigerer.](/files/c4dc4d8c19f78f8a31330d0c1961e62ca9d6264a)

En UTF-8-tekstfil som inneholder engelsk og arabisk tekst åpnet i en hex-redigerer. Du kan tydelig se at tegn i latinsk skrift krever én byte, mens tegn i arabisk skrift lagres med to byte per tegn.

Du kan gjøre et par observasjoner fra dette skjermbildet:

* den arabiske teksten er lagret i en sekvens fra venstre mot høyre, og tegnene er de rå, ubearbeidede (isolerte) versjonene av de arabiske bokstavene og vokaltegnene;
* det finnes ingen tilleggsinformasjon etter den latinske teksten «This is » som forteller programvare som leser denne filen at det neste tegnet er i det arabiske skriftsystemet.

Hvis du setter opp et dokument på flere språk (f.eks. som inneholder engelsk og arabisk), må XeTeX eller LuaTeX under lesing/behandling av inndatafilen (som en strøm av byte) være i stand til å oppdage starten og slutten på hvert tegn og lese riktig antall byte som kreves for å reversere UTF-8-transformasjonen og generere det tilsvarende Unicode-kodepunktet. Det er selve UTF-8-algoritmen som gjør dette mulig for programvaren: den gjør det mulig å oppdage den første byten i hvert enkelt tegn og hvor mange byte som må leses for å beregne det tilsvarende Unicode-kodepunktet. UTF-8 er enkelt å bruke, men egentlig ganske genialt.

#### Logisk rekkefølge, visningsrekkefølge og OpenType-forming

Hvis du ser nøye på den arabiske teksten ovenfor (العَرَبِيَّة), kan det være vanskelig å se at tekstfilen vår faktisk inneholder 12 individuelle arabiske tegn — særlig hvis du ikke er kjent med det arabiske skriftsystemet! Men hvis du nøye teller de arabiske tegnene som vises på høyre side av skjermbildet ovenfor, kan du se at det er 12 totalt.

For språk med komplekst skriftsystem, som arabisk, er det vår tekstfil *lagrer* og det du *ser på skjermen* er synlig *svært* helt forskjellige! Det du ser når du viser denne teksten i for eksempel en nettleser, er (avhengig av fonten som brukes):

![Bilde av satt arabisk tekst](/files/dcb35006e2e992b5e7111feaaa00ea05ca8bd965)

Men, som skjermbildet ovenfor viser, er det tekstfilen faktisk inneholder dette:

![Bilde av usatt arabisk tekst (isolerte tegn)](/files/f10e1ab7603398d5b72966a46a74d58a3d883e50)

Selv om du ikke er kjent med den kursivaktige naturen til det arabiske skriftsystemet, kan du tydelig se at «noe» har skjedd i løpet av overføringen av arabiske tegn som finnes i en tekstfil til satsing og/eller visning på skjermen (som glyfer). Hvis du er vant til å bruke TeX/LaTeX med skriftsystemer som er enkle, for eksempel latinsk-baserte språk, kan dette være svært forvirrende!

Noen viktige begreper er på spill her, fordi Unicode-tekstfiler handler om å lagre … vel, tekst (Unicode), mens sats- og visningssystemer handler om å bruke fonter og glyfer (OpenType):

* tekstfilen lagret de arabiske tegnene i en rekkefølge fra venstre mot høyre, men arabisk leses/vises fra høyre mot venstre: tekstfiler lagrer tekst i såkalt *logisk rekkefølge*;
* tekstfilen inneholder individuelle tegn som ser svært forskjellige ut fra den faktiske visningen som presenteres på skjermen: tekstfilen inneholder de arabiske tegnene i deres isolerte, ikke-sammenkoblede form.

#### Hva er det som skjer?

Innenfor en tekstfil lagres arabisk som en sekvens fra venstre mot høyre av tegn i isolert form: hvis du tenker over det, lagrer tekstfilen den arabiske teksten i rekkefølgen/sekvensen *som den ble skrevet i* (den *logisk rekkefølge*). Det er først når teksten behandles for visning, eller settes, at den vises i sin korrekte leserekkefølge, ofte omtalt som *visuell rekkefølge* eller *visningsrekkefølge*; i tillegg blir de isolerte formene av de arabiske tegnene *formet* til deres typografisk korrekte visningsversjoner. En måte å tenke på dette er at en enkel tekstfil må lagre tekst (Unicode-tegn) i den mest grunnleggende formen mulig: rå, uformede, individuelle teksttegn — det er systemprogramvarens oppgave å rendre disse tegnene for visning basert på operativsystemet, fontene og sats-/renderingsprogramvaren som er tilgjengelig på visningsenheten.

Når den arabiske teksten i den filen settes/vises, gjennomgår den en prosess kalt *forming*. De individuelle arabiske tegnene konverteres til formede glyfer som korrekt representerer varianten av hvert tegn som kreves i henhold til sammenbindingsreglene i det arabiske skriftsystemet og skrivesystemet. I tillegg vil satsprogramvare av høy kvalitet (med gode OpenType-fonter) legge til ytterligere behandling ved å anvende ekstra typografisk sofistikasjon gjennom en prosess kalt *OpenType-forming*—en prosess som omfatter et bredt spekter av typografiske operasjoner som kan inkludere:

* å erstatte flere individuelle glyfer med én enkelt kompleks ligatur-glyf (svært vanlig i arabisk), eller
* plasseringsoperasjoner som for eksempel justerer posisjonene til arabiske vokaler basert på hvilken glyf de står over eller under.

![Bilde som viser transformasjonen arabisk tekst gjennomgår når den settes](/files/dc4cf7dee98e90a160e7ef7caee529ceb41b910f)

Forskjellen mellom logisk rekkefølge og visuell (visnings-) rekkefølge. I denne grafikken kan du se at arabiske tegn som er lagret i en tekstfil, blir omorganisert og formet når de vises eller settes.

Designere og skapere av avanserte OpenType-fonter bruker svært mye tid og ekspertise på å tilby de sofistikerte typografiske funksjonene som er innebygd i fontene deres.

For å slå av formgivningen som brukes på den arabiske teksten, kan vi bruke det utmerkede, gratis, [BabelPad](http://www.babelstone.co.uk/Software/BabelPad.html) Unicode-teksteditor (kun Windows) som lar deg deaktivere formgivningen for å se de rå, individuelle uforbundne (uformede) tegnene som faktisk finnes i tekstfilen—se nederste halvdel av dette sammensatte skjermbildet:

![Bilde som viser BabelPad-teksteditorens mulighet til å slå av OpenType-formgivning](/files/026725d2cf046a1daf08ba804c321154910b9a49)

Bruk av BabelPad Unicode-teksteditor for å slå på OpenType-formgivning (øverste figur) eller slå den av (nederste figur). Å slå av OpenType-formgivning gjør det mye enklere å redigere arabisk tekst.

Begrepene logisk rekkefølge og visningsrekkefølge, sammen med formgivningsprosessene, kan være ganske forvirrende når du først møter dem under redigering eller satsing med flerspråklige tekstfiler som inneholder komplekse skriftsystemer som arabisk: forhåpentligvis har det ovenstående bidratt til å unngå noe av den første forvirringen.


---

# 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/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.