Unicode เป็นระบบการเข้ารหัสที่กำหนดรหัสเฉพาะให้กับอักขระใดๆ โดยไม่คำนึงถึงแพลตฟอร์ม โดยไม่คำนึงถึงโปรแกรม โดยไม่คำนึงถึงภาษา

อันที่จริง แม้แต่ในชื่อเรื่องของบันทึกย่อนี้ก็มีความไม่ถูกต้องอยู่บ้าง - หรือค่อนข้างขัดแย้งกัน ความจริงก็คือว่ายังไม่มีความเป็นเอกฉันท์เกี่ยวกับวิธีการสะกดคำภาษาอังกฤษ Unicode ในตัวอักษรรัสเซียอย่างถูกต้อง - Unicode หรือ Unicode ตอนนี้เราจะใช้ตัวเลือกการสะกดคำแรก

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

มาตรฐานยูนิโค้ดแบ่งออกเป็นสองส่วน ชุดแรกคือชุดตัวเลขที่สอดคล้องกับอักขระแต่ละตัวในตัวอักษรที่รองรับแต่ละตัว เรียกว่าชุดอักขระสากลหรือแค่ UCS ตัวเลขที่ใช้ในพื้นที่โค้ด UCS เป็นจำนวนเต็มและไม่เป็นค่าลบทั้งหมด ตัวเลขเหล่านี้ - ตำแหน่งรหัส - ถูกกำหนดเป็น U + 0000, U + 0001, U + 0002 เป็นต้น ด้วยเหตุนี้ พื้นที่โค้ดจึงไม่เหมือนกัน แต่แบ่งออกเป็นหลายส่วนตามความหมาย รหัสจาก U + 0000 ถึง U + 007F เป็นอักขระ ASCII ตามด้วยอักขระจากตัวอักษรประจำชาติต่างๆ เครื่องหมายวรรคตอน และอักขระทางเทคนิค เช่น แคร่ตลับหมึกเพื่อขึ้นบรรทัดใหม่ ส่วนที่สองของมาตรฐานคือ อันที่จริง การเข้ารหัสที่ให้การแสดงรหัสแต่ละรหัสในข้อความในระดับบิต

อักขระ Unicode ทั้งหมดแบ่งออกเป็นสองประเภท - แบบขยายและแบบไม่มีความกว้าง (กำลังแก้ไข) อักขระขยายเป็นตัวอักษรปกติที่ใช้พิมพ์บันทึกย่อนี้ การแก้ไขคือเครื่องหมายเหนือตัวอักษร เช่น การเน้นเสียง จุด "ตัวพิมพ์ใหญ่" ฯลฯ เป็นต้น ตัวอักษรส่วนใหญ่ที่มีเครื่องหมายคล้ายกันสำหรับตัวอักษรทั้งหมดจะแสดงเป็นลำดับของสัญลักษณ์ที่ขยายและปรับเปลี่ยน จริงซีริลลิก "e" และ "y" จะแสดงเป็นอักขระขยายที่แยกจากกัน

การใช้งาน Unicode ในทางปฏิบัติที่พบบ่อยที่สุดคือ UTF-8 มาตรฐานนี้มีความเข้ากันได้ดีกับข้อความ ASCII แบบเก่า เนื่องจากอักขระของตัวอักษรภาษาอังกฤษและอักขระทั่วไปอื่นๆ (เช่น อักขระที่มีรหัส ASCII ตั้งแต่ 0 ถึง 127) ถูกเขียนในหนึ่งไบต์ อักขระที่เหลือเขียนด้วยไบต์จำนวนมาก - จากสองถึงหก

Unicode และมาตรฐานที่เกี่ยวข้องกำลังได้รับการพัฒนาโดย Unicode Consortium ตามที่เขียนไว้บนเว็บไซต์อย่างเป็นทางการขององค์กรนี้ www.unicode.org "Unicode Consortium เป็นองค์กรไม่แสวงหาผลกำไรที่ก่อตั้งขึ้นเพื่อพัฒนาและพัฒนามาตรฐาน Unicode ที่กำหนดการแสดงข้อมูลที่เป็นข้อความในผลิตภัณฑ์และมาตรฐานซอฟต์แวร์สมัยใหม่ และ เพื่อส่งเสริมการเผยแพร่และการใช้งานอย่างกว้างขวาง สมาชิก Consortium เป็นองค์กรและองค์กรจำนวนมากที่ทำงานในด้านการประมวลผลข้อมูลและอุตสาหกรรมคอมพิวเตอร์ การสนับสนุนทางการเงินของ Consortium ดำเนินการผ่านค่าธรรมเนียมสมาชิกของสมาชิกเท่านั้น Unicode Consortium เปิดให้องค์กรหรือบุคคลใดๆ ที่สนับสนุนมาตรฐาน Unicode และต้องการช่วยกระจายและนำไปใช้ " เข้าร่วมกับเรา! :)

มาตรฐาน Unicode หรือ ISO / IEC 10646 เป็นผลมาจากความร่วมมือระหว่างองค์กรระหว่างประเทศเพื่อการมาตรฐาน (ISO) และผู้ผลิตคอมพิวเตอร์ชั้นนำและ ซอฟต์แวร์... เหตุผลที่ระบุไว้ในหน้าก่อนหน้านี้ทำให้พวกเขาสร้างสูตรใหม่โดยพื้นฐานสำหรับคำถาม: เหตุใดจึงใช้ความพยายามในการพัฒนาตารางรหัสที่แยกจากกัน หากสามารถสร้างตารางเดียวสำหรับภาษาประจำชาติทั้งหมดได้ งานดังกล่าวดูทะเยอทะยานเกินไป แต่เพียงแวบแรกเท่านั้น ความจริงก็คือจาก 6,700 ภาษาที่มีชีวิต ประมาณห้าสิบภาษาเป็นภาษาราชการของรัฐ และพวกเขาใช้สคริปต์ที่แตกต่างกันประมาณ 25 แบบ: ตัวเลขสำหรับอายุคอมพิวเตอร์ของเราสามารถคาดการณ์ได้ค่อนข้างมาก

การประมาณการเบื้องต้นพบว่าช่วง 16 บิตเพียงพอที่จะเข้ารหัสสคริปต์เหล่านี้ทั้งหมด นั่นคือช่วงตั้งแต่ 0000 ถึง FFFF แต่ละสคริปต์ได้รับการจัดสรรบล็อกของตัวเองในช่วงนี้ ซึ่งค่อยๆ เต็มไปด้วยรหัสของอักขระของสคริปต์นี้ ทุกวันนี้การเข้ารหัสของสคริปต์ทางการที่มีชีวิตทั้งหมดถือได้ว่าสมบูรณ์

วิธีการที่พัฒนาขึ้นมาอย่างดีสำหรับการวิเคราะห์และอธิบายระบบการเขียนช่วยให้กลุ่ม Unicode ย้ายเมื่อเร็ว ๆ นี้เพื่อเข้ารหัสสคริปต์ที่เหลือของโลกที่น่าสนใจ: สคริปต์เหล่านี้คือภาษาที่ตายแล้ว อักษรอียิปต์โบราณที่เลิกใช้ในปัจจุบัน , ตัวอักษรที่ประดิษฐ์ขึ้นเอง ฯลฯ เพื่อแสดงถึงทุกสิ่งที่ความมั่งคั่งของการเข้ารหัส 16 บิตไม่เพียงพออีกต่อไป และวันนี้ Unicode ใช้พื้นที่รหัส 21 บิต (000000 - 10FFFF) ซึ่งแบ่งออกเป็น 16 โซนที่เรียกว่าระนาบ จนถึงตอนนี้ แผน Unicode มีเครื่องบินดังต่อไปนี้:

Plane 0 (รหัส 000000 - 00FFFF) - BMP, Basic Multilingual Plane (BMP, Basic Multilingual Plane) สอดคล้องกับช่วง Unicode ดั้งเดิม

เครื่องบิน 1 (รหัส 010000 - 01FFFF) - DMP, เครื่องบินหลายภาษาเสริม (SMP) มีไว้สำหรับสคริปต์ที่ไม่ทำงาน

เครื่องบิน 2 (รหัส 020000 - 02FFFF) - DIP ซึ่งเป็นระนาบอักษรอียิปต์โบราณเพิ่มเติม (SIP, เครื่องบิน Ideographic เสริม) มีไว้สำหรับอักษรอียิปต์โบราณที่ไม่รวมอยู่ใน BMP

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

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

เครื่องบิน 14 (รหัส 0E0000 - 0EFFFF) เป็นแผ่นไม้อัดซึ่งเป็นระนาบพิเศษเพิ่มเติม (SSP, เครื่องบินวัตถุประสงค์พิเศษเสริม) ซึ่งมีไว้สำหรับอักขระวัตถุประสงค์พิเศษ

เครื่องบิน 15 (รหัส 0F0000 - 0FFFFF) - เครื่องบินส่วนตัวซึ่งมีไว้สำหรับสัญลักษณ์ของการเขียนเทียม

เครื่องบิน 16 (รหัส 100000 - 10FFFF) - เครื่องบินส่วนตัวสำหรับใช้เป็นสัญลักษณ์ของการเขียนเทียม

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

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

การแยก BMP ออกเป็นบล็อคมีให้ใน WDH: Unicode Standard ที่นี่เราทราบเพียงว่า 128 รหัสแรก (00000 - 0007F) สอดคล้องกับรหัส ASCII และเข้ารหัสบล็อกละตินฐาน เลย์เอาต์ของสคริปต์สำหรับช่วง Unicode จะอธิบายโดยละเอียดในบทความของฉัน "Unicode และสคริปต์ของโลก" เนื่องจากในอนาคตเราจะสนใจเฉพาะสัญลักษณ์ BMP เท่านั้น ฉันจึงใช้รหัส 16 บิตในรูปแบบ XXXX (บิตที่สำคัญที่สุดมีค่าเท่ากับศูนย์และไม่ได้ระบุ)

คำอธิบายทั่วไป

Unicode ขึ้นอยู่กับแนวคิดของตัวละคร สัญลักษณ์เป็นแนวคิดนามธรรมที่มีอยู่ในระบบการเขียนเฉพาะและรับรู้ผ่านรูปภาพ (กราฟ) ซึ่งหมายความว่าแต่ละตัวอักษรจะได้รับ รหัสเฉพาะและเป็นของบล็อก Unicode เฉพาะ ตัวอย่างเช่น มีกราฟ A ในตัวอักษรภาษาอังกฤษ รัสเซีย และกรีก อย่างไรก็ตาม ใน Unicode จะสอดคล้องกับอักขระสามตัวที่แตกต่างกัน "อักษรละตินตัวพิมพ์ใหญ่ A" (รหัส 0041), "ตัวอักษร Cyrillic ตัวพิมพ์ใหญ่ A" (รหัส 0410) และ "ตัวพิมพ์ใหญ่ภาษากรีก ALPHA" (รหัส 0391) หากตอนนี้เราใช้การแปลงเป็นอักษรตัวพิมพ์เล็กกับอักขระเหล่านี้ เราจะได้รับ "อักษรตัวพิมพ์เล็กละติน A" ตามลำดับ (รหัส 0061, กราฟ a), "อักษรตัวพิมพ์เล็ก Cyrillic A" (รหัส 0430, grapheme a) และ "อักษรตัวพิมพ์เล็กกรีก ALPHA" (รหัส 03B1, กราฟ α), เช่น กราฟต่างๆ

คำถามอาจเกิดขึ้น: การแปลงเป็นตัวพิมพ์เล็กคืออะไร? เรามาถึงจุดที่น่าสนใจและสำคัญที่สุดในมาตรฐาน ประเด็นคือ Unicode ไม่ใช่เรื่องง่าย ตารางรหัส... แนวคิดของสัญลักษณ์นามธรรมทำให้ผู้สร้าง Unicode สามารถสร้างฐานข้อมูลอักขระที่อธิบายอักขระแต่ละตัวด้วยรหัสที่ไม่ซ้ำกัน (คีย์ฐานข้อมูล) ชื่อเต็ม และชุดของคุณสมบัติ ตัวอย่างเช่น สัญลักษณ์ที่มีรหัส 0410 อธิบายไว้ในฐานข้อมูลนี้ดังนี้:

0410; อักษรตัวใหญ่ซิริลลิก A; Lu; 0; L ;;;;; N ;;;; 0430;

มาถอดรหัสรายการนี้กัน หมายความว่ารหัส 0410 ถูกกำหนดให้กับ "Cyrillic ตัวพิมพ์ใหญ่А "(ชื่อเต็มของสัญลักษณ์) ซึ่งมีคุณสมบัติดังต่อไปนี้:

คุณสมบัติที่แสดงไว้ถูกกำหนดสำหรับอักขระ Unicode แต่ละตัว สิ่งนี้ทำให้นักพัฒนาสามารถสร้างอัลกอริธึมมาตรฐานที่กำหนดโดยยึดตามคุณสมบัติของสัญลักษณ์ กฎสำหรับการแสดงผล การเรียงลำดับ และการแปลงเป็นอักษรตัวพิมพ์ใหญ่/ตัวพิมพ์เล็ก

โดยสรุป เราสามารถพูดได้ว่ามาตรฐาน Unicode ประกอบด้วยสามส่วนที่เกี่ยวข้องกัน:

ฐานข้อมูลสัญลักษณ์

ฐานของกราฟ (ร่ายมนตร์) ซึ่งกำหนดการแสดงสัญลักษณ์เหล่านี้

ชุดของอัลกอริทึมที่กำหนดกฎสำหรับการทำงานกับสัญลักษณ์

โดยสรุปในส่วนนี้ เราขอนำเสนอกราฟของบล็อกซีริลลิก (รหัส 0400 - 04FF) โปรดทราบว่าไม่เพียงแต่รวมตัวอักษรของอักษรซีริลลิกสมัยใหม่ (รัสเซีย ยูเครน เบลารุส บัลแกเรีย เซอร์เบีย มาซิโดเนีย ฯลฯ) แต่ยังรวมถึงตัวอักษรทั้งหมดของอักษรซีริลลิกดั้งเดิมที่ใช้ในงานเขียนภาษาสลาฟของคริสตจักร

รูปแบบการแปลงร่าง

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

ลำดับของไบต์ในคำนั้นแตกต่างกันสำหรับโปรเซสเซอร์ที่ต่างกัน โปรเซสเซอร์ Intel, DEC และตัวประมวลผลอื่นๆ จะเก็บไบต์ที่สำคัญที่สุดไว้ในไบต์แรกของคำเครื่อง ขณะที่ Motorola, Sparc และตัวประมวลผลอื่นๆ จะเก็บไบต์ที่มีนัยสำคัญน้อยที่สุด พวกมันถูกเรียกว่า little-endian และ big-endian ตามลำดับ (คำเหล่านี้มาจาก "spikes" และ "blunts" ของ Swift ซึ่งเป็นการโต้เถียงกันเกี่ยวกับจุดสิ้นสุดของการทำลายไข่)

ระบบและโปรโตคอลเชิงไบต์จำนวนมากอนุญาตเฉพาะไบต์จากช่วงที่ระบุเป็นข้อมูล ส่วนที่เหลือของไบต์ถือเป็นโอเวอร์เฮด โดยเฉพาะอย่างยิ่ง เป็นเรื่องปกติที่จะใช้ไบต์ว่างเป็นอักขระสิ้นสุดบรรทัด เนื่องจาก Unicode เข้ารหัสอักขระในแถว การส่งรหัสโดยตรงเป็นสตริงไบต์อาจขัดแย้งกับกฎของโปรโตคอลการถ่ายโอนข้อมูล

เพื่อแก้ปัญหาเหล่านี้ มาตรฐานได้รวมรูปแบบการแปลงสามรูปแบบ UTF-8, UTF-16 และ UTF-32 ซึ่งกำหนดกฎสำหรับการเข้ารหัสอักขระ Unicode เป็นสตริงไบต์ คู่คำ 16 บิต และคำ 32 บิตตามลำดับ การเลือกรูปแบบที่จะใช้ขึ้นอยู่กับสถาปัตยกรรมของระบบคอมพิวเตอร์และการจัดเก็บข้อมูลและมาตรฐานการรับส่งข้อมูล คำอธิบายสั้น ๆ ของรูปแบบการแปลงมีอยู่ใน WDH: Unicode Standard

ปัญหาการใช้งาน

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

ระบบปฏิบัติการต้องสนับสนุนรูปแบบการแปลง Unicode ที่ระดับอินพุต ที่จัดเก็บ และการแสดงสตริงข้อความ

เราต้องการไดรเวอร์แป้นพิมพ์อัจฉริยะที่ช่วยให้เราป้อนอักขระในบล็อก Unicode ใดๆ และส่งรหัสไปยังระบบปฏิบัติการได้

โปรแกรมแก้ไขข้อความควรสนับสนุนการแสดงอักขระ Unicode ทั้งหมดและดำเนินการชุดอักขระทั่วไปกับอักขระดังกล่าว

DBMS จะต้องทำเช่นเดียวกันอย่างถูกต้องสำหรับฟิลด์ข้อความและบันทึกช่วยจำ

เนื่องจากการเข้ารหัสระดับประเทศจะอยู่ร่วมกับ Unicode เป็นเวลานาน จึงจำเป็นต้องสนับสนุนการแปลงข้อความระหว่างกัน

น่าเสียดายที่เราต้องยอมรับว่าในสิบปี (Unicode 1.0 ปรากฏในปี 1991) มีการดำเนินการในทิศทางนี้น้อยกว่าที่เราต้องการมาก แม้แต่ Windows ซึ่งมีการรองรับ Unicode ที่สม่ำเสมอที่สุดในระดับระบบก็ยังเต็มไปด้วยข้อจำกัดที่ไม่ลงตัวโดยสิ้นเชิงอันเนื่องมาจากการพัฒนาในอดีตเท่านั้น สถานการณ์เลวร้ายยิ่งกว่าบน Unix เนื่องจากการรองรับ Unicode ได้ถูกย้ายจากเคอร์เนลไปยังแอพพลิเคชั่นเฉพาะ เรียกได้ว่า Unicode ได้รับการสนับสนุนอย่างหนักที่สุดในปัจจุบันในสองสภาพแวดล้อม: เว็บเบราว์เซอร์และเครื่องเสมือน Java ไม่น่าแปลกใจเลย เนื่องจากแต่เดิมสภาพแวดล้อมทั้งสองได้รับการออกแบบมาให้ไม่ขึ้นกับระบบ

ปัญหาวัตถุประสงค์ในการสนับสนุน Unicode ควรสังเกตด้วย ตัวอย่างเช่น เราจะเน้นที่การแสดงกราฟเท่านั้น ซึ่งคุณต้องติดตั้งฟอนต์ที่เหมาะสมในระบบ ปัญหาคือฟอนต์ที่มีกราฟ Unicode ทั้งหมดจะมีขนาดที่น่าอึดอัดใจอย่างยิ่ง ตัวอย่างเช่น แบบอักษร TrueType Arial Unicode MS ซึ่งมีอักขระ Unicode ส่วนใหญ่ "หนัก" 24MB เมื่อ Unicode เติมบล็อกใหม่ ขนาดของฟอนต์ดังกล่าวจะเข้าใกล้ 100MB ทางออกของสถานการณ์คือการโหลดสัญลักษณ์ตามความต้องการของ Microsoft ซึ่งยอมรับในเบราว์เซอร์ Internet Explorer... อย่างไรก็ตามในขณะที่มาตรฐานเกี่ยวกับกฎสำหรับการสร้างแบบอักษร Unicode นั้นเงียบ

วิธีการทำงานด้วย อักขระ Unicodeและการเข้ารหัสระดับประเทศในสภาพแวดล้อมที่สำคัญที่สุดและระบบการเขียนโปรแกรมจะกล่าวถึงในบทความต่อไปนี้

ไม่มีหน้าดังกล่าว

เธออาจจะเป็น สักวันหนึ่ง ก่อนหน้านี้. หรืออย่างอื่นในแผนเท่านั้น แต่ตอนนี้เธอจากไปแล้ว