เหตุใดจึงไม่ใช้ base128 [ปิด]

เหตุใดจึงใช้เฉพาะ base64 แทนที่จะเป็น base128 ในการส่งข้อมูลไบนารีบนเว็บ ชุดอักขระ ASCII มีอักขระ 128 ตัวซึ่งในทางทฤษฎีสามารถแสดงถึงฐาน 128 แต่ส่วนใหญ่จะใช้เฉพาะ base64 แต่ไม่ได้ใช้ base128

ปัญหาคืออย่างน้อย 32 อักขระของชุดอักขระ ASCII เป็น 'อักขระควบคุม' ซึ่งอาจถูกตีความโดยเทอร์มินัลรับ เช่นมีอักขระ BEL (กระดิ่ง) ที่ทำให้เทอร์มินัลกระดิ่งรับ มีตัวอักษร SOT (Start Of Transmission) และ EOT (End Of Transmission) ซึ่งแสดงถึงชื่อของพวกเขา และอย่าลืมอักขระ CR และ LF ซึ่งอาจมีความหมายพิเศษในการทำให้โครงสร้างข้อมูลต่อเนื่อง / แบนลงในสตรีม

Adobe สร้างการเข้ารหัส Base85เพื่อใช้อักขระเพิ่มเติมในชุดอักขระ ASCII แต่ AFAIK ได้รับการคุ้มครองโดยสิทธิบัตร

เนื่องจากอักขระ 128 ตัวบางตัวไม่สามารถพิมพ์ได้ (ส่วนใหญ่เป็นอักขระที่ต่ำกว่าจุดรหัส 0x20) ดังนั้นจึงไม่สามารถส่งเป็นสตริงผ่านสายได้อย่างน่าเชื่อถือ และถ้าคุณอยู่เหนือ codepoint 128 คุณอาจมีปัญหาในการเข้ารหัสเนื่องจากการเข้ารหัสที่แตกต่างกันที่ใช้ในระบบต่างๆ

ตามที่ระบุไว้แล้วในคำตอบอื่นประเด็นสำคัญคือการลดชุดอักขระให้เป็นแบบที่สามารถพิมพ์ได้ รูปแบบการเข้ารหัสที่มีประสิทธิภาพมากขึ้นคือbasE91เนื่องจากใช้ชุดอักขระที่ใหญ่กว่าและยังคงหลีกเลี่ยงอักขระควบคุม / เว้นวรรคในช่วง ASCII ที่ต่ำ หน้าเว็บมีการเปรียบเทียบประสิทธิภาพการเข้ารหัสแบบไบนารีกับ base64 เทียบกับbasE91

ฉันเคยล้างการใช้งาน Java หากผู้คนสนใจฉันสามารถส่งมันไปที่ GitHub

อัพเดท : ก็ตอนนี้บน GitHub

อักขระ 32 ตัวแรกเป็นอักขระควบคุมไม่มีความเกี่ยวข้องอย่างแน่นอนเพราะคุณไม่จำเป็นต้องใช้อักขระเหล่านี้เพื่อรับอักขระ 128 ตัว เรามีอักขระ 256 ตัวให้เลือกและมีเพียง 32 ตัวแรกเท่านั้นที่เป็นอักขระควบคุม ซึ่งทำให้เหลือ 192 อักขระดังนั้น 128 จึงเป็นไปได้อย่างสมบูรณ์โดยไม่ต้องใช้อักขระควบคุม

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

นั่นคือเหตุผล!

Base64 เป็นเรื่องปกติเพราะสามารถแก้ปัญหาได้หลากหลาย (ทำงานได้เกือบทุกที่ที่คุณนึกออก)

• คุณไม่จำเป็นต้องกังวลว่าการขนส่งจะสะอาดแบบ 8 บิตหรือไม่

• สามารถพิมพ์อักขระทั้งหมดในการเข้ารหัสได้ คุณสามารถดูได้ คุณสามารถคัดลอกและวางได้ คุณสามารถใช้ใน URL (ตัวแปรเฉพาะ) เป็นต้น

• ขนาดการเข้ารหัสคงที่ คุณทราบดีว่าmไบต์สามารถเข้ารหัสเป็นnไบต์ได้เสมอ

• ทุกคนเคยได้ยินเรื่องนี้ - ได้รับการสนับสนุนอย่างกว้างขวางมีห้องสมุดจำนวนมากจึงทำงานร่วมกันได้ง่าย

Base128 ไม่มีข้อดีทั้งหมด

ดูเหมือนว่าจะสะอาด 8 บิต - แต่จำได้ว่า base64 ใช้ 65 สัญลักษณ์ หากไม่มีอักขระนอกแบนด์คุณจะไม่สามารถใช้ประโยชน์จากขนาดการเข้ารหัสที่คงที่ได้ หากคุณใช้ตัวละครนอกวงคุณจะไม่สามารถทำความสะอาดแบบ 8 บิตได้อีกต่อไป

ไม่ใช่เชิงลบทั้งหมด

• base128 เข้ารหัส / ถอดรหัสได้ง่ายกว่า base64 - คุณแค่ใช้กะและมาสก์ อาจมีความสำคัญสำหรับการใช้งานแบบฝัง

• base128 ใช้การขนส่งอย่างมีประสิทธิภาพมากกว่า base64 เล็กน้อยโดยใช้บิตที่มีให้มากขึ้น

คนทำใช้ base128 - ฉันใช้มันสำหรับบางสิ่งบางอย่างในขณะนี้ มันไม่ธรรมดาเหมือนกัน

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

esaji พูดถูก Base64 ใช้ในการเข้ารหัสข้อมูลไบนารีสำหรับการส่งโดยใช้โปรโตคอลที่คาดหวังเฉพาะข้อความ ในรายการWiki

ชำระเงิน base128 PHP-Class การเข้ารหัสและถอดรหัสด้วยชุดอักขระ ISO 8859-1

GoogleCode PHP-Class Base128