Base64 e-posta eklerinde, JWT'lerde, data URI'lerde ve API yanıtlarında karşınıza çıkar. 3 baytın 4 karaktere nasıl dönüştüğünü, boyutun neden üçte bir arttığını ve en sık yapılan hataları örneklerle anlatıyoruz.
Base64, ikili veriyi (bir resmi, PDF'i, anahtar dosyasını ya da herhangi bir bayt dizisini) yalnızca 64 güvenli karakterden oluşan düz metne çeviren bir kodlama yöntemidir. Her 3 bayt 4 karaktere dönüşür; bu yüzden çıktı girdiden yaklaşık üçte bir daha büyüktür. Base64 nedir sorusunun kısa cevabı şu: yalnızca metin taşıyabilen bir kanala (e-posta, JSON alanı, URL, HTML) ikili veri sokmanın standart yolu. Şifreleme değildir; anahtar kullanmaz ve herkes saniyeler içinde geri çözebilir.
Bu yazıda hesabı önce elle yapacağız, sonra gerçek projelerde karşılaşılan hatalara bakacağız. Denemeler için Base64 kodlayıcı / çözücü aracını yan sekmede açık tutabilirsiniz. Adres çubuğuna girecek değerler için URL kodlayıcı / çözücü, bir token'dan çıkan JSON'u okumak için JSON düzenleyici, koda gömülecek bir görseli önceden hafifletmek için görsel sıkıştırıcı, çıktının uzunluğunu ölçmek için de karakter sayacı işinizi görür.
İnternetin ilk e-posta altyapısı 7 bitlik ASCII metin için tasarlanmıştı. Bir fotoğrafı ya da Word belgesini olduğu gibi göndermek mümkün değildi: yoldaki bazı sunucular 8. biti siliyor, uzun satırları bölüyor ya da kontrol karakterlerini yutuyordu. Çözüm, ikili veriyi her sistemin bozmadan taşıyabileceği küçük bir karakter kümesine çevirmekti. MIME standardı (RFC 2045, 1996) bu yöntemi e-posta ekleri için tanımladı; bugün geliştiricilerin başvurduğu genel tanım ise RFC 4648'dedir.
Aynı sorun bugün başka kılıklarda karşımıza çıkıyor. JSON yalnızca metin taşır, ikili alan tipi yoktur. HTML ve CSS dosyaları metindir. HTTP başlıkları metindir. Bu kanallardan bir bayt dizisi geçirmek gerektiğinde Base64 hâlâ en yaygın köprüdür; API yanıtlarında, sertifika dosyalarında ve e-postaların kaynak kodunda onu görmenizin sebebi budur.
Adı buradan gelir: kodlamada tam 64 sembol kullanılır ve her sembol 6 bitlik bir değeri (0–63) temsil eder. Sıra sabittir ve her uygulamada aynıdır:
| Değer aralığı | Karakterler | Not |
|---|---|---|
| 0–25 | A–Z | Büyük harfler |
| 26–51 | a–z | Küçük harfler |
| 52–61 | 0–9 | Rakamlar |
| 62 | + | base64url'de yerini - alır |
| 63 | / | base64url'de yerini _ alır |
| Dolgu | = | Değer taşımaz, uzunluğu tamamlar |
Türkçe harflerin hiçbiri alfabede yoktur ve olması da gerekmez. Kodlanan şey harfler değil, baytlardır.
Mantığı görmenin en iyi yolu küçük bir örneği elle çözmek. "Kar" kelimesini kodlayalım:
01001011 01100001 01110010.010010 110110 000101 110010.S2Fy olur.24 sayısı hem 8'e hem 6'ya tam bölündüğü için 3 bayt her zaman 4 karaktere oturur. Kod çözme aynı yolu tersinden yürür: her karakter 6 bite, her dört karakter üç bayta geri döner.
Veri uzunluğu 3'ün katı değilse son grup eksik kalır. Eksik bitler sıfırla doldurulur, çıktı da yine 4'ün katına = işaretiyle tamamlanır:
| Girdi | Bayt sayısı | Çıktı | Dolgu |
|---|---|---|---|
| Kar | 3 | S2Fy | Yok |
| Ka | 2 | S2E= | Bir işaret |
| K | 1 | Sw== | İki işaret |
Üç dolgu karakterini asla görmezsiniz. Uzunluğu 4'e bölündüğünde 1 kalan bir dizi de geçersizdir; bu çoğunlukla kopyalarken bir karakterin kaybolduğunu ya da veritabanı sütununun değeri kestiğini gösterir.
Kodlanan şey ekrandaki harf değil, metnin bayt hâlidir. UTF-8'de "ç", "ş", "ğ" gibi harfler iki bayt tutar. Bu yüzden üç harfli "çay" dört bayttır ve w6dheQ== olur; "şeker" beş harf ama altı bayttır ve xZ9la2Vy çıkar. UTF-8 ile kodlanmış bir değeri çözen taraf baytları Windows-1254 gibi eski bir kodlamayla okursa "ç" yerine "ç" görürsünüz. Bu bozulma Base64'ün değil, iki sistemin karakter kodlamasında anlaşamamasının sonucudur.
Her 3 bayt 4 karakter olduğuna göre çıktı uzunluğu 4 × ⌈n / 3⌉ formülüyle bulunur. 30 KB'lık bir ikon yaklaşık 40 KB metne, 3 MB'lık bir PDF yaklaşık 4 MB'a dönüşür. MIME biçiminde her 76 karakterde bir satır sonu eklendiği için e-posta eklerinde ek yük yüzde 37 civarına çıkar.
İkili veriyi metne çeviren tek yöntem bu değildir. Diğerleri yoğunluk ile sadelik arasında farklı bir denge kurar:
| Kodlama | Oran | Boyut artışı | Nerede görülür |
|---|---|---|---|
| Hex (Base16) | Bayt başına 2 karakter | %100 | Özet (hash) değerleri, sağlama toplamları |
| Base32 | 5 bayta 8 karakter | %60 | İki adımlı doğrulama anahtarları |
| Base64 | 3 bayta 4 karakter | Yaklaşık %33 | E-posta, JSON, JWT, data URI |
| Ascii85 | 4 bayta 5 karakter | %25 | PDF ve PostScript akışları |
Base64'ü yaygın yapan verimlilik değil, sadeliği ve her dilde hazır bulunmasıdır. Gzip gibi HTTP sıkıştırması metin ağırlıklı yüklerde kaybın bir kısmını geri alır; ama zaten sıkıştırılmış bir JPEG ya da ZIP kodlandığında ek yükün çoğu yerinde kalır. Büyük bir dosyayı Base64'e çevirip taşımak bu yüzden çoğu zaman tasarım hatasıdır; dosyayı ayrı göndermek neredeyse her durumda daha iyidir.
Standart alfabedeki iki karakter web adreslerinde sorun çıkarır: / yol ayırıcıdır, + ise form verisinde boşluk olarak okunabilir. RFC 4648'in 5. bölümü bu yüzden ikinci bir alfabe tanımlar. + yerine -, / yerine _ kullanılır ve dolgu çoğu biçimde atılır, çünkü uzunluk veriden hesaplanabilir.
Fark tek örnekte görülür. <<???>> metni standart alfabede PDw/Pz8+Pg==, base64url'de PDw_Pz8-Pg olur. Standart hâli bir sorgu parametresine kaçışsız konursa sunucu artı işaretinin yerinde boşluk görebilir. Ya base64url kullanırsınız ya da değeri önce yüzde kodlamasından geçirirsiniz: PDw%2FPz8%2BPg%3D%3D.
JSON Web Token (JWT) bu alfabenin en bilinen kullanıcısıdır. Bir token'ın noktayla ayrılmış ilk iki parçası dolgusuz base64url'dir. eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 parçasını çözdüğünüzde {"alg":"HS256","typ":"JWT"} başlığı çıkar. Pek çok token'ın "eyJ" ile başlaması da tesadüf değildir: bir JSON nesnesinin açılışındaki {" karakterleri, ardından bir harf geldiğinde, kodlanınca hep bu üç harfe dönüşür.
RFC 2397'de tanımlanan data URI, bir dosyayı ayrı bir istek açmadan HTML ya da CSS içine yerleştirmeyi sağlar. Biçimi data:[medya türü][;base64],veri şeklindedir. Bir PNG dosyasının kodlanmış hâli her zaman iVBORw0KGgo ile başlar, çünkü bu karakterler PNG'nin sabit 8 baytlık imzasının karşılığıdır:
<img src="data:image/png;base64,iVBORw0KGgo..." alt="Logo">
Küçük ikonlarda ve tek parça hâlinde gönderilen e-posta şablonlarında bu yöntem işe yarar. Büyük görsellerde ise zarar verir:
Pratikte birkaç kilobaytın altındaki dosyalar için gömme makuldür. Gömmeden önce görseli sıkıştırmak, Base64 ek yükünü daha küçük bir sayının üzerine bindirmek anlamına gelir. SVG ikonlarda ise Base64 yerine URL kodlamalı düz metin (data:image/svg+xml,...) çoğu zaman daha kısa sonuç verir, çünkü SVG zaten metindir.
En pahalı yanlış anlama budur. Base64 veriyi gizlemez, yalnızca biçimini değiştirir. Anahtar yoktur, gizli bir parametre yoktur; algoritma herkese açıktır ve her programlama dilinde tek satırla tersine çevrilir.
HTTP Basic kimlik doğrulaması bunun en net örneğidir. Tarayıcı kullanıcı adını ve parolayı iki noktayla birleştirip kodlar ve başlığa koyar (RFC 7617). kullanici:Sifre123 çifti Authorization: Basic a3VsbGFuaWNpOlNpZnJlMTIz olarak gider. Bu başlığı gören biri parolayı anında okur; korumayı kodlama değil, bağlantının HTTPS olması sağlar.
Kural basit: bir yapılandırma dosyasında ya da log satırında Base64'e benzeyen bir değer görüyorsanız, onu düz metin kabul edin ve ona göre koruyun.
Aşağıdaki durumların hepsi gerçek projelerde tekrar tekrar yaşanır ve çoğu "bozuk karakter", "Invalid character" ya da "geçersiz anahtar" hatası olarak kendini gösterir.
btoa() fonksiyonu yalnızca Latin-1 aralığındaki karakterleri kabul eder; btoa("ş") bir InvalidCharacterError fırlatır. Metni önce TextEncoder ile UTF-8 baytlarına çevirmek gerekir. Sitedeki araç bunu kendisi yapar.echo "merhaba" | base64 komutu bWVyaGFiYQo= verir, çünkü echo metnin sonuna bir satır sonu ekler. Beklenen bWVyaGFiYQ== değeri için printf '%s' merhaba | base64 kullanın. Bir API anahtarı bu şekilde kodlanırsa sunucu anahtarı reddeder ve sebep saatlerce bulunamaz.-w 0 parametresi gerekir. Katı çözücüler bu satır sonlarını reddeder.+ karakterini boşluk sanır.= ekleyerek tamamlayın.- ve _, dolgulu ya da dolgusuz) ve satırlara bölünmüş MIME biçimi de kabul edilir.İşlem tarayıcınızda yapılır; girdiğiniz veri sunucuya gönderilmez, sayfa yalnızca anonim bir kullanım sayacını artırır. Yine de üretim ortamına ait gizli anahtarları denetiminizde olmayan hiçbir web formuna yapıştırmamak sağlıklı bir alışkanlıktır.
Girdi 3 baytın katı olmadığında çıktı 4 karakterin katına dolgu işaretiyle tamamlanır. Tek eşittir son grupta 2 bayt, iki eşittir 1 bayt olduğunu gösterir. Bazı biçimler, özellikle base64url kullananlar, dolguyu tamamen atar.
Hayır, büyütür. Çıktı, girdinin yaklaşık 4/3 katı kadardır. Boyut küçültmek istiyorsanız önce sıkıştırma (gzip, ZIP ya da daha uygun bir görsel formatı) gerekir; Base64'e yalnızca kanal metin istiyorsa başvurulur.
Sayılmaz. Değeri gören herkes onu tek adımda çözer. Base64 yalnızca bir taşıma biçimidir; gizlilik için şifreleme, parola saklamak için geri çevrilemez özet fonksiyonları kullanılır.
Mantık aynıdır, iki karakter farklıdır: base64url + yerine -, / yerine _ kullanır ve dolguyu çoğunlukla atar. Biri diğerine bu iki karakter değiştirilip gerekirse dolgu eklenerek çevrilir.
Dosyaları taşınabilir değil de daha küçük yapmak istiyorsanız minify nedir, kod küçültme nasıl yapılır yazısına bakın. 16 baytlık bir kimliğin base64url ile nasıl 22 karaktere indiğini UUID nedir yazısında anlattık. Base64 alanlarını sıkça taşıyan JSON verisi için JSON dosyası biçimlendirme rehberi, vektör ikonları koda gömmeden önce de SVG dosyası nedir yazısı işinize yarar.
