• begin 666 hede.txt $eklinde ba$layan header'indaki "666" her byte'in kac bitinin alindigini belirten bir ibare degildir. kendisi bilakis unix file permission bitleridir.. hatta cogu zaman 644'tur kendisi.. (bkz: chmod)

    ayrica cok eski bir encoding teknigidir bu.. bu sebepten eski mail aktarim sistemlerinde problem olan satir uzunlugu, auto-wrapping gibi konulari da a$mak icin satir sonunu anlamayi saglayan ek bilgilere de bu yuzden sahiptir.. alfabesinde kucuk harf olmama sebebi de kimi milattan oncesinden kalma sistemlerde kucuk harfin varolmamasindan ve aktarimlarda translation a$amasinda kaybolmalarindan kaynaklanir..

    ayrica (bkz: xxencode) (bkz: base64)
  • herhangi bir web based mail accountunda eklentilerin olduğundan daha fazla yer kaplamasının nedenidir bu format... 1 mb eklentili bir mail gonderirsiniz bakarsınız ki accountunuzun 2 mb'ı azalmış... eğer bunun farkında değilseniz web mail servis sağlayıcınızı suçlarsınız ama bu heryerde böyledir. her mail aslında sadece text'ten oluşur. bizim mail serverlarımız da bizim için bunları binary'e çevirip bize öyle gösterir... bizi uğraştırmazlar... öyle de güzel makinalardır bu serverlar.
  • bazı bash scriptlere binary dosya(lar) çakmanız gerektiğinde bununla encode edip içeride tutmak akıllıca olabilir, ama olmayabilir de. dosya gereğinden fazla büyüyebilir. hatta büyümesi kaçınılmazdır çünkü algoritma 3 byte'ı alır, 4 karakter ile (dolayısıyla 4 byte ile) ifade eder. bu da en az %33 büyüme anlamına gelir.

    bir diğer problem de scriptin çalışacağı makinede uudecode olması gerekliliğidir. ilginç bir biçimde bazı sistemlerde uuencode/decode olmayıp xxd olabiliyor.
hesabın var mı? giriş yap