> For the complete documentation index, see [llms.txt](https://ayakaleaf-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://ayakaleaf-pro.ayaka.space/latex/tr/derinlemesine-makaleler/51-unicode-utf-8-and-multilingual-text-an-introduction.md).

# Unicode, UTF-8 ve çok dilli metin: Bir giriş

## Unicode ve OpenType: Karakterler ve glifler

Modern TeX motorları, yani XeTeX ve LuaTeX, büyük ölçüde Knuth’un özgün TeX motorundan, özellikle Unicode (metin için) ve OpenType (yazı tipleri için) başta olmak üzere teknoloji dünyasındaki gelişmelere ayak uydurma gereksinimi nedeniyle evrilmiştir. Günümüzde, gibi paketlerin kullanımı sayesinde [fontspec](https://ctan.org/pkg/fontspec?lang=en) ve [unicode-math](https://ctan.org/pkg/unicode-math?lang=en), LaTeX kullanıcıları OpenType yazı tiplerinin sağladığı son derece gelişmiş dizgi yeteneklerine erişebilirler; buna gelişmiş çokdilli dizgi ve OpenType tabanlı matematik dizgisi de dahildir ([Microsoft tarafından öncülük edilen](https://blogs.msdn.microsoft.com/murrays)).

Ancak, OpenType yazı tiplerini XeTeX/LuaTeX ile kullanmaktan en yüksek verimi almak için, özellikle sorun gidermek veya daha gelişmiş/karmaşık çalışmaların yolunu açmak amacıyla, bazı arka plan konularına/kavramlarına aşina olmak yararlı olabilir. Örneğin, XeTeX ve LuaTeX motorlarının “UTF-8 giriş” kullandığını ya da “Unicode farkındalığı”na sahip olduğunu okuyabilir ve OpenType yazı tipleri hakkında daha fazla okuma yaptığınızda “Unicode kodlaması”, OpenType “yazı tipi özellikleri”, “glifler”, “glif kimlikleri”, “glif adları” vb. konuların geçebildiğini görebilirsiniz. Amacımız, bu terimlere/konulara bir giriş yapmak ve bunların nasıl ilişkili olduğunu gösterecek temel bir çerçeveyi bir araya getirmek; umarım, sonraki çalışmalar veya sorun çözümü için de destek sağlamaktır.

Ele almayı hedeflediğimiz konular oldukça düzgün biçimde iki ana alana ayrılır: *Unicode* fiilen metin/karakterler ve metin kodlaması dünyasında yaşayan *OpenType* ve elbette bu iki dünya birbirine bağlıdır; bu ilk makalede bile aralarında bir miktar kesişim vardır.

### Hangi konuları tartışacağız?

Bu makalenin ana odağı, Unicode ile ilgili bazı konulardır: “karakter”den ne kastedildiğinin tartışılmasıyla başlayıp yazı sistemleri/diller, Unicode kodlaması ve UTF-8’i tanıtmaya; bununla birlikte çok dilli metin dosyalarıyla çalışmaya dair bir örneğe uzanıyor. Sonraki bir makale, OpenType yazı tipi teknolojisiyle ilgili arka plan konularını ele almak üzere bu parça üzerine inşa edilecektir. Açıkçası, bir blog yazısının sınırları içinde, tartışmayı umduğumuz tüm alanlarda “derinlemesine bir inceleme” yapmaya çalışmak mümkün değildir: açıkça belirttiğimiz amaç, birkaç temel kavramın nasıl ilişkili olduğunu ve birlikte nasıl çalıştığını gösteren genel çerçeveyi sunmaktır. En temel kavramla başlayacağız: *karakteri*.

## Karakter: Temel bir yapı taşı

Tartışmalarımızın (ve Unicode’un) tam merkezinde yer alan temel bir fikir/kavram, bir “karakter”in ne anlama geldiğidir: bu, gündelik işlerde ve konuşmalarda kullanımıyla anlamı çoğu zaman “varsayılan” sözcüklerden biridir. Ancak Unicode, dizgi ve yazı tipi teknolojileri açısından “karakter”in ne anlama geldiğini biraz daha kesin tanımlamamız gerekir. Örneğin, bizim için **a** ve *a* ifadelerini farklı “karakterler” olarak düşünmek oldukça doğal olabilir: ‘kalın a’ ve ‘italik a’. Ama durum böyle değildir: bunlar aynı temel karakterin yalnızca farklı görsel temsilleridir; Unicode bu karaktere resmî olarak şu adı verir [LATİN KÜÇÜK HARF A](http://unicode.org/charts/PDF/U0000.pdf).

Unicode [bir karakteri tanımlar](http://www.unicode.org/glossary/#character) şu şekilde tanımlar:

> “Anlam değeri olan yazılı dilin en küçük bileşeni; belirli bir biçimden ziyade soyut anlamı ve/veya biçimi ifade eder...”

ki bu, bir karakterin belirli *görsel görünümüne* ile *anlamı*.

Bir karakteri bir dilin ya da daha doğru bir ifadeyle bir *alfabesi*nin temel birimi ya da yapı taşı olarak düşünebilirsiniz — aşağıda tartıştığımız bir konu. Bir karakterin belirli bir yazı tipiyle görüntülendiğinde gerçekte nasıl göründüğü, Unicode’un karakter tanımı açısından önemli değildir: burada gerçekten önemli olan yalnızca *anlamı* burada gerçekten önemli olan şey şudur: *rolü ve amacı* her bir karakterin, yazı sistemlerinin/dillerin en sonunda oluşturulduğu yapı taşlarından biri olarak.

### Yazı sistemi ve dil

Kısaca değinmeye değer iki önemli kavram vardır: *yazı sistemleri* ve *dilleri*. Unicode web sitesi yararlı bir [yazı sistemi tanımı](https://www.unicode.org/standard/supported.html):

> “Unicode Standardı yazı sistemlerini diller yerine kodlar. Birden fazla dil için yazı sistemleri, tarihsel olarak ilişkili türetilere sahip grafik sembol kümelerini paylaştığında, bu grafik sembollerin tümünün birleşimi kodlama için tek bir karakterler topluluğu olarak ele alınır ve tek bir yazı sistemi olarak tanımlanır.”

Bir [Wikipedia’dan bir örnek](https://en.wikipedia.org/wiki/Script_\(Unicode\)), Latin yazı sistemi belirli bir [karakterler kümesinden](http://unicode.org/charts/) oluşur; bu karakterler birden çok dilde kullanılır: İngilizce, Fransızca, Almanca, İtalyanca vb. Elbette, Latin yazı sistemi içinde tanımlanan tüm karakterler Latin yazı sistemine dayanan bütün diller tarafından kullanılmaz; örneğin İngiliz alfabesi, Fransızca ya da Almanca gibi diğer Avrupa dillerinde bulunan aksanlı karakterleri içermez.

### OpenType yazı tipleri: yazı sistemleri ve diller

Bu noktada Unicode’dan OpenType yazı tiplerine geçiş yapacağız; çünkü yazı sistemi ve dil kavramları OpenType yazı tipi teknolojisinde de son derece önemli bir rol oynar.

Aynı [alfabesi](http://www.unicode.org/glossary/#script) yazı sistemini kullanan bir dizi dilin her biri, belirli bir dilde yazılmış metni görüntüleme (dizgi) konusunda farklı tipografik geleneklere sahip olabilir. Güzel bir örnek Türkçede ve [noktasız i’nin davranışında](https://en.wikipedia.org/wiki/Dotted_and_dotless_I) (bakınız o sayfanın birleşik harfler notları). Yazı sistemleri/dillerle ilgili tipografik “kurallar”, sözde yazı sistemi ve dil *etiketler* özelliklerinin kullanımı yoluyla OpenType yazı tiplerinin işlevselliğine yerleştirilmiştir; bu özellikler, belirli yazı sistemi/dil kombinasyonları için uygulanması gereken kuralları tanımlamakta kullanılır. Doğal olarak, her OpenType yazı tipinin desteklediği yazı sistemi/dil kümesi, yazı tipini oluşturanların yaptığı tercihlere ve yazı tipinin üretilme nedenine göre değişecektir. XeTeX veya LuaTeX gibi gelişmiş dizgi yazılımları, OpenType yazı tiplerine yerleştirilmiş bu kurallardan yararlanarak, belirli bir dilde metin dizgilenirken kullanıcıların bunları girdi metnine seçici biçimde uygulamasına izin verebilir; örneğin LaTeX [fontspec paketini](https://ctan.org/pkg/fontspec?lang=en).

#### Bir OpenType yazı tipinin içini görmek: yazı sistemleri/diller

Bunu biraz daha netleştirmek için, ücretsiz [Scheherazade OpenType yazı tipini](http://software.sil.org/scheherazade/download/) içinde açılmış halde gösteren bir ekran görüntüsü [Microsoft VOLT](https://www.microsoft.com/en-us/Typography/volt.aspx) yazı tipi düzenleme yazılımını (o da ücretsiz) gösteren aşağıdaki görüntüye bakabilirsiniz. Bu görüntüde Scheherazade’nin içine yerleşik yazı sistemlerini, dilleri ve tipografik özellikleri görebilirsiniz — VOLT kullanarak Scheherazade’ye ek özellikler ve işlevler ekleyebilirsiniz, ancak bu bu makalenin kapsamının çok dışındadır!

![Scheherazade OpenType (TrueType türü) yazı tipinin Microsoft VOLT içinde açılmış hâli](/files/0ec3a285a8c80550a75ff25d57db0b5606c78106)

Bu ekran görüntüsünden Scheherazade’nin Arapça ve Latin yazı sistemlerini desteklediğini ve Arap yazı sistemini kullanan birkaç dil için daha özel destek sağladığını görebilirsiniz — yukarıdaki yeşil çerçeveli kutuda listelenen sözde OpenType özellikleri kullanılarak. Bu özelliklerin ayrıntılarına girmeyeceğiz; ancak buradaki mesaj, yüksek kaliteli OpenType yazı tiplerinin, yazı tiplerine yerleştirilmiş tipografik kurallardan yararlanabilen dizgi yazılımlarının kullanımı için hazır durumda pek çok zekâ içermesidir.

İlgilenen okuyucu, OpenType etiket kayıt defterine bakarak [yazı sistemi etiketlerini](https://www.microsoft.com/typography/otspec/scripttags.htm) ve [dil etiketlerini](https://www.microsoft.com/typography/developers/opentype/languagetags.aspx) günümüzde OpenType belirtiminde kullanılanları görebilir.

### Karakterlere geri dönelim: Farklı karakter rolleri

Bir yazı sisteminin (ya da dilin) temel öğelerini oluşturan karakter kümesindeki bütün karakterler aynı rolü üstlenmez. Örneğin, çoğu dilde şu karakterler vardır: *noktalama işaretleri*, sayısal *rakamlar* ayrıca bizim *harfler* olarak düşündüğümüz, bazı yazı sistemlerinde büyük ve küçük harf biçimleri de bulunan alfabe karakterleri. Karakter kavramı oldukça geniştir ve Unicode Standardı, özel görevleri olan karakterleri de içerir; bunlar *görüntülenmek için tasarlanmamıştır* ama görevleri “metnin yorumlanmasını veya görüntülenmesini denetlemektir”. Örneğin, bazı Arapça metinleri dizgi yaparken belirli karakterlerin birleşme davranışını zorlamak veya engellemek isteyebilirsiniz; Unicode standardı bunu yapmak için özel denetim karakterleri sağlar: sözde [ZERO WIDTH JOINER](https://en.wikipedia.org/wiki/Zero-width_joiner) ve [ZERO WIDTH NON-JOINER](https://en.wikipedia.org/wiki/Zero-width_non-joiner). Bu karakterler görüntüleme için amaçlanmamıştır ve metni işlerken yazılım tarafından, amaçlanan görsel etkileri üretmek üzere “soğurulur”.

Unicode standardında belirtilen tüm karakterlere, her bir karakterin Unicode kodlamasındaki rolünü ve amacını fiilen tanımlayan bir özellikler kümesi atanır — LATIN SMALL LETTER A gibi karakter adları, bir karakterin özellikler listesinin yalnızca bir öğesidir. Bu özellikler, tamamen şu kaynakta açıklanır: [Unicode Karakter Veritabanı (UCD)](http://www.unicode.org/reports/tr44/) ve arama, sıralama, yazım denetimi vb. bilgisayarlı metin işleme işlemlerinde yaygın olarak kullanılır. Unicode karakter özelliklerini listeleyen veri dosyaları da [indirilebilir](http://www.unicode.org/Public/UCD/latest/).

Atanan her karakterin özellikleri arasında, tartışmamız açısından en önemlisi *sayısal bir tanımlayıcıdır* Unicode kodlaması tarafından atanır; şimdi bu konuya geçiyoruz.

### Karakterler: Sayılar ve kodlamalar

Bu açık bir ifade ama bilgisayarlar ve diğer dijital aygıtlar sayısal verileri saklama ve işleme işindedir: peki bu metinle nasıl ilişkilidir? Bir bilgisayar klavyesi kullanarak ya da bir mobil cihazın ekranına dokunarak biraz metin yazdığınızda, tuş vuruşlarınız yazmakta olduğunuz karakter dizisini temsil eden sayılara dönüştürülür.

Bir noktada o metni (bir sayı dizisini) bir e-posta, kısa mesaj ya da Tweet veya bir çeşit sosyal medya gönderisi gibi çevrimiçi iletişim yoluyla aktarmak isteyebilirsiniz. Açıkçası, metni oluşturduğunuz cihaz ile alıcının/alıcıların kullandığı cihaz(lar) bir şekilde, hangi sayıların hangi karakterleri temsil ettiği konusunda anlaşmalıdır. Aksi halde metniniz alıcının cihazında doğru görüntülenmeyebilir.

Günümüzün küresel iletişiminin çalışması için, gönderen ve alan cihazların, belirli bir sayı kümesinin belirli bir karakter kümesini temsil ettiği konusunda “karşılıklı olarak kabul edilmiş bir kurala” ihtiyacı vardır. Bu kurala bir *kodlama*: belirli bir karakter kümesini temsil etmek için kullanılan sayı kümesi; Unicode kodlaması artık *fiilî* küresel standarttır.

## Unicode: Metin saklamak için bitler ve baytlar

Unicode, metin kodlamasından çok daha fazlasını kapsayan devasa bir standarttır ama burada yalnızca sağladığı kodlamaya odaklanıyoruz.

#### Bitler, baytlar ve kaç karakter?

Aygıtların metni sayılar olarak saklayıp temsil ettiğini söyledik — daha özel olarak, karakterler tamsayılar olarak saklanacaktır: tam sayılar. Bunun Unicode kodlaması açısından sonuçlarını anlamak için, tamsayıların bilgisayarlarda nasıl saklandığına dair *çok* kısa, *çok* temel bir gözden geçirmeye ihtiyacımız var (bilgisayar bilimine girmeyi amaçlamıyoruz).

Uzun hikâyeyi çok kısaltarak söylemek gerekirse, günümüz masaüstü veya elde taşınan aygıtları tamsayıları 1, 2, 4 ya da 8 bayt uzunluğunda ayrık “parçalar” halinde saklar. Bu depolama birimlerinin her biri, her depolama birimindeki toplam bit sayısına bağlı olarak belirli bir en büyük pozitif değere kadar tamsayı saklayabilir:

* 1 bayt (8 bit): en büyük pozitif tamsayı 255’tir;
* 2 bayt (16 bit): en büyük pozitif tamsayı 65535’tir;
* 4 bayt (32 bit): en büyük pozitif tamsayı 4.294.967.295’tir;
* 8 bayt (64 bit): en büyük pozitif tamsayı 18.446.744.073.709.551.615’tir.

Uygulamada, Unicode standardı dünyanın tüm karakterlerini kodlamak için 0 ile 1.114.111 arasındaki sayıları kullanır; sonuç olarak tüm aralığı kodlamak için yalnızca 21 bite ihtiyaç duyar. Bunu, n bit içeren depolama birimlerinin 0’dan, en büyük değer olan $$2^n -1$$’e kadar herhangi bir pozitif tamsayıyı temsil edebildiğini fark ederek görebiliriz; dolayısıyla:

* 20 bitte saklanabilen en büyük değer $$2^{20} -1 = 1,048,575$$ (çok küçük);
* 21 bitte saklanabilen en büyük değer $$2^{21} -1 = 2,097,151$$ (yeterince büyük).

Bilgisayarların veriyi (sayıları) 1, 2, 4 (veya 8) baytlık birimlerde sakladığını belirttik; peki 1.114.111 olan Unicode’un en büyük değerine kadar değerleri saklamamız gerekiyorsa depolama birimi ne kadar büyük olmalıdır? Açıkça, bir baytlık depolama birimi en fazla 255 değeri ve 2 bayt 65535’i saklayabilir: bunların hiçbiri Unicode tarafından kodlanan karakterlerin tüm aralığını saklamak için yeterli değildir. Sonraki kullanılabilir seçenek, boyutu 4 bayt olan depolama birimleridir; bunlar 4.294.967.295’e kadar tamsayıları saklayabilir ki bu bizim gerçekte ihtiyaç duyacağımızdan çok daha fazladır. Yani, depolama birimi olarak 4 baytı seçersek tüm Unicode değerlerini saklamak için kesinlikle fazlasıyla yerimiz olur; her karakter 4 bayt (32 bit) gerektiren bir tamsayı olarak saklanır. Ancak, her şeyi saklamak için 4 bayt kullanmak oldukça alan israfıdır çünkü en büyük Unicode değerleri bile en fazla 21 bit gerektirir — bunlar 32 bit kullanılarak saklanırsa, bu 32 bitin 11’i hiçbir zaman kullanılmayacaktır.

**Not**: Unicode aralığı 0 ile 1.114.111 arasında olsa da o aralıktaki her değer aslında kullanılmaz: teknik nedenlerle, bazı değerler gerçek Unicode karakterleri olarak kullanım için geçersiz sayılır.

### Peki, UTF-8 nedir?

XeTeX veya LuaTeX hakkında okursanız, o TeX motorlarının metin ve LaTeX giriş dosyalarını “UTF-8 biçiminde” okuduğunu söyleyen açıklamalarla neredeyse kesin olarak karşılaşırsınız. Peki “UTF-8 biçimi” nedir ve Unicode ile nasıl ilişkilidir? Unicode terminolojisinde, dünyanın karakterlerini kodlamak için kullanılan 0 ile 1.114.111 arasındaki değerlerinin her birine bir [kod noktası](http://www.unicode.org/glossary/#code_point).

Gördük ki, *kuramsal olarak*, Unicode kodlanmış metnimizin tamamını Unicode’un kod noktalarının tüm aralığını temsil etmek için karakter başına 4 bayt kullanarak saklamamız gerekir. Ancak uygulamada, oldukça zeki bazı insanlar tek bir Unicode sayısını (kod noktasını) *dizisiyle* olarak temsil etmenin basit bir yolunu icat etti; bu daha küçük sayıların her biri tek bir baytta saklanır: bu,  *dönüştüren* tek bir (daha büyük) tamsayıyı daha küçük (bayt boyutunda) bir diziye *çok baytlı bir dizi*— metin dosyasındaki 1 ila 4 ardışık bayt, tek bir bireysel Unicode karakterini (yani kod noktası değerini) temsil edebilir.

UTF şu anlama gelir: *Unicode Dönüşüm Biçimi* ve burada anahtar sözcük *Dönüşüm*. Esasen, UTF-8’i tek bir Unicode kod noktası değerini 1 ila 4 bayt boyutundaki parçalardan oluşan bir diziye dönüştürmek için bir “tarif” ya da algoritma olarak düşünebilirsiniz. Unicode kod noktasının değeri arttıkça, onu UTF-8 biçiminde temsil etmek için gereken tekil bayt sayısı da artar.

UTF-8 oluşturulmasının teknik ve tarihsel nedenleri vardır ve UTF-8’in icrasının arkasındaki hikâye [2003 tarihli büyüleyici bir e-postada kaydedilmiştir](https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt), ki e-postanın başlarına yakın bir yerde şu satır yer alır:

> “Bu doğru değil. UTF-8, 1992’nin Eylül ayında ya da öyle bir zamanda, bir gece New Jersey’de bir lokantada, gözlerimin önünde bir servis altlığı üzerine tasarlandı.”

#### Örnek: Arapça harf ل

Arapça ل harfinin (Unicode adı ARABIC LETTER LAM) örneğini ele alalım; bu harfe Unicode kod noktası değeri 1604 (ondalık) veya 0644 (onaltılık) atanmıştır: UTF-8’deki gösterimi *iki baytlık* D9 84 (onaltılık) dizisi ya da ondalık olarak 217 132’dir. Metni saklamak için UTF-8 biçimini kullanırken, ل’yi temsil etmek üzere tek bir 1604 sayısı içeren bir metin dosyası yerine, bu iki baytlık değere dönüştürülür: 217 ve 132 — ل karakteri bir *iki baytlık dizi*olarak saklanır. UTF-8 algoritmasını daha ayrıntılı keşfetmek isteyen okuyucular, ayrıntılı bir açıklamayı ve C kodunu benim [kişisel blog sitesinde](http://www.readytext.co.uk/?p=1284).

Bir yazılım parçası (örneğin XeTeX veya LuaTeX) UTF-8 biçiminde metin okuduğunda, o yazılımın o dosyada bulunan her karakter için Unicode değerini belirlemesi gerekir; bu nedenle *tersine çevirmesi* UTF-8 dönüşüm sürecini tersine çevirmek için bir algoritma kullanır. Bu “tersine çevirme algoritması” sayesinde iki bayt (217 ve 132) yeniden birleştirilerek 1604 tamsayısı oluşturulur; bu da daha sonra Arapça ل harfinin Unicode kod noktası değeri olarak tanınabilir.

Dolayısıyla, sonuç olarak UTF-8 aslında Unicode kodlu metnin depolanması ve iletilmesi için kullanılan yalnızca ara bir veri biçimidir.

**Not**: Bazı sistemler metni karakter başına 32 bit kullanarak saklamayı seçer; buna [UTF-32](https://en.wikipedia.org/wiki/UTF-32)denir — ayrıca [UTF-16](https://en.wikipedia.org/wiki/UTF-16) da vardır; ancak Unicode kodlu metni saklamanın en yaygın yolu UTF-8’dir.

## Çok dilli TeX dosyaları: XeTeX ve LuaTeX

Hem XeTeX hem de LuaTeX, çok gelişmiş çokdilli dizgi yapabilir; ancak bunu gerçekleştirme mekanizmaları oldukça farklıdır ve her motorun tasarım/geliştirme felsefesini yansıtır. Bunu derinlemesine incelemeyeceğiz, sadece XeTeX motorunun LuaTeX’te bulunmayan yazılım bileşenleri içerdiğini — özellikle de *OpenType şekillendirme* (örneğin, adlı bir kitaplık aracılığıyla [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)).

Buna karşılık LuaTeX farklı bir yaklaşım benimser: tesisleri doğrudan gerçek TeX motorunun içine yerleştirmek yerine, LuaTeX son derece zengin bir komutlar kümesi (TeX ilkelleri) ve çok güçlü bir [Lua tabanlı API](/latex/tr/derinlemesine-makaleler/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md) sunar; bu arayüz üzerinden geliştiriciler çokdilli dizgi için aynı derecede gelişmiş çözümler oluşturabilir. LuaTeX felsefesi LaTeX paket geliştiricileri için ek iş gerektirebilse de, çözümler gerçek LuaTeX motorunun içine “gömülü” değil, TeX ve Lua kodundan — ya da C/C++ ile yazılmış eklentilerden — oluşturulduğu için çok daha fazla esneklik sağlar.

**Not**: Okuyucular, OpenType şekillendirmenin büyüleyici ama karmaşık dünyasını daha fazla keşfetmek isterlerse, adlı mükemmel açık kaynaklı kitaplık hakkında okumak isteyebilirler [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)—Firefox, Chrome ve LibreOffice dâhil birçok uygulama tarafından ve elbette XeTeX tarafından kullanılır. Bu makalenin yazarı, Arapça dizgi yapmak için HarfBuzz kullanarak [LuaTeX eklentileri oluşturdu](http://www.readytext.co.uk/?p=3186).

Günümüzde (örneğin sosyal medyada) birden çok dilden karakterler içeren metinleri iletmek olağandır ve çok dilli metin depolayan bir UTF-8 metin dosyası, UTF-8’de gösterimi 1, 2, 3 veya 4 bayt uzunluğunda olabilen karakterler içerebilir. Dolayısıyla, özünde bir UTF-8 metin dosyası yalnızca tek baytların bir akışıdır; ancak o dosyadaki her gerçek karakter 1 ila 4 bayt uzunluğunda olabilir: tek tek karakterler *çok baytlı dizilere*.

Çokdilli metinle çalışma (dizgi) konusunun bazı temel yönlerini daha fazla incelemek için Arap yazı sistemini içeren bir örnek kullanacağız; çünkü Arapça bize birden çok kavramı ele alma imkânı sağlar.

#### Not: Arap yazı sistemi

Bu [Arap yazı sistemi](https://en.wikipedia.org/wiki/Arabic_script) sağdan sola okunan ve sağdan sola yazılan bitişik bir tarzda yazılır. Her Arap harfi, şu koşullara göre potansiyel olarak 4 farklı biçimden birini alabilir:

* tek başına, bağımsız (yalıtılmış) bir karakter olarak görüntülenip görüntülenmediği (başka hiçbir şeye bağlanmamışsa);
* bir sözcük içinde — bir sözcüğün başında, ortasında ya da sonunda — yer alıp almadığı: sırasıyla *başlangıç*, *orta* ve *son* biçimleri olarak adlandırılır.

Arap yazı sisteminin her karakterinin kendi birleşme kuralları vardır ve solunda, sağında ya da hem solunda hem sağında başka bir karakter olduğunda biçim/görünüm değiştirebilir ya da değiştirmeyebilir. Bunu daha fazla keşfetmek isteyen okuyucular [Wikipedia’da tam bir liste bulabilir](https://en.wikipedia.org/wiki/Template:Arabic_alphabet_shapes/joining).

#### Örnek: UTF-8’de Arapça ve İngilizce metin

Arapça ve İngilizce metinden oluşan tek bir satır içeren bir UTF-8 metin dosyası oluşturduğumuzu varsayalım: This is العَرَبِيَّة text!

Bu metin satırı 3 boşluk karakteri, 11 İngilizce (Latin yazı sistemi) karakteri ve 12 Arapça karakter içerir (her ne kadar bu hemen açık/görünür olmayabilse de). UTF-8 metin dosyası olarak kaydedildiğinde, aşağıdaki sebeplerle 38 bayt depolama kaplar:

* **Latin yazı sistemi**: boşluklar artı İngilizce metin: 14 ✕ 1 baytlık karakter = 14 bayt;
* **Arap yazı sistemi**: 12 Arapça karakter ✕ karakter başına 2 bayt = 24 bayt.

Toplamda 14 + 24 = 38 bayt.

#### Daha derine inelim

Örnek metnimizi `arabic.txt` adlı bir UTF-8 dosyasına kaydedip onu bir onaltılık düzenleyicide açarsak, içerdiği gerçek baytları inceleyebiliriz. Aşağıdaki açıklamalı ekran görüntüsünü inceleyerek Arapça metnin karakter başına 2 bayt olarak saklandığını görebilirsiniz:

![Bir onaltılık düzenleyici içinde açılmış İngilizce ve Arapça metin içeren bir UTF-8 metin dosyası.](/files/f32077d4dae4c7f5a0d13de2275d4df9f63d8312)

Bir onaltılık düzenleyici içinde açılmış İngilizce ve Arapça metin içeren bir UTF-8 metin dosyası. Latin yazı sistemi karakterlerinin tek bir bayt gerektirdiğini, Arap yazı sistemi karakterlerinin ise karakter başına iki bayt kullanılarak saklandığını açıkça görebilirsiniz.

Bu ekran görüntüsünden birkaç gözlem yapabilirsiniz:

* Arapça metin soldan sağa bir sıra halinde saklanmıştır ve karakterler, Arap harflerinin ve ünlülerin ham, şekillendirilmemiş (yalıtılmış) sürümleridir;
* Latin yazı sistemi “This is ” ifadesini takiben, bu dosyayı okuyan herhangi bir yazılıma bir sonraki karakterin Arap yazı sisteminde olduğunu bildiren ek bir bilgi yoktur.

Eğer çok dilli bir belge dizgi yapıyorsanız (örneğin İngilizce ve Arapça içeren), giriş metin dosyasını (bayt akışı olarak) okuma/işleme sırasında XeTeX veya LuaTeX, her karakterin başlangıcını ve sonunu algılayabilmeli ve UTF-8 dönüşümünü tersine çevirmek ve ilgili Unicode kod noktası değerini oluşturmak için gereken doğru bayt sayısını okuyabilmelidir. Yazılımın bunu yapmasını sağlayan şey UTF-8 algoritmasının kendisidir: her bir karakterin ilk baytını ve ilgili Unicode kod noktasını hesaplamak için kaç bayt okunması gerektiğini algılamayı mümkün kılar. UTF-8 kullanımı kolaydır ama gerçekten oldukça zekicedir.

#### Mantıksal sıra, görüntüleme sırası ve OpenType şekillendirme

Yukarıdaki Arapça metne (العَرَبِيَّة) dikkatle bakarsanız, metin dosyamızın gerçekten de 12 ayrı Arapça karakter içerdiğini görmek zor olabilir — özellikle de Arap yazı sistemine aşina değilseniz! Ancak, yukarıdaki ekran görüntüsünün sağ tarafında görüntülenen Arapça karakterleri dikkatle sayarsanız toplamda 12 tane olduğunu görebilirsiniz.

Arapça gibi karmaşık yazı sistemli dillerde, metin dosyamızın *saklar* ve sizin *ekranda gördüğünüz* gözle görülür biçimde *çok* gerçekten farklıdır! Diyelim ki bu metni bir tarayıcıda görüntülerken gördüğünüz şey şudur:

![Dizgi yapılmış Arapça metin görüntüsü](/files/1f956ad95b263e83d21aa52f9e0e8199d35bc481)

Ama yukarıdaki ekran görüntüsünün gösterdiği gibi, UTF-8 metin dosyasının gerçekte içerdiği şey şudur:

![Dizgi yapılmamış Arapça metin görüntüsü (yalıtılmış karakterler)](/files/ecce608f1e2fa607c0d5508b240d22c5cf7323e5)

Arap yazı sisteminin bitişik doğasına aşina olmasanız bile, bir metin dosyasında bulunan Arapça karakterlerin aktarılmasından dizgiye ve/veya ekranda görüntülenmesine (glifler olarak) kadar geçen süreçte “bir şeylerin” gerçekleştiğini açıkça görebilirsiniz. TeX/LaTeX’i, örneğin Latin tabanlı basit yazı sistemli dillerle kullanmaya alışkınsanız, bu gerçekten çok kafa karıştırıcı olabilir!

Burada bazı önemli kavramlar devrededir; çünkü Unicode metin dosyaları… yani, metin (Unicode) saklama işindedir ve dizgi ile görüntüleme sistemleri yazı tipleri ve glifler (OpenType) kullanma işindedir:

* metin dosyası Arapça karakterleri soldan sağa bir sırada kaydetmiştir ama Arapça sağdan sola okunur/görüntülenir: metin dosyaları metni sözde *mantıksal sıra*;
* metin dosyası, ekranda sunulan gerçek görüntüden çok farklı görünen tek tek karakterler içerir: metin dosyası Arapça karakterleri yalıtılmış, bağlanmamış biçimlerinde içerir.

#### Neler oluyor?

Bir metin dosyasında Arapça, soldan sağa sıralanmış yalıtılmış biçim karakterleri olarak saklanır: düşünürseniz, metin dosyası Arapça metni *yazıldığı sırayla* (b *mantıksal sıra*sırada kaydeder). Bu metin görüntüleme için işlendiğinde ya da dizgi yapıldığında, doğru okuma sırasına göre görüntülenir; buna çoğu zaman *görsel sıra* ya da *görüntüleme sırası*denir; ayrıca Arapça karakterlerin yalıtılmış biçimleri *şekillendirilir* ve tipografik olarak doğru görüntü sürümlerine dönüştürülür. Bunu düşünmenin bir yolu, basit bir metin dosyasının metni (Unicode karakterlerini) mümkün olan en temel biçimde saklamak zorunda olduğudur: ham, şekillendirilmemiş, tek tek metin karakterleri — bu karakterleri işletim sistemi, yazı tipleri ve görüntüleme aygıtında bulunan dizgi/görüntüleme yazılımına dayanarak görüntülemek sistem yazılımının görevidir.

adı verilen bir süreçten geçer *şekillendirme*. Tek tek Arapça karakterler, Arap yazı sisteminin ve yazı düzeninin birleşme kurallarına göre gereken her karakterin varyantını doğru şekilde temsil eden şekillendirilmiş gliflere dönüştürülür. Buna ek olarak, yüksek kaliteli dizgi yazılımı (iyi OpenType yazı tipleri kullanarak), adı verilen bir süreç aracılığıyla ek tipografik gelişmişlik uygulayarak daha fazla işlem yapacaktır *OpenType şekillendirme*—çok çeşitli tipografik işlemleri kapsayan bir süreç; bunlar arasında şunlar yer alabilir:

* birden fazla tekil glifi tek bir karmaşık birleşik harf glifiyle değiştirmek (Arapçada çok yaygındır) ya da
* örneğin Arapça ünlü işaretlerinin, hangi glifin üzerinde veya altında yer aldıklarına göre konumlarını ayarlayan konumlandırma işlemleri.

![Dizgi yapıldığında Arapça metnin geçirdiği dönüşümü gösteren görsel](/files/5148aa50ff9a7db8b0cba1f795bc8ce27a45d308)

Mantıksal sıralama ile görsel (ekrandaki) sıralama arasındaki fark. Bu grafikte, bir metin dosyasında saklanan Arapça karakterlerin görüntülendiklerinde veya dizgi yapıldıklarında yeniden sıralanma ve şekillendirmeden geçtiğini görebilirsiniz.

Gelişmiş OpenType yazı tiplerinin tasarımcıları ve oluşturucuları, yazı tiplerine yerleştirilmiş sofistike tipografik yetenekleri sunmak için çok ciddi miktarda zaman ve uzmanlık yatırır.

Arapça metne uygulanan şekillendirmeyi kapatmak için mükemmel, ücretsiz, [BabelPad](http://www.babelstone.co.uk/Software/BabelPad.html) şekillendirmeyi devre dışı bırakıp metin dosyasında gerçekten bulunan ham, tek tek birleştirilmemiş (şekillendirilmemiş) karakterleri görmenizi sağlayan Unicode metin düzenleyicisi (yalnızca Windows) — bu birleştirilmiş ekran görüntüsünün alt yarısına bakın:

![BabelPad metin düzenleyicisinin OpenType şekillendirmeyi kapatma yeteneğini gösteren görsel](/files/566ed516b28da9fd3102b11503e0ad7c1a4494d9)

BabelPad Unicode metin düzenleyicisini kullanarak OpenType şekillendirmeyi açmak (üstteki şekil) ya da kapatmak (alttaki şekil). OpenType şekillendirmeyi kapatmak, Arapça metni düzenlemeyi çok daha kolay hale getirir.

Mantıksal sıralama ve görüntüleme sıralaması kavramları, şekillendirme süreçleriyle birlikte, Arapça gibi karmaşık yazı sistemleri içeren çok dilli metin dosyalarıyla düzenleme veya dizgi yaparken onlarla ilk kez karşılaştığınızda oldukça kafa karıştırıcı olabilir: umarım yukarıdakiler, başlangıçtaki bazı karışıklıkları önlemeye yardımcı olmuştur.


---

# 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://ayakaleaf-pro.ayaka.space/latex/tr/derinlemesine-makaleler/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.