Ek ve ileti boyutları neden farklıdır?
Gönderim sırasında esas olarak PDF'ni içeren iletinin boyutu artar. E-posta başlangıçta metin için tasarlanmıştır. Bu nedenle e-posta programın, dosya eklerini MIME biçiminde paketler ve ikili verileri genellikle Base64 ile basit metin karakterlerine dönüştürür. Böylece dosyanın her 3 baytından 4 karakter oluşur ve bu karakterler, satır sonu işaretleri bulunan satırlara dağıtılır. Base64 kodlamasının kendisi geri döndürülebilir: Kod çözüldüğünde orijinal baytlar aynen yeniden elde edilir. Tamamlanmış iletiye ayrıca üstbilgiler, ileti metni ve ayrı bölümler arasındaki ayırıcılar eklenir.
Bu nedenle bir ileti, seçtiğin ekten belirgin ölçüde daha büyük olabilir. Almanca bir forumda birisi, 20,1 MB boyutundaki bir PDF'nin neden 27,5 MB boyutunda gönderilmiş bir e-postaya dönüştüğünü sormuştu. Bu hesaplayıcıda 20.100.000 baytı satır sonları açık ve ek bayt olmadan hesapladığında 26.800.000 bayt Base64 verisi ve 705.264 bayt satır sonu elde edilir. Toplam 27.505.264 bayt, yani yaklaşık 27,51 MB eder. Hesaplama, bu büyüklüğün nasıl oluştuğunu gösterir. Bu bir model hesabıdır ve söz konusu e-postanın analizi değildir.
Tahmin nasıl oluşur?
Her ek ayrı ayrı kodlandığı için her dosyayı ayrı bir satıra gir. Boyutları B, KB, MB, GB, MiB veya GiB gibi birimlerle belirtebilirsin. Hesaplayıcı MB için ondalık sistemi kullanır: 1 MB, 1.000.000 bayttır. MiB için ikili sistemi kullanır: 1 MiB, 1.048.576 bayttır. Birim dönüşümünden sonra tam sayı kadar bayt elde edilmelidir; negatif dosya boyutları geçersizdir. Sayı girerken ondalıklar için virgül, binlik gruplama için nokta kullan. 1.000 bin anlamına gelir. Bin değerini 1.000 veya 1.000,00 şeklinde yazabilirsin; 1 000 gibi boşluklu girişler kabul edilmez. Sayı alanına birim yazma; birimi ayrı seç.
- Orijinal boyut: Eklerinin bayt cinsinden toplamı. Başlangıç değeridir ve ek sınırıyla karşılaştırmada kullanılır.
- Base64 verileri: n baytlık bir ekten 4 × yukarı yuvarla(n ÷ 3) karakter oluşur. Sondaki kalan kısım tam bir üçlü grup oluşturmaya yetmiyorsa son dörtlü grup dolgu ile tamamlanır.
- Satır sonları: Varsayılan olarak “Satır sonları” ayarı açıktır. Bu ayar açıkken hesaplayıcı, her ekin karakterlerini en fazla 76 karakterlik satırlara ayırır. Son satır dâhil her satır için CRLF satır sonuna 2 bayt ekler.
- Ek baytlar: Metin, üstbilgiler ve iletinin diğer bölümleri için kendi belirlediğin değer. Önceden ayarlanan değer 0 olur.
- Tahmin: Tüm eklerin Base64 verileri ve satır sonları ile ek baytların toplamı.
Base64 her zaman tam olarak üçte bir daha mı büyüktür?
Yalnızca yaklaşık olarak. 3 bayttan 4 karakter oluşması, büyük dosyalarda 33⅓ % artışa yaklaşır. Satır sonları olmadan 10.000.000 bayt, tam olarak 13.333.336 bayta dönüşür; yani yaklaşık 33,33 % artar. Tam üçte birlik artıştan bu küçük sapma dolgudan kaynaklanır. Satır sonlarıyla birlikte boyut 13.684.214 bayt olur; bu da yaklaşık 36,8 % artış demektir. Dolayısıyla yaklaşık 37 % gibi pratik kurallar, satır sonları içeren kodlanmış verileri ifade eder. Bunlar satır uzunluğuna ve satır sonuna bağlıdır; üstbilgileri ve metni hesaba katmaz.
Küçük dosyalarda sabit bir çarpan artık işe yaramaz. 1 baytlık bir ek, 4 Base64 karakteri ve 2 bayt satır sonuyla toplam 6 bayta dönüşür. Bu nedenle hesaplayıcı, her şeyi tek bir genel değerle çarpmak yerine her eki tam olarak hesaplar.
Birden fazla ek: Her dosya ayrı ayrı
Ekler tek bir büyük blokta birleştirilmez; her biri ayrı kodlanır. Bu nedenle her dosyanın kendi dolgusu ve kendine ait son satır sonu vardır. Bunu en açık biçimde, her biri 1 bayt olan iki dosyadan oluşan uç bir örnek gösterir.
Tek bir büyük PDF'de bu birkaç baytın etkisi pek hissedilmez. Ancak çok sayıda küçük dosyada birikerek artar.
76 karakterlik satır uzunluğu, MIME standardının Base64 satırları için öngördüğü en yüksek uzunluktur. Son satırdan sonra da bir CRLF sayılması bu hesaplayıcıya özgü bir tercihtir. Daha kısa satırlar kullanan veya bitişi farklı düzenleyen e-posta programları biraz farklı değerler verir. Yaygın bir başka yanlış anlama da şudur: Base64 hiçbir şeyi şifrelemez. Anahtar olmadan geri çözülebilen bir kodlamadan ibarettir ve ekinin içeriğini korumaz.
Doğru boyut sınırıyla karşılaştırma
Bir boyut sınırı sana bir sayı verir, ancak bu sayının neye uygulandığını her zaman belirtmez. Bazı kurallar orijinal eklerin toplamını, yani e-posta programının gösterdiği dosya boyutlarını sınırlar. Diğerleri ise kodlanmış ekler, metin ve üstbilgiler dâhil iletinin tamamını sınırlar. Bu nedenle hesaplayıcıda sınırın neyle karşılaştırılacağını seçersin. Önceden doldurulmuş 25 MB değeri yalnızca bir başlangıç değeridir ve belirli bir sağlayıcının kuralı değildir. Tam sınırda olan bir sonuç, sınıra uyulmuş sayılır.
Bu nedenle aynı dosya bir kurala uyarken diğerini aşabilir; bu bir çelişki değildir.
Farklı değerlere uygulanan iki gerçek kural
- Gmail: Eklerle ilgili Almanca Gmail Yardım sayfasına göre (erişim tarihi: 13 Ekim 2026), kişisel hesaplarda eklerin toplam boyutu en fazla 25 MB olabilir. Burada kastedilen eklerin toplamıdır; dolayısıyla orijinal eklerle karşılaştırma uygundur. Google Workspace hesaplarında sınırları yönetici belirler. Toplam daha büyükse ekin yerine bir Google Drive bağlantısı eklenir.
- Erlangen-Nürnberg Üniversitesi RRZE: E-posta eklerinin boyut sınırıyla ilgili yönerge (erişim tarihi: 13 Ekim 2026), RRZE sunucularında gelen ve giden e-postalar için iletinin tamamına en fazla 20 MB sınırı koyar. Burada tahmini iletiyle karşılaştırma yapmalısın; ek baytları da girmen uygun olur.
Her iki kural da yalnızca kendi kapsamı için geçerlidir ve değişebilir. Gönderimin için ister kişisel ister işveren, okul veya üniversite tarafından yönetilen bir hesap olsun, kendi hesabının kuralı geçerlidir. Alıcının posta kutusunun kuralı da aynı derecede önemlidir. Alıcının koşulunu biliyorsan tam olarak neye uygulandığını dikkate alarak karşılaştırmaya kat. Bir sağlayıcı büyük dosyaları otomatik olarak bağlantı şeklinde gönderiyorsa dosya artık iletide ek olarak bulunmaz. Alıcının bu bağlantıyı açıp açamayacağı ve açmaya yetkili olup olmadığı ise ayrı bir konudur.
Tam bir ileti için başka neler gerekir?
Kodlanmış bir ek tek başına bir e-posta oluşturmaz. Tam bir iletide gönderen, alıcılar, konu ve teknik bilgileri içeren üstbilgiler bulunur. Bunlara, çoğu zaman hem düz metin hem HTML olarak yer alan ileti metni, MIME bölümleri arasındaki ayırıcı satırlar ve imzadaki logo gibi gömülü görüntüler eklenir. Bunların ne kadar yer kapladığı e-posta programına, metnine ve alıcılarına bağlıdır.
Hangi ek bayt değerini girebilirsin?
Herkes için doğru olan tek bir değer yoktur. 0 ek baytla hesaplayıcı, yalnızca satır sonlarıyla birlikte kodlanmış ekleri gösterir; yani metin ve üstbilgileri içermeyen bir model değeri sunar. Bu nedenle kendi e-postana uygun bir varsayım gir. Görüntü içermeyen kısa bir metin az yer kaplarken gömülü grafikler içeren bir HTML e-posta belirgin biçimde daha fazla yer kaplar. Başka e-postalara ait örneklerdeki değerler yalnızca o e-postalar için geçerlidir. Sonucun sınırın hemen altındaysa denemek için daha yüksek bir değerle hesapla. Karşılaştırma hâlâ sınıra uyuyorsa payın var demektir. Sonuç sınırı aşmaya başlıyorsa çok az payın vardır.
Karşılaştırma başarılı olduğu hâlde e-posta geri dönerse
- İleti, ek baytlar için varsaydığından daha fazlasını içeriyordur veya e-posta programın farklı satır uzunluklarıyla kodluyordur.
- Alıcının sunucusunun boyut sınırı, senin hesabınınkinden daha düşüktür.
- Sınır iletinin tamamı için geçerlidir, ancak sen orijinal eklerle karşılaştırmışsındır. Ya da hesabın için varsaydığından farklı bir kural geçerlidir.
- Alıcı, makro içeren belgeler veya çalıştırılabilir programlar gibi belirli dosya türlerine izin vermiyor ve boyutlarından bağımsız olarak bunları engelliyordur.
Hesaplayıcı yalnızca seçtiğin sayıyı karşılaştırır. Hiçbir şey göndermez, teslimatı test etmez; dosya biçimlerini veya güvenlik kurallarını da kontrol etmez. E-posta bültenlerinde ayrıca görüntüleme sınırları vardır: Bazı posta kutuları uzun HTML e-postaları yalnızca kısaltılmış olarak gösterir. Bu, eklerin boyutundan farklı bir konudur ve burada hesaplanmaz.
Çok büyük: Hazır PDF ile devam et
Tahmin sınırın üzerindeyse iki seçeneğin vardır: Dosyanın kendi bayt miktarını azaltmak veya ek olarak göndermek yerine başka bir yol seçmek. Alıcı özellikle ek bekliyorsa şu adımları izle:
- PDF'yi göndermeden önce sıkıştır veya sabit bir sınır biliyorsan PDF'yi bir boyut sınırına göre küçült. Dosyanın ne kadar küçüleceği içeriğine bağlıdır. Hedef boyuta her durumda ulaşılamaz.
- Sonucu aç ve belgenin hâlâ rahatça okunabildiğini kontrol et.
- İndirdiğin dosyanın boyutunu buraya yeniden gir. Belirleyici olan umulan tasarruf değil, hazır dosyadır.
- Tahmin sınıra uyuyorsa e-postayı gönder. Uymuyorsa alıcıyla başka bir yol hakkında konuş.
Alıcı bağlantıları kabul ediyorsa ve erişim izinleri ile gizlilik koşulları belgene uygunsa bir bulut veya dosya hizmeti üzerinden paylaşım bağlantısı alternatif olabilir. Hizmeti kendin seçersin. Bu hesaplayıcı yalnızca girilen sayılarla çalışır; dosya kaydetmez veya göndermez. Buna karşılık ZIP arşivi, daha küçük bir PDF'nin güvenilir bir alternatifi değildir: PDF'yi her zaman küçültmez ve özellikle PDF dosyası isteyen bir alıcı arşivi kabul etmeyebilir.
Dosyayı e-postayla göndermek yerine bir portala yükleyeceksen PDF yükleme sınırlarını kontrol edebilir ve önceden dosyanın yükleme süresini tahmin edebilirsin.