เครื่องมือจัดการ padding Base64

อินพุต

ตัวละคร... Enter: (padd) =

อินพุต

ตัวละคร... Enter: (padd) =

ผลลัพธ์

อักขระ =เปลี่ยน] =

คำนวณจำนวน = padding ที่ท้าย Base64 ตามมาตรฐาน RFC 4648 ในเบราว์เซอร์โดยอัตโนมัติ รองรับการเติมหรือลบ padding ทั้งสองทิศทาง แก้ไขสตริง Base64 ที่ไม่ตรงตามข้อกำหนด ทำงานทั้งหมดในเครื่อง

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

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

ถอดรหัส Base64

เครื่องมือล้าง Base64

การจัดรูปแบบ Base64

URL Safe Base64

สถิติความยาว Base64

padding Base64 คืออะไร?

padding Base64 คืออักขระ '=' ที่กำหนดโดยมาตรฐาน RFC 4648 ใช้เพื่อทำให้ความยาวของผลลัพธ์ Base64 เป็นพหุคูณของ 4 Base64 จะแมป 3 ไบต์ (24 บิต) เป็น 4 อักขระ แต่เมื่อไบต์สุดท้ายไม่ครบ 3 ไบต์ จำเป็นต้องเติมด้วย = มิฉะนั้นตัวถอดรหัสจะไม่สามารถระบุจำนวนไบต์จริงที่ท้ายได้

กฎการเติม: ①จำนวนไบต์ดั้งเดิม mod 3 = 0 → ไม่มี = ที่ท้าย; ②mod 3 = 1 → เติม = 2 ตัวที่ท้าย; ③mod 3 = 2 → เติม = 1 ตัวที่ท้าย ผลลัพธ์ของความยาวสตริง Base64 ใดๆ mod 4 ต้องเท่ากับจำนวน = ที่หายไป

ทำไมต้องมี padding: การถอดรหัส Base64 ต้องการขอบเขตที่ชัดเจน padding ทำให้ตัวถอดรหัสรู้ว่า = ที่ท้ายสอดคล้องกับไบต์จริงกี่ไบต์ หลีกเลี่ยงความกำกวม เมื่อไม่มี padding อินพุต 1 ไบต์และ 2 ไบต์อาจถูกเข้ารหัสเป็น Base64 ที่มีความยาวเท่ากัน ทำให้ตัวถอดรหัสระบุจำนวนไบต์ไม่ได้

การใช้งานจริง: โปรโตคอลส่วนใหญ่ (Data URL, MIME, JWT, ไฟล์การตั้งค่า) ปฏิบัติตาม padding อย่างเคร่งครัด; บางสถานการณ์ (เส้นทาง URL, ชื่อไฟล์, ลิงก์สั้น) จะละ padding เพื่อประหยัดพื้นที่ เครื่องมือนี้รองรับการแปลงทั้งสองทิศทาง

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

ซ่อมแซมข้อผิดพลาดการถอดรหัส base64 (เช่น InvalidCharacterError หรือความยาวไม่ใช่พหุคูณของ 4) โดยเติม = ก่อนแล้วจึงถอดรหัส
จัดการเอาต์พุต Base64 จาก API, JWT, บันทึก โดยลบการขึ้นบรรทัดใหม่ที่เกินและเติม padding ที่หายไป
เมื่อสร้าง Data URL ต้องแน่ใจว่าส่วน Base64 เป็นไปตาม RFC 4648 อย่างเคร่งครัด เพื่อหลีกเลี่ยงการถอดรหัสล้มเหลวในเบราว์เซอร์หรือเครื่องมือของบุคคลที่สาม
ตรวจสอบและเติม padding อย่างรวดเร็วสำหรับ JWT token, ไฟล์การตั้งค่า, ข้อมูลรับรอง API
ลบ padding สำหรับ URL, ชื่อไฟล์ เพื่อประหยัดอักขระ (ภายใต้เงื่อนไขที่โปรโตคอลรองรับ)
เมื่อเรียนรู้หลักการเข้ารหัส Base64 เปรียบเทียบความสัมพันธ์ระหว่างจำนวนไบต์อินพุตกับจำนวน padding

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

วางหรือพิมพ์สตริง Base64 ที่ต้องการจัดการ (อาจมีหรือไม่มี padding, การขึ้นบรรทัดใหม่)
เลือกโหมด: เติม padding (เพิ่ม = ที่ท้าย) หรือลบ padding (ลบ = ที่ท้าย)
เครื่องมือจะคำนวณและแสดงผลลัพธ์โดยอัตโนมัติ พร้อมแสดงจำนวนอักขระและการเปลี่ยนแปลงของ padding แบบเรียลไทม์
คัดลอกผลลัพธ์ไปยังคลิปบอร์ด หรือดาวน์โหลดเป็นไฟล์ .txt เพื่อนำไปใช้ต่อ

คุณสมบัติ

คำนวณจำนวน padding อัตโนมัติ: แสดงความแตกต่างระหว่างจำนวน = ที่ควรมีกับที่มีอยู่แบบเรียลไทม์
โหมดเติม padding: เติมสตริง Base64 ใดๆ ให้มีความยาวเป็นพหุคูณของ 4 ซ่อมแซมข้อผิดพลาดของความยาวได้ทันที
โหมดลบ padding: ลบอักขระ = ที่ท้าย เหมาะกับสถานการณ์ที่ต้องประหยัดอักขระ เช่น URL และชื่อไฟล์
ข้ามการขึ้นบรรทัดใหม่และช่องว่างอัตโนมัติ: วาง Base64 ที่มีการขึ้นบรรทัดใหม่ (จากอีเมล เอาต์พุต JWT) ก็จัดการได้ถูกต้อง
นับอักขระแบบเรียลไทม์: แสดงจำนวนอักขระอินพุต เอาต์พุต และจำนวน padding ที่เพิ่มหรือลด
คัดลอก/ดาวน์โหลดได้ทันที: คัดลอกผลลัพธ์ไปยังคลิปบอร์ดหรือดาวน์โหลดเป็นไฟล์ .txt ได้
ประมวลผลในเบราว์เซอร์ท้องถิ่น: การคำนวณทั้งหมดทำในเบราว์เซอร์ เนื้อหาต้นฉบับไม่ถูกอัปโหลดไปยังเซิร์ฟเวอร์ใดๆ

Best Practices

ยืนยันว่าอินพุตเป็น Base64 จริงก่อนเติม

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

Data URL และ JWT ต้องเติม padding เสมอ

ทั้ง Data URL (RFC 2397) และ JWT (RFC 7519) ต้องการ padding อย่างเคร่งครัด การละ = จะทำให้เกิดข้อผิดพลาดในการถอดรหัสหรือผลลัพธ์ไม่สอดคล้องกันในการใช้งานส่วนใหญ่ โปรดใช้เครื่องมือนี้เติมให้เป็นพหุคูณของ 4 ก่อนส่ง

URL/ชื่อไฟล์สามารถละ padding ได้ แต่ต้องใช้ชุดอักขระ URL-safe คู่กัน

หากต้องการใส่ Base64 ในเส้นทาง URL, ชื่อไฟล์ หรือลิงก์สั้น การลบ padding อย่างเดียวไม่พอ ต้องแทนที่ + และ / ด้วย - และ _ (Base64URL) ด้วย การละ = เพียงอย่างเดียวยังคงเป็น Base64 มาตรฐาน + และ / ยังผิดกฎหมายใน URL

หากถอดรหัสล้มเหลวหลังลบ padding ด้วย "ความยาวไม่ถูกต้อง"

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

ไฟล์ขนาดใหญ่แนะนำให้แบ่งก่อนประมวลผล

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

อย่าลืมแนบการคำนวณ padding เมื่อแสดงในการสอนหรือเอกสาร

padding Base64 เป็นจุดที่ผู้เริ่มต้นสับสนมากที่สุด เมื่ออธิบายต้องแนบตารางเปรียบเทียบ "จำนวนไบต์อินพุต mod 3 = เศษ สอดคล้องกับการเติม = กี่ตัว" (ดู referenceTables ในหน้านี้) มิฉะนั้นนักเรียนจะเข้าใจยากว่าทำไมบางครั้งต้องเติม 1 ตัว บางครั้งต้องเติม 2 ตัว

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

padding Base64 มีประโยชน์อย่างไร?

ทำให้ความยาวเอาต์พุต Base64 เป็นพหุคูณของ 4 เสมอ ให้ตัวถอดรหัสมีขอบเขตสิ้นสุดที่ชัดเจน เมื่อไม่มี padding อินพุต 1 ไบต์และ 2 ไบต์อาจถูกเข้ารหัสเป็นอักขระที่มีความยาวเท่ากัน ตัวถอดรหัสไม่สามารถแยกแยะจำนวนไบต์ดั้งเดิมได้

ทำไมความยาว Base64 ต้องเป็นพหุคูณของ 4?

เพราะ Base64 แมป 3 ไบต์เป็น 4 อักขระ ทุกกลุ่มมีอัตราส่วนคงที่ 3→4 เมื่ออินพุตไม่ใช่พหุคูณของ 3 จำเป็นต้องเติม = ที่ท้ายเพื่อให้ครบ 4 อักขระ Base64 ที่ไม่ใช่พหุคูณของ 4 ถือว่าไม่ถูกต้องตามกฎหมาย

จะคำนวณจำนวน padding ได้อย่างไร?

สูตรคือ (4 - จำนวนไบต์อินพุต % 3) % 3 หรือดูจำนวนอักขระ Base64 mod 4 โดยตรง: เศษ 0 สอดคล้องกับ = 0 ตัว, เศษ 2 สอดคล้องกับ = 1 ตัว, เศษ 3 สอดคล้องกับ = 2 ตัว เครื่องมือนี้จะคำนวณให้อัตโนมัติ

สามารถลบ padding ได้หรือไม่?

ลบได้ แต่ต้องทำเมื่อโปรโตคอลรองรับเท่านั้น เช่น ชื่อไฟล์, เส้นทาง URL, JSON Web Token ในบางการใช้งานยอมรับ Base64 ที่ไม่มี padding แต่ Data URL, MIME, ไฟล์การตั้งค่ามักต้องการอย่างเคร่งครัด ใช้โหมดลบ padding ของเครื่องมือนี้เมื่อยืนยันแล้วว่าโปรโตคอลรองรับเท่านั้น

การถอดรหัส Base64 แจ้งว่า "ความยาวไม่ใช่พหุคูณของ 4" ต้องทำอย่างไร?

เปลี่ยนเป็นโหมดเติม padding ของเครื่องมือนี้ เพิ่ม = ที่ท้ายทันที หากยังรายงานข้อผิดพลาดหลังเติม แสดงว่าอินพุตมีอักขระที่ผิดกฎหมายหรือถูกตัดทอน ต้องใช้เครื่องมือทำความสะอาด Base64 ตรวจสอบก่อน

การเติม padding จะเปลี่ยนไบต์ดั้งเดิมหรือไม่?

ไม่เปลี่ยน การเติมเป็นเพียงการเพิ่ม = ที่ท้ายเท่านั้น ไม่แก้ไขอักขระตรงกลาง ดังนั้นไบต์ดั้งเดิมจึงยังคงอยู่ครบถ้วน ไบต์หลังถอดรหัสจะตรงกับข้อมูลต้นฉบับ

รองรับ Base64 ที่มีการขึ้นบรรทัดใหม่หรือช่องว่างหรือไม่?

รองรับ เครื่องมือนี้จะลบการขึ้นบรรทัดใหม่, การขึ้นต้นบรรทัด และช่องว่างโดยอัตโนมัติก่อนคำนวณ padding Base64 หลายบรรทัดจากไฟล์แนบอีเมล, เอาต์พุต JWT, ไฟล์การตั้งค่า สามารถวางได้โดยตรง

padding Base64 กับ Base64URL เป็นเรื่องเดียวกันหรือไม่?

ไม่ใช่ padding Base64 เป็นปัญหาเกี่ยวกับอักขระ = ที่ท้าย; Base64URL เป็นปัญหาเกี่ยวกับชุดอักขระ (ใช้ - แทน +, ใช้ _ แทน /) เครื่องมือนี้จัดการเฉพาะ padding หากต้องการแปลงเป็น URL-safe โปรดใช้เครื่องมือ Base64URL เฉพาะ

เนื้อหาจะถูกอัปโหลดไปยังเซิร์ฟเวอร์หรือไม่?

ไม่ การคำนวณ padding ทั้งหมดทำในเบราว์เซอร์ท้องถิ่น สตริง Base64 ต้นฉบับจะไม่ออกจากอุปกรณ์ของคุณ สามารถใช้กับข้อมูลอ่อนไหว (ข้อมูลรับรอง, token) ได้อย่างสบายใจ

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

การถอดรหัสแจ้งว่า "ความยาวไม่ใช่พหุคูณของ 4"

ใช้โหมดเติม padding ของเครื่องมือนี้เติม = แล้วจึงถอดรหัส หากยังรายงานข้อผิดพลาด แสดงว่าอินพุตมีอักขระที่ผิดกฎหมาย ขอแนะนำให้ตรวจสอบด้วยเครื่องมือทำความสะอาด Base64 ก่อน

สงสัยว่าอินพุตมีอักขระที่ไม่ถูกต้องปะปน

Base64 มาตรฐานมีเพียง A-Z a-z 0-9 + / = อักขระอื่นใด (อักษรไทยหรืออักขระนอกชุดตัวอักษรละติน, ช่องว่าง, สัญลักษณ์นอกเหนือจากการขึ้นบรรทัดใหม่) ถือว่าผิดกฎหมาย เครื่องมือนี้จะข้ามการขึ้นบรรทัดใหม่และช่องว่างโดยอัตโนมัติ แต่อักขระที่ผิดกฎหมายอื่นๆ ต้องใช้เครื่องมือทำความสะอาด Base64 ก่อน

URL ยังรายงานข้อผิดพลาดหลังลบ padding

อาจเป็นเพราะ URL ยังมีอักขระที่ต้องเข้ารหัส URL เช่น ? & = หรือมีสัญลักษณ์ในชุดอักขระ Base64 เช่น + / การลบ padding ไม่เท่ากับ URL-safe ต้องแปลงด้วย Base64URL หรือเข้ารหัส URL อีกครั้ง

ไม่มีผลลัพธ์หลังวาง

อาจเป็นเพราะอินพุตเป็นอักขระว่างทั้งหมด (การขึ้นบรรทัดใหม่, ช่องว่าง, Tab) เครื่องมือจะละอักขระเหล่านี้ในการคำนวณ แต่อินพุตที่ว่างทั้งหมดจะไม่ทริกเอาต์พุต โปรดป้อนอักขระ Base64 อย่างน้อยหนึ่งตัว

อภิธานศัพท์

อักขระ padding =: อักขระเติมท้าย Base64 ที่กำหนดโดยมาตรฐาน RFC 4648 ใช้ระบุจำนวนไบต์จริงที่หายไป padding ที่ถูกต้องจะปรากฏที่ท้ายสตริงเท่านั้น
พหุคูณของ 4: ความยาวของผลลัพธ์ Base64 ตามมาตรฐาน RFC 4648 ต้องเป็นพหุคูณของ 4 มิฉะนั้นจะถือว่าเป็นการเข้ารหัสที่ไม่ถูกต้อง โหมด Base64 แบบเข้มงวดจะรายงานข้อผิดพลาดทันทีเมื่อถอดรหัส
สูตรคำนวณ padding: จำนวน = ที่ต้องการ = (4 - จำนวนไบต์อินพุต % 3) % 3; เทียบเท่ากับดูจำนวนอักขระ Base64 mod 4 ผลลัพธ์ 0/2/1 สอดคล้องกับ = 0/1/2 ตัว
Base64 แบบไม่มี padding: ตัวแปร Base64 ที่ละ = ท้ายออก พบได้บ่อยในเส้นทาง URL และชื่อไฟล์ แต่ไม่ตรงตามมาตรฐาน RFC 4648 อย่างเคร่งครัด อาจถอดรหัสไม่สำเร็จในบางโปรโตคอล
ชุดอักขระ Base64: A-Z, a-z, 0-9, +, / รวม 64 อักขระ บวก = สำหรับ padding อักขระอื่นใดถือว่าไม่ถูกต้อง ต้องใช้เครื่องมือทำความสะอาด Base64 ก่อน

ตารางค้นหากฎ padding Base64 ฉบับย่อ

ความสัมพันธ์ระหว่างจำนวนไบต์อินพุต Base64 กับจำนวน = padding ที่ท้าย

จำนวนไบต์อินพุต	mod 3	จำนวนอักขระ Base64	จำนวน = padding	ตัวอย่าง (อินพุต→เอาต์พุต)
`3n`	0	`4n`	0	ABC → QUJD
`3n+1`	1	`4n+2`	2	AB → QUI=
`3n+2`	2	`4n+3`	1	A → QQ==

ข้อกำหนด padding ของโปรโตคอลทั่วไป

โปรโตคอลต่างๆ มีข้อกำหนดเกี่ยวกับ = padding ต่างกัน การละผิดจะทำให้ถอดรหัสไม่สำเร็จ

สถานการณ์การใช้งาน	ต้องการ padding หรือไม่	การใช้งานทั่วไป
`Data URL (RFC 2397)`	แนะนำ (เพื่อความเข้ากันได้)	HTML / CSS / การฝังรูปภาพ
`JWT (RFC 7519)`	ต้องการ (เข้มงวด)	OAuth / การยืนยันตัวตน API
`MIME (RFC 2045)`	ต้องการ	การเข้ารหัสไฟล์แนบอีเมล
`เส้นทาง URL / ชื่อไฟล์`	ไม่จำเป็น (มักละ)	ลิงก์สั้น / คีย์แคช
`ไฟล์การตั้งค่า (YAML / JSON)`	ต้องการ	การจัดเก็บข้อมูลรับรองและลายเซ็น