เหตุใดจึงมีการเข้ารหัส Unicode หลายตัว

ฉันคิดว่า Unicode ได้รับการออกแบบมาเพื่อแก้ไขปัญหาทั้งหมดของการเข้ารหัสที่แตกต่างกันมากมายเนื่องจากพื้นที่ที่อยู่ขนาดเล็ก (8 บิต) ในการพยายามก่อนหน้าส่วนใหญ่ (ASCII ฯลฯ )

ทำไมจึงมีการเข้ารหัส Unicode จำนวนมาก แม้แต่รุ่นเดียวกัน (เป็นหลัก) หลายรุ่นเช่น UTF-8, UTF-16 เป็นต้น

เพราะคนไม่ต้องการใช้ 21 บิตกับตัวละครแต่ละตัว ในระบบที่ทันสมัยทั้งหมดนี้จะหมายถึงการใช้สามไบต์ต่อตัวอักษรซึ่งมากกว่าสามเท่าของคนที่คุ้นเคยดังนั้นพวกเขาจึงไม่อยากใช้ Unicode เลย ต้องพบการประนีประนอม: เช่น UTF-8 ดีมากสำหรับข้อความภาษาอังกฤษเพราะไฟล์ ASCII ดั้งเดิมไม่จำเป็นต้องแปลงเลย แต่มันมีประโยชน์น้อยกว่าสำหรับภาษายุโรปและใช้น้อยสำหรับภาษาเอเชีย

โดยพื้นฐานแล้วใช่เราสามารถกำหนดการเข้ารหัสสากลเดียวเช่นเดียวกับแผนภูมิอักขระสากลเดียว แต่ตลาดจะไม่ยอมรับ

Unicode คือการเข้ารหัสอักขระขนาด 21 บิตที่อธิบาย "CodePoints" โดยไม่ซ้ำกันแต่ละจุดรหัสที่แสดงด้วย aa glyph (การแสดงกราฟิก)

• 16 บิตใช้เพื่อระบุจุดรหัสในระนาบ (จุดโค้ดส่วนใหญ่อยู่บนระนาบ 0)
• 5 บิตเพื่อระบุระนาบ

การเข้ารหัสที่รองรับคือ:

• UTF-8 (เพื่อเข้ารหัสแต่ละจุดโดยใช้ค่า 8 บิต)
• UTF-16 (เพื่อเข้ารหัสแต่ละจุดโดยใช้ค่า 16 บิต)
• UTF-32 (เพื่อเข้ารหัสแต่ละจุดโดยใช้ค่า 32 บิต)

แต่ไม่ว่าการเข้ารหัสจะเป็นอย่างไรเมื่อคุณถอดรหัสพวกเขาจะแมปกลับไปที่ codepoint เฉพาะที่มีความหมายเหมือนกัน

• 'A' (U + 65)
  UTF-32 => 0x00000041 UTF-16 => 0x0041 UTF-8 => 0x41
• LATIN เล็กมัด OE (U + 0153)
  UTF-32 => 0x00000153 UTF-16 => 0x0153 UTF-8 => 0xC5 0x93
• ไม่ได้รับมอบหมาย (U + 11153)
  UTF-32 => 0x00011153 UTF-16 => 0xD804 0xDD53 UTF-8 => 0xF0 0x91 0x91 0x85 0x93

UTF-8

นี่เป็นรูปแบบขนาดผันแปร โดยที่ codepoint แต่ละตัวจะมีค่า 1 ถึง 4 ไบต์

UTF-16

นี่เป็นรูปแบบขนาดผันแปร จุดรหัสใน "Basic Multilingual plane" (BMP หรือ Plane 0) สามารถแสดงด้วยค่า 16 บิตเดียว จุดโค้ดบนระนาบอื่นนั้นแทนด้วยคู่ตัวแทน (2 ค่า 16 บิต)

UTF-32

นี่คือรูปแบบขนาดคงที่ จุดโค้ดทั้งหมดแสดงด้วยค่า 32 บิตเดียว

ฉันคิดว่ามันมีประโยชน์ที่จะแยก 2 แนวคิด:

1. Unicode - การแม็พอักขระจากทั่วโลกไปยังจุดโค้ด
2. การเข้ารหัส - การจับคู่โค้ดชี้ไปที่รูปแบบบิต (UTF-8, UTF-16, ฯลฯ )

UTF-8, UTF-16 และการเข้ารหัสอื่น ๆ มีข้อดีและข้อเสียต่างกัน ปรึกษาWikipediaเกี่ยวกับเรื่องนี้ดีกว่า

UTF-7, UTF-8, UTF-16 และ UTF-32 เป็นเพียงรูปแบบการแปลงอัลกอริทึมของการเข้ารหัสแบบเดียวกัน(codepoints) ของตัวละคร พวกเขากำลังเข้ารหัสของระบบหนึ่งของการเข้ารหัสของตัวละคร

นอกจากนี้ยังง่ายกว่าในการนำอัลกอริธึมไปข้างหน้าและข้างหลังกว่าโครงร่างก่อนหน้าส่วนใหญ่สำหรับจัดการกับชุดอักขระที่มีขนาดใหญ่กว่า 256 อักขระ

นี่เป็นสิ่งที่แตกต่างจากรหัสทั่วไปของประเทศและบางครั้งผู้ขายของ glyphs ในภาษาญี่ปุ่นเพียงอย่างเดียวมีความหลากหลายของ JIS เพียงอย่างเดียวไม่พูดถึง EUC-JP และการเปลี่ยนแปลงของ JIS ที่มุ่งเน้นไปที่เพจรหัสที่เครื่อง DOS / Windows ใช้เรียก Shift-JIS (ในระดับหนึ่งมีการแปลงอัลกอริธึมของสิ่งเหล่านี้ แต่ไม่ง่ายอย่างยิ่งและมีความแตกต่างเฉพาะของผู้ขายในตัวละครที่มีอยู่ทวีคูณโดยสองร้อยประเทศและวิวัฒนาการแบบค่อยเป็นค่อยไปของระบบอักษรที่ซับซ้อนมากขึ้น ยุค) และคุณฝันร้ายจริงๆ

ทำไมคุณต้องใช้รูปแบบการแปลงของ Unicode เหล่านี้ เนื่องจากระบบดั้งเดิมจำนวนมากถือว่าลำดับของอักขระ ASCII ช่วง 7 บิตดังนั้นคุณจึงต้องการโซลูชันที่สะอาดแบบ 7 บิตอย่างปลอดภัยผ่านข้อมูลที่ไม่ถูกขัดจังหวะผ่านระบบเหล่านั้นดังนั้นคุณจึงต้องใช้ UTF-7 จากนั้นมีระบบที่ทันสมัยกว่าที่สามารถจัดการกับชุดอักขระ 8 บิตได้ แต่โดยทั่วไปแล้ว nulls มีความหมายพิเศษสำหรับพวกเขาดังนั้น UTF-16 จึงไม่ทำงานสำหรับพวกเขา 2 ไบต์สามารถเข้ารหัสทั้งระนาบพูดได้หลายภาษาพื้นฐานของ Unicode ในการจุติครั้งแรกดังนั้น UCS-2 จึงดูเหมือนเป็นวิธีการที่สมเหตุสมผลสำหรับระบบที่กำลังจะ "Unicode รับรู้ตั้งแต่ต้น" (เช่น Windows NT และ Java VM) จากนั้นส่วนขยายที่เกินจำเป็นสำหรับอักขระเพิ่มเติม ซึ่งส่งผลให้การแปลงอัลกอริทึมของ 21 บิตมูลค่าของการเข้ารหัสที่ถูกสงวนไว้โดยมาตรฐาน Unicode และคู่เกิดตัวแทน; นั่นก็เพียงพอแล้ว UTF-16 หากคุณมีแอพพลิเคชั่นบางตัวที่ความกว้างของตัวอักษรมีความสำคัญมากกว่าประสิทธิภาพของการจัดเก็บ UTF-32 (เมื่อเรียกว่า UCS-4) เป็นตัวเลือก

UTF-16 เป็นสิ่งเดียวที่ซับซ้อนในการจัดการจากระยะไกลและลดลงได้อย่างง่ายดายโดยตัวละครขนาดเล็กที่ได้รับผลกระทบจากการเปลี่ยนแปลงครั้งนี้และความจริงที่ว่าลำดับ 16 บิตนำมีความแตกต่างอย่างสิ้นเชิงจากการลาก ลำดับ 16 บิต นอกจากนี้โลกยังง่ายกว่าการพยายามเดินหน้าและถอยหลังในการเข้ารหัสเอเชียตะวันออกเฉียงเหนือหลายต้นซึ่งคุณต้องใช้เครื่องรัฐ (JIS และ EUC) เพื่อจัดการกับลำดับการหลบหนีหรืออาจย้อนกลับไปหลายตัวอักษรจนกว่าคุณจะพบสิ่งที่รับประกัน เป็นไบต์นำเท่านั้น (Shift-JIS) UTF-16 มีข้อได้เปรียบบางอย่างเกี่ยวกับระบบที่สามารถสับผ่านลำดับ 16 บิตได้อย่างมีประสิทธิภาพเช่นกัน

หากคุณไม่ต้องอาศัยการเข้ารหัสที่แตกต่างกันหลายสิบ (ร้อยจริง ๆ ) หรือต้องสร้างระบบที่รองรับหลายภาษาในการเข้ารหัสที่แตกต่างกันในบางครั้งแม้แต่ในเอกสารเดียวกัน (เช่น WorldScript ใน MacO รุ่นเก่า) คุณอาจคิดว่า รูปแบบการแปลงยูนิโค้ดเป็นความซับซ้อนที่ไม่จำเป็น แต่เป็นการลดความซับซ้อนลงอย่างมากในตัวเลือกก่อนหน้านี้และแต่ละรูปแบบสามารถแก้ไขข้อ จำกัด ทางเทคนิคที่แท้จริงได้ พวกเขายังแปลงได้อย่างมีประสิทธิภาพระหว่างกันโดยไม่ต้องใช้ตารางการค้นหาที่ซับซ้อน

Unicode ไม่ได้ถูกออกแบบมาเพื่อแก้ไขปัญหาทั้งหมดของการเข้ารหัสที่แตกต่างกันมากมาย

Unicode ได้รับการออกแบบมาเพื่อแก้ไขปัญหาทั้งหมดของหนึ่งหมายเลขที่แสดงสิ่งต่าง ๆ มากมายขึ้นอยู่กับหน้ารหัสที่ใช้งานอยู่ ตัวเลข 0 - 127 แสดงถึงอักขระเดียวกันในหน้ารหัส Ansi ใด ๆ นี่คือสิ่งที่เรียกว่าแผนภูมิ ASCII หรือชุดอักขระ ในหน้ารหัส Ansi ซึ่งอนุญาตให้มีได้ 256 ตัวอักษรตัวเลข 128 - 255 หมายถึงอักขระที่แตกต่างกันในหน้ารหัสที่แตกต่างกัน

ตัวอย่างเช่น

• ตัวเลข $ 57 แสดงถึงตัวอักษรตัวใหญ่ W ในทุกหน้ารหัส แต่
• หมายเลข $ EC แสดงสัญลักษณ์ความไม่แน่นอนในหน้ารหัส 437 (สหรัฐอเมริกา) แต่เป็น "LATIN SMALL LETTER N WITH CEDILLA" ในรหัสหน้า 775 (บอลติก)
• เซ็นเซ็นต์คือหมายเลข $ 9B ในรหัสหน้า 437 แต่หมายเลข 96 ในรหัสหน้า 775

สิ่งที่ยูนิโคดทำคือทำให้ทุกอย่างกลับหัวกลับหาง ใน Unicode ไม่มี "การใช้ซ้ำ" แต่ละหมายเลขแสดงถึงอักขระที่ไม่ซ้ำกันเดียว หมายเลข $ 00A2 ใน Unicode คือเครื่องหมายเซ็นต์และเซ็นเซ็นจะปรากฏขึ้นที่อื่นในนิยาม Unicode

ทำไมจึงมีการเข้ารหัส Unicode จำนวนมาก แม้แต่รุ่นเดียวกัน (เป็นหลัก) หลายรุ่นเช่น UTF-8, UTF-16 เป็นต้น

ไม่มีการเข้ารหัสเดียวกันหลายรุ่น มีการเข้ารหัสที่หลากหลายของแผนที่นิยามอักขระ Unicode เดียวกันและสิ่งเหล่านี้ได้รับการ "ประดิษฐ์" เพื่อจัดการกับข้อกำหนดการจัดเก็บสำหรับการใช้งานที่แตกต่างกันของเครื่องบินภาษาต่างๆที่มีอยู่ใน Unicode

Unicode กำหนด (หรือมีพื้นที่ในการกำหนด) 4.294.967.295 อักขระที่ไม่ซ้ำกัน ถ้าคุณต้องการแมปเหล่านี้กับที่เก็บข้อมูลดิสก์ / หน่วยความจำโดยไม่ต้องแปลงอัลกอริทึมใด ๆ คุณต้องมี 4 ไบต์ต่ออักขระ หากคุณต้องการจัดเก็บข้อความที่มีตัวอักษรจากระนาบภาษาทั้งหมดดังนั้น UTF-32 (ซึ่งโดยทั่วไปจะเป็นอักขระ 1 ตัวตรง - การเข้ารหัสหน่วยเก็บข้อมูลขนาด 4 ไบต์ของข้อกำหนด Unicode) อาจเป็นสิ่งที่คุณต้องการ

แต่ข้อความแทบจะไม่ได้ใช้ตัวละครจากเครื่องบินทุกภาษา จากนั้นใช้อักขระ 4 ไบต์ต่อตัวละครดูเหมือนจะเป็นการสิ้นเปลืองขนาดใหญ่ โดยเฉพาะอย่างยิ่งเมื่อคุณคำนึงถึงว่าภาษาส่วนใหญ่ในโลกถูกกำหนดภายในสิ่งที่เรียกว่า Basic Multi-lingual Plane (BMP): หมายเลข 65536 แรกของนิยาม Unicode

และนั่นคือที่มาของ UTF-16 หากคุณใช้ตัวอักษรจาก BMP เพียงอย่างเดียว UTF-16 จะเก็บที่มีประสิทธิภาพมากโดยใช้เพียงสองไบต์ต่อตัวอักษร จะใช้ไบต์เพิ่มเติมสำหรับอักขระนอก BMP เท่านั้น ความแตกต่างระหว่าง UTF-16LE (ลิตเติ้ล Endian) และ UTF-16BE (บิ๊ก Endian) จริงๆเพียง แต่มีบางสิ่งบางอย่างจะทำอย่างไรกับตัวเลขจะแสดงภายในหน่วยความจำคอมพิวเตอร์ (รูปแบบไบต์A0หมายฐานสิบหก $ A0 หรือหมายถึง $ 0A)

หากข้อความของคุณใช้อักขระที่แตกต่างกันน้อยลงเช่นข้อความส่วนใหญ่ในภาษายุโรปตะวันตกคุณจะต้อง จำกัด ข้อกำหนดการจัดเก็บสำหรับข้อความของคุณให้มากขึ้น ดังนั้น UTF-8 ซึ่งใช้ไบต์เดียวเพื่อเก็บอักขระที่มีอยู่ในแผนภูมิ ASCII (ตัวเลข 128 ตัวแรก) และการเลือกจากอักขระ Ansi (ตัวเลข 128 สองหน้าของหน้ารหัสต่าง ๆ ) จะใช้ไบต์เพิ่มเติมสำหรับอักขระที่อยู่นอกชุด "ตัวอักษรที่ใช้มากที่สุด" นี้

ดังนั้นเพื่อสรุป:

• Unicode เป็นการแมปของตัวละครในทุกภาษาบนโลก (และ Klingon บางอันเพื่อบู๊ต) และจากนั้นบางส่วน (คณิตศาสตร์, ดนตรี, และอื่น ๆ ) ไปยังหมายเลขที่ไม่ซ้ำกัน
• การเข้ารหัสเป็นอัลกอริทึมที่กำหนดไว้เพื่อจัดเก็บข้อความโดยใช้ตัวเลขของแผนที่อักขระที่ไม่ซ้ำกันนี้เป็นช่องว่างที่มีประสิทธิภาพที่สุดเท่าที่จะเป็นไปได้เนื่องจาก "การใช้งานเฉลี่ย" ของตัวละครภายในข้อความ

Unicode กำหนดแผนที่ระหว่างตัวเลขและตัวละคร อย่างไรก็ตามเมื่อคุณส่งหมายเลขไปยังผู้รับคุณยังคงต้องกำหนดวิธีการแสดงหมายเลขนั้น นั่นคือสิ่งที่ UTF มีไว้เพื่อ มันกำหนดวิธีการแสดงตัวเลขในกระแสไบต์

เหตุผลที่อยู่เบื้องหลัง UTF-32 นั้นง่ายมาก: มันเป็นการนำเสนอจุดโค้ด Unicode ที่ตรงไปตรงมาที่สุด เหตุใดจึงไม่ใช่ทุกอย่างใน UTF-32 สองเหตุผลหลัก:

หนึ่งคือขนาด UTF-32 ต้องการ 4 ไบต์สำหรับตัวละครทุกตัว สำหรับข้อความที่ใช้เฉพาะอักขระในสถานที่หลายภาษาพื้นฐานนี่เป็นพื้นที่สองเท่าเท่ากับ UTF-16 สำหรับข้อความภาษาอังกฤษมีพื้นที่มากเท่ากับ US-ASCII 4 เท่า

เหตุผลใหญ่หลังเข้ากันได้ การเข้ารหัส Unicode แต่ละแบบนอกเหนือจาก UTF-32 แบบ "unencoded" ได้รับการออกแบบมาเพื่อรองรับความเข้ากันได้แบบย้อนหลังกับมาตรฐานก่อนหน้านี้

• UTF-8: เข้ากันได้ย้อนหลังกับ US-ASCII
• UTF-16: ความเข้ากันได้ย้อนหลังกับ UCS-2 (Unicode 16 บิตก่อนที่จะถูกขยายเกิน BMP)
• UTF-7: ความเข้ากันได้ย้อนหลังกับเมลเซิร์ฟเวอร์ที่ไม่ใช่แบบ 8 บิต
• GB18030: ความเข้ากันได้ย้อนหลังกับการเข้ารหัส GB2312 และ GBK สำหรับภาษาจีน
• UTF-EBCDIC: เข้ากันได้ย้อนหลังกับชุดย่อยภาษาละตินพื้นฐานของ EBCDIC

ฉันคิดว่า Unicode ได้รับการออกแบบมาเพื่อแก้ไขปัญหาทั้งหมดของการเข้ารหัสที่แตกต่างกันมากมาย

มันเป็นและมันก็ทำ การแปลงระหว่าง UTF-8, -16 และ -32 นั้นง่ายกว่าการจัดการกับระบบเก่าที่มีการเข้ารหัสอักขระที่แตกต่างกันหลายร้อยตัวสำหรับภาษาต่าง ๆ และระบบปฏิบัติการที่แตกต่างกัน

คุณรู้ว่าไฟล์ซิปสามารถบีบอัดไฟล์ให้มีขนาดเล็กกว่ามาก (โดยเฉพาะข้อความ) จากนั้นคลายการบีบอัดเป็นไฟล์สำเนาต้นฉบับที่เหมือนกัน

อัลกอริทึมซิปจริงมีหลายขั้นตอนวิธีการที่แตกต่างกันที่มีลักษณะแตกต่างกันเพื่อเลือกจาก: เก็บไว้ (ไม่มีการบีบอัด) หดตัวลดลง (วิธีการ 1-4), imploded, tokenizing, กิ่ว Deflate64, BZIP2, LZMA (EFS), WavPack, PPMD, ในทางทฤษฎีมันสามารถลองพวกเขาทั้งหมดและเลือกผลลัพธ์ที่ดีที่สุด แต่โดยปกติแล้วจะไปกับ Deflated

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