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

# Unicode, UTF-8 och flerspråkig text: En introduktion

## Unicode och OpenType: Tecken och glyfer

Moderna TeX-motorer, dvs. XeTeX och LuaTeX, har utvecklats från Knuths ursprungliga TeX-motor i hög grad på grund av behovet att hålla jämna steg med utvecklingen i tekniklandskapet, särskilt Unicode (för text) och OpenType (för typsnitt). I dag kan LaTeX-användare, genom att använda paket som [fontspec](https://ctan.org/pkg/fontspec?lang=en) och [unicode-math](https://ctan.org/pkg/unicode-math?lang=en), få tillgång till extremt avancerade sättningsfunktioner som tillhandahålls av OpenType-typsnitt — inklusive avancerad flerspråkig sättning och OpenType-baserad matematiksättning ([som banades väg för av Microsoft](https://blogs.msdn.microsoft.com/murrays)).

Men för att få ut det mesta av att använda OpenType-typsnitt med XeTeX/LuaTeX kan det vara hjälpsamt att bekanta sig med ett antal bakgrundsämnen/begrepp — särskilt för felsökning av problem eller för att bana väg för mer avancerat/komplext arbete. Till exempel kan du läsa att XeTeX- och LuaTeX-motorerna använder ”UTF-8-indata” eller att de är ”Unicode-medvetna”, och vidare läsning om OpenType-typsnitt kan diskutera eller nämna ämnen som ”Unicode-kodning”, OpenType-”teckensnittsfunktioner”, ”glyfer”, ”glyf-ID:n”, ”glyfnamn” och så vidare. Vårt mål är att ge en introduktion till dessa termer/ämnen och sammanställa en grundläggande ram för att visa hur de är relaterade och, förhoppningsvis, ge stöd för vidare arbete eller problemlösning.

De ämnen vi avser att täcka faller ganska tydligt in i två huvudområden: *Unicode* som i praktiken befolkar världen av text/tecken och textkodning och *OpenType* vars värld är en av typsnitt och glyfer; men naturligtvis är dessa två världar sammankopplade och det finns en viss överlappning, även i denna första artikel.

### Vilka ämnen ska vi diskutera?

Huvudfokus i denna artikel är några Unicode-relaterade ämnen: vi börjar med en diskussion om vad som menas med ett ”tecken” och går vidare med att introducera skriftsystem/språk, Unicode-kodning och UTF-8 — tillsammans med ett exempel på arbete med flerspråkiga textfiler. En uppföljande artikel kommer att bygga vidare på detta och ta upp bakgrundsämnen relaterade till OpenType-typsnittsteknik. Klart är att det inom ramen för ett blogginlägg inte är möjligt att försöka göra en ”djupdykning” i alla de områden vi hoppas diskutera: vårt uttalade mål är att ge den övergripande ram som visar hur några nyckelbegrepp hänger ihop och samverkar. Vi börjar med det mest grundläggande begreppet: det *tecknet*.

## Tecknet: En grundläggande byggsten

En grundläggande idé/begrepp som står i centrum för våra diskussioner (och för Unicode) är betydelsen av ett ”tecken”: det är ett av de där orden vars betydelse ofta ”tas för given” genom dess användning i vardagligt arbete och samtal. Men ur Unicode-, sättnings- och typsnittsteknikens perspektiv behöver vi vara lite mer precisa och definiera vad som menas med ”ett tecken”. Till exempel kan det vara helt naturligt för oss att tänka på **a** och *a* som olika ”tecken”: ”fet a” och ”kursiv a”. Men inte riktigt: de är bara olika visuella representationer av samma grundläggande tecken, som Unicode ger det officiella namnet [LATIN SMALL LETTER A](http://unicode.org/charts/PDF/U0000.pdf).

Unicode [definierar ett tecken](http://www.unicode.org/glossary/#character) som:

> ”Den minsta komponenten i skriftspråk som har semantiskt värde; syftar på den abstrakta betydelsen och/eller formen, snarare än en specifik form...”

som tydligt skiljer mellan ett teckens specifika *det visuella utseendet* och dess *betydelse*.

Du kan tänka på ett tecken som den grundläggande enheten, eller byggstenen, i ett språk eller, mer korrekt, ett *skriftsystemet*—ett ämne vi diskuterar nedan. Hur ett tecken faktiskt ser ut när det visas med ett visst typsnitt är inte relevant för Unicode-definitionen av ett tecken: endast *betydelse* är av verkligt intresse här: tecknets *roll och syfte* för varje tecken som en av en uppsättning byggstenar av vilka skriftsystem/språk slutligen konstrueras.

### Skriftsystem och språk

Det är värt att kort nämna två viktiga begrepp: *skriftsystem* och *språken*. Unicode-webbplatsen ger en användbar [definition av ett skriftsystem](https://www.unicode.org/standard/supported.html):

> ”Unicode-standarden kodar skriftsystem snarare än språk. När skriftsystem för mer än ett språk delar uppsättningar av grafiska symboler som historiskt har släktledda härledningar, behandlas föreningen av alla dessa grafiska symboler som en enda samling tecken för kodning och identifieras som ett enda skriftsystem.”

Med ett [exempel från Wikipedia](https://en.wikipedia.org/wiki/Script_\(Unicode\)), består det latinska skriftsystemet av en viss [teckenuppsättning](http://unicode.org/charts/) som används i flera språk: engelska, franska, tyska, italienska och så vidare. Naturligtvis används inte alla tecken som definieras inom det latinska skriftsystemet av alla språk som bygger på det latinska skriftsystemet — till exempel innehåller det engelska alfabetet inte de accenttecken som finns i andra europeiska språk som franska eller tyska.

### OpenType-typsnitt: skriftsystem och språk

Här går vi över från Unicode till OpenType-typsnitt eftersom begreppen skriftsystem och språk också spelar en extremt viktig roll inom OpenType-typsnittsteknik.

En uppsättning språk som använder samma [skriftsystemet](http://www.unicode.org/glossary/#script) kan vart och ett ha olika typografiska traditioner när det gäller att visa (sätta) text som är skriven på ett visst språk. Ett bra exempel finns i det turkiska språket och [beteendet hos det punktlösa i](https://en.wikipedia.org/wiki/Dotted_and_dotless_I) (se den sidans anteckningar om ligaturer). Typografiska ”regler” som rör skriftsystem/språk är inbyggda i funktionaliteten hos OpenType-typsnitt genom användning av så kallade skriftsystems- och språk *taggar* som används för att identifiera regler som ska gälla för särskilda kombinationer av skriftsystem/språk. Naturligtvis varierar uppsättningen av skriftsystem/språk som stöds av varje OpenType-typsnitt beroende på valen som gjorts av typsnittets skapare och anledningen till att det producerades. Avancerad sättningsprogramvara, som XeTeX eller LuaTeX, kan dra nytta av dessa regler (inbyggda i OpenType-typsnitt) genom att låta användare selektivt tillämpa dem på indatan när de sätter text på ett visst språk — till exempel genom att använda LaTeX [fontspec-paketet](https://ctan.org/pkg/fontspec?lang=en).

#### Att titta inuti ett OpenType-typsnitt: skriftsystem/språk

För att göra detta tydligare följer här en skärmbild som visar det fria [Scheherazade OpenType-typsnittet](http://software.sil.org/scheherazade/download/) öppet i den (också fria) [Microsoft VOLT](https://www.microsoft.com/en-us/Typography/volt.aspx) programvara för typsnittredigering. I den här bilden kan du se de skriftsystem, språk och typografiska funktioner som är inbyggda i Scheherazade — med VOLT kan du lägga till extra funktioner och möjligheter i Scheherazade, men det ligger långt utanför ramen för denna artikel!

![Scheherazade OpenType-typsnittet (i TrueType-variant) öppnat i Microsoft VOLT](/files/f1d8b9c29a9c5fd432d2acf4b66b50d448590c25)

Av denna skärmbild kan du se att Scheherazade stöder de arabiska och latinska skriftsystemen och ger ytterligare specialiserat stöd för flera språk som använder det arabiska skriftsystemet — med hjälp av så kallade OpenType-funktioner, som listas i rutan med grön kant ovan. Vi går inte in på detaljerna kring dessa funktioner, men budskapet här är att högkvalitativa OpenType-typsnitt har mycket intelligens inbyggd, redo att användas av sättningsprogramvara som kan dra nytta av typografiska regler inbyggda i typsnitten.

Den intresserade läsaren kan bläddra i OpenType taggregistret för att se [skriftsystemtaggar](https://www.microsoft.com/typography/otspec/scripttags.htm) och [språktaggar](https://www.microsoft.com/typography/developers/opentype/languagetags.aspx) som för närvarande används inom OpenType-specifikationen.

### Tillbaka till tecken: Olika teckenroller

Mängden tecken som utgör de grundläggande elementen i ett skriftsystem (eller språk) har inte alla samma roll. Till exempel finns det i de flesta språk tecken för *interpunktion*, tecken för numeriska *siffror* såväl som de tecken som vi tänker på som *bokstäver* i alfabetet, som för vissa skriftsystem också finns i versal- och gemenform. Begreppet tecken är ganska brett och Unicode-standarden innehåller specialtecken som är *inte avsedda att visas* men vars uppgift är att ”styra tolkningen eller visningen av text”. Till exempel, när man sätter viss arabisk text kan man vilja tvinga fram, eller förhindra, sammanbindningsbeteendet hos vissa tecken; Unicode-standarden tillhandahåller särskilda kontrolltecken för detta: de så kallade [ZERO WIDTH JOINER](https://en.wikipedia.org/wiki/Zero-width_joiner) och [ZERO WIDTH NON-JOINER](https://en.wikipedia.org/wiki/Zero-width_non-joiner). Dessa tecken är inte avsedda för visning och ”absorberas” av programvara medan texten bearbetas för att åstadkomma deras avsedda visuella effekter.

Alla tecken som anges inom Unicode-standarden tilldelas en uppsättning egenskaper som i praktiken beskriver varje teckens roll och syfte i Unicode-kodningen — teckennamn, såsom LATIN SMALL LETTER A, är bara ett element i ett teckens egenskapslista. Dessa egenskaper beskrivs fullständigt i [Unicode Character Database (UCD)](http://www.unicode.org/reports/tr44/) och används i stor utsträckning i datoriserade textbehandlingsoperationer som sökning, sortering, stavningskontroll och så vidare. Datafiler som listar Unicode-teckens egenskaper är också [tillgängliga för nedladdning](http://www.unicode.org/Public/UCD/latest/).

Bland de egenskaper som tilldelas varje tecken är den viktigaste för vår diskussion en *numerisk identifierare* som tilldelas av dess Unicode-kodning, ett ämne vi nu går över till.

### Tecken: Siffror och kodningar

Det säger sig självt, men datorer och andra digitala enheter sysslar med att lagra och bearbeta numeriska data: så hur hänger detta ihop med text? När du skriver text med ett datortangentbord eller genom att trycka på skärmen på en mobil enhet omvandlas dina tangenttryckningar till siffror som representerar den teckensträng du skriver.

Vid någon tidpunkt kanske du vill överföra den texten (en sekvens av siffror) via e-post, ett textmeddelande eller via onlinekommunikation som en tweet eller ett inlägg på någon form av sociala medier. Uppenbarligen måste den enhet där du skrev texten och den eller de enheter som används av mottagaren/mottagarna på något sätt vara överens om vilka siffror som representerar vilka tecken. Om inte kanske din text inte visas korrekt på mottagarens enhet.

För att dagens globala kommunikation ska fungera behöver sändande och mottagande enheter någon ”ömsesidigt överenskommen konvention” genom vilken en viss uppsättning siffror representerar en specifik uppsättning tecken. Denna konvention kallas en *kodning*: en uppsättning siffror som används för att representera en viss uppsättning tecken, och Unicode-kodningen är nu den *de facto* globala standarden.

## Unicode: bitar och byte för att lagra text

Unicode är en enorm standard som omfattar långt, långt mer än bara textkodning, men här fokuserar vi endast på den kodning den tillhandahåller.

#### Bitar, byte och hur många tecken?

Vi nämnde att enheter lagrar och representerar text som siffror — närmare bestämt kommer tecken att lagras som heltal: hela tal. För att förstå konsekvenserna av detta för Unicode-kodning behöver vi ha en *mycket* kort, *mycket* grundläggande genomgång av hur datorer lagrar heltal (vi har inte för avsikt att ge oss in på datavetenskap).

För att göra en mycket lång historia kort lagrar dagens stationära eller handhållna enheter heltal i diskreta ”bitar” som kan vara 1, 2, 4 eller 8 byte långa. Var och en av dessa lagringsenheter kan lagra heltal upp till ett maximalt positivt värde baserat på det totala antalet bitar som ingår i varje lagringsenhet:

* 1 byte (8 bitar): maximalt positivt heltal är 255;
* 2 byte (16 bitar): maximalt positivt heltal är 65535;
* 4 byte (32 bitar): maximalt positivt heltal är 4 294 967 295;
* 8 byte (64 bitar): maximalt positivt heltal är 18 446 744 073 709 551 615.

I praktiken använder Unicode-standarden siffror i intervallet 0 till 1 114 111 för att koda alla världens tecken, vilket innebär att den bara behöver 21 bitar för att koda hela intervallet. Vi kan se detta genom att notera att lagringsenheter som innehåller n bitar kan representera vilket positivt heltal som helst från 0 upp till ett maximalt värde på $$2^n -1$$; följaktligen:

* det maximala värde som kan lagras i 20 bitar är $$2^{20} -1 = 1,048,575$$ (för litet);
* det maximala värde som kan lagras i 21 bitar är $$2^{21} -1 = 2,097,151$$ (tillräckligt stort).

Vi har noterat att datorer lagrar data (siffror) i enheter om 1, 2, 4 (eller 8) byte, så hur stor behöver lagringsenheten vara om vi måste lagra värden upp till det maximala Unicode-värdet 1 114 111? Uppenbarligen kan en lagringsenhet på en byte innehålla ett maximalt värde på 255 och 2 byte kan lagra 65535: ingen av dessa räcker för att lagra hela intervallet av tecken som kodas av Unicode. Nästa tillgängliga alternativ är lagringsenheter vars storlek är 4 byte, vilket kan lagra heltal upp till maximalt 4 294 967 295, vilket är långt mer än vi faktiskt skulle behöva. Så om vi valde 4 byte som vår lagringsenhet skulle vi definitivt ha mer än tillräckligt med utrymme för att lagra alla Unicode-värden, där varje tecken lagras som ett heltal som kräver 4 byte (32 bitar). Men att använda 4 byte för att lagra allt är mycket slösaktigt med utrymme eftersom även de största Unicode-värdena behöver högst 21 bitar — vilket, om det lagras med 32 bitar, skulle innebära att 11 av dessa 32 bitar aldrig skulle användas.

**Obs**: Även om Unicode-intervallet sträcker sig från 0 till 1 114 111 används inte varje värde i det intervallet faktiskt: av tekniska skäl anses vissa värden vara ogiltiga för faktisk användning som Unicode-tecken.

### Så vad är UTF-8?

Om du läser om XeTeX eller LuaTeX kommer du nästan säkert att stöta på förklaringar som säger att dessa TeX-motorer läser text och LaTeX-indatafiler i ”UTF-8-format”. Så vad är ”UTF-8-format” och hur förhåller det sig till Unicode? I Unicode-terminologi kallas vart och ett av dess 1 114 112 värden (från 0 till 1 114 111) som används för att koda världens tecken en [kodpunkt](http://www.unicode.org/glossary/#code_point).

Vi har sett att, *i teorin*, skulle vi behöva lagra all vår Unicode-kodade text med 4 byte per tecken för att kunna representera hela intervallet av Unicodes kodpunkter. Men i praktiken uppfann en del ganska kloka människor ett enkelt sätt att representera ett enskilt Unicode-nummer (kodpunkt) som en *sekvens* av mindre siffror, där var och en av dessa mindre siffror lagras i en enda byte: en process som *omvandlar* ett enda (större) heltal till en sekvens av mindre (byte-stora) sådana. På grund av denna omvandling representeras tecknen i vår textfil inte längre var och en av ett enda numeriskt värde: varje tecken blir en *flerbytessekvens*—allt från 1 till 4 (sekventiella) byte i textfilen kan representera ett enda enskilt Unicode-tecken (dvs. dess kodpunktsvärde).

UTF står för *Unicode Transformation Format* och nyckelordet här är *Transformation*. I huvudsak kan du tänka på UTF-8 som ett ”recept” eller en algoritm för att omvandla (transformera) ett enda Unicode-kodpunktsvärde till en sekvens av 1 till 4 bytessmå bitar. Allteftersom värdet på Unicode-kodpunkten ökar ökar också antalet enskilda byte som krävs för att representera det i UTF-8-format.

Det finns tekniska och historiska skäl till att UTF-8 skapades och historien bakom uppfinningen av UTF-8 är [dokumenterad i ett fascinerande e-postmeddelande från 2003](https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt), som tidigt i e-postmeddelandet innehåller raden:

> ”Det stämmer inte. UTF-8 designades, inför mina ögon, på en bordsunderlägg på en diner i New Jersey en kväll i september eller så 1992.”

#### Ett exempel: den arabiska bokstaven ل

Låt oss ta ett exempel med den arabiska bokstaven ل (Unicode-namnet ARABIC LETTER LAM) som tilldelats Unicode-kodpunktsvärdet 1604 (decimalt) eller 0644 (hexadecimalt): dess representation i UTF-8 är den *tvåbyte* sekvensen D9 84 (hex) eller, i decimal, 217 132. När man använder UTF-8 som format för att lagra text, i stället för en textfil som innehåller det enda talet 1604 för att representera ل, omvandlas det till två byte-stora värden: 217 och 132 — tecknet ل lagras som en *tvåbytessekvens*. Läsare som vill utforska UTF-8-algoritmen mer i detalj kan hitta en fördjupad förklaring och C-kod på min [personliga blogg](http://www.readytext.co.uk/?p=1284).

När ett program (t.ex. XeTeX eller LuaTeX) läser text i UTF-8-format behöver programmet fastställa Unicode-värdet för varje tecken som finns i den filen, så det använder en algoritm för att *vända* UTF-8-omvandlingsprocessen. Genom den ”omvända algoritmen” kombineras de två byten (217 och 132) på nytt för att generera heltalet 1604, som sedan kan kännas igen som Unicode-kodpunktsvärdet för den arabiska bokstaven ل.

Så, sammanfattningsvis är UTF-8 verkligen bara ett mellanliggande dataformat som används för lagring och överföring av Unicode-kodad text.

**Obs**: Vissa system väljer att använda/lagra text med 32 bitar per tecken, detta kallas [UTF-32](https://en.wikipedia.org/wiki/UTF-32)—det finns också [UTF-16](https://en.wikipedia.org/wiki/UTF-16) men UTF-8 är det vanligaste sättet att lagra Unicode-kodad text.

## Flerspråkiga TeX-filer: XeTeX och LuaTeX

Både XeTeX och LuaTeX kan göra mycket avancerad flerspråkig sättning, även om deras mekanismer för att uppnå detta är ganska olika och återspeglar varje motors design-/utvecklingsfilosofi. Vi kommer inte att utforska detta på djupet utan bara notera att XeTeX-motorn innehåller programkomponenter (inbyggda i dess körbara fil) som inte finns i LuaTeX — mest anmärkningsvärt programvara för en process som kallas *OpenType-formning* (t.ex. via ett bibliotek som heter [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)).

LuaTeX, däremot, använder ett annat tillvägagångssätt: i stället för att bygga in funktioner direkt i själva TeX-motorn tillhandahåller LuaTeX en extremt rik samling av kommandon (TeX-primitiver) och ett mycket kraftfullt [Lua-baserat API](/latex/sv/fordjupade-artiklar/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md) genom vilket utvecklare kan konstruera lika avancerade lösningar för flerspråkig sättning. Även om LuaTeX-filosofin kan innebära extra arbete för LaTeX-paketsutvecklare, ger den en stor mängd ytterligare flexibilitet eftersom lösningarna inte är ”hårdkodade” i själva LuaTeX-motorn, utan konstrueras av TeX- och Lua-kod — eller insticksmoduler skrivna i C/C++.

**Sidospår**: Läsare som vill utforska den fascinerande men komplexa världen av OpenType-formning vidare kan vara intresserade av att läsa om det utmärkta öppen källkod-biblioteket som heter [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)—använt av många program, inklusive Firefox, Chrome och LibreOffice och, naturligtvis, av XeTeX. Författaren till denna artikel har använt HarfBuzz för att skapa [LuaTeX-insticksmoduler för att göra arabisk sättning](http://www.readytext.co.uk/?p=3186).

Det är numera vardagsmat (t.ex. på sociala medier) att överföra text som innehåller tecken från flera språk, och en UTF-8-textfil som lagrar flerspråkig text kan lätt innehålla tecken vars representation i UTF-8 är 1, 2, 3 eller 4 byte lång. Så i praktiken är en UTF-8-textfil bara en ström av enskilda byte, men varje faktiskt tecken i den filen kan vara allt från 1 till 4 byte långt: de enskilda tecknen har blivit *flerbytessekvenser*.

För att vidare utforska några viktiga aspekter av att arbeta med (sättnings) flerspråkig text använder vi ett exempel som innehåller det arabiska skriftsystemet eftersom arabiskan ger oss utrymme att behandla flera begrepp.

#### Sidospår: det arabiska skriftsystemet

Den [Det arabiska skriftsystemet](https://en.wikipedia.org/wiki/Arabic_script) skrivs i en kursiv stil som läses och skrivs från höger till vänster. Varje arabisk bokstav kan potentiellt anta en av 4 olika former beroende på:

* om den visas som ett enskilt, fristående (isolerat) tecken (inte sammanbundet med något annat);
* om den förekommer inom ett ord — i början, mitten eller slutet av ett ord: benämns *initial*, *medial* och *slutlig* former respektive.

Varje tecken i det arabiska skriftsystemet har sin egen uppsättning sammanbindningsregler och kan, eller kanske inte, ändra form/utseende när det har ett annat tecken till vänster, till höger eller både till vänster och höger. Läsare som är intresserade av att utforska detta vidare kan hitta en [fullständig lista på Wikipedia](https://en.wikipedia.org/wiki/Template:Arabic_alphabet_shapes/joining).

#### Exempel: Arabisk och engelsk text i UTF-8

Anta att vi skapar en UTF-8-textfil som innehåller en enda rad med engelsk och arabisk text: This is العَرَبِيَّة text!

Den här textraden innehåller 3 blanksteg, 11 engelska (latinskt skriftsystem) tecken och 12 arabiska tecken (även om det kanske inte är omedelbart uppenbart). När den sparas som en UTF-8-textfil upptar den 38 byte lagringsutrymme, vilket följer av följande:

* **Latinskt skriftsystem**: blanksteg plus engelsk text: 14 ✕ 1-byte-tecken = 14 byte;
* **Det arabiska skriftsystemet**: 12 arabiska tecken ✕ 2 byte per tecken = 24 byte.

Totalt 14 + 24 = 38 byte.

#### Djupare in i det

Om vi sparar vår exempeltext i en UTF-8-fil som heter `arabic.txt` och öppnar den i en hexeditor kan vi undersöka den för att se de faktiska byte den innehåller. Av studiet av följande kommenterade skärmbild kan du se att den arabiska texten lagras som 2 byte per tecken:

![En UTF-8-textfil som innehåller engelsk och arabisk text öppen i en hexeditor.](/files/647623cb36092e83f9d9e03a00707c6f5fa1747b)

En UTF-8-textfil som innehåller engelsk och arabisk text öppen i en hexeditor. Du kan tydligt se att tecken i det latinska skriftsystemet kräver en enda byte, men tecken i det arabiska skriftsystemet lagras med två byte per tecken.

Du kan dra ett par slutsatser från denna skärmbild:

* den arabiska texten lagras i en vänster-till-höger-sekvens och tecknen är de råa, oformade (isolerade) versionerna av de arabiska bokstäverna och vokalerna;
* det finns ingen ytterligare information efter det latinska skriftsystemet ”This is ” som informerar någon programvara som läser denna fil om att nästa tecken är i det arabiska skriftsystemet.

Om du sätter ett flerspråkigt dokument (t.ex. med engelska och arabiska), måste XeTeX eller LuaTeX under läsning/bearbetning av indatafilen (som en ström av byte) kunna upptäcka början och slutet av varje tecken och läsa det korrekta antal byte som krävs för att reversera UTF-8-omvandlingen och generera motsvarande Unicode-kodpunkt. Det är själva UTF-8-algoritmen som gör detta möjligt för programvara: den möjliggör identifiering av den första byten i varje enskilt tecken och hur många byte som behöver läsas för att beräkna motsvarande Unicode-kodpunkt. UTF-8 är enkelt att använda, men verkligen ganska genialt.

#### Logisk ordning, visningsordning och OpenType-formning

Om du tittar noga på arabiskan ovan (العَرَبِيَّة) kan det vara svårt att se att vår textfil faktiskt innehåller 12 enskilda arabiska tecken — särskilt om du inte är bekant med det arabiska skriftsystemet! Men om du noggrant räknar de arabiska tecken som visas på höger sida av skärmbilden ovan kan du se att det finns 12 totalt.

För språk med komplexa skriftsystem, som arabiska, vad vår textfil *lagrar* och vad du *ser på skärmen* är tydligt *mycket* olika verkligen! Det du ser när du visar den texten i till exempel en webbläsare är (beroende på vilket typsnitt som används):

![Bild av satt arabisk text](/files/57ea28edbed8029441c615a9182e050e08434348)

Men, som skärmbilden ovan visar, vad UTF-8-textfilen faktiskt innehåller är detta:

![Bild av osatt arabisk text (isolerade tecken)](/files/18f6fa6e80052251ae9d3e1212e0937e3f25e8ae)

Även om du inte är bekant med det arabiska skriftsystemets kursiva natur kan du tydligt se att ”något” har hänt under överföringen av arabiska tecken i en textfil till sättning och/eller visning på skärmen (som glyfer). Om du är van vid att använda TeX/LaTeX med språk med enkla skriftsystem, till exempel latinskt baserade språk, kan detta verkligen vara mycket förvirrande!

Några viktiga begrepp är i spel här eftersom Unicode-textfiler sysslar med att lagra… ja, text (Unicode), och sättnings- och visningssystem sysslar med att använda typsnitt och glyfer (OpenType):

* textfilen sparade de arabiska tecknen i vänster-till-höger-ordning men arabiska läses/visas från höger till vänster: textfiler lagrar text i så kallad *logisk ordning*;
* textfilen innehåller enskilda tecken som ser mycket annorlunda ut än den faktiska visningen som presenteras på skärmen: textfilen innehåller de arabiska tecknen i deras isolerade, ej sammanbundna, form.

#### Vad är det som händer?

I en textfil lagras arabiska som en vänster-till-höger-sekvens av tecken i isolerad form: om du tänker efter lagrar textfilen den arabiska texten i den ordning/sekvens *som den skrevs in i* (den *logisk ordning*). Det är först när den texten bearbetas för visning, eller sätts, som den visas i sin korrekta läsordning, ofta kallad *visuell ordning* eller *visningsordning*; dessutom *formas* omvandlas de isolerade formerna av de arabiska tecknen till deras typografiskt korrekta visningsversioner. Ett sätt att tänka på detta är att en enkel textfil måste lagra text (Unicode-tecken) i så grundläggande form som möjligt: råa, oformade, enskilda texttecken — det är systemprogrammets uppgift att rendera dessa tecken för visning baserat på operativsystemet, typsnitten och den sättnings-/renderingsprogramvara som finns tillgänglig på visningsenheten.

När den arabiska texten i den filen sätts/visas genomgår den en process som kallas *formning*. De enskilda arabiska tecknen omvandlas till formade glyfer som korrekt representerar varianten av varje tecken som krävs enligt sammanbindningsreglerna i det arabiska skriftsystemet och skriftsystemet. Dessutom kommer högkvalitativ sättningsprogramvara (som använder bra OpenType-typsnitt) att lägga till ytterligare bearbetning genom att tillämpa ytterligare typografisk sofistikering genom en process som kallas *OpenType-formning*—en process som omfattar ett brett spektrum av typografiska operationer som kan inkludera:

* att ersätta flera enskilda glyfer med en enda komplex ligaturglyf (mycket vanligt i arabiska), eller
* placeringsoperationer som till exempel justerar positionerna för arabiska vokaler beroende på vilken glyf de sitter ovanför eller under.

![Bild som visar transformationen som arabiska texter genomgår när de sätts](/files/3d015479527f9dd0611be9d173af41394ebbea88)

Skillnaden mellan logisk ordning och visuell (visnings-)ordning. I denna grafik kan du se att arabiska tecken som lagras i en textfil genomgår omordning och formning när de visas eller sätts.

Formgivare och skapare av avancerade OpenType-teckensnitt lägger ner mycket tid och expertis på att tillhandahålla de sofistikerade typografiska funktioner som är inbyggda i deras teckensnitt.

För att stänga av formningen som tillämpas på den arabiska texten kan vi använda den utmärkta, kostnadsfria, [BabelPad](http://www.babelstone.co.uk/Software/BabelPad.html) Unicode-textredigeraren (endast Windows) som låter dig inaktivera formningen för att se de råa, enskilda, oanslutna (oformade) tecknen som faktiskt finns i textfilen—se den nedre halvan av denna sammansatta skärmdump:

![Bild som visar BabelPad-textredigerarens möjlighet att stänga av OpenType-formning](/files/9d23365f97112c4b162b9f6ad852c4deb15ff974)

Att använda BabelPad Unicode-textredigeraren för att slå på OpenType-formning (övre bilden) eller stänga av den (nedre bilden). Att stänga av OpenType-formning gör det mycket enklare att redigera arabisk text.

Begreppen logisk ordning och visningsordning, tillsammans med processerna för formning, kan vara ganska förvirrande när man först stöter på dem vid redigering eller sättning med flerspråkiga textfiler som innehåller komplexa skriftsystem såsom arabiska: förhoppningsvis har det ovanstående hjälpt till att undvika en del inledande förvirring.


---

# 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/sv/fordjupade-artiklar/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.