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

# Unicode, UTF-8, dan teks multibahasa: Sebuah pengantar

## Unicode dan OpenType: Karakter dan glif

Mesin TeX modern, yaitu XeTeX dan LuaTeX, telah berkembang dari mesin TeX asli Knuth sebagian besar karena kebutuhan untuk mengikuti perkembangan dalam lanskap teknologi, khususnya Unicode (untuk teks) dan OpenType (untuk font). Saat ini, melalui penggunaan paket seperti [fontspec](https://ctan.org/pkg/fontspec?lang=en) dan [unicode-math](https://ctan.org/pkg/unicode-math?lang=en), pengguna LaTeX dapat mengakses kemampuan penyusunan huruf yang sangat canggih yang disediakan oleh font OpenType—termasuk penyusunan huruf multibahasa tingkat lanjut dan penyusunan huruf matematika berbasis OpenType ([dipelopori oleh Microsoft](https://blogs.msdn.microsoft.com/murrays)).

Namun, untuk memanfaatkan font OpenType dengan XeTeX/LuaTeX secara maksimal, ada baiknya mengenal sejumlah topik/konsep latar belakang—terutama untuk memecahkan masalah atau membuka jalan bagi pekerjaan yang lebih lanjut/kompleks. Misalnya, Anda mungkin membaca tentang mesin XeTeX dan LuaTeX menggunakan “input UTF-8” atau bahwa keduanya “mengenali Unicode”, dan bacaan lebih lanjut tentang font OpenType mungkin membahas atau menyebut topik seperti “pengodean Unicode”, “fitur font” OpenType, “glif”, “ID glif”, “nama glif” dan sebagainya. Tujuan kami adalah memberikan pengantar terhadap istilah/topik ini dan menyusun kerangka dasar untuk menunjukkan bagaimana semuanya saling terkait dan, semoga, memberikan dukungan untuk pekerjaan atau pemecahan masalah lebih lanjut.

Topik-topik yang ingin kami bahas cukup rapi terbagi ke dalam dua area utama: *Unicode* yang, pada praktiknya, berada di dunia teks/karakter dan pengodean teks, dan *OpenType* yang dunianya adalah font dan glif; tetapi, tentu saja, kedua dunia itu saling terhubung dan ada sedikit tumpang tindih, bahkan dalam artikel pertama ini.

### Topik apa yang akan kita bahas?

Fokus utama artikel ini adalah beberapa topik terkait Unicode: dimulai dengan pembahasan tentang apa yang dimaksud dengan “karakter” dan dilanjutkan dengan pengenalan skrip/bahasa, pengodean Unicode, dan UTF-8—bersama dengan contoh bekerja dengan file teks multibahasa. Artikel lanjutan akan membangun tulisan ini untuk membahas topik latar belakang terkait teknologi font OpenType. Jelas, dalam keterbatasan sebuah posting blog tidak mungkin mencoba “mendalami” semua area yang ingin kami bahas: tujuan kami yang dinyatakan adalah menyediakan kerangka keseluruhan yang menunjukkan bagaimana beberapa konsep kunci saling berhubungan dan bekerja bersama. Kita akan mulai dengan konsep yang paling dasar: yaitu *karakter*.

## Karakter: Blok bangunan dasar

Sebuah gagasan/konsep mendasar yang menjadi inti pembahasan kita (dan juga Unicode) adalah makna dari “karakter”: ini adalah salah satu kata yang maknanya sering “diasumsikan” melalui penggunaannya dalam pekerjaan dan percakapan sehari-hari. Namun, dari perspektif Unicode, penyusunan huruf, dan teknologi font, kita perlu sedikit lebih tepat dan mendefinisikan apa yang dimaksud dengan “sebuah karakter”. Misalnya, mungkin sangat wajar bagi kita untuk menganggap **a** dan *a* sebagai “karakter” yang berbeda: ‘a tebal’ dan ‘a miring’. Tetapi ternyata tidak: keduanya hanyalah representasi visual berbeda dari karakter fundamental yang sama, yang oleh Unicode diberi nama resmi [HURUF KECIL LATIN A](http://unicode.org/charts/PDF/U0000.pdf).

Unicode [mendefinisikan sebuah karakter](http://www.unicode.org/glossary/#character) sebagai:

> “Komponen terkecil bahasa tulis yang memiliki nilai semantik; mengacu pada makna dan/atau bentuk abstrak, bukan bentuk tertentu...”

yang dengan jelas membedakan antara bentuk khusus suatu karakter *tampilan visual* dan *maknanya*.

Anda dapat memandang karakter sebagai unit dasar, atau blok bangunan, dari suatu bahasa atau, lebih tepatnya, suatu *aksara*—topik yang kita bahas di bawah ini. Bentuk sebenarnya suatu karakter ketika ditampilkan dengan font tertentu tidak relevan bagi definisi karakter menurut Unicode: yang hanya *maknanya* yang benar-benar menarik di sini adalah: *peran dan tujuan* dari setiap karakter sebagai salah satu dari seperangkat blok bangunan yang pada akhirnya dibangun menjadi skrip/bahasa.

### Skrip dan bahasa

Ada baiknya secara singkat menyebutkan dua konsep penting: *skrip* dan *bahasa*. Situs web Unicode menyediakan [definisi skrip yang berguna](https://www.unicode.org/standard/supported.html):

> “Standar Unicode mengodekan skrip, bukan bahasa. Ketika sistem tulisan untuk lebih dari satu bahasa berbagi kumpulan simbol grafis yang asal-usul historisnya saling terkait, gabungan dari semua simbol grafis tersebut diperlakukan sebagai satu kumpulan karakter untuk pengodean dan diidentifikasi sebagai satu skrip.”

Dengan menggunakan sebuah [contoh dari Wikipedia](https://en.wikipedia.org/wiki/Script_\(Unicode\)), skrip Latin tersusun atas suatu [kumpulan karakter](http://unicode.org/charts/) yang digunakan di berbagai bahasa: Inggris, Prancis, Jerman, Italia, dan seterusnya. Tentu saja, tidak semua karakter yang didefinisikan dalam skrip Latin digunakan oleh semua bahasa yang berbasis skrip Latin—misalnya, alfabet Inggris tidak memuat karakter beraksen yang terdapat dalam bahasa Eropa lain seperti Prancis atau Jerman.

### Font OpenType: skrip dan bahasa

Pada titik ini kita akan beralih dari Unicode ke font OpenType karena konsep skrip dan bahasa juga memainkan peran yang sangat penting dalam teknologi font OpenType.

Sekumpulan bahasa yang menggunakan [aksara](http://www.unicode.org/glossary/#script) masing-masing dapat memiliki tradisi tipografis yang berbeda ketika menampilkan (menyusun huruf) teks yang ditulis dalam bahasa tertentu. Contoh yang baik dapat ditemukan dalam bahasa Turki dan [perilaku huruf i tanpa titik](https://en.wikipedia.org/wiki/Dotted_and_dotless_I) (lihat catatan pada halaman itu tentang ligatur). “Aturan” tipografis yang berkaitan dengan skrip/bahasa dibangun ke dalam fungsionalitas font OpenType melalui penggunaan apa yang disebut skrip dan bahasa *tag* yang digunakan untuk mengidentifikasi aturan yang seharusnya berlaku pada kombinasi skrip/bahasa tertentu. Tentu saja, kumpulan skrip/bahasa yang didukung oleh setiap font OpenType akan bervariasi sesuai dengan pilihan yang dibuat oleh pembuat font dan alasan pembuatannya. Perangkat lunak penyusunan huruf yang canggih, seperti XeTeX atau LuaTeX, dapat memanfaatkan aturan-aturan tersebut (yang dibangun ke dalam font OpenType) dengan memungkinkan pengguna menerapkannya secara selektif pada teks masukan saat menyusun teks dalam bahasa tertentu—misalnya, dengan menggunakan LaTeX [paket fontspec](https://ctan.org/pkg/fontspec?lang=en).

#### Melihat ke dalam font OpenType: skrip/bahasa

Agar ini lebih jelas, berikut tangkapan layar yang menampilkan [font OpenType Scheherazade](http://software.sil.org/scheherazade/download/) yang dibuka di dalam [Microsoft VOLT](https://www.microsoft.com/en-us/Typography/volt.aspx) perangkat lunak penyunting font. Dalam gambar ini Anda dapat melihat skrip, bahasa, dan fitur tipografis yang dibangun ke dalam Scheherazade—dengan VOLT Anda dapat menambahkan fitur dan fungsi tambahan ke Scheherazade, tetapi itu jauh di luar cakupan artikel ini!

![Font OpenType Scheherazade (varian TrueType) dibuka di dalam Microsoft VOLT](/files/21c9f36b9e2410d48e0e5dbf180d873bd83394ae)

Dari tangkapan layar ini Anda dapat melihat bahwa Scheherazade mendukung skrip Arab dan Latin serta menyediakan dukungan khusus lebih lanjut untuk beberapa bahasa yang menggunakan skrip Arab—dengan menggunakan apa yang disebut fitur OpenType, yang tercantum dalam kotak berbingkai hijau di atas. Kami tidak akan membahas rincian fitur-fitur ini, tetapi pesan di sini adalah bahwa font OpenType berkualitas tinggi memiliki banyak kecerdasan yang dibangun di dalamnya, siap digunakan oleh perangkat lunak penyusunan huruf yang mampu memanfaatkan aturan tipografis yang dibangun ke dalam font.

Pembaca yang berminat dapat menelusuri registri tag OpenType untuk melihat [tag skrip](https://www.microsoft.com/typography/otspec/scripttags.htm) dan [tag bahasa](https://www.microsoft.com/typography/developers/opentype/languagetags.aspx) yang saat ini digunakan dalam spesifikasi OpenType.

### Kembali ke karakter: Peran karakter yang berbeda

Kumpulan karakter yang menyusun elemen-elemen dasar suatu skrip (atau bahasa) tidak semuanya menjalankan peran yang sama. Misalnya, dalam sebagian besar bahasa ada karakter untuk *tanda baca*, karakter untuk angka *digit* serta karakter yang kita anggap sebagai *huruf* dari alfabet yang, untuk beberapa skrip, juga ada dalam bentuk huruf kapital dan huruf kecil. Konsep karakter cukup luas dan Standar Unicode mencakup karakter khusus yang *tidak dirancang untuk ditampilkan* tetapi tugasnya adalah “mengendalikan penafsiran atau tampilan teks”. Misalnya, saat menyusun beberapa teks Arab Anda mungkin ingin memaksa, atau mencegah, perilaku penggabungan karakter tertentu; standar Unicode menyediakan karakter kendali khusus untuk melakukan ini: yang disebut [ZERO WIDTH JOINER](https://en.wikipedia.org/wiki/Zero-width_joiner) dan [ZERO WIDTH NON-JOINER](https://en.wikipedia.org/wiki/Zero-width_non-joiner). Karakter-karakter tersebut tidak dimaksudkan untuk ditampilkan dan “diserap” oleh perangkat lunak saat memproses teks untuk menghasilkan efek visual yang dimaksud.

Semua karakter yang ditentukan dalam standar Unicode diberi seperangkat properti yang, pada praktiknya, menggambarkan peran dan tujuan setiap karakter dalam pengodean Unicode—nama karakter, seperti LATIN SMALL LETTER A, hanyalah salah satu elemen dari daftar properti karakter. Properti-properti ini dijelaskan secara lengkap dalam [Unicode Character Database (UCD)](http://www.unicode.org/reports/tr44/) dan banyak digunakan dalam operasi pemrosesan teks terkomputerisasi seperti pencarian, pengurutan, pemeriksaan ejaan, dan sebagainya. Berkas data yang mencantumkan properti karakter Unicode juga [tersedia untuk diunduh](http://www.unicode.org/Public/UCD/latest/).

Di antara properti yang dialokasikan untuk setiap karakter, yang paling penting untuk pembahasan kita adalah sebuah *pengenal numerik* yang ditetapkan oleh pengodean Unicode-nya, topik yang sekarang akan kita bahas.

### Karakter: Angka dan pengodean

Ini memang sesuatu yang jelas, tetapi komputer dan perangkat digital lainnya memang bertugas menyimpan dan memproses data numerik: jadi bagaimana kaitannya dengan teks? Saat Anda mengetik teks menggunakan papan ketik komputer, atau dengan menyentuh layar perangkat seluler, penekanan tombol Anda diubah menjadi angka yang mewakili rangkaian karakter yang sedang Anda ketik.

Pada suatu saat Anda mungkin ingin mentransfer teks itu (sebuah rangkaian angka) melalui e-mail, pesan teks, atau melalui komunikasi daring seperti Tweet atau kiriman di suatu bentuk media sosial. Jelas, perangkat tempat Anda menyusun teks dan perangkat yang digunakan oleh penerimanya harus, entah bagaimana, sepakat mengenai angka mana yang mewakili karakter mana. Jika tidak, teks Anda mungkin tidak ditampilkan dengan benar pada perangkat penerima.

Agar komunikasi global saat ini dapat berjalan, perangkat pengirim dan penerima membutuhkan suatu “konvensi yang disepakati bersama” yang membuat sekumpulan angka tertentu mewakili sekumpulan karakter tertentu. Konvensi ini disebut *pengkodean*: sekumpulan angka yang digunakan untuk mewakili sekumpulan karakter tertentu dan pengodean Unicode sekarang merupakan *de facto* standar global.

## Unicode: bit dan byte untuk menyimpan teks

Unicode adalah standar yang sangat besar yang mencakup jauh, jauh lebih dari sekadar pengodean teks, tetapi di sini kita hanya berfokus pada pengodean yang disediakannya.

#### Bit, byte, dan berapa banyak karakter?

Kami menyebutkan bahwa perangkat menyimpan dan merepresentasikan teks sebagai angka—lebih tepatnya, karakter disimpan sebagai bilangan bulat: bilangan penuh. Untuk memahami implikasinya bagi pengodean Unicode, kita perlu memiliki *sangat* tinjauan singkat, *sangat* tinjauan dasar tentang bagaimana komputer menyimpan bilangan bulat (kami tidak bermaksud masuk ke ilmu komputer).

Singkat cerita, perangkat desktop atau genggam masa kini menyimpan bilangan bulat dalam “potongan” terpisah yang dapat sepanjang 1, 2, 4, atau 8 byte. Masing-masing unit penyimpanan ini dapat menyimpan bilangan bulat hingga nilai positif maksimum berdasarkan jumlah total bit yang terkandung dalam setiap unit penyimpanan:

* 1 byte (8 bit): bilangan bulat positif maksimum adalah 255;
* 2 byte (16 bit): bilangan bulat positif maksimum adalah 65535;
* 4 byte (32 bit): bilangan bulat positif maksimum adalah 4,294,967,295;
* 8 byte (64 bit): bilangan bulat positif maksimum adalah 18,446,744,073,709,551,615.

Dalam praktiknya, standar Unicode menggunakan angka dalam rentang 0 hingga 1,114,111 untuk mengodekan semua karakter di dunia, sehingga hanya membutuhkan 21 bit untuk mengodekan seluruh rentang tersebut. Kita dapat melihat ini dengan mencatat bahwa unit penyimpanan yang berisi n bit dapat mewakili bilangan bulat positif apa pun dari 0 hingga nilai maksimum $$2^n -1$$; akibatnya:

* nilai maksimum yang dapat disimpan dalam 20 bit adalah $$2^{20} -1 = 1,048,575$$ (terlalu kecil);
* nilai maksimum yang dapat disimpan dalam 21 bit adalah $$2^{21} -1 = 2,097,151$$ (cukup besar).

Kami telah mencatat bahwa komputer menyimpan data (angka) dalam satuan 1, 2, 4 (atau 8) byte, jadi seberapa besar unit penyimpanan yang dibutuhkan jika kita harus menyimpan nilai hingga nilai maksimum Unicode sebesar 1,114,111? Jelas, unit penyimpanan seukuran byte dapat memuat nilai maksimum 255 dan 2 byte dapat menyimpan 65535: keduanya tidak cukup untuk menyimpan seluruh rentang karakter yang dikodekan oleh Unicode. Opsi berikutnya yang tersedia adalah unit penyimpanan berukuran 4 byte, yang dapat menyimpan bilangan bulat hingga maksimum 4,294,967,295 yang jauh lebih besar daripada yang sebenarnya kita perlukan. Jadi, jika kita memilih 4 byte sebagai unit penyimpanan, kita tentu memiliki ruang yang lebih dari cukup untuk menyimpan semua nilai Unicode, dengan setiap karakter disimpan sebagai bilangan bulat yang membutuhkan 4 byte (32 bit). Namun, menggunakan 4 byte untuk menyimpan semuanya sangat boros ruang karena bahkan nilai Unicode terbesar pun hanya membutuhkan maksimum 21 bit—yang, jika disimpan menggunakan 32 bit, berarti 11 dari 32 bit itu tidak akan pernah digunakan.

**Catatan**: Meskipun rentang Unicode membentang dari 0 hingga 1,114,111, tidak setiap nilai dalam rentang itu benar-benar digunakan: karena alasan teknis, beberapa nilai dianggap tidak valid untuk penggunaan nyata sebagai karakter Unicode.

### Jadi, apa itu UTF-8?

Jika Anda membaca tentang XeTeX atau LuaTeX, Anda hampir pasti akan menjumpai penjelasan yang menyatakan bahwa mesin TeX tersebut membaca teks dan berkas masukan LaTeX dalam “format UTF-8”. Jadi, apa itu “format UTF-8” dan bagaimana kaitannya dengan Unicode? Dalam istilah Unicode, masing-masing dari 1,114,112 nilainya (berkisar dari 0 hingga 1,114,111) yang digunakan untuk mengodekan karakter di dunia disebut [titik kode](http://www.unicode.org/glossary/#code_point).

Kita telah melihat bahwa, *secara teoretis*, kita perlu menyimpan semua teks yang dikodekan Unicode menggunakan 4 byte per karakter untuk merepresentasikan seluruh rentang titik kode Unicode. Namun, dalam praktiknya, beberapa orang yang cukup cerdas menemukan cara sederhana untuk merepresentasikan satu angka Unicode (titik kode) sebagai *urutan* rangkaian angka yang lebih kecil, dan masing-masing angka yang lebih kecil itu disimpan dalam satu byte: suatu proses yang *mengubah* satu bilangan bulat tunggal (lebih besar) menjadi rangkaian bilangan yang lebih kecil (seukuran byte). Karena transformasi ini, karakter-karakter dalam berkas teks kita tidak lagi masing-masing diwakili oleh satu nilai numerik: setiap karakter menjadi sebuah *rangkaian multi-byte*—apa pun dari 1 hingga 4 byte (berurutan) dalam berkas teks dapat mewakili satu karakter Unicode individual (yaitu, nilai titik kodenya).

UTF adalah singkatan dari *Unicode Transformation Format* dan kata kunci di sini adalah *Transformasi*. Pada dasarnya, Anda dapat menganggap UTF-8 sebagai “resep” atau algoritme untuk mengubah (mentransformasikan) satu nilai titik kode Unicode menjadi rangkaian potongan berukuran 1 hingga 4 byte. Seiring meningkatnya nilai titik kode Unicode, meningkat pula jumlah byte tunggal yang diperlukan untuk mewakilinya dalam format UTF-8.

Ada alasan teknis dan historis untuk dibuatnya UTF-8 dan kisah di balik penemuan UTF-8 [tercatat dalam sebuah e-mail menarik dari tahun 2003](https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt), yang, di awal e-mail itu, memuat kalimat:

> “Itu tidak benar. UTF-8 dirancang, di depan mata saya, di atas alas meja di sebuah restoran di New Jersey suatu malam pada September atau sekitar 1992.”

#### Contoh: huruf Arab ل

Mari kita ambil contoh huruf Arab ل (nama Unicode ARABIC LETTER LAM) yang diberi nilai titik kode Unicode 1604 (desimal) atau 0644 (heksadesimal): representasinya dalam UTF-8 adalah *dua byte* rangkaian D9 84 (heksa) atau, dalam desimal, 217 132. Saat menggunakan UTF-8 sebagai format penyimpanan teks, alih-alih berkas teks yang berisi satu angka 1604 untuk mewakili ل, angka itu diubah menjadi dua nilai seukuran byte: 217 dan 132—karakter ل disimpan sebagai sebuah *rangkaian dua byte*. Pembaca yang ingin mengeksplorasi algoritme UTF-8 lebih mendetail dapat menemukan penjelasan mendalam, dan kode C, di [situs blog pribadi penulis ini](http://www.readytext.co.uk/?p=1284).

Saat sebuah perangkat lunak (mis., XeTeX atau LuaTeX) membaca teks dalam format UTF-8, perangkat lunak itu perlu menentukan nilai Unicode untuk setiap karakter yang ada dalam berkas tersebut, jadi ia menggunakan algoritme untuk *membalik* proses transformasi UTF-8. Melalui “algoritme pembalikan” itu, dua byte (217 dan 132) digabungkan kembali untuk menghasilkan bilangan bulat 1604, yang kemudian dapat dikenali sebagai nilai titik kode Unicode untuk huruf Arab ل.

Jadi, sebagai kesimpulan, UTF-8 sebenarnya hanyalah format data perantara yang digunakan untuk penyimpanan dan transmisi teks yang dikodekan Unicode.

**Catatan**: Beberapa sistem memilih untuk menggunakan/menyimpan teks dengan 32 bit per karakter, ini disebut [UTF-32](https://en.wikipedia.org/wiki/UTF-32)—ada juga [UTF-16](https://en.wikipedia.org/wiki/UTF-16) tetapi UTF-8 adalah cara yang paling umum untuk menyimpan teks yang dikodekan Unicode.

## Berkas TeX multibahasa: XeTeX dan LuaTeX

Baik XeTeX maupun LuaTeX mampu melakukan penyusunan huruf multibahasa yang sangat canggih, meskipun mekanisme untuk mencapainya cukup berbeda dan mencerminkan filosofi desain/pengembangan masing-masing mesin. Kami tidak akan membahas ini secara mendalam, tetapi cukup mencatat bahwa mesin XeTeX berisi komponen perangkat lunak (tertanam dalam berkas eksekusinya) yang tidak terdapat dalam LuaTeX—terutama perangkat lunak untuk proses yang disebut *pembentukan bentuk OpenType* (mis., melalui pustaka bernama [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)).

LuaTeX, sebaliknya, mengadopsi pendekatan yang berbeda: alih-alih membangun fasilitas langsung ke dalam mesin TeX yang sebenarnya, LuaTeX menyediakan kumpulan perintah (primitif TeX) yang sangat kaya dan sebuah [API berbasis Lua](/latex/id/artikel-mendalam/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md) yang melaluinya pengembang dapat membangun solusi yang sama canggihnya untuk penyusunan huruf multibahasa. Meskipun filosofi LuaTeX mungkin menuntut pekerjaan tambahan bagi pengembang paket LaTeX, ia memberikan banyak fleksibilitas tambahan karena solusi tidak “dikodekan keras” ke dalam mesin LuaTeX itu sendiri, melainkan dibangun dari kode TeX dan Lua—atau plugin yang ditulis dalam C/C++.

**Catatan**: Pembaca yang ingin menjelajahi lebih lanjut dunia pembentukan bentuk OpenType yang menarik namun kompleks mungkin tertarik membaca tentang pustaka sumber terbuka yang sangat bagus bernama [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)—digunakan oleh banyak aplikasi termasuk Firefox, Chrome, dan LibreOffice dan, tentu saja, oleh XeTeX. Penulis artikel ini telah menggunakan HarfBuzz untuk membuat [plugin LuaTeX untuk menyusun huruf Arab](http://www.readytext.co.uk/?p=3186).

Sekarang sudah umum (mis., di media sosial) untuk mengirim teks yang berisi karakter dari berbagai bahasa dan berkas teks UTF-8 yang menyimpan teks multibahasa dengan mudah dapat berisi karakter yang representasinya dalam UTF-8 sepanjang 1, 2, 3, atau 4 byte. Jadi, pada praktiknya, berkas teks UTF-8 hanyalah aliran byte tunggal, tetapi setiap karakter sebenarnya dalam berkas itu bisa sepanjang 1 hingga 4 byte: karakter-karakter individual telah menjadi *rangkaian multi-byte*.

Untuk mengeksplorasi lebih lanjut beberapa aspek kunci dari bekerja dengan teks multibahasa (dalam penyusunan huruf), kita akan menggunakan contoh yang memuat skrip Arab karena bahasa Arab memberi kita ruang untuk membahas beberapa konsep sekaligus.

#### Catatan: skrip Arab

Fitur [Skrip Arab](https://en.wikipedia.org/wiki/Arabic_script) ditulis dengan gaya kursif yang dibaca dan ditulis dari kanan ke kiri. Setiap huruf Arab berpotensi mengambil salah satu dari 4 bentuk berbeda sesuai dengan:

* apakah ditampilkan sebagai karakter tunggal, berdiri sendiri (terisolasi), (tidak digabungkan dengan apa pun);
* apakah muncul di dalam kata—di awal, tengah, atau akhir kata: disebut sebagai *bentuk awal*, *bentuk medial* dan *final* bentuk masing-masing.

Setiap karakter dalam skrip Arab memiliki seperangkat aturan penggabungannya sendiri dan dapat, atau tidak dapat, mengubah bentuk/penampilan ketika ada karakter lain di sebelah kirinya, kanannya, atau di kiri dan kanan. Pembaca yang ingin menjelajahi ini lebih lanjut dapat menemukan sebuah [daftar lengkap di Wikipedia](https://en.wikipedia.org/wiki/Template:Arabic_alphabet_shapes/joining).

#### Contoh: teks Arab dan Inggris dalam UTF-8

Misalkan kita membuat berkas teks UTF-8 yang berisi satu baris teks Inggris dan Arab: This is العَرَبِيَّة text!

Baris teks ini berisi 3 karakter spasi, 11 karakter bahasa Inggris (skrip Latin), dan 12 karakter Arab (meskipun itu mungkin tidak langsung jelas/terlihat). Saat disimpan sebagai berkas teks UTF-8, teks ini menempati 38 byte penyimpanan, yang berasal dari hal berikut:

* **Skrip Latin**: spasi ditambah teks Inggris: 14 ✕ karakter 1 byte = 14 byte;
* **Skrip Arab**: 12 karakter Arab ✕ 2 byte per karakter = 24 byte.

Total 14 + 24 = 38 byte.

#### Menelusuri lebih jauh

Jika kita menyimpan teks contoh kita dalam sebuah berkas UTF-8 bernama `arabic.txt` dan membukanya di editor heksadesimal, kita dapat memeriksanya untuk melihat byte sebenarnya yang dikandungnya. Dari studi atas tangkapan layar beranotasi berikut, Anda dapat melihat bahwa teks Arab disimpan sebagai 2 byte per karakter:

![Berkas teks UTF-8 yang berisi teks Inggris dan Arab dibuka di dalam editor heksa.](/files/8174c1c70d03ca5c9c9b3c868ddb1ee2e70b2df2)

Berkas teks UTF-8 yang berisi teks Inggris dan Arab dibuka di dalam editor heksa. Anda dapat dengan jelas melihat bahwa karakter skrip Latin memerlukan satu byte, sedangkan karakter skrip Arab disimpan menggunakan dua byte per karakter.

Anda dapat membuat beberapa pengamatan dari tangkapan layar ini:

* teks Arab disimpan dalam urutan kiri ke kanan dan karakternya adalah versi mentah yang belum dibentuk (terisolasi) dari huruf dan vokal Arab;
* tidak ada informasi tambahan setelah skrip Latin “This is ” untuk memberi tahu perangkat lunak apa pun yang membaca berkas ini bahwa karakter berikutnya adalah dalam skrip Arab.

Jika Anda menyusun dokumen multibahasa (mis., berisi bahasa Inggris dan Arab), maka selama membaca/memproses berkas teks masukan (sebagai aliran byte) XeTeX atau LuaTeX harus mampu mendeteksi awal dan akhir setiap karakter dan membaca jumlah byte yang benar yang diperlukan untuk membalik transformasi UTF-8 dan menghasilkan titik kode Unicode yang sesuai. Algoritme UTF-8 itu sendiri yang memungkinkan perangkat lunak melakukan ini: memungkinkan deteksi byte pertama dari setiap karakter individual dan berapa banyak byte yang perlu dibaca untuk menghitung titik kode Unicode yang sesuai. UTF-8 mudah digunakan, tetapi sungguh sangat cerdik.

#### Urutan logis, urutan tampilan, dan pembentukan bentuk OpenType

Jika Anda melihat dengan saksama tulisan Arab di atas (العَرَبِيَّة) mungkin sulit untuk melihat bahwa berkas teks kita memang berisi 12 karakter Arab individual—terutama jika Anda tidak akrab dengan skrip Arab! Namun, jika Anda menghitung dengan cermat karakter Arab yang ditampilkan di sisi kanan tangkapan layar di atas, Anda dapat melihat bahwa jumlahnya 12.

Untuk bahasa dengan skrip kompleks, seperti Arab, apa yang ada di berkas teks kita *menyimpan* dan apa yang Anda *lihat di layar* tampak jelas *sangat* memang berbeda! Apa yang Anda lihat saat melihat teks itu, misalnya di peramban, adalah (tergantung pada font yang digunakan):

![Gambar teks Arab yang disusun huruf](/files/dfc1038aef5b12c808fc027d8a5bb7a5e9736f81)

Tetapi, seperti yang ditunjukkan tangkapan layar di atas, isi sebenarnya dari berkas teks UTF-8 itu adalah ini:

![Gambar teks Arab yang belum disusun huruf (karakter terisolasi)](/files/7e5fdf387845166d926874ff687bffeb7aaf681f)

Bahkan jika Anda tidak akrab dengan sifat kursif skrip Arab, Anda dapat dengan jelas melihat bahwa “sesuatu” telah terjadi selama proses memindahkan karakter Arab yang terdapat dalam berkas teks ke tahap penyusunan huruf dan/atau tampilan di layar (sebagai glif). Jika Anda terbiasa menggunakan TeX/LaTeX dengan bahasa skrip sederhana, misalnya bahasa berbasis Latin, ini memang bisa sangat membingungkan!

Beberapa konsep penting berperan di sini karena berkas teks Unicode bertugas menyimpan… yah, teks (Unicode), dan sistem penyusunan huruf serta tampilan bertugas menggunakan font dan glif (OpenType):

* berkas teks menyimpan karakter Arab dalam urutan kiri ke kanan tetapi bahasa Arab dibaca/ditampilkan dari kanan ke kiri: berkas teks menyimpan teks dalam apa yang disebut *urutan logis*;
* berkas teks berisi karakter individual yang tampak sangat berbeda dari tampilan aktual yang disajikan di layar: berkas teks berisi karakter Arab dalam bentuk terisolasi, tidak digabung.

#### Apa yang sedang terjadi?

Di dalam berkas teks, bahasa Arab disimpan sebagai urutan karakter bentuk terisolasi dari kiri ke kanan: jika dipikirkan, berkas teks menyimpan teks Arab dalam urutan/deret *saat teks itu diketik* (yang *urutan logis*). Hanya ketika teks itu diproses untuk ditampilkan, atau disusun huruf, teks itu ditampilkan dalam urutan baca yang benar, sering disebut sebagai *urutan visual* atau *urutan tampilan*; selain itu, bentuk terisolasi dari karakter Arab *dibentuk* menjadi versi tampilan yang secara tipografis benar. Salah satu cara memikirkannya adalah bahwa berkas teks sederhana harus menyimpan teks (karakter Unicode) dalam bentuk paling dasar yang mungkin: karakter teks individual mentah, belum dibentuk—tugas perangkat lunak sistemlah untuk merender karakter-karakter tersebut untuk ditampilkan berdasarkan sistem operasi, font, dan perangkat lunak penyusunan huruf/perenderan yang tersedia pada perangkat tampilan.

Ketika teks Arab dalam berkas itu disusun/ditampilkan, teks tersebut mengalami proses yang disebut *shaping*: Beberapa sistem memilih untuk menggunakan/menyimpan teks dengan 32 bit per karakter, ini disebut *pembentukan bentuk OpenType*—sebuah proses yang mencakup berbagai operasi tipografi yang dapat mencakup:

* mengganti beberapa glif individual dengan satu glif ligatur kompleks (sangat umum dalam bahasa Arab), atau
* operasi penempatan yang, misalnya, menyesuaikan posisi vokal Arab berdasarkan glif mana yang berada di atas atau di bawahnya.

![Gambar yang menunjukkan transformasi yang dialami teks Arab saat disusun huruf](/files/99b5c2bcc976b6113f163daafd45bc4a0a4e444b)

Perbedaan antara urutan logis dan urutan visual (tampilan). Dalam grafik ini Anda dapat melihat bahwa karakter Arab yang disimpan dalam file teks mengalami pengurutan ulang dan pembentukan bentuk saat ditampilkan atau disusun huruf.

Para perancang dan pembuat font OpenType tingkat lanjut menginvestasikan banyak waktu dan keahlian untuk menyediakan kemampuan tipografi canggih yang terpasang di dalam font mereka.

Untuk mematikan pembentukan bentuk yang diterapkan pada teks Arab, kita dapat menggunakan yang sangat baik, gratis, [BabelPad](http://www.babelstone.co.uk/Software/BabelPad.html) editor teks Unicode (khusus Windows) yang memungkinkan Anda menonaktifkan pembentukan bentuk untuk melihat karakter mentah, individual, yang tidak digabung (belum dibentuk) yang benar-benar ada dalam file teks—lihat bagian bawah dari tangkapan layar gabungan ini:

![Gambar yang menunjukkan kemampuan editor teks BabelPad untuk mematikan pembentukan OpenType](/files/d832251d3dc952af86181f555be40905bc696247)

Menggunakan editor teks Unicode BabelPad untuk menyalakan pembentukan OpenType (gambar atas) atau mematikannya (gambar bawah). Mematikan pembentukan OpenType membuat pengeditan teks Arab jauh lebih mudah.

Konsep urutan logis dan urutan tampilan, ditambah dengan proses pembentukan bentuk, bisa cukup membingungkan saat pertama kali Anda menemukannya saat mengedit atau menyusun huruf file teks multibahasa yang berisi aksara kompleks seperti Arab: semoga penjelasan di atas membantu menghindari kebingungan awal.


---

# 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/id/artikel-mendalam/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.