Sebenarnya, tanda sama dengan (=) ini apa sih?

 (lars.ingebrigtsen.no)
3 poin oleh GN⁺ 2026-02-04 | 1 komentar | Bagikan ke WhatsApp
  • Baru-baru ini, kutipan email lama menyebar di Twitter dan memunculkan pertanyaan tentang mengapa ada tanda sama dengan (=) di akhir kalimat
  • Tanda ini muncul karena proses encoding quoted-printable, yang digunakan untuk menandai bahwa baris berlanjut saat baris panjang dipaksa dipecah
  • Saat pengiriman email, CRLF (carriage return + line feed) digunakan sebagai line break, tetapi ketika diubah menjadi NL milik Unix, algoritme decoding bisa gagal bekerja dengan benar sehingga tanda sama dengan tertinggal atau karakter hilang
  • Tanda sama dengan juga dipakai bukan hanya untuk line break, tetapi juga untuk merepresentasikan karakter non-ASCII (misalnya =C2=A0), dan decoder yang salah dapat memicu error dengan menggantinya secara naif
  • Akar masalahnya adalah logika decoding yang bug dan penanganan konversi yang tidak tepat, yang menunjukkan bahwa orang yang memproses email tersebut kurang matang secara teknis

Identitas tanda sama dengan (=) dalam kutipan email

  • Dalam beberapa hari terakhir, banyak kutipan email lama dibagikan di Twitter, dan terlihat fenomena mencolok berupa tanda sama dengan di akhir kalimat

    • Penulis membantah klaim yang salah kaprah bahwa ini adalah kode atau error OCR (optical character recognition)
    • Kenyataannya, ini adalah error pemrosesan encoding yang terjadi saat email diubah agar lebih mudah dibaca

  • Email dulu berupa teks sederhana, tetapi untuk menangani baris panjang atau karakter khusus, diperkenalkan encoding quoted-printable

    • Saat memecah baris panjang, tanda sama dengan (=) diletakkan di akhir baris untuk menandai bahwa “baris ini berlanjut”
    • Setelah tanda sama dengan, akan ada CRLF (carriage return + line feed)

Encoding line break dan error decoding

  • Server email memakai line break CRLF sebagai standar, sementara sistem Unix hanya memakai NL

    • Dalam proses konversi, jumlah byte berkurang satu; jika decoder menanganinya dengan salah, tanda sama dengan bisa tertinggal atau karakter bisa hilang
    • Sebagai contoh, jika “non- =CRLF cloven” diproses keliru, hasilnya bisa menjadi “non- loven” sehingga huruf c menghilang

  • Beberapa implementasi menangani tanda sama dengan di akhir baris dengan cara menghapus dua karakter

    • Algoritme ini bisa salah bekerja pada file berformat Unix sehingga tanda sama dengan tetap tertinggal

Kegunaan lain tanda sama dengan: encoding karakter non-ASCII

  • Tanda sama dengan juga digunakan untuk encoding karakter non-ASCII, bukan hanya untuk line break

    • Contoh: =C2=A0 berarti non-breaking space
    • Ini sering muncul saat mengekspresikan indentasi atau karakter khusus dalam body email

  • Penulis memperkirakan sebagian proses konversi hanya melakukan search-replace sederhana pada =C2, =A0, tanpa memakai decoder yang benar

Latar belakang teknis dan standar

  • Standar RFC 2045 mendefinisikan encoding quoted-printable sebagai format untuk transport

    • Setelah diterima, data seharusnya didecode dan disimpan sebagai teks bersih
    • Namun dalam implementasi nyata, proses ini sering dilewati sehingga error penanganan line break kerap terjadi

  • Dalam contoh kode, (quoted-printable-decode-string "he=\nllo") dipulihkan dengan benar menjadi "hello"

    • Ini terjadi karena algoritme yang mengasumsikan CRLF dalam konteks server SMTP dipakai ulang
    • Pada file berbasis Windows, ini bekerja normal, tetapi gagal pada sistem berbasis Unix

Kesimpulan

  • Tanda sama dengan dalam kutipan email adalah sisa dari encoding quoted-printable, dan merupakan hasil gabungan dari cacat penanganan line break dan decoding karakter non-ASCII
  • Penyebab mendasarnya adalah implementasi decoder yang tidak akurat dan kesalahan konversi encoding
  • Penulis merangkumnya sebagai “masalah teknis sekaligus hasil dari pemrosesan yang keliru”, sambil menekankan perlunya kepatuhan yang cermat pada standar dalam proses konversi email

Bacaan terkait

1 komentar

 
GN⁺ 2026-02-04
Komentar Hacker News

  • Tokoh utama dalam tulisan ini adalah Lars Ingebrigtsen, orang yang menulis manual untuk Gnus, paket pembaca email/Usenet di Emacs
    Manualnya cerdas dan informatif, dan ia punya pemahaman tentang parsing email yang jauh lebih dalam daripada kebanyakan orang
    Manualnya bisa dilihat di sini, dan versi lainnya ada di tautan ini

    • Ia bukan hanya penulis manual, tetapi juga pengembang Gnus itu sendiri
      Saya ingat masa ketika ia pertama kali membuat Gnus di Universitas Oslo (UiO)
      Di antara mahasiswa informatika kami, ia adalah semacam developer bintang, dan semua orang memakai Emacs dan Gnus

  • Insiden ini adalah contoh klasik dari seseorang yang tahu cukup banyak hingga berbahaya
    Ia tahu bahwa email bukan sekadar teks biasa, tetapi tidak tahu bahwa decoding quoted-printable tidak boleh ditangani dengan penggantian sederhana
    Ini sejenis dengan bug parsing HTML langsung dengan regex; awalnya tampak berjalan baik, lalu belakangan muncul situasi di mana dokumen bukti untuk kongres penuh dengan tanda '=' yang tersisa

    • Terkait ini, ada yang membagikan jawaban Stack Overflow yang terkenal. Jawaban itu menjelaskan secara humoris kenapa HTML tidak boleh diparsing dengan regex
    • Karena hasil keluarannya umumnya masih cukup bisa dibaca, tidak ada yang sadar ada masalah sampai bertahun-tahun kemudian ketika diajukan sebagai bukti ke kongres
    • Ditutup dengan lelucon, “orang-orang terbaik sedang menanganinya sekarang”

  • Ada pertanyaan, “kenapa server email membenci baris yang panjang”

    • SMTP adalah protokol berbasis baris, jadi isi pesan pun dikirim per baris
      Server harus bisa mem-parsing header, jadi tidak bisa diperlakukan sebagai binary blob sederhana
      IMAP mengharuskan server melakukan parsing penuh, sedangkan POP3 ditujukan untuk satu perangkat dan sudah kurang cocok untuk zaman sekarang
    • Dulu email diproses per baris dengan buffer panjang tetap
      RFC 821 membatasi panjang baris hingga maksimum 1000 byte, dan demi kompatibilitas biasanya dipotong di bawah 80 karakter
      Karena itu encoding Base64 juga menyisipkan line break setiap 76 karakter
    • Saat SMTP dirancang, memori sangat terbatas
      Misalnya PDP-11 sekitar 512KB, VAX-11 sekitar 2MB, dan para programmer menghitung memori per byte
    • Ada juga penjelasan struktur komunikasi SMTP secara langsung dengan HELO, MAIL FROM, RCPT TO, DATA, dan seterusnya
    • Disebut juga jaringan kampus tahun 1980-an, BITNET, sambil mengenang bahwa saat itu pun ada batas panjang baris
      Dokumen terkait bisa dilihat di dokumentasi resmi IBM dan Wikipedia

  • Awalnya ada yang mengira artikel ini akan membahas makna operator seperti = == === .=. <== ==> <<== ==>> (==) => =~=

    • Ada lelucon, “ini Haskell untuk semut ya?”
    • Tapi ternyata isi sebenarnya jauh lebih menarik

  • Saya pribadi pernah membuat sendiri software pengarsipan email
    Bagian tersulit adalah menangani edge case pada file .eml yang menumpuk lebih dari 20 tahun
    Konsepnya sederhana, tetapi email ternyata sangat kompleks

    • Standar email bukan dibuat ulang dari nol, melainkan semacam standar terkutuk yang dipaksakan dengan menyambung sistem-sistem lama
      Validasi alamat email pun pada praktiknya nyaris mustahil
    • Saya pernah membuat klien email berbasis konsol; 25% ditulis dalam C++, 75% dalam Lua untuk mendefinisikan UI dan pemrosesan
      Selama beberapa tahun ada segelintir pengguna, tetapi pemrosesan MIME adalah penderitaan terbesar

  • Yang menurut saya menarik bukan tanda '=' itu sendiri, melainkan fenomena karakter di sekitarnya ikut hilang
    Rasanya seperti bug off-by-one; bukannya hanya menghapus '=', sebagian teks asli justru ikut lenyap
    Mungkin konversi CRLF/LF ada kaitannya

    • Artikel aslinya menjelaskan alasannya dengan tepat
    • Dengan cara seperti ini, muncullah misteri karakter yang hilang dari dokumen bukti

  • Ada yang penasaran kenapa masalah ini muncul sekarang
    Beberapa hari terakhir orang-orang mengunggah email lama ke Twitter, dan timbul pertanyaan kenapa

    • Mungkin karena pengungkapan email terkait Epstein
    • Disebutkan bahwa DOJ memang merilis tambahan email Epstein

  • Seseorang mengemukakan kemungkinan bahwa penyebab masalah ini bukan Gmail, melainkan transformasi di server perantara
    Selain konversi CRLF→LF, jika quoted-printable diterapkan dua kali maka tanda '=' bisa tersisa, jadi mungkin ada dua server email yang terlibat

    • Di beberapa PDF terlihat metadata plist dari Apple Mail.app, sehingga ada kemungkinan datanya diekstrak dari format internal
    • Hal seperti ini sering terjadi dalam proses pengumpulan barang bukti hukum
      Dalam praktiknya, sering kali intern yang tidak berpengalaman mengumpulkan data dengan alat sederhana, lalu data dikonversi berkali-kali hingga formatnya rusak
      Data asli sudah dibuang, dan yang tersisa hanya fragmen data yang tinggal bentuk luarnya saja
    • Kadang masalah seperti ini muncul saat email diimpor ke file PST milik MS Outlook
    • Ini tampaknya bukan satu dump Gmail tunggal, melainkan hasil dari beberapa sistem yang “berusaha membantu” sambil mengubah data
    • Ada juga pendapat bahwa hipotesis ini yang paling meyakinkan

  • Artikel di archive.today juga menunjukkan gejala quoted-printable yang rusak yang sama
    Tautan terkait adalah pastes.io/correspond dan thread HN

  • Ada yang mengatakan akan bagus jika ada viewer .eml yang secara otomatis mengurai quoted-printable saat melihat email yang diunduh dari Outlook