E-posta içeriği gönderirken, "İçerik Aktarım Kodlaması" başlığının ayarlanması gerekir. Aldığım birçok e-posta başlığını gözlemledim. Bazı e-postalar "7bit" kullanırken bazıları "8bit" kullanıyor.
Bu ikisi arasındaki fark nedir? Hangisi önerilir? Bu başlıkları ayarlamak için e-posta gövdesine özel bir kodlama gerekiyor mu?
Yanıtlar:
Okuması biraz yoğun olabilir, ancak RFC 1341'in "İçerik Aktarımı-Kodlama" bölümü tüm ayrıntıları içerir:
http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html
Durum daha da kötüye gidiyor. İşte özetim:
SMTP, tanımı gereği (RFC 821), postayı her biri 7 bitlik 1000 karakterlik satırlarla sınırlar. Bu, borudan aşağı gönderdiğiniz baytların hiçbirinin en önemli ("en yüksek dereceli") biti "1" olarak ayarlayamayacağı anlamına gelir.
Göndermek istediğimiz içerik, doğası gereği çoğu zaman bu kısıtlamaya uymayacaktır. Bir görüntü dosyası veya Unicode karakterleri içeren bir metin dosyası düşünün: Bu dosyaların baytlarının 8. biti genellikle "1" olarak ayarlanır. SMTP buna izin vermez, bu nedenle uyumsuzluğun üstesinden nasıl geldiğinizi açıklamak için "aktarım kodlaması" kullanmanız gerekir.
Content-Transfer-EncodingBaşlığın değerleri, bu sorunu çözmek için seçtiğiniz kuralı açıklar.
7bitbasitçe "Verilerim, her karakter için yalnızca daha düşük 7 biti kullanan US-ASCII karakterlerinden oluşuyor" anlamına gelir. Temel olarak, içeriğinizdeki tüm baytların zaten SMTP kısıtlamalarına uyduğunu ve bu nedenle özel bir muameleye ihtiyacı olmadığını garanti ediyorsunuz. Onu olduğu gibi okuyabilirsiniz.
Seçtiğinizde 7bit, içeriğinizdeki tüm satırların uzunluğunun 1000 karakterden az olduğunu kabul ettiğinizi unutmayın.
İçeriğiniz bu kurallara bağlı 7bitkaldığı sürece en iyi aktarım kodlamasıdır, çünkü fazladan çalışma gerekmez; baytları borudan çıktıkça okursunuz / yazarsınız. Ayrıca 7bitiçeriği göz önünde bulundurmak ve anlamlandırmak da kolaydır . Buradaki fikir, sadece "düz İngilizce metin" yazıyorsan iyi olacaksın. Ancak bu 2005'te doğru değildi ve bugün de doğru değil.
8bit"Verilerim genişletilmiş ASCII karakterleri içerebilir; standart US-ASCII 7 bitlik karakterlerin dışındaki özel karakterleri belirtmek için 8. (en yüksek) biti kullanabilir." Olduğu gibi 7bit, hala 1000 karakterlik bir satır sınırı var.
8bit, tıpkı 7bit, baytların telden yazıldıkları veya okundukları şekliyle aslında herhangi bir dönüşümü yapmaz. Bu, baytların hiçbirinin en yüksek bitin "1" olarak ayarlanmayacağını garanti etmediğiniz anlamına gelir.
7bitİçeriğinizde size daha fazla özgürlük verdiği için bu bir adım öteye geçiyor gibi görünüyor . Ancak, RFC 1341 şu bilgileri içerir:
Bu belgenin yayınlanması itibariyle, posta gövdelerine kodlanmamış 8 bitlik veya ikili verileri dahil etmenin meşru olduğu standartlaştırılmış İnternet aktarımları yoktur. Dolayısıyla, "8bit" veya "ikili" İçerik Aktarımı-Kodlamasının İnternette yasal olduğu hiçbir koşul yoktur.
RFC 1341 20 yıldan uzun bir süre önce çıktı. O zamandan beri kazanılmış ettik MIME Extensions 8bit içinde RFC 6152 . Ancak o zaman bile, satır sınırları hala geçerli olabilir:
Bu uzantının bir SMTP sunucusunun hat uzunluğunu sınırlama olasılığını ortadan kaldırmadığını unutmayın; sunucular bu uzantıyı uygulamakta özgürdür, ancak yine de satır uzunluğu sınırı 1000 sekizliden daha düşük değildir.
binary8bitsatır uzunluğu kısıtlaması olmaması dışında aynıdır . Yine de istediğiniz herhangi bir karakteri ekleyebilirsiniz ve fazladan kodlama yoktur. 8bitRFC 1341'e benzer şekilde , bunun gerçekten yasal bir kodlama aktarım kodlaması olmadığını belirtir. RFC 3030 bunu BINARYMIME.
Uzantıdan önce, SMTP üzerinden 8BITMIMEyapılamayan içeriği göndermenin bir yolu olmalıydı 7bit. HTML dosyaları (1000 karakterden fazla satırı olabilir) ve uluslararası karakterler içeren dosyalar bunun güzel örnekleridir. quoted-printable(RFC 1341, Bölüm 5.1 tanımlanmıştır) şifreleyen bu işlemek üzere tasarlanmıştır. İki şey yapar:
Quoted Printable, kaçan ve kısa satırlardan dolayı, bir insan tarafından okumaktan 7bitveya çok daha zordur 8bit, ancak çok daha geniş bir olası içerik yelpazesini destekler.
Verileriniz büyük ölçüde metin değilse (örn: bir görüntü dosyası), çok fazla seçeneğiniz yoktur. 7bitmasanın dışında. 8bitve binaryMIME uzantısı RFC'lerinden önce desteklenmiyordu. quoted-printableişe yarar, ancak gerçekten verimsizdir (her bayt 3 karakterle temsil edilecektir).
base64bu tür veriler için iyi bir çözümdür. Nispeten verimli olan 4 US-ASCII karakteri olarak 3 ham baytı kodlar. RFC 1341 ayrıca, base64kodlanmış verilerin satır uzunluğunu bir SMTP mesajına sığması için 76 karakterle sınırlar, ancak yalnızca sabit uzunluklarda rastgele karakterleri böldüğünüzde veya birleştirdiğinizde, bu yönetimi nispeten kolaydır.
En büyük dezavantajı, base64kodlanmış verilerin, altında yalnızca "düz" metin olsa bile, insanlar tarafından neredeyse tamamen okunamaz olmasıdır.