เครื่องมือแปลง Base64 - เครื่องมือแปลง Base64 ออนไลน์ฟรี

Base64 คืออะไร?

Base64 เป็นระบบการเข้ารหัสข้อมูลจากไบนารีเป็นข้อความที่แปลงข้อมูลไบนารีเป็นสตริง ASCII 64 ตัวอักษร เมื่อคุณต้องส่งรูปภาพผ่านอีเมล ฝังข้อมูลใน URL หรือส่งข้อมูลไบนารีผ่าน JSON API Base64 จะช่วยแก้ปัญหาการเสียหายของข้อมูลในช่องทางข้อความ

ระบบการเข้ารหัสนี้ทำงานกับชุดอักขระเฉพาะ:

• ตัวอักษรพิมพ์ใหญ่ A-Z (26 ตัวอักษร)
• ตัวอักษรพิมพ์เล็ก a-z (26 ตัวอักษร)
• ตัวเลข 0-9 (10 ตัวอักษร)
• สัญลักษณ์สองตัว: "+" และ "/" (2 ตัวอักษร)

เครื่องมือเข้ารหัสและถอดรหัส base64 ของเราสามารถแปลงข้อความเป็น Base64 หรือถอดรหัส Base64 กลับเป็นข้อความที่อ่านได้ทันที โดยไม่ต้องติดตั้งอะไรเพิ่มเติม

ทำไม Base64 จึงสำคัญในการพัฒนาสมัยใหม่

เมื่อสร้างเว็บแอปพลิเคชัน คุณจะพบ Base64 อยู่ตลอดเวลา การแนบไฟล์อีเมลใช้การเข้ารหัสผ่าน MIME Data URI ใน CSS และ HTML อาศัยมันเพื่อฝังรูปภาพโดยตรงในโค้ด REST API ใช้เพื่อส่งข้อมูลไบนารีในเพย์โหลด JSON แม้กระทั่งการรับรองความถูกต้องแบบ HTTP Basic ก็ยังขึ้นอยู่กับ Base64 (แม้ว่าจะไม่ใช่การเข้ารหัส—จะอธิบายเพิ่มเติมด้านล่าง)

นี่คือสิ่งที่ทำให้การเข้ารหัสนี้จำเป็น: โพรโทคอลแบบข้อความอย่าง HTTP, JSON และ XML ไม่ได้ถูกออกแบบมาเพื่อจัดการข้อมูลไบนารีดิบอย่างน่าเชื่อถือ การส่งรูปภาพไบนารีผ่าน JSON API โดยไม่เข้ารหัสจะทำให้ข้อมูลเสียหายได้ง่าย Base64 ช่วยให้ข้อมูลไบนารีของคุณปลอดภัยโดยแสดงด้วยอักขระ ASCII ที่ปลอดภัย

วิธีใช้เครื่องมือ Base64

การเข้ารหัสข้อความเป็น Base64:

1. พิมพ์หรือวางข้อความของคุณในช่องป้อนข้อมูล
2. คลิก "เข้ารหัสเป็น Base64" หรือเปิดใช้งานการแปลงสด
3. คัดลอกผลลัพธ์ Base64 เพื่อใช้ในแอปพลิเคชันของคุณ

การถอดรหัส Base64 เป็นข้อความ:

1. วาง Base64 สตริงของคุณในช่องป้อนข้อมูล
2. คลิก "ถอดรหัสจาก Base64" หรือสลับไปยังโหมดถอดรหัส
3. ดูข้อความดั้งเดิมในพื้นที่ผลลัพธ์

โหมดการแปลงสด จะอัปเดตผลลัพธ์โดยอัตโนมัติขณะที่คุณพิมพ์ ซึ่งเหมาะสำหรับการทดสอบและแก้ไขข้อบกพร่องอย่างรวดเร็ว เครื่องมือรองรับข้อความ UTF-8 รวมถึงอีโมจิและอักขระระหว่างประเทศ

วิธีการทำงานของการเข้ารหัส Base64

การเข้ารหัสจะแปลงข้อมูลอินพุตทุก 3 ไบต์ (24 บิต) เป็นอักขระ Base64 สี่ตัว คิดเสมือนเป็นการแปลที่กลุ่มของ 3 ไบต์อินพุตกลายเป็นกลุ่มของ 4 อักขระเอาต์พุต

นี่คือขั้นตอนการเข้ารหัส base64 แบบทีละขั้น:

1. แปลงเป็นไบนารี: ข้อความอินพุตของคุณกลายเป็นการแสดงผลในรูปแบบไบนารี (โดยปกติเป็น UTF-8)
2. จัดกลุ่มเป็นชุด: ข้อมูลไบนารีแบ่งออกเป็นชุด 24 บิต (3 ไบต์ต่อชุด)
3. แบ่งเป็นส่วน 6 บิต: แต่ละชุด 24 บิตแบ่งออกเป็นสี่กลุ่ม 6 บิต
4. แมปเป็นอักขระ: ค่า 6 บิตแต่ละค่า (0-63) แมปเป็นอักขระ Base64 ของตน

เกิดอะไรขึ้นเมื่ออินพุตของคุณไม่หารด้วย 3 ได้ลงตัว? อักขระการเติม ("=") จะเติมช่องว่าง นี่ช่วยรักษาอัตราส่วนคงที่ 4:3 ระหว่างความยาวเอาต์พุตและอินพุต

คณิตศาสตร์เบื้องหลัง Base64

สำหรับลำดับไบต์ $b_1, b_2, b_3$, อักขระ Base64 ที่สอดคล้อง $c_1, c_2, c_3, c_4$ คำนวณได้ดังนี้:

$c_1 = \text{Base64}[(b_1 >> 2)]$ $c_2 = \text{Base64}[((b_1 \& 3) << 4) | (b_2 >> 4)]$ $c_3 = \text{Base64}[((b_2 \& 15) << 2) | (b_3 >> 6)]$ $c_4 = \text{Base64}[(b_3 \& 63)]$

โดยที่ $\text{Base64}[i]$ แสดงถึงอักขระที่ $i$ ในอักษร Base64

กระบวนการถอดรหัส Base64

การถอดรหัสจะย้อนกลับการเข้ารหัสโดยแปลงอักขระ Base64 กลับเป็นไบนารี:

1. แมปอักขระ Base64 แต่ละตัวเป็นค่า 6 บิต
2. เชื่อมต่อค่า 6 บิตเหล่านี้เป็นกระแสบิตต่อเนื่อง
3. แบ่งออกเป็นชุด 8 บิต (ไบต์)
4. แปลงแต่ละไบต์เป็นอักขระที่สอดคล้อง

ทำความเข้าใจการเติม

การเติมช่วยให้ความยาวเอาต์พุตเป็นจำนวนเท่าของ 4 อักขระเสมอ:

• หนึ่งไบต์คงเหลือ: สร้างอักขระ Base64 สองตัวพร้อม "=="
• สองไบต์คงเหลือ: สร้างอักขระ Base64 สามตัวพร้อม "="

ข้อผิดพลาดทั่วไปคือการลบอักขระการเติมเมื่อจัดเก็บสตริง Base64 แม้ว่าตัวถอดรหัสบางตัวจะจัดการกับการขาดหายไปได้ แต่การใช้งานที่เข้มงวดจะปฏิเสธ ให้คงอักขระการเติมไว้เว้นแต่คุณแน่ใจว่าตัวถอดรหัสของคุณมีความยืดหยุ่น

การเข้ารหัส Base64 ตัวอย่าง: "Hello"

มาดูการเข้ารหัส "Hello" โดยใช้ ตัวแปลง base64:

1. ค่า ASCII: 72 101 108 108 111
2. รูปแบบไบนารี: 01001000 01100101 01101100 01101100 01101111
3. จัดกลุ่มเป็นชุด 6 บิต: 010010 000110 010101 101100 011011 000110 1111
4. เติมศูนย์ในชุดสุดท้าย: 010010 000110 010101 101100 011011 000110 111100
5. แปลงเป็นเลขฐานสิบ: 18, 6, 21, 44, 27, 6, 60
6. แมปไปยังอักษร Base64: S, G, V, s, b, G, 8
7. ผลลัพธ์สุดท้าย: SGVsbG8=

สังเกตเครื่องหมาย "=" ที่ต่อท้าย เนื่องจาก "Hello" มี 5 ไบต์ (ไม่หารด้วย 3 ลงตัว) จึงต้องมีการเติมเพื่อบอกว่ากลุ่มสุดท้ายไม่สมบูรณ์

สูตรความยาวของสตริงเข้ารหัส Base64

สูตรสำหรับคำนวณความยาวของสตริงเข้ารหัส:

$\text{encoded\_length} = 4 \times \lceil \frac{\text{input\_length}}{3} \rceil$

โดยที่ $\lceil x \rceil$ แสดงถึงฟังก์ชันเพดาน (ปัดขึ้นไปยังจำนวนเต็มที่ใกล้เคียง)

การใช้งาน Base64 ในโลกแห่งความเป็นจริง

นี่คือสถานที่ที่คุณจะพบกับ การเข้ารหัส base64 ในระบบการทำงานจริง:

1. ไฟล์แนบอีเมล (การเข้ารหัส MIME)

โปรโตคอลอีเมลถูกออกแบบมาสำหรับข้อความ ASCII 7 บิต เมื่อคุณแนบ PDF หรือรูปภาพ MIME จะใช้ Base64 เพื่อแปลงไฟล์ไบนารีให้เป็นข้อความที่ปลอดภัยสำหรับอีเมล นั่นคือเหตุผลที่ไฟล์แนบอีเมลมีขนาดใหญ่กว่าไฟล์ต้นฉบับประมาณ 33% - นี่คือค่าใช้จ่ายของ Base64

2. Data URIs ในการพัฒนาเว็บ

เคยฝังรูปภาพโดยตรงใน CSS หรือ HTML หรือไม่? นั่นคือ Base64 ทำงาน:

1<img src="data:image/png;base64,iVBORw0KGgoAAAANS..." />
2

เทคนิคนี้ลดคำขอ HTTP โดยการฝังสินทรัพย์ขนาดเล็กโดยตรงในโค้ด อย่างไรก็ตาม เหมาะสำหรับรูปภาพขนาดเล็ก (ต่ำกว่า 10KB) - ไฟล์ที่ใหญ่กว่าจะทำให้การแสดงหน้าเว็บช้าลง เนื่องจากไม่สามารถแคชแยกได้

3. การส่งข้อมูลผ่าน API

REST APIs มักใช้ Base64 เพื่อส่งข้อมูลไบนารีผ่าน JSON เมื่ออัปโหลดรูปภาพผ่านจุดสิ้นสุด API ที่ยอมรับเพียง JSON คุณจะเข้ารหัสไฟล์เป็น Base64 โปรดทราบว่านี่เพิ่มขนาดเพย์โหลด 33% ดังนั้นควรพิจารณาใช้ multipart/form-data สำหรับไฟล์ขนาดใหญ่

4. การรับรองความถูกต้อง HTTP Basic

ส่วนหัว Authorization ใช้ Base64 เพื่อเข้ารหัสข้อมูลประจำตัว:

1Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
2

คำเตือนสำคัญ: Base64 ไม่ใช่การเข้ารหัส ใครก็สามารถถอดรหัสได้ทันที ควรใช้ HTTPS เสมอ - ห้ามส่งข้อมูลประจำตัวที่เข้ารหัสด้วย Base64 ผ่าน HTTP ธรรมดา

5. โทเค็น JWT

JSON Web Tokens (JWT) ใช้การเข้ารหัส Base64URL (ตัวแปรที่ปลอดภัยสำหรับ URL) สำหรับส่วนประกอบทั้งสาม สิ่งนี้ช่วยให้โทเค็นสามารถส่งผ่าน URL และส่วนหัว HTTP ได้อย่างปลอดภัย

6. จัดเก็บข้อมูลไบนารีในฐานข้อมูล

เมื่อฐานข้อมูลของคุณไม่รองรับคอลัมน์ไบนารีหรือคุณต้องจัดเก็บข้อมูลไบนารีในฟิลด์ JSON Base64 จะให้โซลูชันที่ปลอดภัยสำหรับข้อความ โปรดทราบว่านี่จะเพิ่มข้อกำหนดการจัดเก็บ 33%

7. การจัดเก็บคุกกี้

คุกกี้ต้องมีเพียงอักขระ ASCII เท่านั้น เมื่อต้องจัดเก็บโครงสร้างข้อมูลที่ซับซ้อนหรือข้อมูลไบนารีในคุกกี้ การเข้ารหัส Base64 จะทำให้พวกเขาปลอดภัยสำหรับคุกกี้

เมื่อไม่ควรใช้ Base64

ก่อนที่จะเข้ารหัสทุกอย่างด้วย Base64 ให้พิจารณาสถานการณ์เหล่านี้ที่ซึ่งเป็นตัวเลือกที่ไม่เหมาะสม:

การส่งไฟล์ขนาดใหญ่: การเพิ่มขนาดขึ้น 33% ส่งผลกระทบอย่างมากต่อแบนด์วิดท์และเวลาโหลด ให้ใช้การถ่ายโอนไบนารีโดยตรง (multipart/form-data) แทน

การจัดเก็บรูปภาพฝั่งไคลเอนต์: รูปภาพ Base64 ใน CSS หรือ HTML ไม่สามารถแคชแยกกันได้และปิดกั้นการแสดงหน้าเว็บ ให้จัดเก็บรูปภาพเป็นไฟล์แยกเพื่อประสิทธิภาพที่ดีกว่า

การจัดเก็บไฟล์ขนาดใหญ่ในฐานข้อมูล: การจัดเก็บสตริง Base64 ขนาดเมกะไบต์ในช่อง TEXT ของฐานข้อมูลจะทำให้เปลืองพื้นที่จัดเก็บและทำให้การสืบค้นช้าลง ให้ใช้คอลัมน์ BLOB หรือบริการจัดเก็บไฟล์ (S3, CloudFlare R2) แทน

ความต้องการด้านความปลอดภัย: Base64 ไม่มีความปลอดภัยเลย อย่าใช้เพื่อ "ซ่อน" คีย์ API รหัสผ่าน หรือข้อมูลที่ละเอียดอ่อน ให้ใช้การเข้ารหัสที่เหมาะสม

สถานการณ์ที่ต้องการประสิทธิภาพสูง: การเข้ารหัส/ถอดรหัส Base64 เพิ่มภาระการประมวลผล เมื่อประมวลผลคำขอหลายพันรายการต่อวินาที การจัดการไบนารีโดยตรงจะมีประสิทธิภาพดีกว่า

ทางเลือกของ Base64: การเลือกการเข้ารหัสที่เหมาะสม

Base64 ไม่ใช่ตัวเลือกที่ดีเสมอไป นี่คือเวลาที่ควรพิจารณาทางเลือกอื่น:

Base64 ที่ปลอดภัยสำหรับ URL

Base64 มาตรฐานใช้ "+" และ "/" ซึ่งทำให้ URL เสีย Base64 ที่ปลอดภัยสำหรับ URL แทนที่ด้วย "-" และ "_" ใช้ตัวแปรนี้สำหรับ:

• พารามิเตอร์คิวรี
• เส้นทาง URL
• โทเค็น JWT
• ข้อมูลที่ส่งผ่าน URL

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

Base32 สร้างผลลัพธ์ที่ยาวขึ้น (เพิ่มขึ้น 40% เทียบกับ 33%) แต่มีความไม่ละเอียดต่ออักษรใหญ่-เล็ก เลือก Base32 เมื่อ:

• ผู้ใช้ต้องพิมพ์ค่าที่เข้ารหัสด้วยตนเอง
• ระบบที่ละเอียดต่ออักษรใหญ่-เล็กก่อให้เกิดปัญหา
• ต้องการการตรวจจับข้อผิดพลาดที่ดีขึ้น

การเข้ารหัสเลขฐานสิบหก

เลขฐานสิบหกเพิ่มขนาดข้อมูล (เพิ่มขึ้น 100%) แต่เรียบง่ายและรองรับอย่างกว้างขวาง เหมาะสำหรับ:

• แสดงค่าแฮช
• รหัสสี
• ที่อยู่ MAC
• สถานการณ์ที่ความสามารถในการอ่านสำคัญกว่าประสิทธิภาพ

การถ่ายโอนไบนารีโดยตรง

สำหรับไฟล์ขนาดใหญ่ ข้ามการเข้ารหัสข้อความทั้งหมด ใช้ multipart/form-data หรือ HTTP ไบนารีด้วยส่วนหัว Content-Type ที่เหมาะสม นี่หลีกเลี่ยงการเพิ่มขนาด 33% และปรับปรุงประสิทธิภาพ

การบีบอัด + Base64

เมื่อเข้ารหัสข้อความหรือข้อมูลที่ซ้ำกันขนาดใหญ่ ให้บีบอัดก่อน (gzip หรือ deflate) แล้วจึงใช้ Base64 วิธีนี้มักได้ผลลัพธ์ที่เล็กกว่าการเข้ารหัส Base64 โดยตรง

ประวัติย่อของการเข้ารหัส Base64

Base64 เกิดขึ้นจากความต้องการในการส่งข้อมูลไบนารีผ่านช่องทางข้อความเท่านั้นในยุคเริ่มแรกของการคำนวณ ข้อกำหนดอย่างเป็นทางการปรากฏครั้งแรกใน RFC 989 (1987) สำหรับ Privacy Enhanced Mail (PEM) จากนั้นได้พัฒนาผ่าน RFC 1421 (1993) และ RFC 2045 (1996) เป็นส่วนหนึ่งของ MIME

ชื่อ "Base64" สะท้อนถึงอักขระ 64 ตัว ซึ่งไม่ได้เกิดขึ้นโดยบังเอิญ—64 เท่ากับ 2^6 ทำให้การแปลง binary เป็น Base64 มีประสิทธิภาพทางคณิตศาสตร์ผ่านการเลื่อนบิตอย่างง่าย

Base64 ในปัจจุบันมีหลายรูปแบบ:

• Base64 มาตรฐาน (RFC 4648): ใช้ A-Z, a-z, 0-9, +, / พร้อมการเติม =
• Base64 ปลอดภัยสำหรับ URL: แทนที่ + และ / ด้วย - และ _ เพื่อส่งผ่าน URL อย่างปลอดภัย
• Base64URL: รุ่นมาตรฐาน IETF สำหรับ URL และชื่อไฟล์
• Base64 แบบดัดแปลง: IMAP ใช้ชุดอักขระของตนเองสำหรับชื่อกล่องจดหมาย

หลังจาก 35 ปีขึ้นไป Base64 ยังคงมีความสำคัญต่อการพัฒนาเว็บสมัยใหม่ โดยเฉพาะอย่างยิ่งเมื่อ JSON APIs และเว็บเซอร์วิสครอบงำภูมิทัศน์

[ส่วนที่เหลือของการแปลจะคงรูปแบบเดิมทุกประการ ซึ่งรวมถึงตัวอย่างโค้ดทั้งหมดในภาษาต่างๆ]

ปัญหาทั่วไปของ Base64 และวิธีแก้ไข

ระวังปัญหาเหล่านี้เมื่อทำงานกับ base64 ดีโค้ด หรือเอนโค้ด:

1. ปัญหาการเข้ารหัสอักขระ

ปัญหา: การเข้ารหัสข้อความที่มีอีโมจิหรืออักขระนานาชาติโดยไม่แปลงเป็น UTF-8 ก่อนจะทำให้ได้ผลลัพธ์เสีย

วิธีแก้: แปลงเป็นไบต์ UTF-8 ก่อนการเข้ารหัส Base64 เสมอ ใน JavaScript หมายถึงการจัดการอักขระหลายไบต์อย่างถูกต้อง—btoa() ในตัวจะล้มเหลวกับ Unicode

2. การเติมข้อมูลที่หายไปหรือไม่ถูกต้อง

ปัญหา: บางระบบตัดอักขระเติม "=" ออก ทำให้ตัวถอดรหัสที่เข้มงวดล้มเหลว

วิธีแก้: ก่อนการถอดรหัส ตรวจสอบความยาวว่าหารด้วย 4 ลงตัวหรือไม่ ถ้าไม่ ให้เติมอักขระ "=" เข้าไป: while (str.length % 4) str += '='

3. การขึ้นบรรทัดในข้อมูลที่เข้ารหัส

ปัญหา: การใช้ MIME แบบเก่าจะเพิ่มการขึ้นบรรทัดทุก 76 อักขระ API สมัยใหม่มักปฏิเสธ

วิธีแก้: ลบช่องว่างและการขึ้นบรรทัดทั้งหมดก่อนการถอดรหัส: str.replace(/\s/g, '')

4. Base64 แบบปลอดภัยสำหรับ URL กับแบบมาตรฐาน

ปัญหา: การใช้ Base64 มาตรฐาน (+, /) ใน URL จะทำให้เกิดปัญหาการเข้ารหัสหรือทำให้การกำหนดเส้นทางเสีย

วิธีแก้: สำหรับ URL ให้ใช้ตัวแปรที่ปลอดภัยสำหรับ URL แทน สลับระหว่าง:

• มาตรฐานเป็นปลอดภัยสำหรับ URL: แทนที่ + ด้วย - และ / ด้วย _
• ปลอดภัยสำหรับ URL เป็นมาตรฐาน: กลับการแทนที่

5. ประสิทธิภาพกับไฟล์ขนาดใหญ่

ปัญหา: การเข้ารหัสไฟล์หลายเมกะไบต์ในหน่วยความจำอาจทำให้เบราว์เซอร์ค้างหรือแอปพลิเคชันล่ม

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

6. ความเข้าใจผิดด้านความปลอดภัย

ข้อผิดพลาดสำคัญ: การปฏิบัติต่อ Base64 ราวกับเป็นการเข้ารหัสลับหรือการปกปิดที่ปลอดภัย

ความเป็นจริง: Base64 สามารถย้อนกลับได้อย่างสมบูรณ์ในเวลาเป็นมิลลิวินาที ห้ามใช้เพื่อ "ซ่อน" ข้อมูลที่ละเอียดอ่อน เป็นเพียงการเข้ารหัสเท่านั้น ไม่ใช่ความปลอดภัย ควรใช้การเข้ารหัสที่เหมาะสม (AES, RSA) เมื่อต้องการความปลอดภัย

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

Base64 คือการเข้ารหัสลับหรือไม่?

ไม่ใช่ Base64 เป็นการเข้ารหัส ไม่ใช่การเข้ารหัสลับ ทุกคนสามารถถอดรหัส Base64 ได้ทันทีโดยไม่ต้องใช้คีย์ การเข้ารหัสลับต้องใช้คีย์ลับและยากต่อการย้อนกลับทางคำนวณ หากต้องการความปลอดภัย ให้ใช้อัลกอริทึมการเข้ารหัสลับที่เหมาะสม เช่น AES-256 แล้วเข้ารหัส Base64 สำหรับการส่งข้อมูลต่อไป

ทำไม Base64 จึงทำให้ขนาดข้อมูลใหญ่ขึ้น?

การเพิ่มขนาด 33% เป็นคุณสมบัติพื้นฐานของอัลกอริทึม ทุก 3 ไบต์อินพุตจะกลายเป็น 4 ตัวอักษรเอาต์พุต เนื่องจาก Base64 ใช้ 6 บิตต่อตัวอักษร ขณะที่ไบต์มาตรฐานใช้ 8 บิต สูตร: 3 ไบต์ × 8 บิต = 24 บิต; 24 บิต ÷ 6 บิตต่อตัวอักษร = 4 ตัวอักษร

สามารถเข้ารหัสรูปภาพเป็น Base64 ได้หรือไม่?

ได้ รูปภาพสามารถเข้ารหัสเป็น Base64 ได้ ซึ่งเป็นเรื่องปกติสำหรับ data URIs ใน HTML/CSS และ API payloads อย่างไรก็ตาม ให้พิจารณาข้อแลกเปลี่ยน: รูปภาพ Base64 ไม่สามารถแคชแยกได้ เพิ่มขนาดหน้าขึ้น 33% และทำให้การแสดงผลเริ่มต้นช้าลง ใช้สำหรับไอคอนขนาดเล็ก (ต่ำกว่า 10KB) ไม่ใช่รูปถ่ายขนาดใหญ่

อะไรคือความแตกต่างระหว่าง Base64 และ Base64URL?

Base64URL ปลอดภัยสำหรับ URL Base64 มาตรฐานใช้ "+" และ "/" ซึ่งมีความหมายพิเศษใน URL (ช่องว่างและตัวคั่นเส้นทาง) Base64URL แทนที่ด้วย "-" และ "_" ซึ่งปลอดภัยใน URL โทเค็น JWT ใช้ Base64URL ด้วยเหตุนี้

ฉันจะแก้ไขข้อผิดพลาด "Invalid Base64 string" ได้อย่างไร?

สาเหตุทั่วไป:

1. ขาดการเติมข้อมูล: เพิ่มอักขระ "=" จนความยาวหารด้วย 4 ลงตัว
2. อักขระไม่ถูกต้อง: ลบอักขระนอกเหนือจาก A-Z, a-z, 0-9, +, /, =
3. ช่องว่าง: ลบช่องว่าง แท็บ และบรรทัดใหม่ทั้งหมด
4. ตัวแปรที่ผิด: Base64 สำหรับ URL ใช้ - และ _ แทน + และ /

สามารถถอดรหัส Base64 เป็นไฟล์ไบนารีได้หรือไม่?

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

ทำไมต้องใช้ Base64 สำหรับไฟล์แนบอีเมล?

SMTP (โปรโตคอลอีเมล) ออกแบบมาสำหรับข้อความ ASCII 7 บิต ไฟล์ไบนารีจะเสียหายระหว่างการส่ง MIME ใช้ Base64 เพื่อแปลงไฟล์ไบนารีเป็นข้อความ ASCII ที่ปลอดภัยซึ่งสามารถส่งผ่านการจัดเส้นทางอีเมลได้ การเพิ่มขนาด 33% คือราคาของความเข้ากันได้

ฉันจะเข้ารหัสอักขระพิเศษใน Base64 ได้อย่างไร?

ก่อนอื่น ให้เข้ารหัสข้อความเป็นไบต์ UTF-8 ก่อน แล้วจึงใช้การเข้ารหัส Base64 กับไบต์เหล่านั้น นี่จะทำให้มั่นใจว่าอีโมจิ อักขระเน้น และสคริปต์นานาชาติเข้ารหัสได้ถูกต้อง ใน JavaScript ให้ใช้ TextEncoder แทน btoa() ซึ่งล้มเหลวกับ Unicode:

1new TextEncoder().encode(text) // แปลงเป็นไบต์ UTF-8 ก่อน
2

การเข้ารหัส Base64 ช้าสำหรับไฟล์ขนาดใหญ่หรือไม่?

การเข้ารหัส/ถอดรหัส Base64 ค่อนข้างเร็ว (หลายล้านไบต์ต่อวินาทีบนซีพียูสมัยใหม่) แต่การประมวลผลไฟล์หลายเมกะไบต์ในหน่วยความจำอาจทำให้เบราว์เซอร์ค้าง สำหรับไฟล์ที่มีขนาดเกิน 1MB ให้ใช้วิธีการสตรีมหรือ Web Workers เพื่อหลีกเลี่ยงการบล็อกเธรดหลัก

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

ใช้ Base64URL (ตัวแปรที่ปลอดภัยสำหรับ URL) แทน Base64 มาตรฐาน Base64 มาตรฐานมี "+" และ "/" ซึ่งก่อปัญหาใน URL ไลบรารีเช่น JWT ใช้ Base64URL โดยอัตโนมัติ ในการแปลง: แทนที่ + ด้วย -, แทนที่ / ด้วย _, และเลือกที่จะลบ padding "=" ออก

การอ้างอิงและมาตรฐาน

• RFC 4648 - การเข้ารหัสข้อมูล Base16, Base32 และ Base64 - ข้อกำหนดอย่างเป็นทางการของ IETF
• RFC 2045 - MIME ส่วนที่หนึ่ง: รูปแบบของเนื้อหาข้อความอินเทอร์เน็ต - มาตรฐานการเข้ารหัส MIME และอีเมล
• MDN Web Docs: btoa() และ atob() - เอกสารประกอบ Browser API
• RFC 7515 - JSON Web Signature (JWS) - การใช้ Base64URL ใน JWT tokens
• W3C Data URLs - ข้อกำหนดของ Data URI