Mengapa base64 diperlukan (alias mengapa saya tidak bisa hanya mengirim email file biner)?


30

Saya membaca tentang encoding Base64, dan menemukan ini di Wikipedia:

Skema pengkodean Base64 umumnya digunakan ketika ada kebutuhan untuk menyandikan data biner yang perlu disimpan dan ditransfer melalui media yang dirancang untuk menangani data tekstual.

... dan contoh yang diberikan adalah mengirim file biner melalui email.

Saya mencoba memahami mengapa base64 diperlukan. Karena data biner adalah sekelompok byte, bukankah itu dapat langsung diterjemahkan ke ASCII, yang merupakan data tekstual? Mengapa base64 diperlukan sama sekali? Atau apakah email memiliki masalah dengan karakter kontrol di ASCII?


Apa yang Anda maksud dengan "diterjemahkan langsung"? Dalam arti apa base64 tidak "langsung"?
David Schwartz

Menurut Anda mengapa itu langsung?
Cookie Monster

4
Bukannya saya pikir itu langsung, itu yang saya pikir "diterjemahkan secara langsung" adalah sebuah oxymoron. Jika "langsung" dapat memasukkan proses penerjemahan, lalu apa yang membuat base64 tidak langsung? Itu hanya proses penerjemahan.
David Schwartz

Jawaban:


37

Ada artikel Wikipedia yang bagus tentang ini.


Iterasi NCP yang paling awal seperti yang digunakan oleh ARPAnet lebih seperti bit stream daripada byte stream, atau upaya untuk menegosiasikan ukuran byte yang nyaman; byte 8-bit hanya distandarisasi jauh kemudian. Ada juga beberapa upaya membuat protokol transfer file yang akan berfungsi di mesin yang berbeda (mail pada awalnya merupakan fungsi dari protokol FTP, terutama sebagai MAILdanMLFL perintah, kemudian dipecah menjadi MTP , kemudian SMTP .). Mesin-mesin itu sering memiliki pengkodean karakter yang berbeda - ASCII vs EBCDIC - atau bahkan ukuran byte yang berbeda, byte 8-bit vs 6-bit ...

Oleh karena itu, fungsi transfer surat pada awalnya didefinisikan untuk mentransfer pesan yang relatif singkat dalam teks biasa; khusus, "NVT-ASCII". Misalnya, RFC 772 mengatakan:

PENYIMPANAN DAN PENYIMPANAN MAIL

Mail ditransfer dari perangkat penyimpanan di host pengirim ke perangkat penyimpanan di host penerima. Mungkin perlu untuk melakukan transformasi tertentu pada surat karena representasi penyimpanan data dalam dua sistem berbeda. Sebagai contoh, NVT-ASCII memiliki representasi penyimpanan data yang berbeda dalam sistem yang berbeda. PDP-10 umumnya menyimpan NVT-ASCII sebagai lima karakter ASCII 7-bit, dibenarkan kiri dalam kata 36-bit. 360's store NVT-ASCII sebagai empat kode EBCDIC 8-bit dalam kata 32-bit. Multics menyimpan NVT-ASCII sebagai empat karakter 9-bit dalam sebuah kata 36-bit.

Demi kesederhanaan, semua data harus direpresentasikan dalam MTP sebagai NVT-ASCII. Ini berarti bahwa karakter harus dikonversi ke representasi NVT-ASCII standar ketika mengirim teks, terlepas dari apakah host pengirim dan penerima berbeda. Pengirim mengonversi data dari representasi karakter internal ke representasi NVT-ASCII 8-bit standar (lihat spesifikasi TELNET). Penerima mengubah data dari bentuk standar ke bentuk internalnya sendiri. Sesuai dengan standar ini, urutan harus digunakan untuk menunjukkan akhir dari satu baris teks.

Meskipun delapan bit ditransmisikan melalui kabel, bit ke-8 sering dibuang atau hancur, karena tidak ada persyaratan untuk melestarikannya; pada kenyataannya, beberapa protokol mengharuskan bit ke-8 diatur ke nol, seperti RFC SMTP awal seperti dikutip di bawah ini. Dengan kata lain, perangkat lunak itu tidak 8-bit bersih .

Transfer data

Koneksi TCP mendukung transmisi byte 8-bit. Data SMTP adalah karakter ASCII 7-bit. Setiap karakter ditransmisikan sebagai byte 8-bit dengan bit orde tinggi dihapus ke nol.

Ini bertahan untuk waktu yang lama bahkan setelah pengkodean karakter ISO-8859-# 8-bit menjadi luas. Meskipun beberapa server sudah bersih 8-bit, banyak yang lain tidak, dan secara acak mengirim data 8 bit akan menghasilkan pesan yang rusak.

Kemudian, "Extended SMTP" diterbitkan, memungkinkan server mail untuk menyatakan ekstensi SMTP yang mereka dukung; salah satunya adalah 8BITMIME, menunjukkan bahwa server penerima dapat dengan aman menerima data 8-bit. Bagian pesan MIME dapat memiliki " Content-Transfer-Encoding : 8bit", yang menunjukkan bahwa mereka tidak dikodekan dengan cara apa pun.

Namun, protokol SMTP tetap berbasis garis dan memiliki batas garis oktet 998, serta menggunakan .garis (0D 0A 2E 0D 0A) sebagai indikator "akhir pesan". Ini berarti bahwa meskipun sebagian besar file biner dapat dikirim tanpa diubah, masih mungkin bahwa file yang berisi urutan oktet ini akan ditafsirkan sebagai akhir dari pesan yang ditransfer, dan sisa file sebagai perintah SMTP, mungkin menyebabkan kerusakan. Demikian pula, "garis" lebih dari 998 oktet mungkin terputus oleh server penerima.

Pada tahun 2000, ekstensi ESMTP "BINARYMIME" diterbitkan sebagai RFC 3030 , memungkinkan transfer data biner mentah melalui SMTP. Pesan sekarang ditransfer dalam potongan panjang yang telah ditentukan sebelumnya, dengan potongan nol panjang digunakan sebagai terminator, dan Base64 & pengkodean serupa tidak diperlukan lagi. Sayangnya, beberapa server SMTP mendukung ekstensi ini; misalnya, Postfix atau Exim4 tidak beriklan CHUNKINGsebagai balasan untuk EHLO. Untuk memanfaatkan BINARYMIME, itu harus didukung oleh semua server di jalur pesan, yang bisa lebih dari satu atau dua.

Lihat juga:


1
Exchange server dalam suatu organisasi mengirim email sebagai biner menggunakan perintah BDAT, tetapi mereka tidak melakukan ini untuk server SMTP di luar organisasi.
james.garriss

7

Beberapa sistem dan perangkat lunak surel yang lebih lama tidak bersih 8-bit , bit ke-8 digunakan sebagai karakter kontrol. Ini cukup untuk membersihkan file biner, oleh karena itu Base64 (atau skema penyandian lainnya) diperlukan.


Jadi apakah kita membuang 2 bit untuk setiap byte hanya karena beberapa sistem email warisan 90-an mungkin tidak dapat memahami pesan dengan benar. Sistem warisan ini di era gmail mungkin kurang dari 1%. Saya berpikir mengapa kita membuang begitu banyak bandwidth untuk segelintir orang? dan apakah Base64 terbatas hanya untuk surel?
vaibhav.g
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.