เครื่องถอดรหัสภาพ Base64 | ถอดรหัสและแสดงภาพออนไลน์
เครื่องมือถอดรหัส base64 ออนไลน์ฟรี ถอดรหัสและแสดงตัวอย่างสตริง base64 เป็นภาพ JPEG, PNG, GIF, WebP หรือ SVG ได้ทันที ใช้งานได้กับ URL ข้อมูลและ base64 ดิบ
เครื่องถอดรหัสและแสดงภาพ Base64
วางสตริงภาพที่เข้ารหัส base64 เพื่อถอดรหัสและดูภาพ
ตัวอย่างภาพ
ไม่มีภาพที่จะแสดง วางสตริง base64 เพื่อดูการถอดรหัสอัตโนมัติ
รองรับ JPEG, PNG, GIF และรูปแบบภาพทั่วไปอื่นๆ
คำแนะนำ
1. วางสตริงภาพที่เข้ารหัส base64 ในพื้นที่ข้อความด้านบน
2. ภาพจะถูกถอดรหัสอัตโนมัติขณะพิมพ์ หรือคลิกปุ่ม 'ถอดรหัสภาพ'
3. ภาพที่ถอดรหัสจะปรากฏในพื้นที่แสดงตัวอย่างด้านล่าง
หมายเหตุ: สตริงควรเริ่มต้นด้วย 'data:image/' เพื่อผลลัพธ์ที่ดีที่สุด แต่เครื่องมือจะพยายามถอดรหัสสตริงที่ไม่มีคำนำหน้านี้เช่นกัน
เอกสารประกอบการใช้งาน
ตัวถอดรหัสรูปภาพ base64 คืออะไร?
ตัวถอดรหัสรูปภาพ base64 คือเครื่องมือที่แปลงสตริงข้อความที่เข้ารหัสด้วย base64 กลับเป็นรูปภาพ Base64 เป็นวิธีเขียนข้อมูลไบนารี เช่น ไบต์ของไฟล์รูปภาพ โดยใช้เพียงอักขระข้อความธรรมดา 64 ตัว ได้แก่ ตัวอักษร ตัวเลข + / และ = สำหรับการเติมให้ครบความยาว เบราว์เซอร์ อีเมล และ API จำนวนมากจัดเก็บรูปภาพด้วยวิธีนี้ เพื่อให้รูปภาพเดินทางอยู่ภายในข้อความธรรมดาแทนการเป็นไฟล์แยกต่างหาก ตัวถอดรหัสจะย้อนกระบวนการดังกล่าว เพียงวางสตริงลงไป รูปภาพต้นฉบับก็จะปรากฏ
รูปแบบ data URL
บนเว็บ รูปภาพ base64 มักเขียนเป็น data URL รูปแบบคือ:
1data:[<media type>];base64,<data>
2ตัวอย่างเช่น:
1data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==
2แต่ละส่วนมีหน้าที่ดังนี้:
data:ระบุว่านี่คือ data URL ไม่ใช่ที่อยู่เว็บทั่วไปimage/pngคือชนิด MIME ซึ่งบอกเบราว์เซอร์ว่าไฟล์นี้เป็นไฟล์ประเภทใด;base64ระบุว่าข้อมูลหลังเครื่องหมายจุลภาคเข้ารหัสด้วย base64- ทุกอย่างหลังเครื่องหมายจุลภาคคือรูปภาพที่เข้ารหัสแล้ว
ตัวถอดรหัสทำงานอย่างไร
การถอดรหัสเกิดขึ้นในสี่ขั้นตอน
- เครื่องมือจะตรวจสอบว่าสตริงเริ่มต้นด้วย
data:หรือไม่ หาก data URL ระบุชนิดสื่อที่ไม่ใช่รูปภาพ เช่นdata:text/plainระบบจะปฏิเสธทันที เพราะไม่สามารถแสดงเป็นรูปภาพได้ - ระบบจะตัดช่องว่าง แท็บ หรือการขึ้นบรรทัดใหม่ออก เนื่องจากบางครั้งสตริง base64 ที่ยาวจะถูกแบ่งข้ามหลายบรรทัด ส่วนเพย์โหลดที่ใช้การเข้ารหัสเปอร์เซ็นต์แทน base64 ซึ่ง RFC 2397 ก็อนุญาตนั้น จะถูกส่งต่อโดยไม่เปลี่ยนแปลง
- ระบบถอดรหัสข้อความ base64 กลับเป็นไบต์ดิบ
- ระบบจะตรวจสอบไบต์สองสามไบต์แรกของผลลัพธ์ รูปแบบรูปภาพทั่วไปทุกชนิดเริ่มต้นด้วยลำดับไบต์คงที่ ซึ่งเรียกว่าลายเซ็นหรือ “magic number” ไฟล์ PNG เริ่มต้นด้วย
89 50 4E 47ส่วนไฟล์ JPEG เริ่มต้นด้วยFF D8 FFและรูปแบบอื่น ๆ ก็เช่นเดียวกัน ตัวถอดรหัสจะจับคู่ลายเซ็นเหล่านี้และระบุชนิดรูปภาพตามที่ลายเซ็นบอก
ไบต์มีความสำคัญมากกว่าป้ายกำกับ หาก data URL ระบุว่า data:image/png แต่ไบต์เริ่มต้นด้วย FF D8 FF ตัวถอดรหัสจะสร้าง URL ใหม่เป็น data:image/jpeg ดังนั้นสตริงที่ปุ่ม “คัดลอก URL รูปภาพ” มอบให้จะไม่ระบุเนื้อหาของตัวเองผิด
หากสตริงไม่มีคำนำหน้า data: ตัวถอดรหัสจะถือว่าเป็นข้อมูล base64 ดิบ ถอดรหัส แล้วอ่านลายเซ็นด้วยวิธีเดียวกัน หากไบต์ไม่ตรงกับลายเซ็นรูปภาพที่รู้จัก และไม่ดูเหมือนข้อความ SVG ตัวถอดรหัสจะแจ้งว่าสตริงนี้ดูเหมือนจะไม่ใช่รูปภาพ ระบบจะไม่เดารูปแบบหรือเปลี่ยนไปใช้ชนิดเริ่มต้นใด ๆ
SVG จัดการต่างออกไป เพราะ SVG เป็นรูปแบบข้อความ (XML) ไม่ใช่ไบนารี จึงไม่มีลายเซ็นไบต์คงที่ ตัวถอดรหัสจะตรวจสอบข้อความที่ถอดรหัสแล้วในช่วง 1024 ไบต์แรก เพื่อหาแท็ก <svg คำประกาศ XML เช่น <?xml version="1.0"?> ที่ตามด้วยแท็กดังกล่าว หรือคำประกาศชนิดเอกสาร SVG ที่ตามด้วยแท็กดังกล่าว ระบบจะละเว้นเครื่องหมายลำดับไบต์ที่อยู่ตรงจุดเริ่มต้น ซึ่งโปรแกรมแก้ไขบางชนิดเพิ่มให้ไฟล์ UTF-8 เนื่องจาก SVG ไม่สามารถระบุได้จากลายเซ็นไบต์ data URL ที่ประกาศว่าเป็น image/svg+xml จึงคงชนิดที่ประกาศไว้
สูตรคำนวณขนาดรูปภาพ Base64
Base64 แปลงข้อมูลไบนารีทุก ๆ 3 ไบต์เป็นอักขระข้อความ 4 ตัว สูตรสำหรับความยาวที่เข้ารหัสคือ:
1encoded_characters = 4 × ⌈original_bytes ÷ 3⌉
2สัญลักษณ์ ⌈ ⌉ หมายถึง “ปัดขึ้นเป็นจำนวนเต็มถัดไป” เพราะ base64 ทำงานเป็นกลุ่ม กลุ่มละ 4 อักขระ และเติมกลุ่มที่เหลือให้ครบด้วยเครื่องหมาย =
สำหรับไฟล์ขนาดใหญ่ จะมีขนาดเพิ่มขึ้นโดยประมาณ 33% เนื่องจาก 4 ÷ 3 ≈ 1.33 ไฟล์ขนาดเล็กอาจมีเปอร์เซ็นต์เพิ่มขึ้นมากกว่า เพราะการปัดขึ้นเป็นกลุ่มถัดไปที่มี 4 อักขระมีผลมากกว่าเมื่อข้อมูลเริ่มต้นมีไม่มาก
ตัวอย่างการคำนวณ
ตัวอย่าง PNG ข้างต้นถอดรหัสได้ข้อมูลรูปภาพ 85 ไบต์ เมื่อใช้สูตร:
14 × ⌈85 ÷ 3⌉ = 4 × 29 = 116
2สตริง base64 มีความยาว 116 อักขระจริง ซึ่งตรงกัน เท่ากับเพิ่มขึ้น 36% จากข้อมูลเดิม 85 ไบต์ (116 ÷ 85 ≈ 1.36) สูงกว่าค่า 33% เล็กน้อย เนื่องจากไฟล์มีขนาดเล็กมาก
รูปแบบรูปภาพที่รองรับ
ตัวถอดรหัสอ่านลายเซ็นไบต์ของข้อมูลที่ถอดรหัสแล้วเพื่อระบุรูปแบบ โดยรู้จักชนิดเหล่านี้:
| รูปแบบ | ชนิด MIME | ลายเซ็นที่ตรวจสอบ |
|---|---|---|
| PNG | image/png | 89 50 4E 47 0D 0A 1A 0A |
| JPEG | image/jpeg | FF D8 FF |
| GIF | image/gif | GIF87a หรือ GIF89a |
| WebP | image/webp | RIFF ตามด้วยไบต์สี่ไบต์ที่ไม่ใช้ แล้วตามด้วย WEBPVP |
| BMP | image/bmp | BM |
| ICO / CUR | image/x-icon | 00 00 01 00 หรือ 00 00 02 00 |
| SVG | image/svg+xml | ไม่มีลายเซ็น ตรวจพบจากข้อความที่มีแท็ก <svg |
วิธีถอดรหัสรูปภาพ base64
- คัดลอกสตริง base64 พร้อมหรือไม่พร้อมคำนำหน้า
data:image/...จาก HTML, CSS, การตอบกลับของ API หรืออีเมล - วางลงในช่องป้อนข้อมูล
- รูปภาพจะถอดรหัสโดยอัตโนมัติครู่หนึ่งหลังหยุดพิมพ์ หรือโดยกดปุ่มถอดรหัส
- รูปภาพที่ถอดรหัสแล้วจะปรากฏในพื้นที่แสดงตัวอย่าง สามารถคัดลอก data URL ได้ด้วยปุ่ม “คัดลอก URL รูปภาพ” และบันทึกรูปภาพได้โดยคลิกขวาที่รูปภาพในพื้นที่แสดงตัวอย่างแล้วเลือกบันทึกรูปภาพ เนื่องจากรูปภาพจะแสดงเป็นองค์ประกอบรูปภาพปกติในเบราว์เซอร์
การใช้งานทั่วไปของรูปภาพ base64
- การฝังใน HTML, CSS หรือ JavaScript: การใส่ข้อมูลรูปภาพไว้โดยตรงในโค้ดช่วยหลีกเลี่ยงการร้องขอไฟล์แยกต่างหาก
- เทมเพลตอีเมล: โปรแกรมรับส่งอีเมลบางชนิดบล็อกรูปภาพที่เชื่อมโยงจากภายนอกเป็นค่าเริ่มต้น แต่รูปภาพ base64 ที่ฝังไว้ยังคงแสดงได้
- เครื่องมือ HTML แบบไฟล์เดียว: ทั้งหน้าเว็บ รวมถึงรูปภาพ สามารถจัดส่งเป็นไฟล์เดียวที่มีข้อมูลครบในตัว
- การตอบกลับของ API: รูปภาพสามารถส่งอยู่ภายในเพย์โหลด JSON ได้ โดยไม่ต้องมีเอนด์พอยต์แยก
- พื้นหลังและไอคอน CSS: บางครั้งไอคอนขนาดเล็กจะถูกเขียนลงในสไตล์ชีตโดยตรงในรูปแบบ data URL
ข้อแลกเปลี่ยนของรูปภาพ base64
การเข้ารหัส Base64 สะดวก แต่ก็มีต้นทุน:
- ข้อความที่เข้ารหัสแล้วมีขนาดใหญ่กว่าไฟล์ต้นฉบับประมาณหนึ่งในสาม
- เบราว์เซอร์ไม่สามารถแคชรูปภาพที่ฝังไว้แบบเดียวกับไฟล์ที่ลิงก์ได้ จึงต้องดาวน์โหลดใหม่ทุกครั้งที่หน้าเว็บหรือสไตล์ชีตที่ครอบอยู่ถูกดาวน์โหลด
- เบราว์เซอร์ต้องถอดรหัสข้อความ base64 ก่อนจะแสดงรูปภาพได้ ซึ่งใช้การประมวลผลเพิ่มเติมเล็กน้อย
- เนื่องจากขนาดที่เพิ่มขึ้นและการแคชที่หายไป การฝัง base64 จึงเหมาะกับรูปภาพขนาดเล็ก เช่น ไอคอนและโลโก้เรียบง่าย ส่วนภาพถ่ายขนาดใหญ่มักเหมาะกับการให้บริการเป็นไฟล์รูปภาพทั่วไปมากกว่า
คำถามที่พบบ่อย
ตัวถอดรหัสรูปภาพ base64 คืออะไร?
เป็นเครื่องมือที่แปลงสตริงข้อความที่เข้ารหัสด้วย base64 กลับเป็นรูปภาพที่ดูได้ เช่น ไฟล์ PNG, JPEG, GIF, WebP, BMP หรือ SVG
ฉันจะถอดรหัสรูปภาพ base64 ได้อย่างไร?
วางสตริง base64 พร้อมหรือไม่พร้อมคำนำหน้า data:image/... ลงในตัวถอดรหัส ระบบจะอ่านสตริง ถอดรหัส และแสดงรูปภาพผลลัพธ์
สามารถถอดรหัสสตริง base64 โดยไม่มีคำนำหน้า data URL ได้หรือไม่?
ได้ ตัวถอดรหัสจะถือว่าเป็นข้อมูล base64 ดิบ ถอดรหัสไบต์ แล้วอ่านไบต์สองสามไบต์แรกเพื่อระบุรูปแบบจากลายเซ็น เช่น PNG, JPEG, GIF, WebP, BMP หรือ ICO ส่วน SVG จะตรวจหาแท็ก <svg ในข้อความที่ถอดรหัสแล้ว หากไม่ตรงกับรูปแบบใดเลย ตัวถอดรหัสจะแจ้งว่าสตริงนี้ดูเหมือนจะไม่ใช่รูปภาพ แทนที่จะเดารูปแบบ
เหตุใดจึงถอดรหัสรูปภาพ base64 ไม่ได้?
สาเหตุส่วนใหญ่มีสามประการ สตริงอาจมีอักขระนอกชุดอักขระมาตรฐานของ base64 ซึ่งได้แก่ A–Z a–z 0–9 + / และ = ส่วนรูปแบบ base64url ที่ใช้ในโทเค็นเว็บบางชนิดจะใช้ - และ _ แทน และไม่รองรับ สตริงอาจถูกตัดกลางคัน ทำให้ความยาวมากกว่าจำนวนเท่าของสี่อยู่หนึ่ง ซึ่งสตริง base64 ที่ถูกต้องจะไม่มีลักษณะนี้ หรือไบต์อาจไม่ใช่รูปแบบรูปภาพที่รองรับ การขาดตัวเติม = เพียงอย่างเดียวไม่ใช่ปัญหา และช่องว่างหรือการขึ้นบรรทัดใหม่จะถูกลบออกก่อนถอดรหัส
base64 เป็นการรักษาความปลอดภัยหรือการเข้ารหัสลับหรือไม่?
ไม่ใช่ Base64 เป็นเพียงวิธีแทนไบต์ด้วยข้อความ ไม่ได้ซ่อนข้อมูลใด ๆ ทุกคนสามารถถอดรหัสสตริง base64 ได้ภายในไม่กี่วินาทีด้วยเครื่องมือฟรี จึงไม่ควรใช้เพื่อปกป้องรูปภาพส่วนตัวหรือข้อมูลอื่น ๆ
สตริง base64 มีขนาดใหญ่กว่ารูปภาพต้นฉบับเท่าใด?
ไฟล์ขนาดใหญ่จะใหญ่ขึ้นประมาณหนึ่งในสาม เนื่องจากข้อมูลต้นฉบับทุก ๆ 3 ไบต์กลายเป็นอักขระข้อความ 4 ตัว รูปภาพขนาด 100 KB จะมีขนาดประมาณ 133 KB เมื่อเข้ารหัสแล้ว รูปภาพขนาดเล็กอาจมีเปอร์เซ็นต์เพิ่มขึ้นมากกว่าเล็กน้อยเนื่องจากการปัดเศษ
ความเป็นมา
Base64 พัฒนามาจากรูปแบบการเข้ารหัสที่สร้างขึ้นในช่วงทศวรรษ 1970 และ 1980 เพื่อส่งข้อมูลไบนารีผ่านระบบอีเมลที่รองรับเฉพาะข้อความธรรมดา โดยทำให้เป็นมาตรฐานสำหรับอีเมลใน RFC 989 (1987) และต่อมาใน RFC 1421 การใช้งานเพื่อฝังรูปภาพในหน้าเว็บเป็นไปได้เมื่อกำหนดรูปแบบ URL data: ใน RFC 2397 (1998) และแพร่หลายมากขึ้นในช่วงกลางทศวรรษ 2000 เมื่อผู้พัฒนามองหาวิธีลดการร้องขอ HTTP แยกต่างหาก โดยเฉพาะบนการเชื่อมต่อมือถือที่ช้า