ขณะส่งเนื้อหาอีเมลจำเป็นต้องตั้งค่าส่วนหัว "Content Transfer Encoding" ฉันสังเกตเห็นส่วนหัวของอีเมลหลายฉบับที่ได้รับ อีเมลบางฉบับใช้ "7 บิต" และบางฉบับใช้ "8 บิต"

สองตัวนี้ต่างกันอย่างไร? แนะนำตัวไหน จำเป็นต้องมีการเข้ารหัสพิเศษสำหรับเนื้อหาอีเมลเพื่อตั้งค่าส่วนหัวเหล่านี้หรือไม่

อาจอ่านได้หนาแน่นเล็กน้อย แต่ส่วน "Content-Transfer-Encoding" ของ RFC 1341 มีรายละเอียดทั้งหมด:

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

สถานการณ์ค่อนข้างแย่ลงไปอีก นี่คือสรุปของฉัน:

พื้นหลัง

SMTP ตามความหมาย (RFC 821) จำกัด เมลไว้ที่บรรทัดละ 1,000 อักขระ 7 บิต นั่นหมายความว่าไม่มีไบต์ใดที่คุณส่งลงไปในไปป์ที่สามารถตั้งค่าบิตที่สำคัญที่สุด ("ลำดับสูงสุด") เป็น "1" ได้

เนื้อหาที่เราต้องการส่งมักจะไม่เป็นไปตามข้อ จำกัด นี้โดยเนื้อแท้ ลองนึกถึงไฟล์รูปภาพหรือไฟล์ข้อความที่มีอักขระ Unicode ไบต์ของไฟล์เหล่านี้มักจะกำหนดบิตที่ 8 ไว้ที่ "1" SMTP ไม่อนุญาตให้ทำเช่นนี้ดังนั้นคุณต้องใช้ "การเข้ารหัสการโอน" เพื่ออธิบายว่าคุณได้แก้ไขปัญหาที่ไม่ตรงกัน

ค่าของContent-Transfer-Encodingส่วนหัวจะอธิบายถึงกฎที่คุณเลือกเพื่อแก้ปัญหานี้

การเข้ารหัส 7 บิต

7bitหมายความว่า "ข้อมูลของฉันประกอบด้วยอักขระ US-ASCII เท่านั้นซึ่งใช้เฉพาะ 7 บิตที่ต่ำกว่าสำหรับแต่ละอักขระ" โดยทั่วไปคุณรับประกันได้ว่าไบต์ทั้งหมดในเนื้อหาของคุณเป็นไปตามข้อ จำกัด ของ SMTP อยู่แล้วดังนั้นจึงไม่จำเป็นต้องได้รับการดูแลเป็นพิเศษ คุณสามารถอ่านได้ตามที่เป็นอยู่

โปรดทราบว่าเมื่อคุณเลือก7bitคุณยอมรับว่าบรรทัดทั้งหมดในเนื้อหาของคุณมีความยาวน้อยกว่า 1,000 อักขระ

ตราบใดที่เนื้อหาของคุณเป็นไปตามกฎเหล่านี้7bitการเข้ารหัสการถ่ายโอนที่ดีที่สุดคือการเข้ารหัสที่ดีที่สุดเนื่องจากไม่จำเป็นต้องทำงานเพิ่มเติม คุณเพียงแค่อ่าน / เขียนไบต์เมื่อมันหลุดออกมาจากท่อ นอกจากนี้ยังง่ายต่อการเข้าถึง7bitเนื้อหาและทำให้เข้าใจได้ แนวคิดก็คือถ้าคุณแค่เขียน "ข้อความภาษาอังกฤษธรรมดา" คุณก็สบายดี แต่นั่นไม่เป็นความจริงในปี 2548และไม่เป็นความจริงในวันนี้

การเข้ารหัส 8 บิต

8bitหมายถึง "ข้อมูลของฉันอาจมีอักขระ ASCII แบบขยายพวกเขาอาจใช้บิตที่ 8 (สูงสุด) เพื่อระบุอักขระพิเศษที่อยู่นอกอักขระ 7 บิต US-ASCII มาตรฐาน" เช่นเดียวกับ7bitขีด จำกัด บรรทัด 1,000 อักขระ

8bitเช่นเดียวกับที่7bitไม่ได้ทำการแปลงไบต์ตามที่เขียนหรืออ่านจากลวด หมายความว่าคุณไม่รับประกันว่าจะไม่มีไบต์ใดตั้งค่าบิตสูงสุดเป็น "1"

สิ่งนี้ดูเหมือนจะเป็นขั้นตอนที่เพิ่มขึ้น7bitเนื่องจากช่วยให้คุณมีอิสระในเนื้อหามากขึ้น อย่างไรก็ตาม RFC 1341 มีความน่าสนใจนี้:

ในขณะที่เผยแพร่เอกสารนี้ไม่มีการขนส่งทางอินเทอร์เน็ตที่เป็นมาตรฐานซึ่งการรวมข้อมูล 8 บิตหรือไบนารีที่ไม่ได้เข้ารหัสไว้ในเนื้อหาเมลนั้นถูกต้องตามกฎหมาย ดังนั้นจึงไม่มีสถานการณ์ใดที่การเข้ารหัสการถ่ายโอนเนื้อหาแบบ "8 บิต" หรือ "ไบนารี" เป็นสิ่งที่ถูกกฎหมายบนอินเทอร์เน็ต

RFC 1341 ออกมาเมื่อ 20 ปีที่แล้ว ตั้งแต่นั้นเราเคย8bit MIME ส่วนขยายในRFC 6152 แต่ถึงอย่างนั้นอาจมีการ จำกัด จำนวนบรรทัด:

โปรดทราบว่าส่วนขยายนี้ไม่ได้ขจัดความเป็นไปได้ที่เซิร์ฟเวอร์ SMTP จะจำกัดความยาวบรรทัด เซิร์ฟเวอร์มีอิสระที่จะใช้ส่วนขยายนี้ แต่ยังคงกำหนดขีดจำกัดความยาวของบรรทัดไว้ไม่ต่ำกว่า 1,000 อ็อกเต็ต

การเข้ารหัสไบนารี

binaryเหมือนกับ8bitยกเว้นว่าไม่มีข้อจำกัดความยาวบรรทัด คุณยังสามารถใส่อักขระที่ต้องการได้และไม่มีการเข้ารหัสเพิ่มเติม เช่นเดียวกับ8bitRFC 1341 ระบุว่าไม่ใช่การเข้ารหัสการถ่ายโอนการเข้ารหัสที่ถูกต้อง RFC 3030ขยายสิ่งนี้ด้วยBINARYMIME.

พิมพ์ได้

ก่อน8BITMIMEส่วนขยายจำเป็นต้องมีวิธีการส่งเนื้อหาที่ไม่สามารถส่ง7bitผ่าน SMTP ได้ ไฟล์ HTML (ซึ่งอาจมีบรรทัดมากกว่า 1,000 อักขระ) และไฟล์ที่มีอักขระสากลเป็นตัวอย่างที่ดีสำหรับสิ่งนี้ การquoted-printableเข้ารหัส (กำหนดไว้ในมาตรา 5.1 ของ RFC 1341) ได้รับการออกแบบมาเพื่อจัดการสิ่งนี้ มันทำสองสิ่ง:

• กำหนดวิธีการหลีกเลี่ยงอักขระที่ไม่ใช่ US-ASCII เพื่อให้สามารถแสดงเป็นอักขระ 7 บิตเท่านั้น (เวอร์ชันสั้น: แสดงเป็นเครื่องหมายเท่ากับบวกอักขระ 7 บิตสองตัว)
• กำหนดว่าบรรทัดจะมีความยาวไม่เกิน 76 อักขระและตัวแบ่งบรรทัดจะแสดงโดยใช้อักขระพิเศษ (ซึ่งจากนั้นจะใช้ Escape)

พิมพ์ได้เนื่องจากการเว้นวรรคและบรรทัดสั้น ๆ นั้นยากต่อการอ่านโดยมนุษย์มากกว่า7bitหรือ8bitแต่รองรับเนื้อหาที่เป็นไปได้ในวงกว้างมากขึ้น

การเข้ารหัส Base64

หากข้อมูลของคุณส่วนใหญ่ไม่ใช่ข้อความ (เช่นไฟล์รูปภาพ) แสดงว่าคุณไม่มีตัวเลือกมากมาย 7bitอยู่นอกโต๊ะ 8bitและbinaryไม่ได้รับการสนับสนุนก่อนส่วนขยาย MIME RFC quoted-printableจะใช้งานได้ แต่ไม่มีประสิทธิภาพจริงๆ (ทุกๆไบต์จะถูกแทนด้วยอักขระ 3 ตัว)

base64เป็นทางออกที่ดีสำหรับข้อมูลประเภทนี้ เข้ารหัส 3 ไบต์ดิบเป็นอักขระ US-ASCII 4 ตัวซึ่งค่อนข้างมีประสิทธิภาพ RFC 1341 จะจำกัดความยาวบรรทัดของbase64ข้อมูลที่เข้ารหัสไว้ที่ 76 อักขระเพื่อให้พอดีกับข้อความ SMTP แต่มันค่อนข้างง่ายในการจัดการเมื่อคุณเพียงแค่แยกหรือต่ออักขระตามอำเภอใจที่ความยาวคงที่

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