เข้ารหัส / ถอดรหัส Base64
แปลงข้อความเป็น Base64 และถอดรหัสกลับในเบราว์เซอร์ของคุณ ปลอดภัยกับ UTF-8 พร้อมตัวเลือก URL-safe โดยไม่มีการอัปโหลดข้อมูลใด ๆ ไปยังเซิร์ฟเวอร์
อินพุต
0 บรรทัด · 0 อักขระ
โหมด
URL-safe
วิธีใช้ เข้ารหัส / ถอดรหัส Base64
- 1
เลือก Encode หรือ Decode
ตั้งโหมดเป็น Encode เพื่อแปลงข้อความเป็น Base64 หรือ Decode เพื่อแปลงสตริง Base64 กลับเป็นข้อความที่อ่านได้
- 2
ป้อนข้อมูลของคุณ
พิมพ์หรือวางข้อความหรือ Base64 ลงในแผงป้อนข้อมูล และหากต้องการ ให้เปิด URL-safe สำหรับชุดอักขระที่เหมาะกับ URL และชื่อไฟล์
- 3
แปลง
คลิก Convert เพื่อประมวลผลข้อมูลในเครื่องในเบราว์เซอร์ของคุณ พร้อมรองรับ UTF-8 และอีโมจิอย่างเต็มที่
- 4
คัดลอกหรือสลับ
คัดลอกผลลัพธ์ หรือใช้ Swap เพื่อย้ายผลลัพธ์กลับไปที่ช่องป้อนข้อมูลและสลับโหมดเพื่อแปลงไป-กลับอย่างรวดเร็ว
คู่มือฉบับสมบูรณ์สำหรับการเข้ารหัส Base64
Base64 คืออะไรกันแน่
Base64 เป็นรูปแบบการเข้ารหัสจากไบนารีไปเป็นข้อความ กล่าวคือมันแทนข้อมูลไบนารีใด ๆ ก็ได้โดยใช้อักขระ ASCII ที่พิมพ์ได้เพียง 64 ตัว ซึ่งสามารถผ่านการส่งผ่านระบบที่สร้างมาสำหรับข้อความล้วนได้โดยไม่เสียหาย ชุดอักขระมาตรฐานที่นิยามไว้ใน RFC 4648 ประกอบด้วยตัวพิมพ์ใหญ่ 26 ตัว A-Z, ตัวพิมพ์เล็ก 26 ตัว a-z, ตัวเลขสิบตัว 0-9 และสัญลักษณ์สองตัวคือ + และ / รวมเป็น 64 สัญลักษณ์ ซึ่งเพียงพอพอดีสำหรับแทนข้อมูลหกบิตต่อหนึ่งอักขระ เพราะสองยกกำลังหกเท่ากับ 64
ชื่อของมันมีความหมายตรงตัว เช่นเดียวกับที่ฐานสิบใช้สัญลักษณ์ตัวเลขสิบตัวและฐานสิบหก (เลขฐานสิบหก) ใช้สิบหกตัว ฐาน 64 ก็ใช้หกสิบสี่ตัว การเข้ารหัสนี้ย้อนกลับได้อย่างสมบูรณ์และไม่สูญเสียข้อมูล ไบต์ใดก็ตามที่คุณเข้ารหัสจะกลับมาเหมือนเดิมทุกไบต์เมื่อคุณถอดรหัส ซึ่งนั่นคือจุดประสงค์ทั้งหมดของมัน
ทำไม Base64 จึงมีอยู่
ช่องทางจำนวนมากถูกออกแบบมาเพื่อส่งข้อความ ไม่ใช่ไบต์ดิบ ๆ และมันจะทำให้สิ่งใดก็ตามที่อยู่นอกช่วง ASCII ที่พิมพ์ได้เสียหาย อีเมลเป็นตัวอย่างคลาสสิก มาตรฐาน SMTP ดั้งเดิมเป็นโปรโตคอลแบบเจ็ดบิตที่อาจทำให้บิตสูงสุดของข้อมูลไบนารีเสียหายหรือถูกตัดทิ้ง ดังนั้น MIME จึงใช้ Base64 เพื่อส่งไฟล์แนบรูปภาพและไฟล์ต่าง ๆ ได้อย่างปลอดภัย ปัญหาเดียวกันนี้ปรากฏขึ้นทุกครั้งที่ข้อมูลไบนารีต้องเดินทางอยู่ภายในสิ่งที่เป็นข้อความ
คุณพบ Base64 อยู่ตลอดเวลาโดยไม่ทันสังเกต Data URI ฝังรูปภาพไว้ใน HTML และ CSS โดยตรงในรูปแบบ data:image/png;base64,iVBORw0K... เพื่อให้ไอคอนขนาดเล็กไม่ต้องร้องขอแยกต่างหาก JSON Web Token (JWT) คือสามส่วน Base64url ที่เชื่อมต่อกันด้วยจุด ส่วนการยืนยันตัวตนแบบ HTTP Basic ส่ง Base64 ของ username:password เบราว์เซอร์เปิดให้ใช้งานผ่านฟังก์ชันในตัวคือ btoa และ atob และมันเป็นวิธีมาตรฐานในการยัดข้อมูลไบนารีลงใน JSON, XML หรือ URL
การจับคู่ 3 ไบต์เป็น 4 อักขระทำงานอย่างไร
Base64 ประมวลผลข้อมูลนำเข้าครั้งละสามไบต์ สามไบต์เท่ากับ 24 บิต และ 24 หารลงตัวเป็นสี่กลุ่ม กลุ่มละหกบิต แต่ละกลุ่มหกบิตคือตัวเลขตั้งแต่ 0 ถึง 63 ซึ่งกลายเป็นหนึ่งอักขระจากชุดอักขระ ดังนั้นทุก 3 ไบต์ของข้อมูลนำเข้าจึงให้ผลลัพธ์เป็น 4 อักขระเสมอ ซึ่งเป็นเหตุที่ Base64 ทำให้ข้อมูลพองขึ้นราวหนึ่งในสาม นั่นคือรูปแบบที่เข้ารหัสแล้วมีขนาดประมาณ 133% ของต้นฉบับ
ตำแหน่งในชุดอักขระคือสิ่งสำคัญ ดัชนี 0 คือ A, ดัชนี 25 คือ Z, ดัชนี 26 คือ a, ดัชนี 51 คือ z, ดัชนี 52 คือ 0, ดัชนี 61 คือ 9, ดัชนี 62 คือ + และดัชนี 63 คือ / ในการอ่านสตริงที่เข้ารหัสแล้วด้วยมือ คุณจับคู่อักขระแต่ละตัวกลับไปเป็นดัชนีของมัน เขียนดัชนีนั้นเป็นหกบิต เชื่อมบิตทั้งหมดเข้าด้วยกัน แล้วหั่นสายข้อมูลกลับเป็นไบต์ละแปดบิต
ตัวอย่างประกอบ: การเข้ารหัส "Man"
ลองนำตัวอักษรสามตัว M, a, n มาพิจารณา ค่าไบต์ ASCII ของพวกมันคือ 77, 97 และ 110 ซึ่งในเลขฐานสองคือ 01001101, 01100001 และ 01101110 เชื่อม 24 บิตเหล่านั้นเข้าด้วยกันเป็นสายเดียว: 010011010110000101101110 จากนั้นหั่นมันเป็นสี่กลุ่ม กลุ่มละหกบิต: 010011, 010110, 000101, 101110
กลุ่มเหล่านั้นคือตัวเลข 19, 22, 5 และ 46 เมื่อค้นหาแต่ละค่าในชุดอักขระจะได้ T (ดัชนี 19), W (ดัชนี 22), F (ดัชนี 5) และ u (ดัชนี 46) ดังนั้น "Man" จึงเข้ารหัสเป็น "TWFu" ซึ่งเป็นการแปลงสามไบต์เป็นสี่อักขระอย่างหมดจดโดยไม่ต้องเติม การถอดรหัสก็เพียงดำเนินขั้นตอนเหล่านี้ย้อนกลับ
การเติม (Padding) และเครื่องหมายเท่ากับ
ข้อมูลนำเข้าไม่ได้เป็นจำนวนเท่าของสามไบต์เสมอไป ดังนั้น Base64 จึงต้องมีวิธีส่งสัญญาณบอกเศษที่เหลือ เมื่อเหลือหนึ่งไบต์ มันจะเข้ารหัสเป็นสองอักขระตามด้วยเครื่องหมายเติมสองตัว (==) เมื่อเหลือสองไบต์ มันจะเข้ารหัสเป็นสามอักขระตามด้วยเครื่องหมายเติมหนึ่งตัว (=) อักขระเติมไม่ได้บรรจุข้อมูลใด ๆ มันเพียงบอกตัวถอดรหัสว่ากลุ่มสุดท้ายแทนไบต์จริงกี่ไบต์
ตัวอย่างเช่น ตัวอักษรเดี่ยว "M" (ไบต์ 77, เลขฐานสอง 01001101) ถูกเติมให้เป็นหกบิตได้เป็น 010011 และ 010000 ซึ่งให้ T และ Q จากนั้นเติมให้สมบูรณ์ด้วย == เป็น "TQ==" ส่วนคำว่า "Ma" (สองไบต์) เข้ารหัสเป็น "TWE=" ด้วยเครื่องหมายเท่ากับท้ายตัวเดียว การนับจำนวนเครื่องหมายเท่ากับที่ท้ายของสตริง Base64 ใด ๆ จะบอกคุณได้ว่าความยาวต้นฉบับเป็นจำนวนเท่าของสามหรือไม่
รูปแบบ URL-safe
อักขระมาตรฐาน + และ / สร้างปัญหาในที่ที่พวกมันมีความหมายอยู่แล้ว เครื่องหมายทับแบ่งส่วนพาธใน URL และเครื่องหมายบวกถูกตีความว่าเป็นช่องว่างในสตริงคิวรีที่เข้ารหัสแบบฟอร์ม ดังนั้นค่า Base64 ปกติจึงอาจพังได้เมื่อถูกวางลงในลิงก์หรือชื่อไฟล์ ชุดอักขระแบบ URL-safe ซึ่งมาจาก RFC 4648 เช่นกัน แก้ปัญหานี้ด้วยการสลับ + เป็น - (ยัติภังค์) และ / เป็น _ (ขีดล่าง)
การเปิดตัวเลือก URL-safe ในเครื่องมือนี้จะให้ผลลัพธ์เป็นรูปแบบนั้น และยังตัดเครื่องหมายเติม = ที่ท้ายออกด้วย เนื่องจากเครื่องหมายเท่ากับก็จำเป็นต้องหลีกใน URL เช่นกัน ผลลัพธ์จึงเสียบเข้าไปในพารามิเตอร์คิวรี ส่วนพาธ คุกกี้ และชื่อไฟล์ได้โดยตรง นี่คือการเข้ารหัสที่ JWT และ web API จำนวนมากใช้ เพียงจำไว้ว่าต้องถอดรหัสข้อมูลนำเข้าแบบ URL-safe ด้วยตัวถอดรหัสแบบ URL-safe เพราะอักขระ - และ _ ไม่ถูกต้องในชุดอักขระมาตรฐาน
Base64 คือการเข้ารหัส ไม่ใช่การเข้ารหัสลับ
นี่คือข้อเท็จจริงเดียวที่สำคัญที่สุดและถูกเข้าใจผิดมากที่สุดเกี่ยวกับ Base64 การเข้ารหัสทำให้ข้อมูลกำกวมเพียงต่อตาเปล่าเท่านั้น มันไม่ให้ความลับใด ๆ เลย ไม่มีกุญแจและไม่มีความลับ ดังนั้นใครก็ตามจึงสามารถถอดรหัสสตริง Base64 ได้ทันทีด้วยเครื่องมือใดก็ได้ รวมถึงเครื่องมือนี้ด้วย การมองว่า Base64 เป็นวิธีซ่อนรหัสผ่าน กุญแจ API หรือข้อมูลส่วนบุคคล ถือเป็นความผิดพลาดด้านความปลอดภัยที่ร้ายแรง
Base64 แก้ปัญหาการขนส่ง ไม่ใช่ปัญหาความลับ มันทำให้ไบนารีเคลื่อนผ่านช่องทางที่รับเฉพาะข้อความได้อย่างปลอดภัย หากคุณต้องการการปกป้องที่แท้จริง ให้เข้ารหัสลับข้อมูลด้วยอัลกอริทึมจริงเช่น AES ก่อน แล้วจึงเข้ารหัสด้วย Base64 กับข้อความที่เข้ารหัสลับแล้วเฉพาะเมื่อคุณต้องการให้มันเดินทางในรูปข้อความเท่านั้น การเข้ารหัสและการเข้ารหัสลับเป็นงานคนละอย่างกัน
ข้อผิดพลาดที่พบบ่อยและเคล็ดลับที่ใช้ได้จริง
ข้อผิดพลาดที่พบบ่อยที่สุดคือความสับสนเรื่องชุดอักขระ ตัว Base64 เองรู้จักเพียงไบต์เท่านั้น ดังนั้นก่อนที่คุณจะเข้ารหัสข้อความได้ คุณต้องตัดสินใจก่อนว่าข้อความนั้นจะกลายเป็นไบต์ได้อย่างไร เครื่องมือนี้ใช้ UTF-8 ซึ่งเป็นเหตุที่ตัวอักษรมีเครื่องหมายและอีโมจิย้อนกลับได้อย่างถูกต้อง การเข้ารหัสสตริงเดียวกันเป็นชุดอักขระอื่นในที่อื่นจะให้ Base64 ที่แตกต่างออกไป กับดักที่พบบ่อยอย่างที่สองคือช่องว่าง การขึ้นบรรทัดใหม่ที่ตัวเข้ารหัสบางตัวแทรกเข้ามา (MIME ตัดบรรทัดที่ 76 อักขระ) ไม่ใช่ส่วนหนึ่งของข้อมูลและต้องถูกตัดออกก่อนการถอดรหัส แม้ว่าตัวถอดรหัสที่เคร่งครัดอาจปฏิเสธมันก็ตาม
กับดักอื่น ๆ ได้แก่ การปนกันระหว่างชุดอักขระมาตรฐานและแบบ URL-safe, การลืมว่าสตริงที่ไม่ได้เติมอาจจำเป็นต้องเรียกคืนการเติมก่อนที่ตัวถอดรหัสที่เคร่งครัดจะยอมรับมัน และการเข้าใจไปเองว่า Base64 ช่วยประหยัดพื้นที่ ทั้งที่มันไม่เคยทำเลย มันทำให้ข้อมูลโตขึ้นราวหนึ่งในสามเสมอ เมื่อการถอดรหัสล้มเหลวที่นี่ ให้ตรวจสอบก่อนเลยว่ามีช่องว่างหลงเหลืออยู่ เครื่องหมายเท่ากับขาดหายไป หรือมี - หรือ _ ที่เป็นของชุดอักขระแบบ URL-safe หรือไม่
คำถามที่พบบ่อย
Encode กับ Decode ในนี้ต่างกันอย่างไร
ตัวเลือก URL-safe ทำอะไร
มันรองรับอีโมจิและอักขระที่ไม่ใช่ภาษาอังกฤษหรือไม่
จะเกิดอะไรขึ้นหากฉันวาง Base64 ที่ไม่ถูกต้องขณะ decode
ข้อมูลของฉันถูกส่งไปที่ไหนหรือไม่
เครื่องมือที่เกี่ยวข้อง
ทำงานต่อด้วยเครื่องมือที่มีประโยชน์เหล่านี้