MIME Base64

ข้อความอินพุต
0 อักขระ

ระบบจัดรูปแบบ MIME Base64 ออนไลน์จาก GeekFormat แทรก CRLF ที่ความกว้าง 76 อักขระตามมาตรฐาน RFC 2045 หรือคืนค่า MIME Base64 หลายบรรทัดกลับเป็นบรรทัดเดียว เหมาะสำหรับการเข้ารหัสไฟล์แนบอีเมล ลายเซ็น S/MIME การจัดการใบรับรอง PEM และความเข้ากันได้กับระบบเก่า ประมวลผลในเบราว์เซอร์เครื่องล้วน ข้อมูลไม่ส่งไปเซิร์ฟเวอร์ รองรับคัดลอกคลิกเดียว

คำแนะนำที่เกี่ยวข้อง

รวม Base64 หลายบรรทัด

วิดีโอเป็น Base64

ตัวแปลงรหัส Unicode

แปลงข้อความเป็น Base64

เครื่องมือจัดรูปแบบ SQL

เครื่องมือทดสอบ Regex

เกี่ยวกับการจัดรูปแบบ MIME Base64

MIME Base64 เป็นรูปแบบการแสดงผลการเข้ารหัส Base64 ที่ใช้ในระบบอีเมล MIME (Multipurpose Internet Mail Extensions ส่วนขยายจดหมายอินเทอร์เน็ตหลายวัตถุประสงค์) เป็นชุดมาตรฐานอินเทอร์เน็ตที่กำหนดวิธีการส่งเนื้อหาที่ไม่ใช่ข้อความ (เช่น ข้อมูลไบนารี เช่น รูปภาพ เสียง วิดีโอ) ในอีเมล Base64 เข้ารหัสข้อมูลไบนารีเป็นข้อความ ASCII ล้วน ทำให้ระบบอีเมลสามารถส่งไฟล์แนบไบนารีได้อย่างปลอดภัย

RFC 2045 เป็นหนึ่งในมาตรฐานหลักที่กำหนด MIME โดยระบุรูปแบบการตัดบรรทัดของเนื้อหาที่เข้ารหัส Base64 ในอีเมล: แต่ละบรรทัดต้องไม่เกิน 76 อักขระ Base64 และใช้ CRLF (\r\n) เป็นตัวจบบรรทัด ข้อจำกัดนี้มาจากข้อจำกัดทางประวัติศาสตร์ของโปรโตคอล SMTP — เมลเซิร์ฟเวอร์ (MTA) รุ่นแรกมีข้อจำกัดความยาวบรรทัดเดียวที่เข้มงวด การตั้งค่า 76 อักขระอย่างอนุรักษ์นิยมรับประกันว่าเนื้อหาจะถูกประมวลผลได้อย่างถูกต้องบนเมลเซิร์ฟเวอร์ทุกตัว โดยไม่ถูกตัดทอนหรือแก้ไข

MIME Base64 และ Base64 ทั่วไปมีเนื้อหาที่เข้ารหัสเหมือนกันทุกประการ — ชุดอักขระเดียวกัน (A-Za-z0-9+/), padding เดียวกัน (เครื่องหมาย =), อัลกอริทึมการเข้ารหัสเดียวกัน ความแตกต่างเพียงอย่างเดียวคือรูปแบบการแสดงผล: MIME Base64 แทรก CRLF ทุก 76 อักขระเป็นข้อความหลายบรรทัด ส่วน Base64 ทั่วไปมักเป็นสตริงบรรทัดเดียวต่อเนื่อง ขณะถอดรหัส ตัวขึ้นบรรทัดจะถูกละเว้นโดยอัตโนมัติ ทั้งสองรูปแบบให้ข้อมูลต้นฉบับเดียวกันหลังถอดรหัส

การแปลงสองทิศทางเป็นความต้องการหลักของการจัดการ MIME Base64 บรรทัดเดียวเป็นตัดบรรทัด: แทรก CRLF ที่ความกว้าง 76 อักขระในสตริง Base64 ต่อเนื่องที่ได้จาก API สร้างรูปแบบ MIME ที่สอดคล้องมาตรฐานอีเมล สามารถฝังในเนื้อหาอีเมลได้โดยตรง ตัดบรรทัดเป็นบรรทัดเดียว: ลบตัวขึ้นบรรทัดทั้งหมดในรูปแบบ MIME คืนค่าเป็นสตริงต่อเนื่อง สะดวกสำหรับพารามิเตอร์คำขอ API ฟิลด์ JSON หรือจัดเก็บในฐานข้อมูล ทั้งสองการดำเนินการเป็นกระบวนการผกผันกัน

CRLF (\r\n) เป็นลำดับตัวจบบรรทัดมาตรฐานที่กำหนดโดยมาตรฐาน MIME: CR (Carriage Return คืนตัว, ASCII 13) + LF (Line Feed ขึ้นบรรทัดใหม่, ASCII 10) นี่คือตัวจบบรรทัดมาตรฐานของโปรโตคอลอินเทอร์เน็ต ต่างจาก LF (\n) ล้วนที่ใช้ในระบบ Unix/Linux และ CR (\r) ล้วนที่ใช้ในระบบ Mac เก่า RFC 2045 กำหนดให้เนื้อหา MIME ใช้ CRLF แต่ขณะคืนค่า ระบบจะรองรับการตรวจจับตัวขึ้นบรรทัดทั้งสามประเภท

S/MIME (Secure/MIME) เป็นส่วนขยายความปลอดภัยของ MIME ใช้สำหรับลายเซ็นดิจิทัลและการเข้ารหัสอีเมล ข้อมูล PKCS#7 หลังลงลายเซ็น S/MIME มีโครงสร้างที่มีเนื้อหาลายเซ็นที่เข้ารหัส Base64 เนื้อหาเหล่านี้ต้องถูกตัดบรรทัดตามมาตรฐาน MIME ก่อนฝังในอีเมล PEM (Privacy Enhanced Mail) เป็นรูปแบบอื่นที่ใช้การตัดบรรทัด Base64 ความกว้างคงที่ แต่ใช้ความกว้าง 64 อักขระ (RFC 1421) ต่างจาก MIME ที่ 76 อักขระ ทั้งสองเป็นรูปแบบการแสดงผล Base64 ความกว้างคงที่ การเข้าใจ MIME Base64 จะช่วยจัดการรูปแบบที่คล้ายกัน

Content-Transfer-Encoding เป็นฟิลด์สำคัญในส่วนหัวอีเมล MIME ระบุวิธีการเข้ารหัสเนื้อหาอีเมล เมื่อค่าเป็น base64 หมายถึงเนื้อหาอีเมลใช้การเข้ารหัส Base64 และแสดงในรูปแบบตัดบรรทัด 76 อักขระ เมื่อไคลเอนต์อีเมลฝั่งรับอ่านระบุนี้ จะถอดรหัส Base64 ที่ตัดบรรทัดกลับเป็นข้อมูลดั้งเดิมโดยอัตโนมัติ ค่า Content-Transfer-Encoding อื่นที่พบบ่อย ได้แก่ 7bit, 8bit, quoted-printable ฯลฯ Base64 เป็นวิธีที่ใช้บ่อยที่สุดสำหรับไฟล์แนบไบนารี

ระบบนี้เน้นการจัดรูปแบบ MIME Base64 — ตัดบรรทัดและคืนค่า ไม่ได้ทำการเข้ารหัสหรือถอดรหัส Base64 การประมวลผลทั้งหมดทำในเบราว์เซอร์ผ่าน JavaScript ข้อมูลไม่ออกจากอุปกรณ์ของคุณ การตัดบรรทัดทำตามมาตรฐาน RFC 2045 อย่างเคร่งครัด (76 อักขระ + CRLF) การคืนค่ารองรับ CRLF, CR, LF ทั้งสามประเภทโดยอัตโนมัติ เหมาะสำหรับการพัฒนาอีเมล การจัดการ S/MIME การดีบั๊กโปรโตคอล และความเข้ากันได้กับระบบเก่า

กรณีการใช้งาน

  • จัดรูปแบบ Base64 บรรทัดเดียวเป็นรูปแบบไฟล์แนบอีเมล MIME ที่ความกว้าง 76 อักขระตามมาตรฐาน RFC 2045
  • คืนค่า MIME Base64 หลายบรรทัดเป็นบรรทัดเดียวสำหรับส่งผ่าน API หรือฝังในฟิลด์ JSON
  • จัดการส่วนเนื้อหาที่เข้ารหัส Base64 ในอีเมลลายเซ็น S/MIME ปรับรูปแบบการตัดบรรทัด
  • รองรับรูปแบบผลลัพธ์ Base64 ความกว้างคงที่ที่ระบบเก่าหรือโปรโตคอลเก่าต้องการ
  • ตรวจสอบว่าการตัดบรรทัดของเนื้อหาไฟล์แนบ Base64 สอดคล้องกับข้อกำหนด MIME ขณะดีบั๊กการพัฒนาอีเมล
  • แปลงสตริง Base64 ต่อเนื่องจาก API เป็นรูปแบบตัดบรรทัด เพื่อให้สะดวกต่อการวางแสดงในเนื้อหาอีเมล
  • อ้างอิงตรรกะการตัดบรรทัดความกว้างคงที่ขณะจัดการเนื้อหา Base64 ในใบรับรอง PEM
  • สถานการณ์ที่ไฟล์คอนฟิกต้องการ Base64 รูปแบบ MIME (เช่น เกตเวย์อีเมล คอนฟิก SMTP relay)
  • ประมวลผลล่วงหน้าเนื้อหา Base64 ก่อนเข้ารหัสไฟล์แนบอีเมล เพื่อรับประกันความกว้างการตัดบรรทัดที่ถูกต้อง
  • รวมข้อมูล Base64 จากแหล่งต่างๆ ให้เป็นมาตรฐาน MIME ก่อนใช้ในระบบอีเมล
  • เปรียบเทียบความแตกต่างของเนื้อหา Base64 ก่อนและหลังตัดบรรทัดขณะตรวจสอบปัญหาการเข้ารหัสไฟล์แนบอีเมล
  • แปลงระหว่าง Base64 ต่อเนื่องจากเอาต์พุตของเครื่องมือคอมมานด์ไลน์ (เช่น OpenSSL) กับรูปแบบตัดบรรทัดที่ระบบอีเมลต้องการ

วิธีการใช้งาน

  1. วางหรือป้อนเนื้อหา Base64 ลงในกล่องอินพุต
  2. เลือกทิศทางการแปลง: บรรทัดเดียวเป็นตัดบรรทัด MIME (76 อักขระ) หรือตัดบรรทัด MIME เป็นบรรทัดเดียว (ลบการตัดบรรทัด)
  3. ระบบประมวลผลรูปแบบตามมาตรฐาน RFC 2045 โดยอัตโนมัติ แสดงผลลัพธ์แบบเรียลไทม์
  4. คลิกปุ่มคัดลอกเพื่อคัดลอกผลลัพธ์ไปยังคลิปบอร์ด สำหรับใช้ในระบบอีเมล พารามิเตอร์ API หรือไฟล์คอนฟิก

คุณสมบัติ

  • ตัดบรรทัดตามมาตรฐาน RFC 2045: แทรก CRLF ที่ความกว้าง 76 อักขระอย่างเคร่งครัด สอดคล้องกับข้อกำหนดการส่งอีเมล MIME
  • แปลงทิศทางสองทาง: รองรับการแปลง Base64 บรรทัดเดียวเป็นรูปแบบตัดบรรทัด MIME และย้อนกลับจากหลายบรรทัดเป็นบรรทัดเดียวต่อเนื่อง
  • ประมวลผลในเบราว์เซอร์ไม่มีการอัปโหลด: การแปลงรูปแบบทั้งหมดทำในเบราว์เซอร์ ไม่ผ่านเซิร์ฟเวอร์ใดๆ ข้อมูลไม่ออกจากอุปกรณ์
  • คัดลอกคลิกเดียว: ผลลัพธ์สามารถคัดลอกไปยังคลิปบอร์ดได้ทันที สำหรับใช้ในไคลเอนต์อีเมล พารามิเตอร์ API หรือไฟล์คอนฟิก
  • มาตรฐานตัวขึ้นบรรทัด CRLF: การตัดบรรทัดใช้ลำดับ CRLF (\r\n) มาตรฐาน สอดคล้องกับข้อกำหนดของ RFC 2045 สำหรับตัวจบบรรทัด MIME
  • ตัดบรรทัด 76 อักขระแม่นยำ: แต่ละบรรทัดมี Base64 อักขระ 76 ตัวพอดี (บรรทัดสุดท้ายอาจสั้นกว่า) รับประกันความเข้ากันได้กับเมลเซิร์ฟเวอร์ทุกตัว
  • คืนค่าหลายบรรทัดอัจฉริยะ: ตรวจจับและลบตัวขึ้นบรรทัด CRLF/CR/LF ในรูปแบบ MIME โดยอัตโนมัติ รวมเป็นสตริง Base64 ต่อเนื่อง
  • เข้ากันได้กับไฟล์แนบอีเมล: รูปแบบผลลัพธ์สามารถฝังในเนื้อหาอีเมล MIME ได้โดยตรง ทำงานกับไคลเอนต์อีเมล เช่น Outlook, Thunderbird
  • รองรับลายเซ็น S/MIME: Base64 ที่ตัดบรรทัดแล้วสามารถใช้ในส่วนเนื้อหาที่เข้ารหัสของโครงสร้างลายเซ็น S/MIME
  • อ้างอิงรูปแบบ PEM: แม้ PEM ใช้การตัดบรรทัด 64 อักขระ แต่ตรรกะการตัดบรรทัดของระบบนี้ช่วยให้เข้าใจและจัดการรูปแบบเข้ารหัสความกว้างคงที่ที่คล้ายกัน
  • พรีวิวเรียลไทม์: แสดงผลลัพธ์การตัดบรรทัด/คืนค่าทันทีหลังป้อนข้อมูล ไม่ต้องกดปุ่มรอ
  • ทำความสะอาดอินพุตอัตโนมัติ: ลบช่องว่างและอักขระที่ไม่ใช่ Base64 จากอินพุตโดยอัตโนมัติ ป้องกันการนำเข้าอักขระรบกวนจากการคัดลอกวาง
  • จัดการข้อความขนาดใหญ่: รองรับสตริง Base64 ยาว (หลายหมื่นอักขระ) สำหรับตัดบรรทัดและคืนค่าอย่างรวดเร็ว ประมวลผลในเบราว์เซอร์ภายในเวลาไม่กี่วินาที
  • ใช้งานฝั่งไคลเอนต์ล้วน: พัฒนาด้วย JavaScript API ดั้งเดิมของเบราว์เซอร์ ไม่ต้องติดตั้งปลั๊กอินหรือพึ่งพาเซิร์ฟเวอร์ภายนอก ใช้งานออฟไลน์ได้

คำถามที่พบบ่อย

ทำไม MIME Base64 ถึงตัดบรรทัดที่ 76 อักขระ?

RFC 2045 กำหนดให้เนื้อหาที่เข้ารหัส MIME แต่ละบรรทัดต้องไม่เกิน 76 อักขระ เพื่อรองรับข้อจำกัดความยาวบรรทัดของเมลเซิร์ฟเวอร์ (MTA) รุ่นแรก โปรโตคอล SMTP ในอดีตกำหนดให้แต่ละบรรทัดต้องไม่เกิน 1000 อักขระ แต่มาตรฐาน MIME จำกัดไว้ที่ 76 อักขระของข้อมูล Base64 บวกกับตัวขึ้นบรรทัด เพื่อรับประกันว่าเมลเซิร์ฟเวอร์ทุกตัวจะประมวลผลได้อย่างถูกต้อง

เนื้อหาที่เข้ารหัสของ MIME Base64 และ Base64 ทั่วไปเหมือนกันหรือไม่?

เนื้อหาที่เข้ารหัสเหมือนกันทุกประการ ความแตกต่างเพียงอย่างเดียวคือรูปแบบการแสดงผล MIME Base64 แทรก CRLF ทุก 76 อักขระ ส่วน Base64 ทั่วไปมักเป็นบรรทัดเดียวต่อเนื่อง ขณะถอดรหัส ตัวขึ้นบรรทัดจะถูกละเว้น ทั้งสองรูปแบบให้ข้อมูลต้นฉบับเดียวกันหลังถอดรหัส

สามารถคืนค่า MIME Base64 หลายบรรทัดเป็นบรรทัดเดียวได้หรือไม่?

ได้ ระบบจะตรวจจับและลบตัวขึ้นบรรทัด CRLF (\r\n), CR (\r) และ LF (\n) ในรูปแบบตัดบรรทัด MIME โดยอัตโนมัติทั้งหมด รวมเป็นสตริง Base64 บรรทัดเดียวต่อเนื่อง หลังคืนค่าจะสะดวกต่อการใช้เป็นพารามิเตอร์คำขอ API ฟิลด์ JSON หรือการส่งผ่านไฟล์คอนฟิก

รูปแบบใบรับรอง PEM กับ MIME Base64 เกี่ยวข้องกันอย่างไร?

รูปแบบ PEM (เช่น ใบรับรอง SSL คีย์ส่วนตัว) ใช้การตัดบรรทัด Base64 ที่ความกว้าง 64 อักขระ ซึ่งต่างจาก MIME ที่ 76 อักขระเล็กน้อย ทั้งสองเป็นรูปแบบการแสดงผล Base64 ความกว้างคงที่ แต่ทำตามมาตรฐานต่างกัน (PEM อ้างอิง RFC 1421, MIME อ้างอิง RFC 2045) ตรรกะการตัดบรรทัดของระบบนี้ช่วยให้เข้าใจรูปแบบที่คล้ายกัน

การตัดบรรทัดใช้ตัวขึ้นบรรทัดอะไร?

ตามมาตรฐาน RFC 2045 การตัดบรรทัด MIME Base64 ใช้ CRLF (\r\n) เป็นตัวจบบรรทัด นี่คือตัวจบบรรทัดมาตรฐานของโปรโตคอลอินเทอร์เน็ต รับประกันความเข้ากันได้กับเมลเซิร์ฟเวอร์และตัวส่งต่อทุกตัว บางระบบอาจใช้เพียง LF (\n) การคืนค่าจะตรวจจับทั้งสองประเภทโดยอัตโนมัติ

ลายเซ็น S/MIME ต้องใช้ MIME Base64 หรือไม่?

ต้อง โครงสร้างลายเซ็น S/MIME (Secure/Multipurpose Internet Mail Extensions) มีส่วนเนื้อหาที่เข้ารหัสใช้รูปแบบ MIME Base64 ข้อมูล PKCS#7 หลังลงลายเซ็นต้องถูกตัดบรรทัดที่ 76 อักขระก่อนฝังในอีเมล ระบบนี้ช่วยสร้าง Base64 ที่ตัดบรรทัดสอดคล้องกับข้อกำหนด S/MIME

บรรทัดสุดท้ายจะถูกเติมให้ครบ 76 อักขระหรือไม่?

ไม่ RFC 2045 กำหนดให้บรรทัดสุดท้ายมีความยาวเท่าใดก็ได้ (1-76 อักขระ) ไม่ต้องเติมให้ครบ ต่างจากการเข้ารหัสความยาวคงที่ (เช่น รูปแบบไบนารีบางประเภทที่แต่ละบรรทัดมี 76 อักขระพอดี) บรรทัดสุดท้ายของ MIME Base64 จะคงจุดสิ้นสุดตามธรรมชาติของการเข้ารหัส Base64 ไว้

จัดการ Base64 padding (เครื่องหมาย =) อย่างไร?

การเข้ารหัส Base64 ใช้เครื่องหมาย = เป็นตัวเติมท้าย (0-2 ตัว) เมื่อตัดบรรทัด MIME เครื่องหมาย = จะปรากฏท้ายบรรทัดสุดท้าย ระบบจะคง padding ไว้ไม่เปลี่ยนแปลง ทั้งการตัดบรรทัดและการคืนค่าจะไม่แก้ไขเนื้อหาของการเข้ารหัส Base64 เอง

ระบบจะแก้ไขเนื้อหาที่เข้ารหัสของ Base64 หรือไม่?

ไม่ ระบบทำเฉพาะการปรับรูปแบบ (แทรกหรือลบตัวขึ้นบรรทัด) ไม่แก้ไขอักขระ Base64 เอง Base64 หลังตัดบรรทัดเมื่อถอดรหัสแล้วจะเหมือนกับอินพุตต้นฉบับทุกประการ สามารถใช้ได้อย่างมั่นใจ

ถ้าอินพุตมีอักขระที่ไม่ใช่ Base64 จะเกิดอะไรขึ้น?

ระบบจะกรองช่องว่าง (เว้นวรรค แท็บ ตัวขึ้นบรรทัด) และอักขระที่ไม่ใช่ Base64 (อักขระที่ไม่อยู่ในช่วง A-Za-z0-9+/=) ออกจากอินพุตโดยอัตโนมัติ เก็บเฉพาะเนื้อหา Base64 ที่ถูกต้องไว้สำหรับประมวลผล ป้องกันการนำเข้าอักขระรบกวนจากการคัดลอกวาง

รองรับสตริง Base64 ยาวเท่าใด?

ระบบประมวลผลด้วย JavaScript ในเบราว์เซอร์เครื่อง รองรับสตริง Base64 ระดับหลายหมื่นอักขระสำหรับตัดบรรทัดและคืนค่าอย่างรวดเร็ว เนื้อหาที่ยาวมาก (เช่น การเข้ารหัส Base64 ของไฟล์แนบขนาดใหญ่) ก็ประมวลผลเสร็จภายในไม่กี่วินาที

ใช้ถอดรหัส Base64 ได้หรือไม่?

ระบบนี้เน้นที่การจัดรูปแบบ MIME (ตัดบรรทัด/คืนค่า) ไม่ได้ทำการเข้ารหัสหรือถอดรหัส Base64 หากต้องการเข้ารหัส/ถอดรหัส Base64 โปรดใช้ตัวช่วยเข้ารหัส/ถอดรหัส Base64 ภายในเว็บไซต์ การจัดรูปแบบ MIME ปรับเฉพาะรูปแบบการตัดบรรทัดของสตริง Base64 เท่านั้น

Content-Transfer-Encoding: base64 หมายถึงอะไร?

นี่คือฟิลด์ในส่วนหัวอีเมล MIME ระบุว่าเนื้อหาอีเมลใช้การเข้ารหัส Base64 เมื่อไคลเอนต์อีเมลฝั่งรับเห็นระบุนี้ จะถอดรหัสเนื้อหา Base64 (รวมการตัดบรรทัด 76 อักขระ) กลับเป็นข้อมูลไบนารีดั้งเดิม Base64 ที่ตัดบรรทัดจากระบบนี้สามารถใช้กับเนื้อหาอีเมลประเภทนี้ได้โดยตรง

ทำไม Base64 ในอีเมลดูมีการขึ้นบรรทัดใหม่มากมาย?

เพราะระบบอีเมลตัดบรรทัดเนื้อหาที่เข้ารหัส Base64 ทุก 76 อักขระตามมาตรฐาน RFC 2045 นี่คือข้อกำหนดของมาตรฐาน MIME เพื่อรับประกันว่าเนื้อหาจะถูกส่งผ่านเมลเซิร์ฟเวอร์ได้อย่างถูกต้อง ในอีเมลที่มีไฟล์แนบ การเข้ารหัส Base64 ของไฟล์แนบจะปรากฏเป็นหลายบรรทัดในซอร์สโค้ดอีเมล

ใช้งานออฟไลน์ได้หรือไม่?

ได้ หลังโหลดหน้าเว็บเสร็จ ฟังก์ชันทั้งหมดทำงานในเบราว์เซอร์เครื่อง ไม่ต้องเชื่อมต่อเครือข่าย แม้ไม่มีอินเทอร์เน็ตก็สามารถตัดบรรทัดและคืนค่า MIME Base64 ได้ตามปกติ ข้อมูลที่ประมวลผลจะไม่ถูกส่งไปยังเซิร์ฟเวอร์ใดๆ

การแก้ไขปัญหา

ถอดรหัส Base64 หลังตัดบรรทัดล้มเหลว?

การตัดบรรทัด MIME Base64 แทรกเพียง CRLF ไม่แก้ไขเนื้อหาที่เข้ารหัส หากถอดรหัสล้มเหลวหลังตัดบรรทัด อาจเป็นเพราะอินพุตเองไม่ใช่การเข้ารหัส Base64 ที่ถูกต้อง โปรดตรวจสอบก่อนว่าเนื้อหาอินพุตถูกต้องด้วยตัวตรวจสอบ Base64 แล้วจึงจัดรูปแบบ MIME

หลังคืนค่าสตริง Base64 ยังมีตัวขึ้นบรรทัดเหลือ?

ระบบจะลบตัวขึ้นบรรทัด CRLF (\r\n), CR (\r) และ LF (\n) ทั้งหมดโดยอัตโนมัติ หากยังมีเหลือหลังคืนค่า อาจมีอักขระที่มองไม่เห็นอื่น (เช่น เว้นวรรค แท็บ) ในอินพุต ระบบจะกรองอักขระเหล่านี้โดยอัตโนมัติเช่นกัน แต่หากปัญหายังคงอยู่ โปรดตรวจสอบว่าเนื้อหาต้นฉบับมีอักขระควบคุมพิเศษหรือไม่

ไคลเอนต์อีเมลแสดงไฟล์แนบเป็นภาษาต่างดาว?

รูปแบบตัดบรรทัด MIME Base64 เป็นเพียงส่วนหนึ่งของการเข้ารหัสอีเมล หากไฟล์แนบแสดงผิดพลาด อาจเป็นเพราะส่วนหัว Content-Transfer-Encoding ตั้งค่าไม่ถูกต้อง การเข้ารหัส Base64 เองมีข้อผิดพลาด หรือ Content-Type ไม่ตรงกัน ตรวจสอบให้แน่ใจว่าส่วนหัวอีเมลตั้งค่า Content-Transfer-Encoding: base64 และใช้ MIME boundary ที่ถูกต้องเป็นตัวคั่น

ความกว้างตัดบรรทัดของใบรับรอง PEM ไม่ถูกต้อง?

รูปแบบ PEM ใช้การตัดบรรทัด 64 อักขระ (RFC 1421) ส่วน MIME ใช้ 76 อักขระ (RFC 2045) ระบบนี้ตัดบรรทัดตามมาตรฐาน MIME (76 อักขระ) ไม่เหมาะสำหรับการจัดรูปแบบใบรับรอง PEM หากต้องการการตัดบรรทัด 64 อักขระของรูปแบบ PEM โปรดใช้โปรแกรมจัดการใบรับรองเฉพาะทางหรือ OpenSSL

อภิธานศัพท์

MIME
Multipurpose Internet Mail Extensions ส่วนขยายจดหมายอินเทอร์เน็ตหลายวัตถุประสงค์ ชุดมาตรฐานอินเทอร์เน็ต (RFC 2045-2049) กำหนดวิธีการส่งเนื้อหาที่ไม่ใช่ข้อความในอีเมล รวมถึงการเข้ารหัส Base64, Content-Type และ Content-Transfer-Encoding และกลไกอื่นๆ
RFC 2045
เอกสารมาตรฐานที่กำหนดส่วนแรกของ MIME ระบุรูปแบบการตัดบรรทัดของการเข้ารหัส Base64 ในอีเมล: แต่ละบรรทัดต้องไม่เกิน 76 อักขระ และใช้ CRLF เป็นตัวจบบรรทัด
CRLF
Carriage Return + Line Feed (\r\n) ลำดับตัวจบบรรทัดมาตรฐานของโปรโตคอลอินเทอร์เน็ต RFC 2045 กำหนดให้การตัดบรรทัด MIME Base64 ใช้ CRLF ต่างจาก LF (\n) ของ Unix และ CR (\r) ของ Mac เก่า
Content-Transfer-Encoding
ฟิลด์ส่วนหัวอีเมล MIME ระบุวิธีการเข้ารหัสเนื้อหาอีเมล เมื่อค่าเป็น base64 หมายถึงเนื้อหาใช้การเข้ารหัส Base64 และตัดบรรทัดที่ 76 อักขระ เป็นวิธีการเข้ารหัสที่ใช้บ่อยที่สุดสำหรับไฟล์แนบไบนารี
S/MIME
Secure/Multipurpose Internet Mail Extensions ส่วนขยายความปลอดภัยของ MIME ใช้สำหรับลายเซ็นดิจิทัลและการเข้ารหัสอีเมล ส่วนเนื้อหาที่เข้ารหัส Base64 ในลายเซ็นต้องถูกตัดบรรทัดตามมาตรฐาน MIME
PEM
Privacy Enhanced Mail รูปแบบที่ใช้การตัดบรรทัด Base64 ที่ความกว้าง 64 อักขระ (RFC 1421) มักใช้สำหรับไฟล์ใบรับรอง SSL และคีย์ส่วนตัว ต่างจากการตัดบรรทัด 76 อักขระของ MIME
Base64 padding
การเติมเครื่องหมาย = (0-2 ตัว) ท้ายการเข้ารหัส Base64 ให้ความยาวเป็นพหุคูณของ 4 เมื่อตัดบรรทัด MIME padding จะปรากฏท้ายบรรทัดสุดท้าย ไม่ถูกลบหรือแก้ไข
MTA
Mail Transfer Agent ตัวแทนส่งต่ออีเมล ซอฟต์แวร์ที่รับผิดชอบส่งต่ออีเมลระหว่างเซิร์ฟเวอร์ MTA รุ่นแรกมีข้อจำกัดความยาวบรรทัดเดียวที่เข้มงวด การตัดบรรทัด 76 อักขระของ MIME ออกแบบมาเพื่อรองรับ MTA
SMTP
Simple Mail Transfer Protocol โปรโตคอลการส่งอีเมลอย่างง่าย โปรโตคอลพื้นฐานของการส่งอีเมลอินเทอร์เน็ต SMTP กำหนดให้แต่ละบรรทัดต้องไม่เกิน 1000 อักขระ (รวม CRLF) การจำกัด 76 อักขระของ MIME อนุรักษ์นิยมกว่า
quoted-printable
วิธี Content-Transfer-Encoding อีกแบบที่ MIME รองรับ ใช้เป็นหลักสำหรับเนื้อหาที่ส่วนใหญ่เป็นข้อความ ASCII เข้ารหัสเฉพาะอักขระที่ไม่ใช่ ASCII ประหยัดพื้นที่มากกว่า Base64
PKCS#7
Public Key Cryptography Standards #7 มาตรฐานไวยากรณ์ข้อความเข้ารหัสที่ S/MIME ใช้ กำหนดโครงสร้างข้อมูลของลายเซ็นดิจิทัลและการเข้ารหัส เนื้อหาที่เข้ารหัสใช้รูปแบบ MIME Base64
RFC 1421
เอกสารมาตรฐานที่กำหนดรูปแบบ PEM (Privacy Enhanced Mail) ระบุให้ Base64 ตัดบรรทัดที่ความกว้าง 64 อักขระ แคบกว่า 76 อักขระของ MIME มักใช้สำหรับไฟล์ใบรับรอง

เปรียบเทียบ MIME Base64 กับ Base64 ทั่วไป

ความแตกต่างหลักของทั้งสองรูปแบบคือวิธีการแสดงผล เนื้อหาที่เข้ารหัสเหมือนกันทุกประการ:

ประเด็นเปรียบเทียบMIME Base64Base64 ทั่วไป
ความกว้างตัดบรรทัด76 อักขระ/บรรทัดมักไม่ตัดบรรทัด (บรรทัดเดียว)
ตัวจบบรรทัดCRLF (\r\n)ไม่มี (หรือขึ้นอยู่กับระบบ)
มาตรฐานอ้างอิงRFC 2045RFC 4648
การใช้งานทั่วไปไฟล์แนบอีเมล, S/MIMEพารามิเตอร์ API, Data URL
ผลการถอดรหัสเหมือนกันเหมือนกัน

ตารางเปรียบเทียบรูปแบบ Base64 ความกว้างคงที่ทั่วไป

เปรียบเทียบความกว้างการตัดบรรทัดที่มาตรฐานต่างๆ ใช้:

รูปแบบมาตรฐานความกว้างตัดบรรทัดการใช้งานทั่วไป
MIME Base64RFC 204576เข้ารหัสไฟล์แนบอีเมล, ลายเซ็น S/MIME
PEMRFC 142164ใบรับรอง SSL, ไฟล์คีย์ส่วนตัว
Base64 ทั่วไปRFC 4648ไม่ตัดบรรทัดพารามิเตอร์ API, Data URL, JWT

เปรียบเทียบวิธี Content-Transfer-Encoding ของ MIME

วิธีการเข้ารหัสการส่งทั่วไปที่ MIME รองรับ:

วิธีการเข้ารหัสเนื้อหาที่เหมาะสมประสิทธิภาพพื้นที่
base64ข้อมูลไบนารีใดๆ (รูปภาพ, เสียง/วิดีโอ ฯลฯ)ขยายประมาณ 33% (3 ไบต์ → 4 อักขระ)
quoted-printableส่วนใหญ่เป็นข้อความ ASCII, มีที่ไม่ใช่ ASCII เล็กน้อยขยายเฉพาะอักขระที่ไม่ใช่ ASCII
7bitข้อความ ASCII ล้วน (ไม่ต้องเข้ารหัส)ไม่ขยาย
8bitข้อความที่มีอักขระ 8 บิต (ต้องการการรองรับ 8BITMIME)ไม่ขยาย

Privacy & Security

ระบบจัดรูปแบบ MIME Base64 นี้ดำเนินการทั้งหมดในเบราว์เซอร์เครื่องของคุณผ่าน JavaScript ไม่ส่งเนื้อหา Base64 ที่ป้อน ผลลัพธ์การประมวลผล หรือบันทึกการใช้งานไปยังเซิร์ฟเวอร์ใดๆ หลังโหลดหน้าเว็บไม่ต้องเชื่อมต่อเครือข่ายก็ใช้งานได้ ข้อมูลทั้งหมดมีอยู่เฉพาะในหน่วยความจำเบราว์เซอร์ ปิดหรือรีเฟรชหน้าเว็บแล้วจะถูกล้างโดยอัตโนมัติ ไม่มีการอัปโหลดหรือจัดเก็บข้อมูล ไม่มีความเสี่ยงด้านความเป็นส่วนตัว

Authoritative References