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

# Unicode, UTF-8 i tekst wielojęzyczny: Wprowadzenie

## Unicode i OpenType: znaki i glify

Nowoczesne silniki TeX-a, tj. XeTeX i LuaTeX, wyewoluowały z oryginalnego silnika TeX Knutha głównie z powodu potrzeby nadążania za zmianami w krajobrazie technologicznym, szczególnie Unicode (dla tekstu) i OpenType (dla czcionek). Dziś, dzięki użyciu pakietów takich jak [fontspec](https://ctan.org/pkg/fontspec?lang=en) i [unicode-math](https://ctan.org/pkg/unicode-math?lang=en), użytkownicy LaTeX-a mogą korzystać z niezwykle zaawansowanych możliwości składu zapewnianych przez czcionki OpenType — w tym zaawansowanego wielojęzycznego składu oraz składu matematycznego opartego na OpenType ([zapoczątkowany przez firmę Microsoft](https://blogs.msdn.microsoft.com/murrays)).

Jednak aby w pełni wykorzystać czcionki OpenType z XeTeX/LuaTeX, pomocne może być zapoznanie się z wieloma zagadnieniami/pojęciami wprowadzającymi — zwłaszcza w celu rozwiązywania problemów lub przygotowania gruntu pod bardziej zaawansowaną/złożoną pracę. Na przykład możesz przeczytać, że silniki XeTeX i LuaTeX używają „wejścia UTF-8” albo że są „świadome Unicode”, a dalsza lektura o czcionkach OpenType może omawiać lub wspominać takie tematy jak „kodowanie Unicode”, „funkcje fontu” OpenType, „glify”, „identyfikatory glifów”, „nazwy glifów” i tak dalej. Naszym celem jest wprowadzenie do tych terminów/tematów i zbudowanie podstawowych ram pokazujących, jak są ze sobą powiązane oraz, miejmy nadzieję, zapewnienie wsparcia dla dalszej pracy lub rozwiązywania problemów.

Tematy, które zamierzamy omówić, dość wyraźnie dzielą się na dwa główne obszary: *Unicode* który w istocie zamieszkuje świat tekstu/znaków i kodowania tekstu oraz *OpenType* którego światem są czcionki i glify; ale oczywiście te dwa światy są ze sobą powiązane i występuje między nimi pewne nakładanie się, nawet w tym pierwszym artykule.

### O jakich tematach będziemy rozmawiać?

Głównym tematem tego artykułu są niektóre zagadnienia związane z Unicode: zaczniemy od omówienia tego, co rozumie się przez „znak”, a następnie wprowadzimy pisma/języki, kodowanie Unicode i UTF-8 — wraz z przykładem pracy z wielojęzycznymi plikami tekstowymi. Artykuł uzupełniający rozwinie ten materiał, aby omówić zagadnienia wprowadzające związane z technologią czcionek OpenType. Oczywiście, w ramach wpisu blogowego nie da się podjąć próby „dogłębnego zanurzenia się” we wszystkich obszarach, o których chcielibyśmy mówić: naszym deklarowanym celem jest przedstawienie ogólnych ram pokazujących, jak kilka kluczowych pojęć jest ze sobą powiązanych i współdziała. Zaczniemy od najbardziej podstawowego pojęcia: tego *znaku*.

## Znak: podstawowy element składowy

Jedną z fundamentalnych idei/pojęć, które leżą u podstaw naszych rozważań (i Unicode), jest znaczenie „znaku”: to jedno z tych słów, których znaczenie często jest „zakładane” na podstawie ich użycia w codziennej pracy i rozmowach. Jednak z perspektywy Unicode, składu i technologii fontów musimy być nieco bardziej precyzyjni i zdefiniować, co rozumie się przez „znak”. Na przykład dość naturalne może być dla nas myślenie o **a** i *a* jako o różnych „znakach”: „a pogrubione” i „a kursywne”. Ale nie: są one jedynie różnymi wizualnymi reprezentacjami tego samego podstawowego znaku, któremu Unicode nadaje oficjalną nazwę [ŁACIŃSKA MAŁA LITERA A](http://unicode.org/charts/PDF/U0000.pdf).

Unicode [definiuje znak](http://www.unicode.org/glossary/#character) jako:

> „Najmniejszy składnik języka pisanego, który ma wartość semantyczną; odnosi się do znaczenia abstrakcyjnego i/lub kształtu, a nie do konkretnego kształtu...”

które wyraźnie rozróżnia specyficzny *wyglądem wizualnym* i jego *znaczenie*.

Można myśleć o znaku jako o fundamentalnej jednostce, albo elemencie składowym, języka, a dokładniej: *pismo*—temat, który omawiamy poniżej. To, jak znak faktycznie wygląda po wyświetleniu przy użyciu określonej czcionki, nie ma znaczenia dla definicji znaku w Unicode: liczy się jedynie *znaczenie* naprawdę istotne jest tutaj: *rola i przeznaczenie* każdego znaku jako jednego z zestawu elementów budulcowych, z których ostatecznie konstruowane są pisma/języki.

### Pismo i język

Warto krótko wspomnieć o dwóch ważnych pojęciach: *pisma* i *języki*. Witryna Unicode udostępnia użyteczną [definicję pisma](https://www.unicode.org/standard/supported.html):

> „Standard Unicode koduje pisma, a nie języki. Gdy systemy pisma dla więcej niż jednego języka współdzielą zbiory symboli graficznych, których pochodzenie jest historycznie powiązane, unia wszystkich tych symboli graficznych jest traktowana jako pojedynczy zbiór znaków do kodowania i jest identyfikowana jako pojedyncze pismo.”

Korzystając z [przykładu z Wikipedii](https://en.wikipedia.org/wiki/Script_\(Unicode\)), pismo łacińskie składa się z określonego [zbioru znaków](http://unicode.org/charts/) które są używane w wielu językach: angielskim, francuskim, niemieckim, włoskim i tak dalej. Oczywiście nie wszystkie znaki zdefiniowane w ramach pisma łacińskiego są używane przez wszystkie języki oparte na tym piśmie — na przykład alfabet angielski nie zawiera znaków z akcentami obecnych w innych językach europejskich, takich jak francuski czy niemiecki.

### Czcionki OpenType: pisma i języki

W tym miejscu przejdziemy od Unicode do czcionek OpenType, ponieważ pojęcia pisma i języka odgrywają również niezwykle ważną rolę w technologii czcionek OpenType.

Zestaw języków, które używają tego samego [pismo](http://www.unicode.org/glossary/#script) może mieć odmienne tradycje typograficzne, jeśli chodzi o wyświetlanie (skład) tekstu pisanego w danym języku. Dobry przykład można znaleźć w języku tureckim i w [zachowaniu litery i bez kropki](https://en.wikipedia.org/wiki/Dotted_and_dotless_I) (zobacz uwagi na tej stronie dotyczące ligatur). Typograficzne „zasady” związane z pismami/językami są wbudowane w funkcjonalność czcionek OpenType za pomocą tak zwanych znaczników pisma i języka *znaczników* które służą do identyfikowania reguł mających zastosowanie do konkretnych kombinacji pisma/języka. Naturalnie zestaw pism/języków obsługiwanych przez każdą czcionkę OpenType będzie się różnić w zależności od wyborów dokonanych przez twórców czcionki i celu, dla którego została ona stworzona. Zaawansowane oprogramowanie składu, takie jak XeTeX lub LuaTeX, może korzystać z tych reguł (wbudowanych w czcionki OpenType), pozwalając użytkownikom selektywnie stosować je do tekstu wejściowego podczas składu tekstu w określonym języku — na przykład za pomocą pakietu LaTeX [pakietu fontspec](https://ctan.org/pkg/fontspec?lang=en).

#### Zaglądając do wnętrza czcionki OpenType: pisma/języki

Aby to było jaśniejsze, poniżej znajduje się zrzut ekranu pokazujący darmową [czcionkę OpenType Scheherazade](http://software.sil.org/scheherazade/download/) otwartą w (równie darmowym) [Microsoft VOLT](https://www.microsoft.com/en-us/Typography/volt.aspx) oprogramowaniu do edycji czcionek. Na tym obrazie można zobaczyć pisma, języki i cechy typograficzne wbudowane w Scheherazade — używając VOLT, możesz dodać dodatkowe funkcje i możliwości do Scheherazade, ale to wykracza daleko poza zakres tego artykułu!

![Czcionka Scheherazade OpenType (w odmianie TrueType) otwarta w Microsoft VOLT](/files/4215d86701c76c97007168182ecf537323b4724b)

Z tego zrzutu ekranu widać, że Scheherazade obsługuje pisma arabskie i łacińskie oraz zapewnia dodatkowe specjalistyczne wsparcie dla kilku języków używających pisma arabskiego — za pomocą tak zwanych funkcji OpenType, które wymieniono w zielono obramowanym polu powyżej. Nie będziemy wchodzić w szczegóły tych funkcji, ale przesłanie jest takie, że wysokiej jakości czcionki OpenType mają wbudowaną sporą inteligencję, gotową do wykorzystania przez oprogramowanie składu zdolne korzystać z reguł typograficznych wbudowanych w czcionki.

Zainteresowany czytelnik może przejrzeć rejestr znaczników OpenType, aby zobaczyć [znaczniki pisma](https://www.microsoft.com/typography/otspec/scripttags.htm) i [znaczniki języka](https://www.microsoft.com/typography/developers/opentype/languagetags.aspx) obecnie używane w specyfikacji OpenType.

### Powrót do znaków: różne role znaków

Zbiór znaków, które tworzą podstawowe elementy pisma (lub języka), nie pełni wszystkich tej samej roli. Na przykład w większości języków są znaki dla *interpunkcji*, znaki dla numerycznych *cyfr* a także znaki, które postrzegamy jako *litery* alfabetu, które w przypadku niektórych pism występują również w formie wielkiej i małej. Pojęcie znaku jest bardzo szerokie, a Standard Unicode obejmuje znaki specjalistyczne, które są *nieprzeznaczone do wyświetlania* lecz których zadaniem jest „kontrolowanie interpretacji lub wyświetlania tekstu”. Na przykład podczas składu niektórych tekstów arabskich możesz chcieć wymusić lub zablokować łączenie pewnych znaków; standard Unicode dostarcza do tego specjalne znaki kontrolne: tak zwane [ZERO WIDTH JOINER](https://en.wikipedia.org/wiki/Zero-width_joiner) oraz [ZERO WIDTH NON-JOINER](https://en.wikipedia.org/wiki/Zero-width_non-joiner). Te znaki nie są przeznaczone do wyświetlania i są „wchłaniane” przez oprogramowanie podczas przetwarzania tekstu, aby wywołać zamierzone efekty wizualne.

Wszystkim znakom określonym w standardzie Unicode przypisany jest zestaw właściwości, który w praktyce opisuje rolę i przeznaczenie każdego znaku w kodowaniu Unicode — nazwy znaków, takie jak ŁACIŃSKA MAŁA LITERA A, są tylko jednym z elementów listy właściwości znaku. Właściwości te są w pełni opisane w [Unicode Character Database (UCD)](http://www.unicode.org/reports/tr44/) i są szeroko używane w komputerowym przetwarzaniu tekstu, takim jak wyszukiwanie, sortowanie, sprawdzanie pisowni i tym podobne. Pliki danych zawierające właściwości znaków Unicode są również [dostępne do pobrania](http://www.unicode.org/Public/UCD/latest/).

Spośród właściwości przypisanych każdemu znakowi najważniejsza dla naszej dyskusji jest *identyfikator numeryczny* przypisany przez jego kodowanie Unicode, do którego teraz przechodzimy.

### Znaki: liczby i kodowania

To oczywiste stwierdzenie, ale komputery i inne urządzenia cyfrowe zajmują się przechowywaniem i przetwarzaniem danych liczbowych: jak więc ma się to do tekstu? Gdy wpisujesz tekst za pomocą klawiatury komputera lub stukając w ekran urządzenia mobilnego, twoje naciśnięcia klawiszy są zamieniane na liczby, które reprezentują ciąg znaków, który wpisujesz.

W pewnym momencie możesz chcieć przesłać ten tekst (ciąg liczb) przez e-mail, wiadomość tekstową lub za pośrednictwem komunikacji online, takiej jak Tweet lub wpis w jakiejś formie mediów społecznościowych. Oczywiście urządzenie, na którym tworzyłeś tekst, oraz urządzenie(a) używane przez jego odbiorcę(-ów) muszą w jakiś sposób zgadzać się co do tego, które liczby reprezentują które znaki. Jeśli nie, twój tekst może nie zostać poprawnie wyświetlony na urządzeniu odbiorcy.

Aby dzisiejsza globalna komunikacja mogła działać, urządzenia wysyłające i odbierające potrzebują pewnej „wzajemnie uzgodnionej konwencji”, dzięki której określony zestaw liczb reprezentuje określony zestaw znaków. Taka konwencja nazywa się *kodowanie*: zbiorem liczb używanym do reprezentowania określonego zestawu znaków, a kodowanie Unicode jest obecnie *de facto* globalnym standardem.

## Unicode: bity i bajty do przechowywania tekstu

Unicode jest ogromnym standardem, który obejmuje znacznie, znacznie więcej niż samo kodowanie tekstu, ale tutaj skupiamy się wyłącznie na kodowaniu, które on zapewnia.

#### Bity, bajty i ile znaków?

Wspomnieliśmy, że urządzenia przechowują i reprezentują tekst jako liczby — konkretnie znaki będą przechowywane jako liczby całkowite: liczby całe. Aby zrozumieć konsekwencje tego dla kodowania Unicode, potrzebujemy *bardzo* krótki, *bardzo* podstawowy przegląd tego, jak komputery przechowują liczby całkowite (nie zamierzamy zapuszczać się w informatykę).

Aby skrócić bardzo długą historię, dzisiejsze komputery stacjonarne i urządzenia przenośne przechowują liczby całkowite w dyskretnych „porcjach”, które mogą mieć długość 1, 2, 4 lub 8 bajtów. Każda z tych jednostek przechowywania może przechowywać liczby całkowite do maksymalnej dodatniej wartości zależnej od całkowitej liczby bitów zawartych w każdej jednostce przechowywania:

* 1 bajt (8 bitów): maksymalna dodatnia liczba całkowita wynosi 255;
* 2 bajty (16 bitów): maksymalna dodatnia liczba całkowita wynosi 65535;
* 4 bajty (32 bity): maksymalna dodatnia liczba całkowita wynosi 4,294,967,295;
* 8 bajtów (64 bity): maksymalna dodatnia liczba całkowita wynosi 18,446,744,073,709,551,615.

W praktyce standard Unicode używa liczb z zakresu od 0 do 1,114,111 do kodowania wszystkich znaków świata, w rezultacie potrzebuje tylko 21 bitów, aby zakodować pełny zakres. Możemy to zobaczyć, zauważając, że jednostki przechowywania zawierające n bitów mogą reprezentować dowolną dodatnią liczbę całkowitą od 0 do maksymalnej wartości $$2^n -1$$; w konsekwencji:

* maksymalna wartość, którą można przechować w 20 bitach, wynosi $$2^{20} -1 = 1,048,575$$ (zbyt mała);
* maksymalna wartość, którą można przechować w 21 bitach, wynosi $$2^{21} -1 = 2,097,151$$ (wystarczająco duża).

Zauważyliśmy, że komputery przechowują dane (liczby) w jednostkach po 1, 2, 4 (lub 8) bajtów, więc jak duża musi być jednostka przechowywania, jeśli musimy przechowywać wartości aż do maksymalnej wartości Unicode 1,114,111? Oczywiście jednostka o rozmiarze bajta może zawierać maksymalnie 255, a 2 bajty mogą przechować 65535: żadne z nich nie wystarcza do przechowania pełnego zakresu znaków kodowanych przez Unicode. Następną dostępną opcją są jednostki przechowywania o rozmiarze 4 bajtów, które mogą przechowywać liczby całkowite do maksymalnej wartości 4,294,967,295, czyli znacznie więcej niż faktycznie potrzebujemy. Jeśli więc wybralibyśmy 4 bajty jako naszą jednostkę przechowywania, z pewnością mielibyśmy wystarczająco dużo miejsca, aby przechować wszystkie wartości Unicode, a każdy znak byłby przechowywany jako liczba całkowita wymagająca 4 bajtów (32 bitów). Jednak używanie 4 bajtów do przechowywania wszystkiego jest bardzo marnotrawne pod względem miejsca, ponieważ nawet największe wartości Unicode potrzebują maksymalnie 21 bitów — co, jeśli byłoby przechowywane przy użyciu 32 bitów, oznaczałoby, że 11 z tych 32 bitów nigdy nie zostałoby użytych.

**Uwaga**: Chociaż zakres Unicode rozciąga się od 0 do 1,114,111, nie każda wartość z tego zakresu jest rzeczywiście używana: z przyczyn technicznych niektóre wartości są uznawane za nieprawidłowe do rzeczywistego użycia jako znaki Unicode.

### A więc czym jest UTF-8?

Jeśli czytasz o XeTeX lub LuaTeX, niemal na pewno natkniesz się na wyjaśnienia stwierdzające, że te silniki TeX-a odczytują tekst i pliki wejściowe LaTeX-a w „formacie UTF-8”. Czym więc jest „format UTF-8” i jak ma się do Unicode? W terminologii Unicode każda z jego 1,114,112 wartości (od 0 do 1,114,111) używanych do kodowania znaków świata nazywa się [punktem kodowym](http://www.unicode.org/glossary/#code_point).

Widzieliśmy, że, *w teorii*, musielibyśmy przechowywać cały tekst zakodowany w Unicode, używając 4 bajtów na znak, aby odwzorować pełny zakres punktów kodowych Unicode. Jednak w praktyce kilku całkiem sprytnych ludzi wynalazło prosty sposób przedstawiania pojedynczej liczby Unicode (punktu kodowego) jako *ciąg* zbioru mniejszych liczb, przy czym każda z tych mniejszych liczb jest przechowywana w pojedynczym bajcie: proces, który *przekształca* jedną (większą) liczbę całkowitą w sekwencję mniejszych (bajtowych) liczb. Z powodu tej transformacji znaki naszego pliku tekstowego nie są już reprezentowane przez jedną wartość liczbową: każdy znak staje się *wielobajtową sekwencją*—od 1 do 4 (kolejnych) bajtów w pliku tekstowym może reprezentować pojedynczy znak Unicode (tj. jego wartość punktu kodowego).

UTF oznacza *Unicode Transformation Format* a kluczowym słowem tutaj jest *Transformacja*. W istocie można myśleć o UTF-8 jako o „przepisie” lub algorytmie konwertującym (transformującym) pojedynczą wartość punktu kodowego Unicode na sekwencję od 1 do 4 elementów wielkości bajta. Wraz ze wzrostem wartości punktu kodowego Unicode rośnie też liczba pojedynczych bajtów wymaganych do przedstawienia jej w formacie UTF-8.

Istnieją techniczne i historyczne powody stworzenia UTF-8, a historia wynalezienia UTF-8 jest [opisana w fascynującym e-mailu z 2003 roku](https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt), który, na początku tego e-maila, zawiera zdanie:

> „To nieprawda. UTF-8 zostało zaprojektowane, na moich oczach, na papierowej podkładce w dinerze w New Jersey pewnej nocy we wrześniu 1992 roku albo około tego czasu.”

#### Przykład: arabska litera ل

Weźmy przykład arabskiej litery ل (nazwa Unicode: ARABIC LETTER LAM), której przypisano wartość punktu kodowego Unicode 1604 (dziesiętnie) lub 0644 (szesnastkowo): jej reprezentacją w UTF-8 jest *dwubajtowa* sekwencja D9 84 (szesnastkowo) lub, dziesiętnie, 217 132. Przy użyciu UTF-8 jako formatu przechowywania tekstu, zamiast pliku tekstowego zawierającego pojedynczą liczbę 1604 reprezentującą ل, zostaje ona przekształcona w dwie wartości bajtowe: 217 i 132 — znak ل jest przechowywany jako *dwubajtową sekwencję*. Czytelnicy, którzy chcą zgłębić algorytm UTF-8 bardziej szczegółowo, mogą znaleźć obszerne wyjaśnienie oraz kod w C na mojej [osobistym blogu autora](http://www.readytext.co.uk/?p=1284).

Gdy jakieś oprogramowanie (np. XeTeX lub LuaTeX) czyta tekst w formacie UTF-8, musi określić wartość Unicode dla każdego znaku obecnego w tym pliku, więc używa algorytmu do *odwrócić* procesu transformacji UTF-8. Dzięki temu „algorytmowi odwracającemu” dwa bajty (217 i 132) są łączone ponownie, aby utworzyć liczbę całkowitą 1604, którą następnie można rozpoznać jako wartość punktu kodowego Unicode dla arabskiej litery ل.

Tak więc, wnioskując, UTF-8 to naprawdę tylko pośredni format danych używany do przechowywania i przesyłania tekstu zakodowanego w Unicode.

**Uwaga**: Niektóre systemy wybierają używanie/przechowywanie tekstu z użyciem 32 bitów na znak, nazywa się to [UTF-32](https://en.wikipedia.org/wiki/UTF-32)— istnieje również [UTF-16](https://en.wikipedia.org/wiki/UTF-16) ale UTF-8 jest najpowszechniejszym sposobem przechowywania tekstu zakodowanego w Unicode.

## Wielojęzyczne pliki TeX: XeTeX i LuaTeX

Zarówno XeTeX, jak i LuaTeX są zdolne do bardzo zaawansowanego wielojęzycznego składu, choć ich mechanizmy osiągania tego są dość różne i odzwierciedlają filozofię projektowania/rozwoju każdego silnika. Nie będziemy tego zgłębiać, a jedynie zauważymy, że silnik XeTeX zawiera komponenty programowe (wbudowane w jego plik wykonywalny), których nie ma w LuaTeX — przede wszystkim oprogramowanie do procesu zwanego *kształtowaniem OpenType* (np. za pośrednictwem biblioteki o nazwie [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)).

LuaTeX natomiast przyjmuje inne podejście: zamiast budować funkcje bezpośrednio w samym silniku TeX, LuaTeX udostępnia niezwykle bogaty zbiór poleceń (prymitywów TeX-a) oraz bardzo potężny [interfejs API oparty na Lua](/latex/pl/artykuly-szczegolowe/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md) dzięki któremu twórcy mogą budować równie zaawansowane rozwiązania do wielojęzycznego składu. Choć filozofia LuaTeX może oznaczać dodatkową pracę dla twórców pakietów LaTeX, zapewnia ona znacznie większą elastyczność, ponieważ rozwiązania nie są „zakodowane na sztywno” w samym silniku LuaTeX, lecz są konstruowane z kodu TeX i Lua — lub wtyczek napisanych w C/C++.

**Uwaga**: Czytelnicy, którzy chcieliby dalej zgłębiać fascynujący, ale złożony świat kształtowania OpenType, mogą być zainteresowani lekturą o znakomitej bibliotece open source o nazwie [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)— używanej przez wiele aplikacji, w tym Firefox, Chrome i LibreOffice, a oczywiście także przez XeTeX. Autor tego artykułu używał HarfBuzza do tworzenia [wtyczek LuaTeX do składu arabskiego](http://www.readytext.co.uk/?p=3186).

Obecnie powszechne jest (np. w mediach społecznościowych) przesyłanie tekstu zawierającego znaki z wielu języków, a plik tekstowy UTF-8 przechowujący tekst wielojęzyczny może łatwo zawierać znaki, których reprezentacja w UTF-8 ma długość 1, 2, 3 lub 4 bajty. Tak więc w istocie plik tekstowy UTF-8 jest po prostu strumieniem pojedynczych bajtów, ale każdy rzeczywisty znak w tym pliku może mieć od 1 do 4 bajtów długości: poszczególne znaki stały się *wielobajtowymi sekwencjami*.

Aby dalej zbadać niektóre kluczowe aspekty pracy z wielojęzycznym tekstem (w składzie), użyjemy przykładu zawierającego pismo arabskie, ponieważ arabski daje nam możliwość omówienia wielu pojęć.

#### Uwaga: pismo arabskie

Ta [Pismo arabskie](https://en.wikipedia.org/wiki/Arabic_script) jest zapisywane stylem kursywnym, czytanym i pisanym od prawej do lewej. Każda arabska litera może potencjalnie przyjmować jedną z 4 różnych postaci w zależności od:

* czy jest wyświetlany jako pojedynczy, samodzielny (izolowany) znak (niepołączony z niczym innym);
* czy występuje w obrębie słowa — na początku, w środku lub na końcu słowa: określane jako *inicjalne*, *medialne* i *finalny* formy, odpowiednio.

Każdy znak pisma arabskiego ma własny zestaw reguł łączenia i może, ale nie musi, zmieniać kształt/wygląd, gdy ma inny znak po lewej, po prawej albo po lewej i prawej stronie. Czytelnicy zainteresowani dalszym zgłębianiem tego tematu mogą znaleźć [pełną listę na Wikipedii](https://en.wikipedia.org/wiki/Template:Arabic_alphabet_shapes/joining).

#### Przykład: tekst arabski i angielski w UTF-8

Załóżmy, że tworzymy plik tekstowy UTF-8 zawierający jedną linię tekstu angielskiego i arabskiego: This is العَرَبِيَّة text!

Ta linia tekstu zawiera 3 znaki spacji, 11 angielskich znaków (pisma łacińskiego) i 12 arabskich znaków (choć może nie być to od razu oczywiste). Gdy zostanie zapisana jako plik tekstowy UTF-8, zajmuje 38 bajtów pamięci, wynikających z następujących elementów:

* **pismo łacińskie**: spacje plus tekst angielski: 14 ✕ znaków jednobajtowych = 14 bajtów;
* **Pismo arabskie**: 12 znaków arabskich ✕ 2 bajty na znak = 24 bajty.

Łącznie 14 + 24 = 38 bajtów.

#### Zagłębiając się bardziej

Jeśli zapiszemy nasz przykładowy tekst w pliku UTF-8 o nazwie `arabic.txt` i otworzymy go w edytorze szesnastkowym, możemy go przeanalizować, aby zobaczyć rzeczywiste bajty, które zawiera. Z analizy poniższego opatrzonego komentarzami zrzutu ekranu można zauważyć, że tekst arabski jest przechowywany jako 2 bajty na znak:

![Plik tekstowy UTF-8 zawierający tekst angielski i arabski otwarty w edytorze szesnastkowym.](/files/8f7449911512d2140539c2cc60c3da7ffd37535f)

Plik tekstowy UTF-8 zawierający tekst angielski i arabski otwarty w edytorze szesnastkowym. Wyraźnie widać, że znaki pisma łacińskiego wymagają pojedynczego bajtu, ale znaki pisma arabskiego są przechowywane jako dwa bajty na znak.

Z tego zrzutu ekranu można wyciągnąć kilka obserwacji:

* tekst arabski jest zapisany w kolejności od lewej do prawej, a znaki są surowymi, nieuformowanymi (izolowanymi) wersjami arabskich liter i samogłosek;
* nie ma żadnych dodatkowych informacji po tekście łacińskim „This is ”, które informowałyby jakiekolwiek oprogramowanie czytające ten plik, że następny znak jest w piśmie arabskim.

Jeśli składasz dokument wielojęzyczny (np. zawierający angielski i arabski), to podczas odczytu/przetwarzania wejściowego pliku tekstowego (jako strumienia bajtów) XeTeX lub LuaTeX muszą być w stanie wykryć początek i koniec każdego znaku oraz odczytać właściwą liczbę bajtów potrzebną do odwrócenia transformacji UTF-8 i wygenerowania odpowiadającego jej punktu kodowego Unicode. To sam algorytm UTF-8 umożliwia oprogramowaniu wykonanie tego: pozwala wykryć pierwszy bajt każdego pojedynczego znaku oraz to, ile bajtów trzeba odczytać, aby obliczyć odpowiadający mu punkt kodowy Unicode. UTF-8 jest prosty w użyciu, ale naprawdę bardzo pomysłowy.

#### Kolejność logiczna, kolejność wyświetlania i kształtowanie OpenType

Jeśli przyjrzysz się uważnie arabskiej frazie powyżej (العَرَبِيَّة), może być trudno zauważyć, że nasz plik tekstowy rzeczywiście zawiera 12 indywidualnych arabskich znaków — zwłaszcza jeśli nie znasz pisma arabskiego! Jeśli jednak starannie policzysz arabskie znaki wyświetlone po prawej stronie powyższego zrzutu ekranu, zobaczysz, że jest ich łącznie 12.

W przypadku języków o złożonym piśmie, takich jak arabski, to, co nasz plik tekstowy *przechowuje* i to, co ty *widzisz na ekranie* wyglądają wyraźnie *bardzo* naprawdę inaczej! To, co widzisz, oglądając ten tekst, na przykład w przeglądarce, to (w zależności od użytej czcionki):

![Obraz składanego tekstu arabskiego](/files/45c5b954fce1be1080051fd2656ee1651ab4c067)

Ale, jak pokazuje powyższy zrzut ekranu, to, co plik tekstowy UTF-8 faktycznie zawiera, wygląda tak:

![Obraz nieskładanego tekstu arabskiego (izolowane znaki)](/files/07bb5cffa9a9a146226b2a10124df75759d1e98a)

Nawet jeśli nie znasz kursywnej natury pisma arabskiego, wyraźnie widać, że podczas przenoszenia arabskich znaków zawartych w pliku tekstowym do składu i/lub wyświetlania na ekranie (jako glify) stało się „coś”. Jeśli jesteś przyzwyczajony do używania TeX/LaTeX z językami o prostym piśmie, na przykład językami opartymi na alfabecie łacińskim, może to być naprawdę bardzo mylące!

W grę wchodzą tu ważne pojęcia, ponieważ pliki tekstowe Unicode zajmują się przechowywaniem… cóż, tekstu (Unicode), a systemy składu i wyświetlania zajmują się używaniem czcionek i glifów (OpenType):

* plik tekstowy zapisał arabskie znaki w kolejności od lewej do prawej, ale arabski czyta/wyświetla się od prawej do lewej: pliki tekstowe przechowują tekst w tak zwanej *kolejności logicznej*;
* plik tekstowy zawiera pojedyncze znaki, które wyglądają zupełnie inaczej niż rzeczywisty obraz wyświetlany na ekranie: plik tekstowy zawiera arabskie znaki w ich izolowanej, niepołączonej formie.

#### Co się dzieje?

W obrębie pliku tekstowego arabski jest przechowywany jako sekwencja izolowanych form znaków czytana od lewej do prawej: jeśli się nad tym zastanowić, plik tekstowy przechowuje tekst arabski w kolejności/sekwencji *w jakiej został wpisany* (ten *kolejności logicznej*). Dopiero gdy ten tekst jest przetwarzany do wyświetlenia lub składu, pojawia się w poprawnej kolejności odczytu, często określanej jako *kolejność wizualna* lub *kolejność wyświetlania*; dodatkowo izolowane formy arabskich znaków są *kształtowane* w ich typograficznie poprawne wersje wyświetlania. Jednym ze sposobów myślenia o tym jest to, że prosty plik tekstowy musi przechowywać tekst (znaki Unicode) w możliwie najbardziej podstawowej formie: surowe, nieuformowane, pojedyncze znaki tekstowe — zadaniem oprogramowania systemowego jest renderowanie tych znaków do wyświetlenia na podstawie dostępnego na urządzeniu systemu operacyjnego, czcionek i oprogramowania składu/renderowania.

Gdy arabski tekst w tym pliku jest składany/wyświetlany, przechodzi proces zwany *kształtowanie*. Poszczególne arabskie znaki są przekształcane w ukształtowane glify, które poprawnie reprezentują wariant każdego znaku wymagany zgodnie z zasadami łączenia pisma arabskiego i systemu pisma. Ponadto wysokiej jakości oprogramowanie składu (korzystające z dobrych czcionek OpenType) doda dalsze przetwarzanie, stosując dodatkowe wyrafinowanie typograficzne poprzez proces zwany *kształtowaniem OpenType*—proces, który obejmuje szeroki zakres operacji typograficznych, które mogą obejmować:

* zastępowanie wielu pojedynczych glifów jednym złożonym glifem ligaturowym (bardzo częste w arabskim) lub
* operacje pozycjonowania, które na przykład dostosowują położenie arabskich samogłosek w zależności od glifu, nad którym się znajdują, lub pod którym się znajdują.

![Obraz pokazujący transformację, jakiej podlega tekst arabski podczas składu](/files/f2b54ad09d394d7a2c7e95e3b7d1183a9de1be0c)

Różnica między porządkiem logicznym a porządkiem wizualnym (wyświetlania). Na tym grafiku widać, że arabskie znaki zapisane w pliku tekstowym podlegają przestawianiu i kształtowaniu, gdy są wyświetlane lub składane.

Projektanci i twórcy zaawansowanych czcionek OpenType poświęcają bardzo dużo czasu i wiedzy eksperckiej, aby zapewnić zaawansowane możliwości typograficzne wbudowane w ich czcionki.

Aby wyłączyć kształtowanie stosowane do tekstu arabskiego, możemy użyć doskonałego, darmowego, [BabelPad](http://www.babelstone.co.uk/Software/BabelPad.html) edytora tekstu Unicode (tylko dla Windows), który pozwala wyłączyć kształtowanie, aby zobaczyć surowe, pojedyncze, niepołączone (nieuformowane) znaki rzeczywiście obecne w pliku tekstowym — zobacz dolną połowę tego połączonego zrzutu ekranu:

![Obraz pokazujący możliwość wyłączenia kształtowania OpenType w edytorze tekstu BabelPad](/files/9936a37aec68d7108137940a65bf5b59ae0537af)

Korzystanie z edytora tekstu Unicode BabelPad do włączania kształtowania OpenType (górny obraz) lub wyłączania go (dolny obraz). Wyłączenie kształtowania OpenType znacznie ułatwia edycję tekstu arabskiego.

Pojęcia porządku logicznego i porządku wyświetlania, w połączeniu z procesami kształtowania, mogą być dość mylące, gdy po raz pierwszy spotykasz się z nimi podczas edycji lub składu wielojęzycznych plików tekstowych zawierających złożone pisma, takie jak arabski: miejmy nadzieję, że powyższe pomogło uniknąć początkowego zamieszania.


---

# 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/pl/artykuly-szczegolowe/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.