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

# Unicode, UTF-8 en meertalige tekst: een inleiding

## Unicode en OpenType: tekens en glyphen

Moderne TeX-engines, d.w\.z. XeTeX en LuaTeX, zijn grotendeels voortgekomen uit Knuths oorspronkelijke TeX-engine doordat ze moesten meegaan met ontwikkelingen in het technologische landschap, met name Unicode (voor tekst) en OpenType (voor lettertypen). Tegenwoordig kunnen LaTeX-gebruikers, via het gebruik van pakketten zoals [fontspec](https://ctan.org/pkg/fontspec?lang=en) en [unicode-math](https://ctan.org/pkg/unicode-math?lang=en), kunnen LaTeX-gebruikers gebruikmaken van uiterst geavanceerde zetmogelijkheden die door OpenType-lettertypen worden geboden — waaronder geavanceerde meertalige opmaak en op OpenType gebaseerde wiskundige opmaak ([geïntroduceerd door Microsoft](https://blogs.msdn.microsoft.com/murrays)).

Het kan echter nuttig zijn om, om het meeste uit het gebruik van OpenType-lettertypen met XeTeX/LuaTeX te halen, vertrouwd te raken met een aantal achtergrondonderwerpen/-concepten — vooral om problemen op te lossen of de weg vrij te maken voor geavanceerder/complexer werk. U kunt bijvoorbeeld lezen dat de XeTeX- en LuaTeX-engines “UTF-8-invoer” gebruiken of “Unicode-bewust” zijn, en verdere lectuur over OpenType-lettertypen kan onderwerpen bespreken of noemen zoals “Unicode-codering”, OpenType-“lettertypefuncties”, “glyphen”, “glyph-ID’s”, “glyphnamen” enzovoort. Ons doel is een inleiding te geven op deze termen/onderwerpen en een basisraamwerk samen te stellen dat laat zien hoe ze met elkaar samenhangen en, hopelijk, ondersteuning biedt voor verder werk of probleemoplossing.

De onderwerpen die we willen behandelen, vallen vrij netjes in twee hoofdgebieden: *Unicode* dat in feite de wereld van tekst/tekens en tekstcodering bewoont en *OpenType* waarvan de wereld er een is van lettertypen en glyphen; maar natuurlijk zijn die twee werelden met elkaar verbonden en is er enige overlap, zelfs in dit eerste artikel.

### Welke onderwerpen gaan we bespreken?

De belangrijkste focus van dit artikel ligt op enkele Unicode-gerelateerde onderwerpen: we beginnen met een bespreking van wat met een “teken” wordt bedoeld en gaan vervolgens verder met het introduceren van schriften/talen, Unicode-codering en UTF-8 — samen met een voorbeeld van het werken met meertalige tekstbestanden. Een vervolgartikel zal voortbouwen op dit stuk om achtergrondonderwerpen te behandelen die verband houden met OpenType-lettertypetechnologie. Uiteraard is het binnen de grenzen van een blogbericht niet mogelijk om een “deep dive” te maken in alle gebieden die we hopen te bespreken: ons uitgesproken doel is het bieden van het algemene raamwerk dat laat zien hoe enkele kernconcepten met elkaar samenhangen en samenwerken. We beginnen met het meest basale concept: dat van het *teken*.

## Het teken: een basisbouwsteen

Een fundamenteel idee/concept dat centraal staat in onze besprekingen (en in die van Unicode) is de betekenis van een “teken”: het is een van die woorden waarvan de betekenis vaak wordt “verondersteld” door het gebruik ervan in het dagelijks werk en in gesprekken. Vanuit het perspectief van Unicode, zetwerk en lettertypetechnologie moeten we echter iets preciezer zijn en definiëren wat met “een teken” wordt bedoeld. Het zou voor ons bijvoorbeeld heel natuurlijk kunnen zijn om **een** en *een* als verschillende “tekens”: ‘vette a’ en ‘cursieve a’. Maar nee: het zijn slechts verschillende visuele representaties van hetzelfde fundamentele teken, waaraan Unicode de officiële naam geeft [LATIN SMALL LETTER A](http://unicode.org/charts/PDF/U0000.pdf).

Unicode [definieert een teken](http://www.unicode.org/glossary/#character) als:

> “Het kleinste onderdeel van de geschreven taal dat semantische waarde heeft; verwijst naar de abstracte betekenis en/of vorm, in plaats van naar een specifieke vorm...”

waarin duidelijk onderscheid wordt gemaakt tussen de specifieke *visuele uitstraling* en de *betekenis*.

U kunt een teken zien als de fundamentele eenheid, of bouwsteen, van een taal of, nauwkeuriger, van een *schrift*—een onderwerp dat we hieronder bespreken. Hoe een teken er daadwerkelijk uitziet wanneer het met een bepaald lettertype wordt weergegeven, is niet relevant voor Unicode’s definitie van een teken: alleen de *betekenis* is hier echt van belang: de *rol en functie* van elk teken als een van de bouwstenen waaruit schriften/talen uiteindelijk worden opgebouwd.

### Schrift en taal

Het is de moeite waard om kort twee belangrijke concepten te noemen: *schriften* en *talen*. De Unicode-website biedt een nuttige [definitie van een schrift](https://www.unicode.org/standard/supported.html):

> “De Unicode-standaard codeert schriften in plaats van talen. Wanneer schrijfsystemen voor meer dan één taal reeksen grafische symbolen delen die historisch verwante afleidingen hebben, wordt de verzameling van al die grafische symbolen behandeld als één enkele verzameling tekens voor codering en geïdentificeerd als één enkel schrift.”

Met een [voorbeeld van Wikipedia](https://en.wikipedia.org/wiki/Script_\(Unicode\)), bestaat het Latijnse schrift uit een bepaalde [verzameling tekens](http://unicode.org/charts/) die in meerdere talen worden gebruikt: Engels, Frans, Duits, Italiaans enzovoort. Natuurlijk worden niet alle tekens die binnen het Latijnse schrift zijn gedefinieerd door alle talen op basis van het Latijnse schrift gebruikt — het Engelse alfabet bevat bijvoorbeeld niet de accenten die voorkomen in andere Europese talen zoals Frans of Duits.

### OpenType-lettertypen: schriften en talen

Op dit punt stappen we over van Unicode naar OpenType-lettertypen, omdat de concepten schrift en taal ook een uiterst belangrijke rol spelen binnen de OpenType-lettertypetechnologie.

Een reeks talen die hetzelfde [schrift](http://www.unicode.org/glossary/#script) kan elk verschillende typografische tradities hebben als het gaat om het weergeven (zetten) van tekst in een bepaalde taal. Een goed voorbeeld is te vinden in de Turkse taal en het [gedrag van de puntloze i](https://en.wikipedia.org/wiki/Dotted_and_dotless_I) (zie de opmerkingen over ligaturen op die pagina). Typografische “regels” die betrekking hebben op schriften/talen zijn ingebouwd in de functionaliteit van OpenType-lettertypen door middel van zogenoemde script- en taal *tags* tags die worden gebruikt om regels te identificeren die van toepassing moeten zijn op specifieke schrift-/taalcombinaties. Natuurlijk varieert de set schriften/talen die door elk OpenType-lettertype wordt ondersteund afhankelijk van de keuzes van de makers van het lettertype en het doel waarvoor het is gemaakt. Geavanceerde zetsoftware, zoals XeTeX of LuaTeX, kan voordeel halen uit die regels (ingebouwd in OpenType-lettertypen) door gebruikers toe te staan ze selectief toe te passen op de invoertekst bij het zetten van tekst in een bepaalde taal — bijvoorbeeld door het LaTeX [fontspec-pakket](https://ctan.org/pkg/fontspec?lang=en).

#### Kijken in een OpenType-lettertype: schriften/talen

Om dit wat duidelijker te maken, hier is een schermafbeelding van het gratis [Scheherazade OpenType-lettertype](http://software.sil.org/scheherazade/download/) geopend in de (ook gratis) [Microsoft VOLT](https://www.microsoft.com/en-us/Typography/volt.aspx) lettertypebewerkingssoftware. In deze afbeelding ziet u de schriften, talen en typografische functies die in Scheherazade zijn ingebouwd — met VOLT kunt u extra functies en functionaliteit aan Scheherazade toevoegen, maar dat valt ver buiten de scope van dit artikel!

![Het Scheherazade OpenType-lettertype (TrueType-variant) geopend in Microsoft VOLT](/files/145b9e8aa965f1ef4b33f5d1c83c45b14d22a1d8)

Uit deze schermafbeelding kunt u zien dat Scheherazade de Arabische en Latijnse schriften ondersteunt en verdere gespecialiseerde ondersteuning biedt voor verschillende talen die het Arabische schrift gebruiken — met behulp van zogenoemde OpenType-functies, die hierboven in het vak met groene rand worden vermeld. We gaan niet in op de details van deze functies, maar de boodschap hier is dat hoogwaardige OpenType-lettertypen veel intelligentie in zich hebben, klaar voor gebruik door zetsoftware die in staat is gebruik te maken van typografische regels die in lettertypen zijn ingebouwd.

Geïnteresseerde lezers kunnen het OpenType-tagregister raadplegen om de [schrift-tags](https://www.microsoft.com/typography/otspec/scripttags.htm) en [taal-tags](https://www.microsoft.com/typography/developers/opentype/languagetags.aspx) die momenteel binnen de OpenType-specificatie worden gebruikt.

### Terug naar tekens: verschillende tekenrollen

De verzameling tekens waaruit de fundamentele elementen van een schrift (of taal) bestaan, vervult niet allemaal dezelfde rol. In de meeste talen zijn er bijvoorbeeld tekens voor *interpunctie*, tekens voor numerieke *cijfers* en daarnaast de tekens die we beschouwen als *letters* van het alfabet, die voor sommige schriften ook bestaan in hoofdletter- en kleinelettervormen. Het concept van een teken is vrij breed en de Unicode-standaard bevat gespecialiseerde tekens die *niet bedoeld zijn om weergegeven te worden* maar waarvan de taak is “de interpretatie of weergave van tekst te sturen”. Wanneer u bijvoorbeeld Arabische tekst zet, wilt u mogelijk het verbindingsgedrag van bepaalde tekens afdwingen of juist voorkomen; de Unicode-standaard biedt hiervoor speciale controletekens: de zogenoemde [ZERO WIDTH JOINER](https://en.wikipedia.org/wiki/Zero-width_joiner) en de [ZERO WIDTH NON-JOINER](https://en.wikipedia.org/wiki/Zero-width_non-joiner). Die tekens zijn niet bedoeld voor weergave en worden door software “geabsorbeerd” tijdens het verwerken van de tekst om het beoogde visuele effect te produceren.

Aan alle tekens die binnen de Unicode-standaard zijn gespecificeerd, wordt een reeks eigenschappen toegewezen die in feite de rol en functie van elk teken in de Unicode-codering beschrijft — tekennamen, zoals LATIN SMALL LETTER A, zijn slechts één element van de eigenschappenlijst van een teken. Deze eigenschappen worden volledig beschreven in de [Unicode Character Database (UCD)](http://www.unicode.org/reports/tr44/) en worden veel gebruikt bij geautomatiseerde tekstverwerking, zoals zoeken, sorteren, spellingcontrole enzovoort. Gegevensbestanden met een opsomming van Unicode-tekeneigenschappen zijn ook [beschikbaar om te downloaden](http://www.unicode.org/Public/UCD/latest/).

Van de eigenschappen die aan elk teken zijn toegewezen, is voor onze bespreking de belangrijkste een *numerieke identifier* die door zijn Unicode-codering wordt toegewezen; daar gaan we nu op in.

### Tekens: cijfers en coderingen

Het spreekt eigenlijk voor zich, maar computers en andere digitale apparaten zijn bezig met het opslaan en verwerken van numerieke gegevens: hoe verhoudt dit zich dus tot tekst? Terwijl u tekst typt met een computertoetsenbord of door op het scherm van een mobiel apparaat te tikken, worden uw toetsaanslagen omgezet in cijfers die de tekenreeks vertegenwoordigen die u aan het typen bent.

Op een bepaald moment wilt u die tekst (een reeks cijfers) misschien verzenden via e-mail, een sms-bericht of online communicatie zoals een tweet of een bericht op een of ander sociaal medium. Het is duidelijk dat het apparaat waarop u de tekst hebt opgesteld en het apparaat/de apparaten van de ontvanger(s) het op de een of andere manier eens moeten zijn over welke cijfers welke tekens voorstellen. Zo niet, dan wordt uw tekst mogelijk niet correct weergegeven op het apparaat van de ontvanger.

Om de wereldwijde communicatie van vandaag te laten werken, hebben verzendende en ontvangende apparaten een soort “wederzijds afgesproken conventie” nodig waarbij een bepaalde reeks cijfers een specifieke reeks tekens voorstelt. Deze conventie heet een *codering*: een reeks cijfers die wordt gebruikt om een bepaalde reeks tekens weer te geven en de Unicode-codering is nu de *de facto* wereldwijde standaard.

## Unicode: bits en bytes voor het opslaan van tekst

Unicode is een enorme standaard die veel, veel meer omvat dan alleen tekstcodering, maar hier richten we ons alleen op de codering die hij biedt.

#### Bits, bytes en hoeveel tekens?

We noemden al dat apparaten tekst opslaan en weergeven als cijfers — specifiek: tekens worden opgeslagen als gehele getallen. Om de implicaties hiervan voor Unicode-codering te begrijpen, hebben we een *zeer* korte, *zeer* basale, herhaling nodig van hoe computers gehele getallen opslaan (we zijn niet van plan de informatica in te duiken).

Kort samengevat: huidige desktop- of handheldapparaten slaan gehele getallen op in afzonderlijke “brokken” die 1, 2, 4 of 8 bytes lang kunnen zijn. Elk van deze opslageenheden kan gehele getallen opslaan tot een maximale positieve waarde op basis van het totale aantal bits in elke opslageenheid:

* 1 byte (8 bits): het maximale positieve gehele getal is 255;
* 2 bytes (16 bits): het maximale positieve gehele getal is 65535;
* 4 bytes (32 bits): het maximale positieve gehele getal is 4.294.967.295;
* 8 bytes (64 bits): het maximale positieve gehele getal is 18.446.744.073.709.551.615.

In de praktijk gebruikt de Unicode-standaard getallen in het bereik 0 tot 1.114.111 om alle tekens ter wereld te coderen, met als gevolg dat slechts 21 bits nodig zijn om het volledige bereik te coderen. We kunnen dit zien door op te merken dat opslageenheden met n bits elk positief geheel getal van 0 tot een maximale waarde van $$2^n -1$$; bijgevolg:

* de maximale waarde die in 20 bits kan worden opgeslagen is $$2^{20} -1 = 1,048,575$$ (te klein);
* de maximale waarde die in 21 bits kan worden opgeslagen is $$2^{21} -1 = 2,097,151$$ (groot genoeg).

We hebben opgemerkt dat computers gegevens (cijfers) opslaan in eenheden van 1, 2, 4 (of 8) bytes, dus hoe groot moet de opslageenheid zijn als we waarden tot de maximale Unicode-waarde 1.114.111 moeten opslaan? Duidelijk is dat een opslageenheid ter grootte van een byte een maximale waarde van 255 kan bevatten en 2 bytes 65535 kunnen opslaan: geen van beide is voldoende om het volledige bereik van tekens te bewaren dat door Unicode wordt gecodeerd. De volgende beschikbare optie zijn opslageenheden van 4 bytes, die gehele getallen kunnen opslaan tot een maximum van 4.294.967.295 — veel meer dan we werkelijk nodig zouden hebben. Dus als we 4 bytes als opslageenheid kiezen, hebben we zeker meer dan genoeg ruimte om alle Unicodewaarden op te slaan, waarbij elk teken wordt opgeslagen als een geheel getal dat 4 bytes (32 bits) vereist. Het gebruik van 4 bytes om alles op te slaan is echter erg verspilling van ruimte, omdat zelfs de grootste Unicodewaarden maximaal 21 bits nodig hebben — wat, als ze met 32 bits worden opgeslagen, zou betekenen dat 11 van die 32 bits nooit zouden worden gebruikt.

**Opmerking**: Hoewel het Unicode-bereik van 0 tot 1.114.111 loopt, wordt niet elke waarde in dat bereik daadwerkelijk gebruikt: om technische redenen worden sommige waarden beschouwd als ongeldig voor daadwerkelijk gebruik als Unicode-tekens.

### Dus, wat is UTF-8?

Als u over XeTeX of LuaTeX leest, zult u vrijwel zeker uitleg tegenkomen waarin staat dat die TeX-engines tekst en LaTeX-invoerbestanden lezen in “UTF-8-formaat”. Dus wat is “UTF-8-formaat” en hoe verhoudt het zich tot Unicode? In de Unicode-terminologie wordt elk van zijn 1.114.112 waarden (van 0 tot 1.114.111) die worden gebruikt om de tekens van de wereld te coderen, een [codepunt](http://www.unicode.org/glossary/#code_point).

We hebben gezien dat, *in theorie*, we al onze Unicode-gecodeerde tekst zouden moeten opslaan met 4 bytes per teken om het volledige bereik van Unicode-codepunten weer te geven. In de praktijk bedachten enkele vrij slimme mensen echter een eenvoudige manier om één Unicode-getal (codepoint) weer te geven als een *reeks* van kleinere getallen, waarbij elk van die kleinere getallen in één byte wordt opgeslagen: een proces dat *transformeert* één enkel (groter) geheel getal in een reeks kleinere (byte-grote) getallen. Door deze transformatie worden de tekens van ons tekstbestand niet langer elk vertegenwoordigd door één enkele numerieke waarde: elk teken wordt een *meerbyte-sequentie*—alles van 1 tot 4 (opeenvolgende) bytes in het tekstbestand kan één afzonderlijk Unicode-teken (d.w\.z. de waarde van zijn codepoint) vertegenwoordigen.

UTF staat voor *Unicode-transformatieformaat* en het belangrijkste woord hier is *Transformatie*. In wezen kunt u UTF-8 zien als een “recept” of algoritme om één Unicode-codepuntwaarde om te zetten in een reeks van 1 tot 4 byte-grote stukjes. Naarmate de waarde van het Unicode-codepunt toeneemt, neemt ook het aantal afzonderlijke bytes toe dat nodig is om het in UTF-8-formaat weer te geven.

Er zijn technische en historische redenen voor de creatie van UTF-8, en het verhaal achter de uitvinding van UTF-8 is [vastgelegd in een fascinerende e-mail uit 2003](https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt), die in het begin van de e-mail de regel bevat:

> “Dat is niet waar. UTF-8 is ontworpen, voor mijn ogen, op een placemat in een diner in New Jersey op een avond in september of daaromtrent in 1992.”

#### Een voorbeeld: de Arabische letter ل

Laten we de Arabische letter ل nemen (Unicode-naam ARABIC LETTER LAM), waaraan de Unicode-codepuntwaarde 1604 (decimaal) of 0644 (hexadecimaal) is toegewezen: de weergave ervan in UTF-8 is de *tweebyte* reeks D9 84 (hex) of, in decimale vorm, 217 132. Wanneer UTF-8 wordt gebruikt als formaat voor het opslaan van tekst, wordt het teken ل, in plaats van een tekstbestand met het enkele getal 1604 om ل weer te geven, omgezet in twee byte-grote waarden: 217 en 132 — het teken ل wordt opgeslagen als een *tweebyte-sequentie*. Lezers die het UTF-8-algoritme in meer detail willen verkennen, kunnen een diepgaande uitleg en C-code vinden op mijn [persoonlijke blogs van deze auteur](http://www.readytext.co.uk/?p=1284).

Wanneer een softwarepakket (bijv. XeTeX of LuaTeX) tekst in UTF-8-formaat leest, moet die software de Unicode-waarde voor elk teken in dat bestand bepalen, dus gebruikt het een algoritme om *omkeren* het UTF-8-transformatieproces om te keren. Door dat “omkeer-algoritme” worden de twee bytes (217 en 132) opnieuw samengevoegd om het gehele getal 1604 te genereren, dat vervolgens kan worden herkend als de Unicode-codepuntwaarde voor de Arabische letter ل.

Dus, kortom, UTF-8 is eigenlijk slechts een tussengegevensformaat dat wordt gebruikt voor de opslag en overdracht van Unicode-gecodeerde tekst.

**Opmerking**: Sommige systemen kiezen ervoor tekst op te slaan/met 32 bits per teken; dit heet [UTF-32](https://en.wikipedia.org/wiki/UTF-32)—er is ook [UTF-16](https://en.wikipedia.org/wiki/UTF-16) maar UTF-8 is de meest gebruikelijke manier om Unicode-gecodeerde tekst op te slaan.

## Meertalige TeX-bestanden: XeTeX en LuaTeX

Zowel XeTeX als LuaTeX zijn in staat tot zeer geavanceerde meertalige opmaak, hoewel hun mechanismen om dit te bereiken nogal verschillen en de ontwerp-/ontwikkelingsfilosofie van elke engine weerspiegelen. We gaan hier niet diep op in, maar merken alleen op dat de XeTeX-engine softwarecomponenten bevat (ingebouwd in het uitvoerbare bestand) die niet aanwezig zijn in LuaTeX — met name software voor een proces genaamd *OpenType-vormgeving* (bijv. via een bibliotheek genaamd [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)).

LuaTeX daarentegen hanteert een andere aanpak: in plaats van functionaliteit direct in de eigenlijke TeX-engine in te bouwen, biedt LuaTeX een uiterst rijke verzameling opdrachten (TeX-primitieven) en een zeer krachtige [op Lua gebaseerde API](/latex/nl/diepgaande-artikelen/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md) waarmee ontwikkelaars even geavanceerde oplossingen voor meertalige opmaak kunnen bouwen. Hoewel de LuaTeX-filosofie extra werk kan betekenen voor ontwikkelaars van LaTeX-pakketten, biedt zij veel extra flexibiliteit omdat oplossingen niet “hard coded” zijn in de eigenlijke LuaTeX-engine zelf, maar worden opgebouwd uit TeX- en Lua-code — of plug-ins geschreven in C/C++.

**Terzijde**: Lezers die de fascinerende, maar complexe wereld van OpenType-vormgeving verder willen verkennen, kunnen geïnteresseerd zijn in de uitstekende open-sourcelibrary genaamd [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)—gebruikt door vele toepassingen, waaronder Firefox, Chrome en LibreOffice en, uiteraard, door XeTeX. De auteur van dit artikel heeft HarfBuzz gebruikt om [LuaTeX-plug-ins voor Arabische opmaak te maken](http://www.readytext.co.uk/?p=3186).

Tegenwoordig is het heel gebruikelijk (bijv. op sociale media) om tekst te verzenden die tekens uit meerdere talen bevat, en een UTF-8-tekstbestand met meertalige tekst kan gemakkelijk tekens bevatten waarvan de weergave in UTF-8 1, 2, 3 of 4 bytes lang is. Een UTF-8-tekstbestand is in feite dus slechts een stroom van afzonderlijke bytes, maar elk daadwerkelijk teken in dat bestand kan ergens tussen 1 en 4 bytes lang zijn: de afzonderlijke tekens zijn *meerbyte-sequenties*.

Om enkele belangrijke aspecten van het werken met (zet) meertalige tekst verder te verkennen, gebruiken we een voorbeeld met het Arabische schrift, omdat Arabisch ons de ruimte biedt om meerdere concepten te behandelen.

#### Terzijde: het Arabische schrift

De [Arabische schrift](https://en.wikipedia.org/wiki/Arabic_script) wordt in een cursieve stijl geschreven en van rechts naar links gelezen en geschreven. Elke Arabische letter kan, in principe, een van 4 verschillende vormen aannemen, afhankelijk van:

* of het wordt weergegeven als een enkel, zelfstandig (geïsoleerd) teken (niet verbonden met iets anders);
* of het binnen een woord voorkomt — aan het begin, in het midden of aan het einde van een woord: aangeduid als *initiële*, *mediale* en *final* vormen respectievelijk.

Elk teken van het Arabische schrift heeft zijn eigen set verbindingsregels en kan, maar hoeft niet, van vorm/uiterlijk veranderen wanneer er een ander teken links, rechts of zowel links als rechts staat. Lezers die dit verder willen verkennen, kunnen een [volledige lijst op Wikipedia](https://en.wikipedia.org/wiki/Template:Arabic_alphabet_shapes/joining).

#### Voorbeeld: Arabische en Engelse tekst in UTF-8

Stel dat we een UTF-8-tekstbestand maken met één regel Engelse en Arabische tekst: This is العَرَبِيَّة text!

Deze tekstregel bevat 3 spatietekens, 11 Engelse tekens (Latijns schrift) en 12 Arabische tekens (hoewel dat misschien niet meteen duidelijk/zichtbaar is). Wanneer het als UTF-8-tekstbestand wordt opgeslagen, neemt het 38 bytes opslagruimte in beslag, als volgt opgebouwd:

* **Latijns schrift**: spaties plus Engelse tekst: 14 ✕ tekens van 1 byte = 14 bytes;
* **Arabische schrift**: 12 Arabische tekens ✕ 2 bytes per teken = 24 bytes.

In totaal 14 + 24 = 38 bytes.

#### Dieper graven

Als we onze voorbeeldtekst opslaan in een UTF-8-bestand met de naam `arabic.txt` en openen in een hexadecimale editor, kunnen we het onderzoeken om de werkelijke bytes te zien die het bevat. Uit bestudering van de volgende geannoteerde schermafbeelding kunt u zien dat de Arabische tekst wordt opgeslagen als 2 bytes per teken:

![Een UTF-8-tekstbestand met Engelse en Arabische tekst geopend in een hex-editor.](/files/64b01d9e31fda86525f07c5e290a91365243607d)

Een UTF-8-tekstbestand met Engelse en Arabische tekst geopend in een hex-editor. U kunt duidelijk zien dat tekens uit het Latijnse schrift één byte nodig hebben, maar tekens uit het Arabische schrift als twee bytes per teken worden opgeslagen.

U kunt uit deze schermafbeelding een paar observaties afleiden:

* de Arabische tekst wordt opgeslagen in een links-naar-rechts-sequentie en de tekens zijn de ruwe, ongevormde (geïsoleerde) versies van de Arabische letters en klinkertekens;
* er volgt geen extra informatie op het Latijnse schrift “This is ” om software die dit bestand leest te informeren dat het volgende teken in het Arabische schrift staat.

Als u een meertalig document zet (bijv. met Engels en Arabisch), dan moet XeTeX of LuaTeX tijdens het lezen/verwerken van het invoertekstbestand (als een stroom bytes) het begin en einde van elk teken kunnen detecteren en het juiste aantal bytes lezen dat nodig is om de UTF-8-transformatie om te keren en het overeenkomstige Unicode-codepunt te genereren. Het is het UTF-8-algoritme zelf dat software dit mogelijk maakt: het laat de detectie toe van de eerste byte van elk afzonderlijk teken en hoeveel bytes moeten worden gelezen om het overeenkomstige Unicode-codepunt te berekenen. UTF-8 is eenvoudig te gebruiken, maar werkelijk heel ingenieus.

#### Logische volgorde, weergavevolgorde en OpenType-vormgeving

Als u goed kijkt naar het Arabisch hierboven (العَرَبِيَّة), kan het moeilijk zijn te zien dat ons tekstbestand inderdaad 12 afzonderlijke Arabische tekens bevat — vooral als u niet bekend bent met het Arabische schrift! Als u echter zorgvuldig de Arabische tekens telt die aan de rechterkant van de bovenstaande schermafbeelding worden weergegeven, ziet u dat het er in totaal 12 zijn.

Voor talen met complexe schriften, zoals Arabisch, is wat ons tekstbestand *slaat op* en wat u *op het scherm ziet* zichtbaar *zeer* anders inderdaad! Wat u ziet wanneer u die tekst bijvoorbeeld in een browser bekijkt, is (afhankelijk van het gebruikte lettertype):

![Afbeelding van gezette Arabische tekst](/files/36e06de1ea2857aa87f2fb2eec600f58cd672831)

Maar, zoals de bovenstaande schermafbeelding laat zien, bevat het UTF-8-tekstbestand in werkelijkheid dit:

![Afbeelding van niet-gezetten Arabische tekst (geïsoleerde tekens)](/files/68f65d583613503965cc342d2ca98a3094a11968)

Zelfs als u niet bekend bent met het cursieve karakter van het Arabische schrift, kunt u duidelijk zien dat er tijdens het overbrengen van Arabische tekens in een tekstbestand naar zetwerk en/of weergave op het scherm (als glyphen) 'iets' is gebeurd. Als u gewend bent TeX/LaTeX te gebruiken met talen met een eenvoudig schrift, bijvoorbeeld talen op basis van het Latijnse schrift, kan dit inderdaad zeer verwarrend zijn!

Hier spelen enkele belangrijke concepten een rol, omdat Unicode-tekstbestanden zich bezighouden met… nou ja, tekst (Unicode), en zet- en weergavesystemen met lettertypen en glyphen (OpenType):

* het tekstbestand de Arabische tekens in een links-naar-rechts-volgorde opsloeg, maar Arabisch wordt van rechts naar links gelezen/weergegeven: tekstbestanden slaan tekst op in de zogenoemde *logische volgorde*;
* het tekstbestand bevat afzonderlijke tekens die er heel anders uitzien dan de daadwerkelijke weergave op het scherm: het tekstbestand bevat de Arabische tekens in hun geïsoleerde, niet-verbonden vorm.

#### Wat gebeurt hier?

Binnen een tekstbestand wordt Arabisch opgeslagen als een links-naar-rechts-opeenvolging van tekens in geïsoleerde vorm: als u erover nadenkt, slaat het tekstbestand de Arabische tekst op in de volgorde/opeenvolging *waarin het is getypt* (de *logische volgorde*). Pas wanneer die tekst wordt verwerkt voor weergave of gezet, wordt deze in de juiste leesvolgorde weergegeven, vaak aangeduid als de *visuele volgorde* of *weergavevolgorde*; bovendien worden de geïsoleerde vormen van de Arabische tekens *gevormd* tot hun typografisch correcte weergaveversies. Een manier om dit te bekijken is dat een eenvoudig tekstbestand tekst (Unicode-tekens) in de meest basale mogelijke vorm moet opslaan: ruwe, ongevormde, afzonderlijke teksttekens — het is de taak van systeemsoftware om die tekens voor weergave te renderen op basis van het besturingssysteem, de lettertypen en de zet-/renderingssoftware die beschikbaar zijn op het weergaveapparaat.

Wanneer de Arabische tekst in dat bestand wordt gezet/weergegeven, ondergaat die een proces genaamd *vormgeven*. De afzonderlijke Arabische tekens worden omgezet in gevormde glyphen die correct de variant van elk teken weergeven die vereist is volgens de verbindingsregels van het Arabische schrift en schrijfsysteem. Daarnaast zal hoogwaardige zetsoftware (met goede OpenType-lettertypen) verdere verwerking toevoegen door extra typografische verfijning toe te passen via een proces genaamd *OpenType-vormgeving*—een proces dat een breed scala aan typografische bewerkingen omvat, waaronder:

* het vervangen van meerdere afzonderlijke glyphs door één complexe ligatuurglyph (zeer gebruikelijk bij Arabisch), of
* plaatsingsbewerkingen die bijvoorbeeld de posities van Arabische klinkers aanpassen op basis van het glyph waarboven of -onder ze staan.

![Afbeelding die de transformatie toont die Arabische tekst ondergaat wanneer deze wordt gezet](/files/c7bd36c44f9038f463b02dbe3ebb91d33d9e5a53)

Het verschil tussen logische volgorde en visuele (weergave-)volgorde. In deze grafiek zie je dat Arabische tekens die in een tekstbestand zijn opgeslagen, opnieuw geordend en gevormd worden wanneer ze worden weergegeven of gezet.

Ontwerpers en makers van geavanceerde OpenType-lettertypen investeren zeer veel tijd en expertise om de geavanceerde typografische mogelijkheden te bieden die in hun lettertypen zijn ingebouwd.

Om de vormgeving die op de Arabische tekst wordt toegepast uit te schakelen, kunnen we gebruikmaken van de uitstekende, gratis, [BabelPad](http://www.babelstone.co.uk/Software/BabelPad.html) Unicode-teksteditor (alleen Windows) waarmee je de vormgeving kunt uitschakelen om de ruwe, afzonderlijke, niet-verbonden (ongevormde) tekens te zien die daadwerkelijk in het tekstbestand aanwezig zijn—zie de onderste helft van deze gecombineerde schermafbeelding:

![Afbeelding die het vermogen van de BabelPad-teksteditor toont om OpenType-vormgeving uit te schakelen](/files/d01e9ce4d9aa14fc8b3d5a4feb5bef6800a95990)

De Unicode-teksteditor BabelPad gebruiken om OpenType-vormgeving in te schakelen (bovenste afbeelding) of uit te schakelen (onderste afbeelding). OpenType-vormgeving uitschakelen maakt het veel gemakkelijker om Arabische tekst te bewerken.

De concepten logische volgorde en weergavevolgorde, samen met de processen van vormgeving, kunnen behoorlijk verwarrend zijn wanneer je er tijdens het bewerken of zetten van meertalige tekstbestanden met complexe schriftsoorten zoals Arabisch voor het eerst mee in aanraking komt: hopelijk heeft het bovenstaande geholpen om enige eerste verwarring te voorkomen.


---

# 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/nl/diepgaande-artikelen/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.