ความยาวหัวเรื่องของอีเมลคืออะไร

227

จำนวนอักขระที่ได้รับอนุญาตให้อยู่ในหัวเรื่องของอีเมลอินเทอร์เน็ต ฉันได้สแกนRFC เพื่อหาอีเมลแต่ไม่สามารถเห็นได้อย่างชัดเจนว่าอนุญาตให้นานแค่ไหน ฉันมีเพื่อนร่วมงานที่ต้องการตรวจสอบโดยทางโปรแกรม

หากไม่มีข้อ จำกัด อย่างเป็นทางการความยาวในการฝึกฝนที่จะแนะนำคืออะไร

email limit

— สกอตต์เฟอร์กูสัน
แหล่งที่มา

17

255 เป็นข้อ จำกัด สำหรับผลิตภัณฑ์จำหน่ายบัตรโดยสารบางอย่าง (ตัวอย่างเช่น Jira) และดูเหมือนว่าจะเป็นข้อ จำกัด ของ outlook ดูเหมือนว่า Thunderbird และ gmail จะถูกตัดทอนหลังจากที่มีจำนวน 130 รายการ

— reconbot

1

RFC2047 เหมาะสมกว่าการตรวจสอบความถูกต้องฉันเห็นซอฟต์แวร์การส่งจดหมายจำนวนมากที่ผลิตเนื้อหา RFC2047 ที่ไม่ถูกต้อง

— Jasen

3

ในฐานข้อมูลเป็นเรื่องปกติมาก (ประเพณีที่คุณสามารถพูดได้) เพื่อกำหนดความยาวของฟิลด์ข้อความที่ไม่ยาวหรือสั้นโดยเฉพาะอย่างยิ่งเป็น VARCHAR (255) หรือชื่อเทียบเท่าที่คล้ายคลึงกัน หากมีการนำเสนอสตริงที่ยาวขึ้นสตริงนั้นจะสร้างข้อผิดพลาดหรือจะถูกตัดเหลือเพียงขีด จำกัด นั่นคือเหตุผลที่จิราและ Outlook ตามที่กล่าวถึงในที่นี้ไม่รองรับตัวอักษรมากขึ้น สำหรับเหตุผลด้านความเข้ากันได้ฉันไม่แนะนำให้ 255+ เพียงเพิ่มครีมบนเค้กอายุ 5 ปี;)

— Alph.Dev

195

ดูRFC 2822ส่วน 2.1.1 เพื่อเริ่มต้น

มีข้อ จำกัด สองประการที่มาตรฐานนี้วางไว้กับจำนวนอักขระในบรรทัด แต่ละบรรทัดของอักขระต้องมีความยาวไม่เกิน 998 ตัวอักษรและควรมีความยาวไม่เกิน 78 ตัวอักษรยกเว้น CRLF

เนื่องจาก RFC ระบุในภายหลังคุณสามารถหลีกเลี่ยงข้อ จำกัด นี้ (ไม่ใช่ว่าคุณควร) โดยการพับตัวแบบผ่านหลายบรรทัด

แต่ละฟิลด์ส่วนหัวเป็นอักขระบรรทัดเดียวที่มีเหตุผลซึ่งประกอบด้วยชื่อฟิลด์โคลอนและเนื้อความฟิลด์ อย่างไรก็ตามเพื่อความสะดวกและเพื่อจัดการกับข้อ จำกัด ของอักขระ 998/78 ต่อบรรทัดส่วนเนื้อหาของฟิลด์ของฟิลด์ส่วนหัวสามารถแบ่งออกเป็นการแสดงหลายบรรทัด สิ่งนี้เรียกว่า "การพับ" กฎทั่วไปคือทุกที่ที่มาตรฐานนี้อนุญาตให้มีพื้นที่สีขาวแบบพับได้ (ไม่ใช่แค่ตัวอักษร WSP), CRLF อาจถูกแทรกก่อน WSP ใด ๆ ตัวอย่างเช่นฟิลด์ส่วนหัว:
       Subject: This is a test
สามารถแสดงเป็น:
       Subject: This
        is a test

คำแนะนำสำหรับหัวข้อที่มีความยาวไม่เกิน 78 ตัวอักษรนั้นสมเหตุสมผล ไม่มีใครอยากเลื่อนเพื่อดูหัวเรื่องทั้งหมดและสิ่งที่สำคัญอาจถูกตัดออกทางด้านขวา

— Michael Petrotta
แหล่งที่มา

8

รุ่นปัจจุบันของข้อมูลจำเพาะ IMF, RFC 5322 สามารถดูได้ที่นี่: tools.ietf.org/html/rfc5322#section-2.1.1

— james.garriss

6

คำตอบนี้กล่าวถึงขีดจำกัดความยาวของบรรทัดเท่านั้นไม่ใช่ขีดจำกัดความยาวโดยรวม

— Chalky

1

มี RFC และมีการใช้งาน Jakob Nielsen บทความหัวเรื่องอีเมล: 5 เคล็ดลับในการดึงดูดผู้อ่านสรุปว่า: "มุ่งเน้นไปที่ตัวอักษร 40 ตัวแรกหัวเรื่องที่อธิบายและเขียนได้ดีช่วยให้ผู้รับสามารถตัดสินใจได้อย่างละเอียดเพื่อรับรายละเอียดเพิ่มเติมหรือดำเนินการต่อ"

— Édouard Lopez

3

ในการชี้แจงไม่มีการจำกัดความยาวของหัวเรื่องเนื่องจากมาตรฐานอนุญาตให้ส่วนหัวยาวกว่า 998 ไบต์โดยการตัดส่วนหัวเดียวข้ามหลายบรรทัดตามที่คุณต้องการ คำแนะนำของ ~ 80 ตัวอักษรแน่นอนเหมาะสม หากคุณกำลังเขียนไคลเอนต์อีเมลที่คุณมีเพื่อให้สามารถรับมือกับวิชายาวขันโดยไม่ทำลายในทางที่น่ากลัวโดยเฉพาะการตัดเมื่อแสดงเป็นส่วนหนึ่งของรายการ

— thomasrutter

1

... นี่จะเป็นกรณีที่มีฟิลด์ส่วนหัวอื่น ๆ ด้วย (เช่น "จาก") ป.ล. ถ้าคุณสงสัยว่าทำไม 78 แทน 80 หรือทำไม 998 แทน 1,000 อาจเป็นเพราะมาตรฐานอีเมลระบุ CRLF (\ r \ n) เป็นตัวคั่นซึ่งเป็นสองไบต์ทำให้ 1,000 ไบต์ต่อบรรทัดซึ่ง 998 เท่ากับ ส่วนหัวของมันเอง โปรดทราบด้วยเช่นกันว่าชื่อส่วนหัวและช่องว่างใด ๆ หลังเครื่องหมายจุดคู่เช่น "หัวเรื่อง:" จะต้องพอดีกับส่วนนี้เช่นกัน

— thomasrutter

20

RFC2322 ระบุว่าหัวข้อหัวเรื่อง "ไม่มีการจำกัดความยาว"

แต่ในการผลิตส่วนหัวที่มีความยาว แต่คุณต้องแยกมันออกเป็นหลาย ๆ บรรทัดกระบวนการที่เรียกว่า

เรื่องถูกกำหนดเป็น "ไม่มีโครงสร้าง" ใน RFC 5322

นี่คือบางคำพูด ([... ] ระบุสิ่งที่ฉันละเว้น)

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
แหล่งที่มา

@jasen คุณรู้หรือไม่ว่าเครื่องมือสำหรับการพับ?

— mahdi

ห้องสมุดอีเมลที่เขียนได้ดีจะทำเช่นนี้ รายการโปรดของฉันคือc-client

— Jasen

นี่คือคำตอบที่ถูกต้อง ส่วนที่สองของคำถาม "ระยะเวลาในการฝึกที่ดี" ขึ้นอยู่กับแอพของคุณ หากคุณบันทึกอีเมลที่ได้รับคุณจะต้องสนับสนุนความยาวไม่ จำกัด

— Rob

4

หลังการทดสอบ: ถ้าคุณส่งอีเมลไปยังไคลเอนต์ outlook และหัวเรื่องคือ> 77 ตัวอักษรและจำเป็นต้องใช้"=?ISO"ภายในหัวเรื่อง (ในกรณีของฉันเนื่องจากการเน้นเสียง) OutLook จะ "ตัด" หัวเรื่องตรงกลาง มันและประกบมันทั้งหมดที่เกิดขึ้นหลังจากนั้นรวมถึงเนื้อความ, สิ่งที่แนบมา ฯลฯ ... ทั้งหมดเป็นตาข่าย!

ฉันมีตัวอย่างหลายอย่างเช่นนี้:

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".?=

ถึง:

อย่างที่คุณเห็นในบรรทัดหัวเรื่องมันตัดกับถ่าน 78 ด้วย "=" ตามด้วยตัวดึงข้อมูลบรรทัด 2 หรือ 3 จากนั้นดำเนินการต่อกับส่วนที่เหลือของหัวเรื่องที่ไม่ดี

มีรายงานให้ฉันจากลูกค้าหลายรายที่ใช้ OutLook ลูกค้าอีเมลรายอื่นจัดการกับวิชาเหล่านั้นได้

หากคุณไม่มี ISO บนมันก็ไม่เจ็บ แต่ถ้าคุณเพิ่มลงในหัวเรื่องของคุณว่าดีต่อ RFC คุณก็จะได้รับเซอร์ไพรส์นี้จาก OutLook บิตถ้าคุณไม่เพิ่ม ISO จากนั้นอีเมลของ iPhone จะไม่เข้าใจ (และแนบไฟล์ที่มีชื่อโดยใช้อักขระดังกล่าวจะไม่ทำงานบน iPhone)

— เซร์คิโอ
แหล่งที่มา

5

มีปัญหามากมายกับเรื่องที่คุณตั้งค่า: 1. ช่องว่างควรเข้ารหัสด้วย '_', 2. 'เข้ารหัส - คำ' (=? charset? Q / B? data? =) อาจมีความยาวไม่เกิน 75 ตัวอักษร (RFC2047) อันดับที่ 3 คุณไม่สามารถหลบหนีขึ้นบรรทัดใหม่ด้วย '=' อักขระที่ท้ายบรรทัด (การเข้ารหัส QP ส่วนหัวแตกต่างจากเนื้อหาของ QP) บรรทัดล่างคือ: มันไม่ใช่ความผิดของ Outlook

— Pawel Lesnikowski

2

ฉันไม่เชื่อว่ามีการ จำกัด อย่างเป็นทางการที่นี่และฉันค่อนข้างแน่ใจว่าไม่มีการ จำกัด ที่ยากใน RFC เช่นกันตามที่คุณพบ

ฉันคิดว่าข้อ จำกัด ทั่วไปของหัวเรื่อง (ไม่ใช่แค่อีเมล) คือ:

80 ตัวอักษร
128 ตัวละคร
256 ตัวอักษร

เห็นได้ชัดว่าคุณต้องการที่จะเกิดขึ้นกับสิ่งที่เหมาะสม หากคุณกำลังเขียนไคลเอนต์อีเมลคุณอาจต้องการไปกับ 256 ตัวอักษรและทดสอบกับเซิร์ฟเวอร์เชิงพาณิชย์ขนาดใหญ่อย่างละเอียดเพื่อให้แน่ใจว่าบริการอีเมลของคุณถูกต้อง

หวังว่านี่จะช่วยได้!

— Ed Altorfer
แหล่งที่มา

13

ไม่มีเหตุผลใดที่ทำให้ 256 ดีกว่า 250 หรือ 300 หรือ 372 เราใช้เวลานานในการใช้ไบต์สำหรับความยาวสตริง

— เกร็ก Hewgill

4

255 เป็นขีด จำกัด ที่เกิดขึ้นจริงในผลิตภัณฑ์บางอย่าง (Jira และแนวโน้มตัวอย่าง)

— reconbot

5

คำตอบนี้ผิด RFC 5322 ซึ่งเป็นข้อมูลจำเพาะของ IMF เวอร์ชันปัจจุบันกำหนดความยาวบรรทัดสูงสุดได้อย่างชัดเจน ดูคำตอบของ Michael

— james.garriss

2

+1 ข้อจำกัดความยาวบรรทัดสำหรับข้อความทุกบรรทัด แต่ฉันไม่เห็นสิ่งใดที่บอกว่าคุณไม่สามารถมีหัวเรื่องยาวหลายบรรทัด (หมายความว่าไม่มีข้อ จำกัด เกี่ยวกับจำนวนอักขระสำหรับหัวเรื่อง) ดู 2.2.3 และตัวอย่างที่ตามมาหลังจากนั้นโดยตรง

— Cypher

1

VARCHAR 255 น่าจะเป็นความยาวของคอลัมน์ข้อมูล (และมีประสิทธิภาพมากขึ้น) ที่พบมากที่สุดใน MySQL / MariaDB ไบต์มีความเกี่ยวข้องมากที่สุดอย่างแน่นอน MySQL จะใช้ 1 ไบต์เพื่อเก็บความยาวถ้าน้อยกว่า 256 หรือมากกว่านั้น ลองดูว่า C ++ ใช้ std :: string อย่างไรถ้าคุณคิดว่าความยาวของสตริงนั้นไม่สำคัญและนับเป็นไบต์

— ebyrob

0

สิ่งสำคัญคือกลไกที่คุณใช้ส่งอีเมล ห้องสมุดที่ทันสมัยที่สุด (เช่น System.Net.Mail) จะซ่อนการซ่อนจากคุณ คุณเพิ่งใส่หัวเรื่องอีเมลที่ยาวมาก ๆ โดยไม่ต้อง (CR, LF, HTAB) หากคุณเริ่มพยายามหมอบด้วยตนเองการเดิมพันทั้งหมดจะถูกปิด มันจะเริ่มรายงานข้อผิดพลาด ดังนั้นหากคุณมีปัญหานี้เพียงแค่กรอง CR, LF, HTAB และปล่อยให้ห้องสมุดทำงานให้คุณ โดยปกติคุณสามารถตั้งค่าประเภทข้อความที่เข้ารหัสเป็นฟิลด์แยก ไม่จำเป็นต้องใช้การเข้ารหัส iso ในหัวเรื่อง

— kariato
แหล่งที่มา