Berapa batas panjang subjek email?

227

Berapa banyak karakter yang boleh berada di baris subjek email Internet? Saya telah memindai The RFC untuk email tetapi tidak dapat melihat secara spesifik berapa lama diizinkan. Saya memiliki seorang kolega yang ingin memvalidasi program untuk itu.

Jika tidak ada batasan formal, berapa panjang yang baik dalam praktik untuk disarankan?

email limit

— Scott Ferguson
sumber

17

255 adalah batas pada beberapa produk tiket (Jira misalnya) dan tampaknya menjadi batas pada pandangan, thunderbird dan gmail tampaknya terpotong setelah 130.

— recbot

1

RFC2047 lebih cocok untuk validasi, saya melihat banyak perangkat lunak surat massal yang memproduksi konten RFC2047 tidak valid.

— Jasen

3

Dalam basis data, sangat umum (sebuah tradisi yang dapat Anda katakan) untuk menentukan panjang bidang teks yang tidak terlalu panjang atau pendek sebagai VARCHAR (255) atau nama-nama serupa yang serupa. Jika string yang lebih panjang disajikan, itu akan menghasilkan kesalahan atau hanya akan terpotong ke batas. Itu sebabnya Jira dan Outlook seperti yang disebutkan di sini tidak mendukung lebih banyak karakter. Untuk alasan kompatibilitas saya tidak akan merekomendasikan 255+ Hanya menambahkan krim pada kue berusia 5 tahun;)

— Alph.Dev

195

Lihat RFC 2822 , bagian 2.1.1 untuk memulai.

Ada dua batasan yang standar ini tempatkan pada jumlah karakter dalam satu baris. Setiap baris karakter HARUS tidak lebih dari 998 karakter, dan HARUS tidak lebih dari 78 karakter, tidak termasuk CRLF.

Seperti yang dinyatakan RFC nanti, Anda dapat mengatasi batas ini (bukan Anda seharusnya) dengan melipat subjek ke beberapa baris.

Setiap bidang tajuk secara logis adalah satu baris karakter yang terdiri dari nama bidang, titik dua, dan badan bidang. Namun untuk kenyamanan, dan untuk menangani batasan karakter 998/78 per baris, bagian badan bidang dari bidang tajuk dapat dibagi menjadi beberapa representasi garis; ini disebut "lipat". Aturan umum adalah bahwa di mana pun standar ini memungkinkan untuk melipat ruang putih (bukan hanya karakter WSP), CRLF dapat dimasukkan sebelum WSP. Misalnya, bidang tajuk:
       Subject: This is a test
dapat direpresentasikan sebagai:
       Subject: This
        is a test

Rekomendasi untuk tidak lebih dari 78 karakter di header subjek terdengar masuk akal. Tidak ada yang ingin menggulir untuk melihat seluruh baris subjek, dan sesuatu yang penting mungkin terpotong di sebelah kanan.

— Michael Petrotta
sumber

8

Versi IMF saat ini, RFC 5322, dapat ditemukan di sini: tools.ietf.org/html/rfc5322#section-2.1.1

— james.garriss

6

Jawaban ini hanya membahas batas panjang garis, bukan batas panjang keseluruhan.

— Chalky

1

Ada RFC dan ada kegunaan. Artikel Jakob Nielsen Email Baris Subjek: 5 Tips untuk Menarik Pembaca meringkas sebagai: "Fokus pada 40 karakter pertama. Baris subjek deskriptif dan ditulis dengan baik memungkinkan penerima untuk membuat keputusan untuk mendapatkan informasi lebih lanjut atau melanjutkan."

— Édouard Lopez

3

Untuk memperjelas, tidak ada batasan panjang untuk baris subjek, karena standar memungkinkan header lebih dari 998 byte dengan membungkus header tunggal di atas baris sebanyak yang Anda suka. Rekomendasi ~ 80 karakter memang masuk akal. Jika Anda menulis klien email, Anda harus dapat mengatasi subjek yang sangat panjang tanpa merusak dengan cara yang mengerikan, lebih disukai dengan pemotongan ketika ditampilkan sebagai bagian dari daftar.

— thomasrutter

1

... Ini akan menjadi kasus dengan bidang tajuk lainnya juga (misalnya "Dari"). PS jika Anda bertanya-tanya mengapa 78 bukannya 80, atau mengapa 998 bukan 1000, itu karena standar email menentukan CRLF (\ r \ n) sebagai pemisah, yang merupakan dua byte, menjadikannya 1000 byte per baris yang 998 adalah header itu sendiri. Perhatikan juga bahwa nama tajuk dan spasi apa pun setelah titik dua, misalnya "Subjek:" juga harus sesuai dengan ini.

— thomasrutter

20

RFC2322 menyatakan bahwa judul subjek "tidak memiliki batasan panjang"

tetapi untuk menghasilkan tajuk yang panjang tetapi Anda harus membaginya menjadi beberapa baris, suatu proses yang disebut "lipat".

subjek didefinisikan sebagai "tidak terstruktur" dalam RFC 5322

inilah beberapa kutipan ([...] menunjukkan barang yang saya hilangkan)

3.6.5. Informational Fields
  The informational fields are all optional.  The "Subject:" and
  "Comments:" fields are unstructured fields as defined in section
  2.2.1, [...]

2.2.1. Unstructured Header Field Bodies
  Some field bodies in this specification are defined simply as
  "unstructured" (which is specified in section 3.2.5 as any printable
  US-ASCII characters plus white space characters) with no further
  restrictions.  These are referred to as unstructured field bodies.
  Semantically, unstructured field bodies are simply to be treated as a
  single line of characters with no further processing (except for
  "folding" and "unfolding" as described in section 2.2.3).

2.2.3  [...]  An unfolded header field has no length restriction and
  therefore may be indeterminately long.

— Jasen
sumber

@ Yasen, apakah Anda tahu alat untuk melipat?

— mahdi

perpustakaan email yang ditulis dengan baik akan melakukan ini. favorit saya adalahc-client

— Jasen

Ini jawaban yang benar. Bagian ke-2 dari pertanyaan "panjang yang baik dalam praktik" benar-benar tergantung pada aplikasi Anda. Jika Anda menyimpan email yang diterima maka Anda harus mendukung panjang yang tidak terbatas.

— Rob

4

setelah beberapa tes: Jika Anda mengirim email ke klien prospek, dan subjeknya> 77 karakter, dan itu perlu digunakan "=?ISO" di dalam subjek (dalam kasus saya karena aksen) maka OutLook akan "memotong" subjek di tengah-tengah dan sambungkan semua yang muncul setelahnya, termasuk teks isi, lampiran, dll ... semuanya adalah tautan!

Saya punya beberapa contoh seperti ini:

Subject: =?ISO-8859-1?Q?Actas de la obra N=BA.20100154 (Expediente N=BA.20100182) "NUEVA RED FERROVIARIA.=

TRAMO=20BEASAIN=20OESTE(Pedido=20PC10/00123-125),=20BEASAIN".?=

Untuk:

Seperti yang Anda lihat, pada baris subjek dipotong pada char 78 dengan "=" diikuti oleh 2 atau 3 umpan baris, kemudian dilanjutkan dengan sisa subjek dengan buruk.

Itu dilaporkan kepada saya dari beberapa pelanggan yang semuanya menggunakan OutLook, klien email lain berurusan dengan subjek tersebut ok.

Jika Anda tidak memiliki ISO di dalamnya, tidak ada salahnya, tetapi jika Anda menambahkannya ke subjek Anda untuk bersikap baik pada RFC, maka Anda mendapatkan kejutan ini dari OutLook. Sedikit jika Anda tidak menambahkan ISO, maka email iPhone tidak akan memahaminya (dan melampirkan file dengan nama menggunakan karakter tersebut tidak akan berfungsi pada iPhone).

— Sergio
sumber

5

Ada banyak masalah dengan subjek yang Anda atur: 1. Spasi harus dikodekan dengan '_', 2. Sebuah 'kata yang dikodekan' (=? Charset? Q / B? Data? =) Mungkin tidak boleh lebih dari 75 karakter (rfc2047). 3 Anda tidak dapat keluar dari baris baru dengan karakter '=' di akhir baris (pengkodean QP header berbeda dengan body QP). Intinya adalah: itu bukan kesalahan Outlook.

— Pawel Lesnikowski

2

Saya tidak percaya bahwa ada batas formal di sini, dan saya cukup yakin tidak ada batasan keras yang ditentukan dalam RFC, seperti yang Anda temukan.

Saya pikir beberapa batasan umum untuk baris subjek secara umum (bukan hanya e-mail) adalah:

80 Karakter
128 Karakter
256 Karakter

Jelas, Anda ingin membuat sesuatu yang masuk akal. Jika Anda menulis klien email, Anda mungkin ingin menggunakan 256 karakter, dan tentu saja menguji secara menyeluruh terhadap server komersial besar di luar sana untuk memastikan mereka melayani email Anda dengan benar.

Semoga ini membantu!

— Ed Altorfer
sumber

13

Tidak ada alasan khusus mengapa 256 lebih baik dari 250, atau 300, atau 372. Kami sudah lama menggunakan byte untuk panjang string.

— Greg Hewgill

4

255 adalah batas sebenarnya pada beberapa produk (Jira dan pandangan misalnya)

— pengawas ulang

5

Jawaban ini salah. RFC 5322, versi terkini dari spesifikasi IMF, jelas mendefinisikan panjang garis maks. Lihat jawaban @Michael.

— james.garriss

2

+1 Batasan panjang garis adalah untuk semua baris pesan, tapi saya tidak melihat apa pun yang mengatakan Anda tidak dapat memiliki subjek rentang beberapa baris (menyiratkan tidak ada batasan pada jumlah karakter untuk subjek). Lihat 2.2.3 dan contoh yang mengikuti langsung sesudahnya.

— Cypher

1

VARCHAR 255 mungkin merupakan panjang kolom data yang paling umum (dan lebih efisien) di MySQL / MariaDB. Bytes pasti masih relevan. MySQL akan menggunakan 1 byte untuk menyimpan panjangnya jika kurang dari 256, atau lebih. Lihatlah bagaimana C ++ mengimplementasikan std :: string jika Anda berpikir panjang string tidak terlalu penting dan dihitung dalam byte.

— ebyrob

0

Yang penting adalah mekanisme mana yang Anda gunakan mengirim email. Sebagian besar perpustakaan modern (yaitu System.Net.Mail) akan menyembunyikan lipatan dari Anda. Anda cukup memasukkan baris subjek email yang sangat panjang tanpa (CR, LF, HTAB). Jika Anda mulai mencoba melipat sendiri semua taruhan dibatalkan. Ini akan mulai melaporkan kesalahan. Jadi, jika Anda mengalami masalah ini, cukup filter CR, LF, HTAB dan biarkan perpustakaan bekerja untuk Anda. Anda biasanya dapat juga mengatur jenis teks penyandian sebagai bidang terpisah. Tidak perlu untuk pengkodean iso di baris subjek.

— kariato
sumber