Saat mengirim konten email, diperlukan untuk menyetel header "Pengkodean Transfer Konten". Saya mengamati banyak header email yang saya terima. Beberapa email menggunakan "7bit" dan beberapa menggunakan "8bit".

Apa perbedaan antara keduanya? Mana yang direkomendasikan? Apakah ada pengkodean khusus yang diperlukan untuk badan email untuk menyetel header ini?

Ini bisa agak padat untuk dibaca, tetapi bagian "Pengkodean-Transfer-Konten" dari RFC 1341 memiliki semua detail:

http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html

Situasinya berubah dari buruk menjadi lebih buruk. Inilah ringkasan saya:

Latar Belakang

SMTP, menurut definisi (RFC 821), membatasi mail ke baris 1000 karakter masing-masing 7 bit. Itu berarti bahwa tidak ada byte yang Anda kirimkan ke pipa dapat memiliki bit paling signifikan ("urutan tertinggi") yang disetel ke "1".

Konten yang ingin kami kirim seringkali tidak mematuhi batasan ini secara inheren. Pikirkan file gambar, atau file teks yang berisi karakter Unicode: byte dari file-file ini sering kali memiliki bit ke-8 yang disetel ke "1". SMTP tidak mengizinkan ini, jadi Anda perlu menggunakan "transfer encoding" untuk menjelaskan bagaimana Anda mengatasi ketidakcocokan tersebut.

Nilai untuk Content-Transfer-Encodingtajuk menjelaskan aturan yang Anda pilih untuk menyelesaikan masalah ini.

7Bit Encoding

7bitberarti "Data saya hanya terdiri dari karakter US-ASCII, yang hanya menggunakan 7 bit lebih rendah untuk setiap karakter." Anda pada dasarnya menjamin bahwa semua byte dalam konten Anda sudah mematuhi batasan SMTP, sehingga tidak memerlukan perlakuan khusus. Anda bisa membacanya apa adanya.

Perhatikan bahwa ketika Anda memilih 7bit, Anda setuju bahwa semua baris dalam konten Anda kurang dari 1000 karakter.

Selama konten Anda mematuhi aturan ini, itu 7bitadalah pengkodean transfer terbaik, karena tidak ada pekerjaan tambahan yang diperlukan; Anda hanya membaca / menulis byte saat mereka keluar dari pipa. Ini juga mudah untuk melihat 7bitkonten dan memahaminya. Idenya di sini adalah bahwa jika Anda hanya menulis dalam "teks bahasa Inggris biasa" Anda akan baik-baik saja. Tapi itu tidak benar di tahun 2005 dan tidak benar hari ini.

8Bit Encoding

8bitberarti "Data saya mungkin menyertakan karakter ASCII yang diperpanjang; mereka dapat menggunakan bit ke-8 (tertinggi) untuk menunjukkan karakter khusus di luar karakter standar 7-bit US-ASCII." Adapun 7bit, masih ada batas baris 1000 karakter.

8bit, sama seperti 7bit, tidak benar-benar melakukan transformasi byte saat ditulis atau dibaca dari kabel. Ini hanya berarti bahwa Anda tidak menjamin bahwa tidak ada byte yang memiliki bit tertinggi yang disetel ke "1".

Ini sepertinya merupakan langkah maju 7bit, karena memberi Anda lebih banyak kebebasan dalam konten Anda. Namun, RFC 1341 berisi berita gembira ini:

Sejak publikasi dokumen ini, tidak ada pengangkutan Internet standar yang sah untuk menyertakan data 8-bit atau biner yang tidak dikodekan di badan surat. Jadi, tidak ada situasi di mana Pengkodean-Transfer-Konten "8bit" atau "biner" sebenarnya legal di Internet.

RFC 1341 keluar lebih dari 20 tahun yang lalu. Sejak itu kami mendapatkan Ekstensi MIME 8bit di RFC 6152 . Namun demikian, batas garis masih mungkin berlaku:

Perhatikan bahwa ekstensi ini TIDAK menghilangkan kemungkinan server SMTP membatasi panjang baris; server bebas untuk mengimplementasikan ekstensi ini tetapi bagaimanapun juga menetapkan batas panjang baris tidak lebih rendah dari 1000 oktet.

Pengkodean Biner

binarysama dengan 8bit, hanya saja tidak ada batasan panjang garis. Anda tetap dapat memasukkan karakter apa pun yang Anda inginkan, dan tidak ada pengkodean tambahan. Mirip dengan 8bit, RFC 1341 menyatakan bahwa ini bukan pengkodean transfer pengkodean yang sah. RFC 3030 memperpanjang ini dengan BINARYMIME.

Dikutip Printable

Sebelum 8BITMIMEekstensi, harus ada cara untuk mengirim konten yang tidak bisa 7bitmelalui SMTP. File HTML (yang mungkin memiliki lebih dari 1000 baris karakter) dan file dengan karakter internasional adalah contoh yang bagus untuk ini. The quoted-printableencoding (Ditetapkan di Bagian 5.1 dari RFC 1341) dirancang untuk menangani hal ini. Itu melakukan dua hal:

• Menentukan cara keluar dari karakter non-US-ASCII sehingga dapat direpresentasikan hanya dalam karakter 7-bit. (Versi singkat: mereka ditampilkan sebagai tanda sama dengan ditambah dua karakter 7-bit.)
• Mendefinisikan bahwa baris tidak akan lebih dari 76 karakter, dan baris baru akan diwakili menggunakan karakter khusus (yang kemudian di-escape).

Dikutip Printable, karena garis pendek dan pelariannya, jauh lebih sulit dibaca oleh manusia daripada 7bitatau 8bit, tetapi mendukung lebih banyak kemungkinan konten.

Pengkodean Base64

Jika sebagian besar data Anda bukan teks (mis .: file gambar), Anda tidak memiliki banyak opsi. 7bitdari meja. 8bitdan binarytidak didukung sebelum RFC ekstensi MIME. quoted-printableakan berfungsi, tetapi sangat tidak efisien (setiap byte akan diwakili oleh 3 karakter).

base64adalah solusi yang bagus untuk jenis data ini. Ini mengkodekan 3 byte mentah sebagai 4 karakter US-ASCII, yang relatif efisien. RFC 1341 selanjutnya membatasi panjang baris base64data yang dienkode menjadi 76 karakter agar sesuai dengan pesan SMTP, tetapi itu relatif mudah dikelola saat Anda hanya memisahkan atau menggabungkan karakter arbitrer pada panjang tetap.

Kelemahan besar adalah bahwa base64data yang disandikan hampir seluruhnya tidak dapat dibaca oleh manusia, bahkan jika itu hanya teks "biasa" di bawahnya.