Unicode

จากวิกิพีเดีย สารานุกรมเสรี
ข้ามไปที่การนำทาง ข้ามไปที่การค้นหา

Unicode
New Unicode logo.svg
โลโก้ของUnicode Consortium
นามแฝงชุดอักขระรหัสสากล (UCS)
ภาษาระหว่างประเทศ
มาตรฐานมาตรฐานยูนิโค้ด
รูปแบบการเข้ารหัส
ก่อนหน้าISO/IEC 8859 , อื่นๆ มากมาย

Unicode , อย่างเป็นทางการมาตรฐาน Unicodeเป็นเทคโนโลยีสารสนเทศ มาตรฐานสำหรับสอดคล้องเข้ารหัส , การแสดงและการจัดการของข้อความที่แสดงในส่วนของโลกที่มีระบบการเขียน มาตรฐานซึ่งดูแลโดยUnicode Consortiumกำหนด 144,762 อักขระครอบคลุม 159 สคริปต์สมัยใหม่และประวัติศาสตร์ตลอดจนสัญลักษณ์อีโมจิและโค้ดการควบคุมและการจัดรูปแบบที่ไม่ใช่การมองเห็น

รายการอักขระ Unicode ซิงโครไนซ์กับISO/IEC 10646โดยแต่ละรายการเป็นโค้ดสำหรับโค้ดเหมือนกันอย่างไรก็ตาม Unicode Standardมีมากกว่าแค่โค้ดฐานนอกจากการเข้ารหัสอักขระแล้ว สิ่งพิมพ์อย่างเป็นทางการของ Consortium ยังมีรายละเอียดมากมายเกี่ยวกับสคริปต์และวิธีแสดงสคริปต์เหล่านี้: กฎการทำให้เป็นมาตรฐาน การแยกส่วน การเรียงการแสดงผล และลำดับการแสดงข้อความแบบสองทิศทางสำหรับข้อความหลายภาษา และอื่นๆ[1]มาตรฐานนอกจากนี้ยังมีการอ้างอิงไฟล์ข้อมูลและแผนภูมิภาพเพื่อพัฒนาความช่วยเหลือและนักออกแบบอย่างถูกต้องดำเนินการละคร

ความสำเร็จ Unicode ที่ชุดตัวอักษรรวมกันได้นำไปสู่การใช้อย่างแพร่หลายและเด่นในสากลและท้องถิ่นของเครื่องคอมพิวเตอร์ซอฟแวร์มาตรฐานที่ได้รับการดำเนินการในเทคโนโลยีล่าสุดจำนวนมากรวมทั้งที่ทันสมัยระบบปฏิบัติการ , XML , Java (และอื่น ๆการเขียนโปรแกรมภาษา ) และ.NET Framework

Unicode สามารถใช้งานได้โดยการเข้ารหัสอักขระต่างๆ มาตรฐาน Unicode กำหนด Unicode Transformation Formats (UTF): UTF-8 , UTF-16และUTF-32และการเข้ารหัสอื่นๆ อีกหลายอย่าง การเข้ารหัสที่ใช้บ่อยที่สุดคือ UTF-8, UTF-16 และUCS-2 ที่ล้าสมัย(สารตั้งต้นของ UTF-16 โดยไม่รองรับ Unicode อย่างเต็มรูปแบบ) GB18030แม้ว่าจะไม่ใช่มาตรฐาน Unicode อย่างเป็นทางการ แต่เป็นมาตรฐานในประเทศจีนและใช้งาน Unicode ได้อย่างเต็มที่

UTF-8 ซึ่งเป็นการเข้ารหัสหลักบนเวิลด์ไวด์เว็บ (ใช้ในกว่า 95% ของเว็บไซต์ ณ ปี 2020 และมากถึง 100% สำหรับบางภาษา) [2]และบนระบบปฏิบัติการที่คล้าย Unixส่วนใหญ่ใช้หนึ่งไบต์[หมายเหตุ 1] (8  บิต ) สำหรับจุดโค้ด 128 จุดแรก และสูงสุด 4 ไบต์สำหรับอักขระอื่นๆ[3]จุดโค้ด Unicode 128 จุดแรกแสดงถึงอักขระ ASCIIซึ่งหมายความว่าข้อความ ASCII ใดๆ ก็เป็นข้อความ UTF-8 ด้วย

UCS-2 ใช้สองไบต์ (16 บิต) สำหรับแต่ละอักขระ แต่สามารถเข้ารหัสได้เฉพาะจุดรหัส 65,536 แรกเท่านั้นซึ่งเรียกว่าBasic Multilingual Plane (BMP) ด้วยจุดรหัส Unicode ที่เป็นไปได้ 1,112,064 จุดซึ่งสอดคล้องกับอักขระ (ดูด้านล่าง ) บนเครื่องบิน 17 ลำ และด้วยจุดรหัสมากกว่า 144,000 จุดที่กำหนดไว้ในเวอร์ชัน 14.0 ทำให้ UCS-2 สามารถแสดงอักขระ Unicode ที่เข้ารหัสได้น้อยกว่าครึ่งหนึ่งเท่านั้น ดังนั้น UCS-2 จึงล้าสมัย แม้ว่าจะยังใช้ในซอฟต์แวร์อยู่ก็ตาม UTF-16 ขยาย UCS-2 โดยใช้การเข้ารหัส16 บิตเดียวกันกับ UCS-2 สำหรับ Basic Multilingual Plane และการเข้ารหัส 4 ไบต์สำหรับระนาบอื่น ตราบใดที่ไม่มีจุดรหัสในช่วงที่สงวนไว้ U+D800–U+DFFF [ จำเป็นต้องชี้แจง]ข้อความ UCS-2 เป็นข้อความ UTF-16 ที่ถูกต้อง

UTF-32 (เรียกอีกอย่างว่า UCS-4) ใช้สี่ไบต์ในการเข้ารหัสจุดรหัสใดๆ ที่ระบุ แต่ไม่จำเป็นว่าจะต้องเป็นอักขระที่ผู้ใช้รับรู้ (พูดอย่างหลวม ๆ ว่าgrapheme ) เนื่องจากอักขระที่ผู้ใช้รับรู้อาจแสดงด้วย a กราฟคลัสเตอร์ (ลำดับของจุดโค้ดหลายจุด) [4]เช่นเดียวกับ UCS-2 จำนวนไบต์ต่อจุดรหัสได้รับการแก้ไข อำนวยความสะดวกในการจัดทำดัชนีจุดรหัส แต่ต่างจาก UCS-2 ตรงที่ UTF-32 สามารถเข้ารหัสจุดรหัส Unicode ทั้งหมดได้ อย่างไรก็ตาม เนื่องจากแต่ละจุดโค้ดใช้สี่ไบต์ UTF-32 จึงใช้พื้นที่มากกว่าการเข้ารหัสอื่นๆ อย่างมาก และไม่ได้ใช้กันอย่างแพร่หลาย แม้ว่า UTF-32 จะมีขนาดคงที่สำหรับจุดโค้ดแต่ละจุด แต่ก็มีความยาวผันแปรตามอักขระที่ผู้ใช้รับรู้ ตัวอย่าง ได้แก่เทวนาครี kshiซึ่งเข้ารหัสด้วยรหัส 4 จุดและอิโมจิธงประจำชาติซึ่งประกอบด้วยจุดรหัสสองจุด [5]ทั้งหมดลำดับตัวอักษรรวมเป็นอักษร แต่มีลำดับอื่น ๆ ของจุดรหัสที่มีเช่นกันตัวอย่างเช่น\ r \ n [6] [7] [8] [9]

กำเนิดและการพัฒนา

Unicode มีจุดมุ่งหมายที่ชัดเจนในการก้าวข้ามข้อจำกัดของการเข้ารหัสอักขระแบบเดิม เช่น ที่กำหนดไว้โดยมาตรฐาน ISO/IEC 8859ซึ่งพบการใช้งานอย่างกว้างขวางในประเทศต่างๆ ทั่วโลก แต่ส่วนใหญ่ยังคงเข้ากันไม่ได้ การเข้ารหัสอักขระแบบดั้งเดิมจำนวนมากมีปัญหาร่วมกันคืออนุญาตให้ประมวลผลด้วยคอมพิวเตอร์สองภาษา (มักใช้อักขระละตินและสคริปต์ในเครื่อง) แต่ไม่ใช่การประมวลผลคอมพิวเตอร์แบบหลายภาษา (การประมวลผลด้วยคอมพิวเตอร์ของสคริปต์ตามอำเภอใจผสมกัน)

โดยเจตนา Unicode จะเข้ารหัสอักขระที่อยู่ข้างใต้— กราฟและหน่วยที่เหมือนกราฟ—แทนที่จะเป็นอักขระแบบแปรผัน(การแสดงผล) สำหรับอักขระดังกล่าว ในกรณีของอักษรจีนบางครั้งสิ่งนี้นำไปสู่ข้อโต้แย้งเกี่ยวกับการแยกความแตกต่างของอักขระที่เป็นพื้นฐานจากร่ายมนตร์ที่ต่างกันออกไป (ดูการรวมฮัน )

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

จุดรหัส 256 จุดแรกถูกสร้างขึ้นเหมือนกับเนื้อหาของISO/IEC 8859-1เพื่อให้การแปลงข้อความตะวันตกที่มีอยู่เป็นเรื่องเล็กน้อย อักขระที่เหมือนกันจำนวนมากได้รับการเข้ารหัสหลายครั้งที่จุดโค้ดต่างๆ เพื่อรักษาความแตกต่างที่ใช้โดยการเข้ารหัสแบบเดิม ดังนั้นจึงอนุญาตให้แปลงจากการเข้ารหัสเหล่านั้นเป็น Unicode (และย้อนกลับ) โดยไม่สูญเสียข้อมูลใดๆ ตัวอย่างเช่น ส่วน " รูปแบบเต็มความกว้าง " ของจุดโค้ดจะรวมตัวอักษรละตินที่ซ้ำกันทั้งหมด เนื่องจากแบบอักษรจีน ญี่ปุ่น และเกาหลี ( CJK ) มีตัวอักษรสองเวอร์ชัน "เต็มความกว้าง" ที่ตรงกับความกว้างของอักขระ CJK และ ความกว้างปกติ สำหรับตัวอย่างอื่นดูตัวอักษรที่ซ้ำกันใน Unicode

ผู้รับรางวัล Unicode Bulldog Award จัดหมวดหมู่ชื่อต่างๆ มากมายที่มีอิทธิพลต่อการพัฒนา Unicode และรวมถึงTatsuo Kobayashi , Thomas Milo, Roozbeh Pournader , Ken LundeและMichael Everson [10]

ประวัติ

จากประสบการณ์กับXerox Character Code Standard (XCCS) ตั้งแต่ปี 1980 [11]จุดเริ่มต้นของ Unicode มาถึงปี 1987 เมื่อJoe BeckerจากXeroxร่วมกับLee CollinsและMark DavisจากAppleเริ่มตรวจสอบการปฏิบัติจริงของการสร้างชุดอักขระสากล[12]ด้วยการป้อนข้อมูลที่เพิ่มขึ้นจากปีเตอร์เฟนวิคและเดฟ Opstad, [11]โจเบกเกอร์ตีพิมพ์ข้อเสนอร่างเป็น "ข้อความตัวอักษรระบบการเข้ารหัสต่างประเทศ / พูดได้หลายภาษาในเดือนสิงหาคมปี 1988 แน่นอนเรียกว่า Unicode" เขาอธิบายว่า "[t]เขาชื่อ 'Unicode' มีวัตถุประสงค์เพื่อแนะนำการเข้ารหัสสากลที่ไม่ซ้ำใครและเป็นหนึ่งเดียว" (11)

ในเอกสารนี้ ชื่อUnicode 88เบกเกอร์สรุปโมเดลอักขระ16 บิต : [11]

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

การออกแบบ 16 บิตดั้งเดิมของเขามีพื้นฐานอยู่บนสมมติฐานที่ว่าต้องมีการเข้ารหัสเฉพาะสคริปต์และอักขระที่ใช้ในปัจจุบันเท่านั้น: [11]

Unicode ให้ความสำคัญกับการสร้างประโยชน์ใช้สอยสำหรับอนาคตมากกว่าการอนุรักษ์โบราณวัตถุในอดีต Unicode มุ่งเป้าไปที่ตัวอักษรตัวแรกที่ตีพิมพ์ในข้อความสมัยใหม่ (เช่น ในหนังสือพิมพ์และนิตยสารทั้งหมดที่พิมพ์ในโลกในปี 1988) ซึ่งมีตัวเลขต่ำกว่า 2 14 = 16,384 อย่างไม่ต้องสงสัยนอกเหนือจากอักขระที่ใช้ในปัจจุบันแล้ว อักขระอื่นๆ ทั้งหมดอาจถูกกำหนดให้ล้าสมัยหรือหายาก สิ่งเหล่านี้เป็นตัวเลือกที่ดีกว่าสำหรับการลงทะเบียนแบบส่วนตัวมากกว่าการรวมรายการสาธารณะของ Unicodes ที่มีประโยชน์โดยทั่วไป

ในช่วงต้นปี 1989 คณะทำงาน Unicode ได้ขยายไปถึง Ken Whistler และ Mike Kernaghan จาก Metaphor, Karen Smith-Yoshimura และ Joan Aliprand จากRLGและ Glenn Wright จากSun Microsystemsและในปี 1990 Michel Suignard และ Asmus Freytag จากMicrosoftและ Rick McGowan ของNeXTเข้าร่วมกลุ่ม ภายในสิ้นปี 1990 งานส่วนใหญ่เกี่ยวกับการทำแผนที่มาตรฐานการเข้ารหัสอักขระที่มีอยู่ได้เสร็จสิ้นลง และร่างการตรวจสอบขั้นสุดท้ายของ Unicode ก็พร้อมแล้ว

Unicode Consortiumเป็น บริษัท ในแคลิฟอร์เนียที่ 3 มกราคม 1991 [13]และในเดือนตุลาคมปี 1991 เล่มแรกของมาตรฐาน Unicode รับการตีพิมพ์ เล่มที่สองซึ่งครอบคลุมแนวความคิดของฮั่น ตีพิมพ์ในเดือนมิถุนายน พ.ศ. 2535

ในปี 1996 กลไกอักขระตัวแทนถูกนำมาใช้ใน Unicode 2.0 เพื่อให้ Unicode ไม่ถูกจำกัดที่ 16 บิตอีกต่อไป สิ่งนี้ทำให้ Unicode codespace เพิ่มขึ้นเป็นล้านจุดรหัส ซึ่งอนุญาตให้เข้ารหัสสคริปต์ประวัติศาสตร์จำนวนมาก (เช่นอักษรอียิปต์โบราณ ) และอักขระที่ไม่ค่อยได้ใช้หรือล้าสมัยนับพันตัวที่ไม่คาดคิดว่าจำเป็นต้องเข้ารหัส ในบรรดาอักขระที่ไม่ได้มีไว้สำหรับ Unicode แต่เดิมนั้นไม่ค่อยมีการใช้คันจิหรือตัวอักษรจีน ซึ่งหลายตัวเป็นส่วนหนึ่งของชื่อส่วนบุคคลและชื่อสถานที่ ทำให้ไม่ค่อยได้ใช้ แต่มีความสำคัญมากกว่าที่จินตนาการไว้ในสถาปัตยกรรมดั้งเดิมของ Unicode [14]

ข้อกำหนด Microsoft TrueType เวอร์ชัน 1.0 จากปี 1992 ใช้ชื่อ 'Apple Unicode' แทน 'Unicode' สำหรับรหัสแพลตฟอร์มในตารางการตั้งชื่อ

Unicode Consortium

Unicode Consortium เป็นองค์กรไม่แสวงหาผลกำไรที่ประสานงานการพัฒนา Unicode สมาชิกเต็มรูปแบบรวมถึงส่วนใหญ่ของซอฟแวร์และฮาร์ดแวร์คอมพิวเตอร์หลักของ บริษัท ที่มีความสนใจในมาตรฐานการประมวลผลข้อความรวมทั้งAdobe , แอปเปิ้ล , Facebook , Google , IBM , Microsoft , Netflixและเอสเอพีเอจี [15]

หลายปีที่ผ่านมา หลายประเทศหรือหน่วยงานรัฐบาลเป็นสมาชิกของ Unicode Consortium ปัจจุบันมีเพียงกระทรวงเอ็นดาวเม้นท์และกิจการศาสนา (โอมาน) เท่านั้นที่เป็นสมาชิกเต็มรูปแบบที่มีสิทธิออกเสียง [15]

Consortium มีเป้าหมายที่ทะเยอทะยานในการแทนที่รูปแบบการเข้ารหัสอักขระที่มีอยู่ในที่สุดด้วย Unicode และรูปแบบ Unicode Transformation Format (UTF) มาตรฐาน เนื่องจากรูปแบบที่มีอยู่จำนวนมากมีขนาดและขอบเขตจำกัด และไม่เข้ากันกับสภาพแวดล้อม หลายภาษา

สคริปต์ครอบคลุม

แอปพลิเคชันสมัยใหม่จำนวนมากสามารถแสดงชุดย่อยจำนวนมากของสคริปต์จำนวนมากใน Unicodeดังที่แสดงในภาพหน้าจอนี้จากแอปพลิเคชันOpenOffice.org

Unicode ครอบคลุมสคริปต์เกือบทั้งหมด ( ระบบการเขียน ) ที่ใช้อยู่ในปัจจุบัน [16] [ ต้องการแหล่งที่ดีกว่า ]

สคริปต์ทั้งหมด 159 สคริปต์[17]รวมอยู่ในเวอร์ชันล่าสุดของ Unicode (ครอบคลุมตัวอักษร , abugidasและsyllabaries ) แม้ว่าจะมีสคริปต์ที่ยังไม่ได้เข้ารหัส โดยเฉพาะอย่างยิ่งสคริปต์ที่ใช้เป็นหลักในบริบททางประวัติศาสตร์ พิธีกรรม และวิชาการ การเพิ่มอักขระเพิ่มเติมในสคริปต์ที่เข้ารหัสแล้ว เช่นเดียวกับสัญลักษณ์ โดยเฉพาะอย่างยิ่งสำหรับคณิตศาสตร์และดนตรี (ในรูปแบบของโน้ตและสัญลักษณ์จังหวะ) ก็เกิดขึ้นเช่นกัน

คณะกรรมการแผนงาน Unicode ( Michael Everson , Rick McGowan, Ken Whistler, VS Umamaheswaran) [18]รักษารายการสคริปต์ที่เป็นตัวเลือกหรือผู้สมัครที่มีศักยภาพสำหรับการเข้ารหัสและการกำหนดบล็อคโค้ดเบื้องต้นในหน้า Unicode Roadmap [19]ของUnicodeเว็บไซต์สมาคม สำหรับสคริปต์บางรายการในแผนงาน เช่นสคริปต์ขนาดเล็กของJurchenและKhitanข้อเสนอการเข้ารหัสได้รับการจัดทำขึ้นแล้วและกำลังดำเนินการตามกระบวนการอนุมัติ สำหรับสคริปต์อื่นๆ เช่นMayan (นอกเหนือจากตัวเลข) และRongorongoยังไม่มีการเสนอใดๆ และพวกเขากำลังรอข้อตกลงเกี่ยวกับละครคาแรคเตอร์และรายละเอียดอื่นๆ จากชุมชนผู้ใช้ที่เกี่ยวข้อง

สคริปต์ประดิษฐ์สมัยใหม่บางตัวที่ยังไม่ได้รวมไว้ใน Unicode (เช่นTengwar ) หรือที่ไม่เข้าเกณฑ์ที่จะรวมใน Unicode เนื่องจากขาดการใช้งานจริง (เช่นKlingon ) อยู่ในConScript Unicode Registryพร้อมกับไม่เป็นทางการ แต่การกำหนดรหัส พื้นที่ใช้งานส่วนตัวที่ใช้กันอย่างแพร่หลาย

นอกจากนี้ยังมีMedieval Unicode Font Initiative ที่เน้นไปที่อักขระพิเศษในยุคกลางของละติน ส่วนหนึ่งของข้อเสนอเหล่านี้รวมอยู่ใน Unicode แล้ว

ความคิดริเริ่มการเข้ารหัสสคริปต์

The Script Encoding Initiative, [20]เป็นโครงการที่ดำเนินการโดย Deborah Anderson ที่มหาวิทยาลัยแห่งแคลิฟอร์เนีย, Berkeleyก่อตั้งขึ้นในปี 2002 โดยมีเป้าหมายในการจัดหาเงินทุนสำหรับข้อเสนอสำหรับสคริปต์ที่ยังไม่ได้เข้ารหัสในมาตรฐาน โครงการนี้ได้กลายเป็นแหล่งสำคัญของการเสนอเพิ่มเติมมาตรฐานในช่วงไม่กี่ปีที่ผ่านมา [21]

รุ่น

Unicode Consortium และInternational Organization for Standardization (ISO) ได้ร่วมกันพัฒนารายการเพลงที่ใช้ร่วมกันหลังจากการตีพิมพ์ครั้งแรกของThe Unicode Standardในปี 1991; Unicode และUniversal Coded Character Set (UCS) ของ ISO ใช้ชื่ออักขระและจุดรหัสเหมือนกัน อย่างไรก็ตาม เวอร์ชัน Unicode แตกต่างจาก ISO ที่เทียบเท่าในสองวิธีที่สำคัญ

แม้ว่า UCS จะเป็นแผนผังอักขระอย่างง่าย แต่ Unicode จะระบุกฎ อัลกอริทึม และคุณสมบัติที่จำเป็นเพื่อให้เกิดความสามารถในการทำงานร่วมกันระหว่างแพลตฟอร์มและภาษาต่างๆ ดังนั้นมาตรฐาน Unicode จึงรวมข้อมูลเพิ่มเติม ครอบคลุมหัวข้อต่างๆ ในเชิงลึก เช่น การเข้ารหัสระดับบิต การเรียงและการเรนเดอร์ นอกจากนี้ยังมีแค็ตตาล็อกคุณสมบัติอักขระที่ครอบคลุม รวมถึงคุณสมบัติที่จำเป็นสำหรับการสนับสนุนข้อความแบบสองทิศทางตลอดจนแผนภูมิภาพและชุดข้อมูลอ้างอิงเพื่อช่วยผู้ดำเนินการ ก่อนหน้านี้มาตรฐาน Unicodeถูกขายเป็นปริมาณการพิมพ์ที่มีข้อกำหนดหลักที่สมบูรณ์ ภาคผนวกมาตรฐาน และแผนภูมิโค้ด อย่างไรก็ตาม Unicode 5.0 ซึ่งเผยแพร่ในปี 2549 เป็นเวอร์ชันสุดท้ายที่พิมพ์ด้วยวิธีนี้ ตั้งแต่เวอร์ชัน 5.2 เป็นต้นไป อาจซื้อเฉพาะข้อกำหนดหลักที่เผยแพร่เป็นปกอ่อนแบบพิมพ์ตามความต้องการเท่านั้น[22] ในทางกลับกัน ข้อความฉบับเต็มได้รับการเผยแพร่ในรูปแบบ PDF ฟรีบนเว็บไซต์ Unicode

เหตุผลเชิงปฏิบัติสำหรับวิธีการเผยแพร่นี้เน้นถึงความแตกต่างที่สำคัญประการที่สองระหว่าง UCS และ Unicode นั่นคือความถี่ในการเผยแพร่เวอร์ชันที่อัปเดตและเพิ่มอักขระใหม่มาตรฐาน Unicodeได้เผยแพร่เวอร์ชันขยายประจำปีเป็นประจำ โดยในบางครั้งอาจมีเวอร์ชันที่เผยแพร่มากกว่าหนึ่งเวอร์ชันในปีปฏิทิน และในบางกรณีซึ่งเกิดขึ้นไม่บ่อยนักซึ่งต้องเลื่อนกำหนดการออกตามกำหนดการ ยกตัวอย่างเช่นในเดือนเมษายนปี 2020 เพียงหนึ่งเดือนหลังจากที่รุ่น 13.0 ได้รับการตีพิมพ์ใน Unicode Consortium ประกาศว่าพวกเขามีการเปลี่ยนแปลงวันที่ปล่อยตั้งใจสำหรับรุ่น 14.0 ผลักดันมันกลับมาหกเดือนตั้งแต่เดือนมีนาคม 2021 กันยายน 2021 เนื่องจากการCOVID-19 การแพร่ระบาด

จนถึงปัจจุบัน มาตรฐาน Unicode เวอร์ชันหลักและรองต่อไปนี้ได้รับการเผยแพร่แล้ว เวอร์ชันอัปเดต ซึ่งไม่มีการเปลี่ยนแปลงใดๆ กับละครของตัวละคร จะแสดงด้วยตัวเลขที่สาม (เช่น "เวอร์ชัน 4.0.1") และถูกละไว้ในตารางด้านล่าง [23]

เวอร์ชั่น วันที่ หนังสือ สอดคล้องตามISO/IEC 10646ฉบับ สคริปต์ ตัวละคร
รวม[บันทึกย่อ 1] การเพิ่มเติมที่โดดเด่น
1.0.0 [24] ตุลาคม 1991 ISBN  0-201-56788-1 (ฉบับที่ 1) 24 7,129 [tablenote 2] ละครเริ่มต้นครอบคลุมสคริปต์เหล่านี้: อาหรับ , อาร์เมเนีย , บังคลาเทศ , Bopomofo , ซีริลลิ , เทวนาครี , จอร์เจีย , กรีกและอียิปต์โบราณ , คุชราต , Gurmukhi , อังกูล , ภาษาฮิบรู , ฮิรางานะ , นาดา , คาตาคานะ , ลาว , ภาษาละติน , มาลายาลัม , โอริยา , ทมิฬ , เตลูกู , ไทยและทิเบต. [24]
1.0.1 [25] มิถุนายน 1992 ISBN  0-201-60845-6 (ฉบับที่ 2) 25 28,327
(เพิ่ม 21,204
ลบแล้ว 6)
ชุดเริ่มต้นของ 20,902 CJK Unified Ideographsถูกกำหนด [25]
1.1 [26] มิถุนายน 2536 ISO/IEC 10646-1: 1993 24 34,168
(เพิ่ม 5,963
ลบ 89 ออก
33 จัดประเภทใหม่
เป็น
อักขระควบคุม)
เพิ่มพยางค์ฮันกุลอีก 4,306 ตัวในชุดดั้งเดิม 2,350 อักขระ ทิเบตถอดออก (26)
2.0 [27] กรกฎาคม 2539 ไอเอสบีเอ็น 0-201-48345-9 ISO/IEC 10646-1: 1993 บวกแก้ไขเพิ่มเติม 5, 6 และ 7 25 38,885
(เพิ่ม 11,373
ลบ 6,656 ออก)
ชุดพยางค์ดั้งเดิมของฮันกึลถูกลบออก และเพิ่มชุดพยางค์ใหม่ของ 11,172 พยางค์ฮันกึลที่ตำแหน่งใหม่ ทิเบตได้เพิ่มกลับเข้าไปในตำแหน่งใหม่และด้วยละครคาแรคเตอร์ที่แตกต่างออกไป กลไกอักขระตัวแทนกำหนดและ Plane 15 และ Plane 16 Private Use Areasจัดสรร [27]
2.1 [28] พฤษภาคม 1998 ISO/IEC 10646-1: 1993 บวกการแก้ไข 5, 6 และ 7 ตลอดจนอักขระสองตัวจากการแก้ไข 18 25 38,887
(2 เพิ่ม)
เครื่องหมายยูโรและเปลี่ยนวัตถุตัวละครเพิ่ม (28)
3.0 กันยายน 2542 ไอเอสบีเอ็น 0-201-61633-5 ISO/IEC 10646-1:2000 38 49,194
(เพิ่ม 10,307)
Cherokee , Ethiopic , Khmer , Mongolian , Burmese , Ogham , Runic , Sinhala , Syriac , Thaana , Unified Canadian Aboriginal Syllabics , และYi Syllables ที่เพิ่มเข้ามา รวมถึงชุดของรูปแบบอักษรเบรลล์ [29]
3.1 มีนาคม 2544 ISO/IEC 10646-1:2000

ISO/IEC 10646-2:2001

41 94,140
(เพิ่ม 44,946)
เพิ่ม Deseret , GothicและOld Italicรวมถึงชุดสัญลักษณ์สำหรับดนตรีตะวันตกและดนตรี ByzantineและCJK Unified Ideographsเพิ่มเติม 42,711 รายการ [30]
3.2 มีนาคม 2545 ISO/IEC 10646-1:2000 บวกแก้ไข 1

ISO/IEC 10646-2:2001

45 95,156
(เพิ่ม 1,016)
ฟิลิปปินส์สคริปต์Buhid , ภาษาฮานุโน , ภาษาตากาล็อกและTagbanwaเพิ่ม [31]
4.0 เมษายน 2546 ไอเอสบีเอ็น 0-321-18578-1 ISO/IEC 10646:2003 52 96,382
(เพิ่ม 1,226)
อักษรไซปรัส , Limbu , ตรงข , ออสมาเนีย , ชอว์ , ไทเลอและUgariticเพิ่มเช่นเดียวกับสัญลักษณ์แฉก (32)
4.1 มีนาคม 2548 ISO/IEC 10646:2003 บวกแก้ไข 1 59 97,655
(1,273 เพิ่ม)
บูกิส , กลาโกลิติก , Kharoshthi , นิวไทลื้อ , เก่าเปอร์เซีย , Syloti NagriและTifinaghเพิ่มและอียิปต์โบราณถูก disunified จากภาษากรีก เพิ่มตัวเลขกรีกโบราณและสัญลักษณ์ทางดนตรีด้วย [33]
5.0 กรกฎาคม 2549 ไอเอสบีเอ็น 0-321-48091-0 ISO/IEC 10646:2003 บวกการแก้ไข 1 และ 2 รวมถึงอักขระสี่ตัวจากการแก้ไข 3 64 99,024
(เพิ่ม 1,369)
บาหลี , ฟอร์ม , อึนโก , พักส์-PAและPhoenicianเพิ่ม [34]
5.1 เมษายน 2551 ISO/IEC 10646:2003 บวกแก้ไข 1, 2, 3 และ 4 75 100,648
(เพิ่ม 1,624)
คา , จาม , Kayah Li , Lepcha , ไลเซีย , ลีเดีย , เฒ่า Chiki , Rejang , Saurashtra , ซุนดาและVaiเพิ่มเช่นเดียวกับชุดของสัญลักษณ์สำหรับPhaistos Disc , กระเบื้องไพ่นกกระจอกและกระเบื้องโดมิโน นอกจากนี้ยังมีส่วนเพิ่มเติมที่สำคัญสำหรับภาษาพม่า การเพิ่มเติมตัวอักษรและตัวย่อแบบ Scribal ที่ใช้ในต้นฉบับยุคกลางและการเพิ่มตัวพิมพ์ใหญ่[35]
5.2 ตุลาคม 2552 ISBN  978-1-936213-00-9 ISO/IEC 10646:2003 บวกแก้ไขเพิ่มเติม 1, 2, 3, 4, 5 และ 6 90 107,296
(6,648 เพิ่ม)
, Bamum , อักษรอียิปต์ (คนการ์ดิเนอชุดประกอบด้วย 1,071 ตัวอักษร) อิมพีเรียลอราเมอิก , จารึกปาห์ลาวี , จารึกคู่ปรับ , ชวา , ไกถี , ลีซอ , Meetei Mayek , Old South อาหรับ , เก่าเตอร์ก , ซามาเรีย , ธรรมและไทเวียดนามเพิ่ม เพิ่มเติม 4,149 CJK Unified Ideographs (CJK-C) รวมถึง Jamo แบบขยายสำหรับOld Hangulและอักขระสำหรับเวทสันสกฤต . (36)
6.0 ตุลาคม 2010 ISBN  978-1-936213-01-6 ISO/IEC 10646:2010 บวกเครื่องหมายรูปีอินเดีย 93 109,384
(2,088 เพิ่ม)
Batak , Brahmi , Mandaic , บัตรเล่นสัญลักษณ์การขนส่งและแผนที่สัญลักษณ์สัญลักษณ์เล่นแร่แปรธาตุ , อีโมติคอนและอีโมจิ เพิ่มCJK Unified Ideographs (CJK-D) อีก 222 รายการ [37]
6.1 มกราคม 2555 ISBN  978-1-936213-02-3 ISO/IEC 10646:2012 100 110,116
(เพิ่ม 732)
Chakma , Meroitic เล่นหาง , กราฟฟิค Meroitic , แม้ว , Sharada , โซระ Sompengและตากรี [38]
6.2 กันยายน 2555 ISBN  978-1-936213-07-8 ISO/IEC 10646:2012 บวกเครื่องหมายลีราตุรกี 100 110,117
(1 เพิ่ม)
สัญญาณลีร่าตุรกี [39]
6.3 กันยายน 2013 ไอ 978-1-936213-08-5 ISO/IEC 10646:2012 บวกหกอักขระ 100 110,122
(เพิ่ม 5 รายการ)
5 อักขระการจัดรูปแบบสองทิศทาง [40]
7.0 มิถุนายน 2014 ISBN  978-1-936213-09-2 ISO/IEC 10646:2012 บวกแก้ไข 1 และ 2 รวมทั้งเครื่องหมายรูเบิล 123 112,956
(2,834 เพิ่ม)
Bassa Vah , ผิวขาวแอลเบเนีย , Duployan , Elbasan , Grantha , Khojki , Khudawadi , ตรงที่ , Mahajani , Manichaean , Mende Kikakui , Modi , Mro , Nabataean , ทิศตะวันตกเฉียงเหนืออาหรับ , เก่าเพอร์มิค , อักษรม้ง , Palmyrene , เพาคินฮาว , Psalter ปาห์ลาวี , Siddham , Tirhuta , Warang ซิตี้และดิงบัตส์ [41]
8.0 มิถุนายน 2015 ISBN  978-1-936213-10-8 ISO/IEC 10646:2014 บวกการแก้ไข 1 เช่นเดียวกับเครื่องหมาย Lariแนวคิดแบบรวม CJK เก้ารายการ และอักขระอีโมจิ 41 ตัว[42] 129 120,672
(เพิ่ม 7,716)
Ahom , อักษรอียิปต์โบราณอนาโตเลีย , Hatran , Multani , ฮังการีเก่า , SignWriting , 5,771 CJK unified ideographs , ชุดของตัวพิมพ์เล็กสำหรับCherokeeและตัวปรับแต่งโทนสีผิวอีโมจิห้าตัว [43]
9.0 มิถุนายน 2559 ISBN  978-1-936213-13-9 ISO/IEC 10646:2014 บวกแก้ไข 1 และ 2 รวมถึง Adlam, Newa, สัญลักษณ์ทีวีญี่ปุ่น, อีโมจิและสัญลักษณ์ 74 รายการ[44] 135 128,172
(เพิ่ม 7,500)
Adlam , Bhaiksuki , Marchen , Newa , เซจ , Tangutและ 72 อีโมจิ [45] [46]
10.0 มิถุนายน 2017 ISBN  978-1-936213-16-0 ISO/IEC 10646:2017 บวกอักขระอีโมจิ 56 ตัว, อักขระhentaigana 285 ตัว และอักขระ Zanabazar Square 3 ตัว[47] 139 136,690
(เพิ่ม 8,518)
Zanabazar สแควร์ , Soyombo , Masaram Gondi , Nüshu , hentaigana (ที่ไม่ได้มาตรฐานฮิรางานะ ) 7494 CJK แบบครบวงจร ideographs 56 อีโมจิและBitcoinสัญลักษณ์[48]
11.0 มิถุนายน 2018 ISBN  978-1-936213-19-1 ISO/IEC 10646:2017 บวกการแก้ไข 1 รวมทั้งอักษรตัวพิมพ์ใหญ่ Mtavruli จอร์เจีย 46 ตัว, อุดมการณ์แบบรวม CJK 5 แบบ และอักขระอีโมจิ 66 ตัว [49] 146 137,374
(เพิ่ม 684)
Dogra , จอร์เจีย MtavruliตัวอักษรทุนGunjala Gondi , Hanifi โรฮิงญา , หมายเลขสันสกฤต siyaq , Makasar , Medefaidrin , เก่าซอคเดียนและซอคเดียน , เลขยัน 5 ความจำเป็นเร่งด่วนCJK แบบครบวงจร ideographsสัญลักษณ์สำหรับหมากรุก (หมากรุกจีน) และการจัดอันดับดาวและ 145 อีโมจิ . [50]
12.0 มีนาคม 2019 ISBN  978-1-936213-22-1 ISO/IEC 10646:2017 บวกการแก้ไข 1 และ 2 รวมทั้งอักขระเพิ่มเติม 62 ตัว [51] 150 137,928
(เพิ่ม 554)
Elymaic , Nandinagari , Nyiakeng Puachue Hmong , Wancho , Miao scriptเพิ่มเติมสำหรับหลายภาษา Miao และ Yi ในประเทศจีน, ฮิรางานะและคาตาคานะตัวอักษรขนาดเล็กสำหรับการเขียนภาษาญี่ปุ่นโบราณ, เศษส่วนประวัติศาสตร์ทมิฬและสัญลักษณ์, ตัวอักษรลาวสำหรับภาษาบาลี , ตัวอักษรละตินสำหรับการทับศัพท์ทางอียิปต์และภาษาอูการิติก , ตัวควบคุมรูปแบบอักษรอียิปต์โบราณ และอีโมจิ 61 ตัว [52]
12.1 พฤษภาคม 2019 ISBN  978-1-936213-25-2 150 137,929
(1 เพิ่ม)
เพิ่มตัวอักษรตัวเดียวที่ U + 32FF สำหรับรูปแบบรัดตารางของชื่อของยุค REIWA [53]
13.0 [54] มีนาคม 2020 ISBN  978-1-936213-26-9 ISO/IEC 10646:2020 [55] 154 143,859
(เพิ่ม 5,930)
Chorasmian , Dives Akuru , Khitan small script , Yezidi , 4,969 CJK unified ideographs เพิ่ม (รวมถึง 4,939 ในExt. G ) เพิ่มเติมสคริปต์ภาษาอาหรับที่ใช้ในการเขียนHausa , Wolofและภาษาอื่น ๆ ในแอฟริกาและส่วนเพิ่มเติมอื่น ๆ ที่ใช้ในการเขียนHindkoและPunjabiใน ปากีสถาน, Bopomofo เพิ่มเติมใช้สำหรับสัญลักษณ์กวางตุ้ง, ใบอนุญาต Creative Commons, อักขระกราฟิกสำหรับความเข้ากันได้กับเทเลเท็กซ์และระบบคอมพิวเตอร์ที่บ้านตั้งแต่ทศวรรษ 1970 และ 1980 และอีโมจิ 55 ตัว [54]
14.0 [56] กันยายน 2564 ISBN  978-1-936213-29-0 159 144,697
(เพิ่ม 838)
Toto , Cypro-Minoan , Vithkuqi , Old Uyghur , Tangsa , การเพิ่มอักษรละตินเพื่อใช้ในIPAแบบขยาย, การเพิ่มสคริปต์ภาษาอาหรับสำหรับใช้ในภาษาต่างๆ ในแอฟริกาและในอิหร่าน, ปากีสถาน, มาเลเซีย, อินโดนีเซีย, ชวา และบอสเนีย และเพื่อเขียนคำให้เกียรติ , เพิ่มเติมสำหรับการใช้อัลกุรอาน, เพิ่มเติมอื่นๆ เพื่อรองรับภาษาในอเมริกาเหนือ, ฟิลิปปินส์, อินเดีย และมองโกเลีย, การเพิ่มสัญลักษณ์สกุลเงินซอมคีร์กีซสถาน , รองรับโน้ตดนตรีZnameennyและ 37 อีโมจิ [56]
  1. ^ จำนวนตัวอักษรที่ระบุไว้สำหรับแต่ละรุ่น Unicode เป็นจำนวนรวมของกราฟิกและรูปแบบตัวอักษร (เช่นไม่รวมตัวอักษรส่วนตัวการใช้งาน ,ตัวควบคุม , noncharactersและจุดรหัสตัวแทน )
  2. ^ ไม่นับ 'ช่องว่าง' หรืออักขระที่ไม่พิมพ์ 33 ตัว (ทั้งหมด 7,163 ตัว) [24]

สถาปัตยกรรมและศัพท์เฉพาะ

มาตรฐาน Unicode กำหนดCodespace, [57]ชุดของค่าตัวเลขตั้งแต่ 0 ถึง 10FFFF 16 , [58]ที่เรียกว่าจุดรหัส[59]และแสดงเป็น U + 0000 ผ่าน U + 10FFFF ( "U +" บวกค่าจุดรหัส ในเลขฐานสิบหก , ใช้ได้กับศูนย์ชั้นนำเป็นสิ่งจำเป็นที่จะส่งผลในการต่ำสุดของตัวเลขสี่หลักซึ่งเป็นe. กรัม. , U + 00F7 สำหรับการเข้าสู่ระบบส่วน÷แต่ U + 13254 สำหรับอักษรอียิปต์โบราณอียิปต์ Hiero O4.pngการกำหนดพักพิงกกหรือผนังคดเคี้ยว . [60] ของเหล่านี้ 2 16 + 2 20จุดรหัสที่กำหนด รหัสชี้จาก U+D800 ถึง U+DFFF ซึ่งใช้ในการเข้ารหัสคู่ตัวแทนในUTF-16ถูกสงวนไว้โดยมาตรฐานและไม่สามารถใช้ในการเข้ารหัสอักขระที่ถูกต้อง ส่งผลให้รวมสุทธิ 2 16 − 2 11 + 2 20 = 1,112,064 จุดรหัสที่เป็นไปได้ซึ่งสอดคล้องกับอักขระ Unicode ที่ถูกต้อง จุดโค้ดเหล่านี้ไม่จำเป็นต้องสอดคล้องกับอักขระที่มองเห็นได้ทั้งหมด ตัวอย่างเช่น หลายรายการถูกกำหนดให้กับรหัสควบคุม เช่น การขึ้นบรรทัดใหม่

รหัสเครื่องบินและบล็อก

Unicode codespace แบ่งออกเป็น 17 ระนาบโดยมีหมายเลข 0 ถึง 16:

ทุกจุดรหัสใน BMP มีการเข้าถึงเป็นหน่วยเดียวในรหัสUTF-16เข้ารหัสและสามารถเข้ารหัสในหนึ่งสองหรือสามไบต์ในUTF-8 จุดรหัสในเครื่องบิน 1 ถึง 16 ( เครื่องบินเสริม ) มีการเข้าถึงเป็นคู่ตัวแทนใน UTF-16 และเข้ารหัสเป็นสี่ไบต์ใน UTF-8

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

คุณสมบัติหมวดหมู่ทั่วไป

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

หมวดหมู่ทั่วไป( คุณสมบัติอักขระ Unicode ) [a]
ค่า หมวดหมู่ วิชาเอก ผู้เยาว์ ประเภทพื้นฐาน[b] ตัวละครที่ได้รับมอบหมาย[b] นับ(ณ 14.0)
หมายเหตุ
 
L, จดหมาย; LC, Cased Letter (Lu, Ll และ Lt เท่านั้น) [c]
ลู่ ตัวพิมพ์ใหญ่ กราฟฟิค อักขระ 1,831
NS อักษรตัวพิมพ์เล็ก กราฟฟิค อักขระ 2,227
ร.ต.อ จดหมายชื่อเรื่อง กราฟฟิค อักขระ 31 อักษรควบที่มีตัวพิมพ์ใหญ่ตามด้วยอักษรตัวพิมพ์เล็ก (เช่นDž , Lj , Nj , และDz )
หื้มม จดหมาย, ตัวแก้ไข กราฟฟิค อักขระ 334 จดหมายปรับปรุง
หล่อ จดหมาย อื่นๆ กราฟฟิค อักขระ 127,333 Ideographหรือตัวอักษรในหนึ่งตัวอักษร unicase
เอ็ม มาร์ค
มิน มาร์ค ไม่เว้นวรรค กราฟฟิค อักขระ 1,950
Mc ทำเครื่องหมายระยะห่างรวม กราฟฟิค อักขระ 445
ผม ทำเครื่องหมายล้อมรอบ กราฟฟิค อักขระ 13
N, จำนวน
NS ตัวเลข ทศนิยม กราฟฟิค อักขระ 660 ทั้งหมดเหล่านี้และเฉพาะเหล่านี้มีประเภทตัวเลข = De [d]
Nl ตัวเลข ตัวอักษร กราฟฟิค อักขระ 236 ตัวเลขประกอบด้วยตัวอักษรหรือสัญลักษณ์คล้ายตัวอักษร (เช่นเลขโรมัน )
เลขที่ จำนวน, อื่นๆ กราฟฟิค อักขระ 895 เช่นเศษส่วนหยาบคาย , ยกและห้อยตัวเลข
P, เครื่องหมายวรรคตอน
พีซี เครื่องหมายวรรคตอนตัวเชื่อมต่อ กราฟฟิค อักขระ 10 รวม "_" ขีดล่าง
Pd เครื่องหมายวรรคตอน dash กราฟฟิค อักขระ 26 รวมอักขระยัติภังค์หลายตัว
ปล เครื่องหมายวรรคตอน เปิด กราฟฟิค อักขระ 79 อักขระ วงเล็บเปิด
วิชาพลศึกษา เครื่องหมายวรรคตอน ปิด กราฟฟิค อักขระ 77 อักขระวงเล็บปิด
ปี่ เครื่องหมายวรรคตอน ใบเสนอราคาเริ่มต้น กราฟฟิค อักขระ 12 เปิดเครื่องหมายคำพูด ไม่รวมเครื่องหมายอัญประกาศ "เป็นกลาง" ของ ASCII อาจจะทำตัวเหมือน Ps หรือ Pe ขึ้นอยู่กับการใช้งาน
Pf เครื่องหมายวรรคตอน ใบเสนอราคาสุดท้าย กราฟฟิค อักขระ 10 เครื่องหมายคำพูดปิด อาจจะทำตัวเหมือน Ps หรือ Pe ขึ้นอยู่กับการใช้งาน
โป เครื่องหมายวรรคตอน อื่นๆ กราฟฟิค อักขระ 605
S, สัญลักษณ์
Sm สัญลักษณ์คณิตศาสตร์ กราฟฟิค อักขระ 948 สัญลักษณ์ทางคณิตศาสตร์ (เช่น+ , , = , × , ÷ , , , ) ไม่รวมวงเล็บและวงเล็บที่อยู่ในหมวดหมู่ Ps และ Pe ยังไม่รวม! , * , - , หรือ/ซึ่งแม้จะใช้เป็นตัวดำเนินการทางคณิตศาสตร์บ่อยครั้ง แต่โดยหลักแล้วจะถือว่าเป็น "เครื่องหมายวรรคตอน"
Sc สัญลักษณ์ สกุลเงิน กราฟฟิค อักขระ 63 สัญลักษณ์สกุลเงิน
Sk สัญลักษณ์ตัวดัดแปลง กราฟฟิค อักขระ 125
ดังนั้น สัญลักษณ์ อื่นๆ กราฟฟิค อักขระ 6,605
Z, ตัวคั่น
Zs ตัวแยกช่องว่าง กราฟฟิค อักขระ 17 รวมช่องว่าง แต่ไม่ใช่TAB , CRหรือLFซึ่งก็คือ Cc
Zl ตัวแยกบรรทัด รูปแบบ อักขระ 1 เฉพาะU+2028 LINE SEPARATOR (LSEP)
Zp ตัวคั่นวรรค รูปแบบ อักขระ 1 เฉพาะU+2029ย่อหน้าSEPARATOR (PSEP)
C, อื่นๆ
ซีซี อื่นๆ, ควบคุม ควบคุม อักขระ 65 (จะไม่เปลี่ยนแปลง) [ง] ไม่มีชื่อ[e] <control>
Cf อื่นๆ, รูปแบบ รูปแบบ อักขระ 163 รวมเครื่องหมายยัติภังค์อักขระควบคุมที่เข้าร่วม ( zwnjและzwj ) อักขระควบคุมเพื่อรองรับข้อความสองทิศทางและอักขระ แท็กภาษา
Cs อื่นๆ, ตัวแทน ตัวแทน ไม่ (ใช้เฉพาะในUTF-16 ) 2,048 (ไม่มีวันเปลี่ยนแปลง) [ง] ไม่มีชื่อ[e] <ตัวแทน>
โค อื่นๆ, ของใช้ส่วนตัว ของใช้ส่วนตัว ตัวละคร (แต่ไม่ได้ระบุการตีความ) ทั้งหมด 137,468 (จะไม่เปลี่ยนแปลง) [d] ( 6,400 ในBMP , 131,068 ในเครื่องบิน 15–16 ) ไม่มีชื่อ[e] <private-use>
Cn อื่นๆ ไม่ได้รับมอบหมาย ไม่ใช่ตัวละคร ไม่ 66 (จะไม่เปลี่ยนแปลง) [d] ไม่มีชื่อ[e] <noncharacter>
ที่สงวนไว้ ไม่ 829,768 ไม่มีชื่อ[e] <จองแล้ว>
  1. ^ "ตารางที่ 4-4: หมวดหมู่ทั่วไป" (PDF) . มาตรฐาน Unicode สมาคม Unicode กันยายน 2564
  2. ^ a b "ตารางที่ 2-3: ประเภทของจุดรหัส" (PDF) . มาตรฐาน Unicode สมาคม Unicode กันยายน 2564
  3. ^ "5.7.1 ค่าหมวดหมู่ทั่วไป" . UTR # 44: Unicode ฐานข้อมูลตัวอักษร สมาคม Unicode 2020-03-04.
  4. ^ a b c d e นโยบายความเสถียรในการเข้ารหัสอักขระ Unicode: นโยบายความเสถียรของค่าคุณสมบัติความเสถียร: กลุ่ม gc บางกลุ่มจะไม่เปลี่ยนแปลง gc=Nd สอดคล้องกับ Numeric Type=De (ทศนิยม)
  5. ^ อี "ตาราง 4-9: การก่อสร้างของป้ายรหัสพอยท์" (PDF) มาตรฐาน Unicode สมาคม Unicode กันยายน 2564 โค้ดป้ายจุดอาจถูกใช้เพื่อระบุจุดรหัสนิรนาม เช่น <control- ฮะฮะ >, <control-0088> ชื่อยังคงว่างเปล่า ซึ่งสามารถป้องกันการแทนที่โดยไม่ได้ตั้งใจ ในเอกสารประกอบ ชื่อตัวควบคุมที่มีรหัสควบคุมที่แท้จริง Unicode ยังใช้ <ไม่ใช่อักขระ> สำหรับ <noncharacter>

จุดรหัสในช่วง U+D800–U+DBFF (1,024 จุดรหัส) เรียกว่าจุดรหัสตัวแทนระดับสูงและจุดรหัสในช่วง U+DC00–U+DFFF (1,024 จุดรหัส) เรียกว่าตัวแทนต่ำ จุดรหัส จุดรหัสตัวแทนสูงที่ตามด้วยจุดรหัสตัวแทนต่ำจะสร้างคู่ตัวแทนเสมือนในUTF-16เพื่อแสดงจุดรหัสที่มากกว่า U+FFFF มิฉะนั้นจะใช้จุดรหัสเหล่านี้ไม่ได้ (กฎนี้มักถูกละเลยในทางปฏิบัติโดยเฉพาะเมื่อไม่ได้ใช้ UTF-16)

ชุดโค้ดพอยต์ขนาดเล็กรับประกันว่าจะไม่ถูกใช้สำหรับการเข้ารหัสอักขระ แม้ว่าแอปพลิเคชันอาจใช้จุดโค้ดเหล่านี้ภายในได้หากต้องการ ไม่มีอักขระเหล่านี้หกสิบหกตัว : U+FDD0–U+FDEF และจุดโค้ดใดๆ ที่ลงท้ายด้วยค่า FFFE หรือ FFFF (เช่น U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, ... U +10FFFE, U+10FFFF). ชุดของ noncharacters นั้นเสถียรและจะไม่มีการกำหนด noncharacters ใหม่ [61]เช่นเดียวกับตัวแทนเสมือน กฎที่ไม่สามารถใช้สิ่งเหล่านี้ได้มักจะถูกละเว้น แม้ว่าการดำเนินการของเครื่องหมายลำดับไบต์จะถือว่า U+FFFE จะไม่มีวันเป็นจุดโค้ดแรกในข้อความ

การยกเว้นตัวแทนเสมือนและอักขระที่ไม่ใช่อักขระจะทำให้มีรหัส 1,111,998 คะแนนที่พร้อมใช้งาน

จุดรหัสส่วนตัวถือเป็นอักขระที่กำหนด แต่ไม่มีการตีความที่ระบุโดยมาตรฐาน Unicode [62]ดังนั้นการแลกเปลี่ยนอักขระดังกล่าวจำเป็นต้องมีข้อตกลงระหว่างผู้ส่งและผู้รับในการตีความ มีพื้นที่ใช้งานส่วนตัวสามแห่งใน Unicode codespace:

  • พื้นที่ใช้งานส่วนตัว: U+E000–U+F8FF (6,400 ตัวอักษร),
  • พื้นที่ใช้งานส่วนตัวเสริม-A: U+F0000–U+FFFFD (65,534 อักขระ),
  • พื้นที่ใช้งานส่วนตัวเสริม-B: U+100000–U+10FFFD (65,534 อักขระ)

ตัวอักษรกราฟิกเป็นตัวละครที่กำหนดโดย Unicode ที่จะมีความหมายโดยเฉพาะอย่างยิ่งและอาจมีการมองเห็นสัญลักษณ์รูปทรงหรือเป็นตัวแทนของพื้นที่ที่มองเห็นได้ สำหรับ Unicode 14.0 มีอักขระกราฟิก 144,532 ตัว

อักขระรูปแบบคืออักขระที่ไม่มีลักษณะที่ปรากฏ แต่อาจมีผลต่อลักษณะที่ปรากฏหรือพฤติกรรมของอักขระใกล้เคียง ตัวอย่างเช่น อาจใช้U+200C ZERO WIDTH NON-JOINERและU+200D ZERO WIDTH JOINERเพื่อเปลี่ยนพฤติกรรมการกำหนดรูปร่างเริ่มต้นของอักขระที่อยู่ติดกัน (เช่น เพื่อยับยั้งการควบแน่นหรือร้องขอการสร้างเส้นควบ) มีอักขระรูปแบบ 165 ตัวใน Unicode 14.0

หกสิบห้าจุดรหัส (U + 0000-U + 001F และ U + 007F-U + 009F) จะถูกสงวนไว้เป็นการควบคุมรหัสและสอดคล้องกับC0 C1 และรหัสควบคุมที่กำหนดไว้ในมาตรฐาน ISO / IEC 6429 U+0009 (Tab), U+000A (Line Feed) และ U+000D (Carriage Return) ใช้กันอย่างแพร่หลายในข้อความที่เข้ารหัส Unicode ในทางปฏิบัติ จุดโค้ด C1 มักถูกแปลอย่างไม่เหมาะสม ( mojibake ) เนื่องจากเป็นอักขระWindows-1252แบบเดิมที่ใช้โดยข้อความภาษาอังกฤษและยุโรปตะวันตกบางส่วน

ตัวอักษรกราฟิกตัวอักษรรูปแบบตัวอักษรรหัสควบคุมและตัวอักษรการใช้งานส่วนตัวเป็นที่รู้จักกันเป็นตัวละครที่ได้รับมอบหมาย จุดรหัสที่สงวนไว้คือจุดรหัสที่พร้อมใช้งาน แต่ยังไม่ได้กำหนด สำหรับ Unicode 14.0 มีจุดรหัสที่สงวนไว้ 829,768 จุด

ตัวละครที่เป็นนามธรรม

ชุดของอักขระกราฟิกและรูปแบบที่กำหนดโดย Unicode ไม่สอดคล้องโดยตรงกับรายการของอักขระนามธรรมที่แสดงภายใต้ Unicode Unicode เข้ารหัสอักขระโดยเชื่อมโยงอักขระนามธรรมกับจุดโค้ดเฉพาะ[63]อย่างไรก็ตาม ไม่ใช่ทุกอักขระที่เป็นนามธรรมจะถูกเข้ารหัสเป็นอักขระ Unicode ตัวเดียว และอักขระนามธรรมบางตัวอาจแสดงเป็น Unicode โดยลำดับของอักขระตั้งแต่สองตัวขึ้นไป ยกตัวอย่างเช่นตัวอักษรตัวเล็กละติน "ฉัน" กับออกอแนกเป็นจุดดังกล่าวข้างต้นและสำเนียงเฉียบพลันซึ่งเป็นสิ่งจำเป็นในลิทัวเนีย, แสดงโดยลำดับอักขระ U+012F, U+0307, ​​U+0301 Unicode รักษารายการลำดับอักขระที่มีชื่อเฉพาะสำหรับอักขระนามธรรมที่ไม่ได้เข้ารหัสโดยตรงใน Unicode [64]

อักขระกราฟิก รูปแบบ และการใช้งานส่วนตัวทั้งหมดมีชื่อเฉพาะและไม่เปลี่ยนรูปแบบซึ่งสามารถใช้ระบุได้ ความไม่เปลี่ยนรูปแบบนี้ได้รับการรับรองตั้งแต่ Unicode เวอร์ชัน 2.0 โดยนโยบายความเสถียรของชื่อ[61]ในกรณีที่ชื่อมีข้อบกพร่องอย่างร้ายแรงและทำให้เข้าใจผิด หรือมีข้อผิดพลาดในการพิมพ์อย่างร้ายแรง อาจมีการกำหนดนามแฝงที่เป็นทางการ และขอแนะนำให้ใช้นามแฝงที่เป็นทางการแทนชื่อตัวละครที่เป็นทางการ ตัวอย่างเช่นU+A015YI SYLLABLE WUมีนามแฝงอย่างเป็นทางการYI SYLLABLE ITERATION MARKและU+FE18PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRA KC ET ( sic ) มีนามแฝงที่เป็นทางการ ฟอร์มการนำเสนอสำหรับแนวตั้งสีขาว Lenticular BRA CK ET [65]

อักขระสำเร็จรูปเทียบกับคอมโพสิต

Unicode มีกลไกสำหรับแก้ไขอักขระที่ขยายรายการเพลงที่รองรับอย่างมาก ซึ่งครอบคลุมถึงการใช้เครื่องหมายกำกับเสียงที่อาจเพิ่มหลังอักขระพื้นฐานโดยผู้ใช้ อาจมีการใช้เครื่องหมายกำกับเสียงแบบผสมหลายตัวพร้อมกันกับอักขระตัวเดียวกัน Unicode ยังมีชุดค่าผสมของตัวอักษร/เครื่องหมายกำกับเสียงส่วนใหญ่ในรูปแบบprecomposedในการใช้งานปกติ สิ่งเหล่านี้ทำให้การแปลงเป็นและจากการเข้ารหัสแบบเดิมง่ายขึ้น และอนุญาตให้แอปพลิเคชันใช้ Unicode เป็นรูปแบบข้อความภายในโดยไม่ต้องใช้อักขระที่รวมกัน ตัวอย่างเช่นéสามารถแสดงเป็น Unicode เป็นU+ 0065 ( LATIN SMALL LETTER E ) ตามด้วย U+0301 ( COMBINING ACUTE ACCENT) แต่ยังสามารถแสดงเป็นอักขระล่วงหน้า U+00E9 ( LATIN SMALL LETTER E WITH ACUTE ) ได้ ดังนั้น ในหลายกรณี ผู้ใช้มีหลายวิธีในการเข้ารหัสอักขระเดียวกัน ที่จะจัดการกับเรื่องนี้ Unicode ให้กลไกของความเท่าเทียมที่ยอมรับ

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

ตัวอักษร CJKปัจจุบันมีรหัสเฉพาะสำหรับรูปแบบ precomposed ของพวกเขา อย่างไรก็ตาม อักขระเหล่านี้ส่วนใหญ่ประกอบด้วยองค์ประกอบที่ง่ายกว่า (เรียกว่าRadical ) ดังนั้นโดยหลักการแล้ว Unicode สามารถย่อยสลายได้เหมือนกับที่ทำกับฮันกึล สิ่งนี้จะลดจำนวนจุดรหัสที่จำเป็นลงอย่างมาก ในขณะที่อนุญาตให้แสดงอักขระที่เป็นไปได้แทบทุกตัว (ซึ่งอาจช่วยแก้ปัญหาบางอย่างที่เกิดจากการรวมกลุ่มของ Han ) ความคิดที่คล้าย ๆ กันคือใช้โดยบางส่วนวิธีการป้อนข้อมูลเช่นCangjieและWubiอย่างไรก็ตาม ความพยายามที่จะทำเช่นนี้สำหรับการเข้ารหัสอักขระได้สะดุดกับความจริงที่ว่าตัวอักษรจีนไม่สลายง่ายหรือสม่ำเสมอเหมือนที่ฮันกึลทำ

ชุดของอนุมูลถูกจัดให้อยู่ใน Unicode 3.0 (อนุมูล CJK ระหว่าง U + 2E80 และ U + 2EFF อนุมูล Kangxi ใน U + 2F00 เพื่อ U + 2FDF และตัวอักษรคำอธิบาย ideographic จาก U + 2FF0 เพื่อ U + 2FFB) แต่มาตรฐาน Unicode (ch. 12.2 ของ Unicode 5.2) เตือนไม่ให้ใช้ลำดับคำอธิบายเชิงอุดมคติเป็นตัวแทนทางเลือกสำหรับอักขระที่เข้ารหัสก่อนหน้านี้:

กระบวนการนี้แตกต่างจากการเข้ารหัสที่เป็นทางการของอุดมการณ์ ไม่มีคำอธิบายตามบัญญัติของแนวคิดเชิงอุดมคติที่ไม่ได้เข้ารหัส ไม่มีความหมายที่กำหนดให้กับ ideographs ที่อธิบาย; ไม่มีความเท่าเทียมกันที่กำหนดไว้สำหรับ ideographs ที่อธิบายไว้ ตามแนวคิด คำอธิบายเชิงอุดมคตินั้นคล้ายกับวลีภาษาอังกฤษ "an 'e' ที่เน้นเสียงแหลม" มากกว่าลำดับอักขระ <U+0065, U+0301>

ลีเกเจอร์

สคริปต์จำนวนมากรวมทั้งภาษาอาหรับและDevanāgarīมีกฎ orthographic พิเศษที่ต้องมีการรวมกันของบางอย่าง letterforms ที่จะรวมกันเป็นพิเศษในรูปแบบรัด กฎเกณฑ์ที่ควบคุมการสร้างเส้นควบอาจค่อนข้างซับซ้อน โดยต้องใช้เทคโนโลยีการสร้างสคริปต์พิเศษ เช่น ACE (Arabic Calligraphic Engine โดย DecoType ในทศวรรษ 1980 และใช้เพื่อสร้างตัวอย่างภาษาอาหรับทั้งหมดในฉบับพิมพ์ของมาตรฐาน Unicode) ซึ่งกลายเป็นข้อพิสูจน์ ของแนวคิดสำหรับOpenType (โดย Adobe และ Microsoft), Graphite (โดยSIL International ) หรือAAT (โดย Apple)

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

ชุดย่อยมาตรฐาน

ชุดย่อยของ Unicode หลายชุดได้รับการกำหนดมาตรฐาน: Microsoft Windows เนื่องจากWindows NT 4.0รองรับWGL-4 ที่มีอักขระ 657 ตัว ซึ่งถือว่าสนับสนุนภาษายุโรปร่วมสมัยทั้งหมดโดยใช้สคริปต์ละติน กรีก หรือซิริลลิก ชุดย่อยมาตรฐานอื่น ๆ ของ Unicode รวมถึงชุดย่อยหลายภาษาของยุโรป: [66]

MES-1 (อักษรละตินเท่านั้น 335 อักขระ), MES-2 (อักขระละติน กรีก และซิริลลิก 1062 ตัว) [67]และ MES-3A & MES-3B (ชุดย่อยที่ใหญ่กว่าสองชุด ไม่ได้แสดงที่นี่) โปรดทราบว่า MES-2 มีอักขระทุกตัวใน MES-1 และ WGL-4

WGL-4 , MES-1และ MES-2
แถว เซลล์ ช่วง
00 20–7E ภาษาละตินพื้นฐาน (00–7F)
A0–FF อาหารเสริม Latin-1 (80–FF)
01 00–13, 14–15, 16–2B, 2C–2D, 2E–4D, 4E–4F, 50–7E, 7F ภาษาละติน Extended-A (00–7F)
8F, 92, B7, DE-EF, FA–FF ละติน Extended-B (80–FF ... )
02 18–1B, 1E–1F ภาษาละติน Extended-B ( ... 00–4F)
59, 7C, 92 ส่วนขยาย IPA (50–AF)
BB–BD, C6, C7, C9, D6, D8–DB, DC, DD, DF, EE ตัวอักษรปรับระยะห่าง (B0–FF)
03 74–75, 7A, 7E, 84–8A, 8C, 8E–A1, A3–CE, D7, DA–E1 กรีก (70–FF)
04 00–5F, 90–91, 92–C4, C7–C8, CB–CC, D0–EB, EE–F5, F8–F9 ซิริลลิก (00–FF)
1E 02-03, 0A–0B, 1E–1F, 40–41, 56–57, 60–61, 6A–6B, 80–85, 9B, F2–F3 ภาษาละตินขยายเพิ่มเติม (00–FF)
1F 00–15, 18–1D, 20–45, 48–4D, 50–57, 59, 5B, 5D, 5F–7D, 80–B4, B6–C4, C6–D3, D6–DB, DD–EF, F2–F4, F6–FE กรีกขยาย (00–FF)
20 13–14, 15, 17, 18–19, 1A–1B, 1C–1D, 1E, 20–22, 26, 30, 32–33, 39–3A, 3C, 3E, 44, 4A เครื่องหมายวรรคตอนทั่วไป (00–6F)
7F , 82 ตัวยกและตัวห้อย (70–9F)
A3–A4, A7, ไฟฟ้ากระแสสลับ, AF สัญลักษณ์สกุลเงิน (A0–CF)
21 05, 13, 16, 22, 26, 2E สัญลักษณ์คล้ายตัวอักษร (00–4F)
5B–5E แบบฟอร์มตัวเลข (50–8F)
90–93, 94–95, A8 ลูกศร (90–FF)
22 00, 02, 03, 06, 08–09, 0F, 11–12, 15, 19–1A, 1E–1F, 27–28, 29, 2A, 2B, 48, 59, 60–61, 64–65, 82–83, 95, 97 ตัวดำเนินการทางคณิตศาสตร์ (00–FF)
23 02, 0A, 20–21, 29–2A เทคนิคเบ็ดเตล็ด (00–FF)
25 00, 02, 0C, 10, 14, 18, 1C, 24, 2C, 34, 3C, 50-6C แบบกล่อง (00–7F)
80, 84, 88, 8C, 90–93 บล็อกเอลิเมนต์ (80–9F)
A0–A1, AA–AC, B2, BA, BC, C4, CA–CB, CF, D8–D9, E6 รูปทรงเรขาคณิต (A0–FF)
26 3A–3C, 40, 42, 60, 63, 65–66, 6A, 6B สัญลักษณ์เบ็ดเตล็ด (00–FF)
F0 (01–02) พื้นที่ใช้งานส่วนตัว (00–FF ...)
FB 01–02 แบบฟอร์มการนำเสนอตามตัวอักษร (00–4F)
FF FD พิเศษ

ซอฟต์แวร์แสดงผลที่ไม่สามารถประมวลผลอักขระ Unicode ได้อย่างเหมาะสมมักแสดงเป็นสี่เหลี่ยมเปิด หรือ Unicode " อักขระแทนที่ " (U+FFFD, ) เพื่อระบุตำแหน่งของอักขระที่ไม่รู้จัก บางระบบได้พยายามให้ข้อมูลเพิ่มเติมเกี่ยวกับอักขระดังกล่าว แอปเปิ้ลล่าสุดรีสอร์ทอักษรจะแสดงสัญลักษณ์แทนระบุช่วง Unicode ของตัวละครและSIL นานาชาติ 's ตัวอักษร Unicode สำรองจะแสดงกล่องแสดงค่าสเกลาเลขฐานสิบหกของตัวละครที่

การทำแผนที่และการเข้ารหัส

มีการระบุกลไกหลายอย่างสำหรับการจัดเก็บชุดของจุดโค้ดเป็นชุดของไบต์

Unicode กำหนดวิธีการแมปสองวิธี: การเข้ารหัส Unicode Transformation Format (UTF) และการเข้ารหัสUniversal Coded Character Set (UCS) แผนที่ที่เข้ารหัส (อาจจะเป็นส่วนหนึ่งของ) ช่วงของยูนิโค้ดจุดรหัสลำดับของค่าในช่วงขนาดคงที่บางที่เรียกว่าหน่วยรหัส โค้ดแมปการเข้ารหัส UTF ทั้งหมดชี้ไปที่ลำดับไบต์ที่ไม่ซ้ำกัน [68]ตัวเลขในชื่อของการเข้ารหัสระบุจำนวนบิตต่อหน่วยรหัส (สำหรับการเข้ารหัส UTF) หรือจำนวนไบต์ต่อหน่วยรหัส (สำหรับการเข้ารหัส UCS และUTF-1 ) UTF-8 และ UTF-16 เป็นการเข้ารหัสที่ใช้บ่อยที่สุด UCS-2 เป็นชุดย่อยที่ล้าสมัยของ UTF-16; UCS-4 และ UTF-32 เทียบเท่ากับการใช้งาน

การเข้ารหัส UTF รวมถึง:

  • UTF-8ใช้หนึ่งถึงสี่ไบต์สำหรับแต่ละจุดโค้ด เพิ่มความเข้ากันได้กับASCII
  • UTF-EBCDICคล้ายกับ UTF-8 แต่ออกแบบมาเพื่อให้เข้ากันได้กับEBCDIC (ไม่ใช่ส่วนหนึ่งของThe Unicode Standard )
  • UTF-16ใช้หน่วยรหัส 16 บิตหนึ่งหรือสองหน่วยต่อจุดรหัส ไม่สามารถเข้ารหัสตัวแทนได้
  • UTF-32ใช้หน่วยรหัส 32 บิตหนึ่งหน่วยต่อจุดรหัส

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

การเข้ารหัส UCS-2 และ UTF-16 ระบุ Unicode Byte Order Mark (BOM) เพื่อใช้ที่จุดเริ่มต้นของไฟล์ข้อความ ซึ่งอาจใช้สำหรับการตรวจจับการสั่งซื้อไบต์ (หรือการตรวจจับจุดสิ้นสุดของไบต์ ) BOM ซึ่งเป็นโค้ดพอยต์ U+FEFF มีคุณสมบัติที่สำคัญของความชัดเจนในการเรียงลำดับไบต์ใหม่ โดยไม่คำนึงถึงการเข้ารหัส Unicode ที่ใช้ U+FFFE (ผลลัพธ์ของการเปลี่ยนไบต์ U+FEFF) ไม่เท่ากับอักขระทางกฎหมาย และ U+FEFF ในตำแหน่งอื่นที่ไม่ใช่จุดเริ่มต้นของข้อความสื่อถึงช่องว่างแบบไม่แบ่งความกว้างศูนย์ (อักขระที่ไม่ปรากฏและ ไม่มีผลอื่นใดนอกจากป้องกันการก่อตัวของมัด )

ตัวละครเดียวกันแปลงเป็น UTF-8 EF BB BFกลายเป็นลำดับไบต์ Unicode Standard อนุญาตให้ BOM "สามารถทำหน้าที่เป็นลายเซ็นสำหรับข้อความที่เข้ารหัส UTF-8 โดยที่ชุดอักขระไม่ถูกทำเครื่องหมาย" [69]นักพัฒนาซอฟต์แวร์บางคนได้นำมันมาใช้กับการเข้ารหัสอื่น ๆ รวมถึง UTF-8 เพื่อพยายามแยกแยะ UTF-8 จากหน้ารหัส 8 บิตในเครื่อง อย่างไรก็ตามRFC 3629 มาตรฐาน UTF-8 ขอแนะนำว่าห้ามใช้เครื่องหมายลำดับไบต์ในโปรโตคอลที่ใช้ UTF-8 แต่กล่าวถึงกรณีที่อาจไม่สามารถทำได้ นอกจากนี้ ข้อจำกัดขนาดใหญ่เกี่ยวกับรูปแบบที่เป็นไปได้ใน UTF-8 (เช่น ต้องไม่มีไบต์เดี่ยวที่มีชุดบิตสูง) หมายความว่าควรแยกแยะ UTF-8 ออกจากการเข้ารหัสอักขระอื่นๆ ได้โดยไม่ต้องอาศัย BOM

ใน UTF-32 และ UCS-4 หน่วยโค้ด32 บิตหนึ่งหน่วยทำหน้าที่เป็นตัวแทนโดยตรงของจุดโค้ดของอักขระใดๆ (แม้ว่า endianness ซึ่งแตกต่างกันไปตามแพลตฟอร์มต่างๆ จะส่งผลต่อวิธีที่หน่วยโค้ดแสดงเป็นลำดับไบต์) ในการเข้ารหัสอื่น ๆ แต่ละจุดรหัสอาจแสดงด้วยจำนวนตัวแปรของหน่วยรหัส UTF-32 ใช้กันอย่างแพร่หลายในการแสดงข้อความภายในในโปรแกรม (ต่างจากที่จัดเก็บหรือส่งข้อความ) เนื่องจากระบบปฏิบัติการ Unix ทุกระบบที่ใช้คอมไพเลอร์gccเพื่อสร้างซอฟต์แวร์จะใช้เป็นการเข้ารหัส " อักขระแบบกว้าง " มาตรฐานภาษาโปรแกรมบางภาษา เช่นSeed7ใช้ UTF-32 เป็นตัวแทนภายในสำหรับสตริงและอักขระPython .เวอร์ชันล่าสุดภาษาการเขียนโปรแกรม (เริ่มต้นด้วย 2.2) อาจถูกกำหนดค่าให้ใช้ UTF-32 เป็นตัวแทนสำหรับสตริง Unicode ซึ่งเผยแพร่การเข้ารหัสดังกล่าวในซอฟต์แวร์เข้ารหัส ระดับสูงอย่างมีประสิทธิภาพ

Punycodeซึ่งเป็นรูปแบบการเข้ารหัสอีกรูปแบบหนึ่ง ช่วยให้สามารถเข้ารหัสสตริง Unicode ลงในชุดอักขระที่จำกัดซึ่งรองรับโดยระบบชื่อโดเมน (DNS) ที่ใช้ASCII การเข้ารหัสนี้ใช้เป็นส่วนหนึ่งของIDNAซึ่งเป็นระบบที่ทำให้สามารถใช้ชื่อโดเมนสากลในสคริปต์ทั้งหมดที่ได้รับการสนับสนุนโดย Unicode ก่อนหน้านี้และตอนนี้ข้อเสนอประวัติศาสตร์ ได้แก่UTF-5และUTF-6

GB18030เป็นรูปแบบการเข้ารหัสอีก Unicode จากการบริหารมาตรฐานของประเทศจีน มันเป็นอย่างเป็นทางการชุดอักขระของสาธารณรัฐประชาชนจีน (PRC) BOCU-1และSCSUเป็นรูปแบบการบีบอัด Unicode Fools เมษายนวัน RFC 2005 ระบุสองล้อเลียนการเข้ารหัส UTF, UTF-9และUTF-18

การรับบุตรบุญธรรม

ระบบปฏิบัติการ

Unicode ได้กลายเป็นรูปแบบที่โดดเด่นสำหรับการประมวลผลภายในและการจัดเก็บข้อความ แม้ว่าข้อความจำนวนมากจะยังคงถูกเก็บไว้ในการเข้ารหัสแบบเดิม แต่ Unicode นั้นถูกใช้เพื่อสร้างระบบประมวลผลข้อมูลใหม่โดยเฉพาะ ผู้ใช้งานในช่วงแรกมีแนวโน้มที่จะใช้UCS-2 (ตัวตั้งต้นแบบสองไบต์ที่มีความกว้างคงที่สำหรับ UTF-16) และต่อมาได้ย้ายไปยังUTF-16 (มาตรฐานปัจจุบันที่มีความกว้างแปรผันได้) เนื่องจากวิธีนี้เป็นวิธีที่รบกวนน้อยที่สุดในการเพิ่มการรองรับสำหรับ non -BMP อักขระ ระบบดังกล่าวที่รู้จักกันดีที่สุดคือWindows NT (และลูกหลานของWindows 2000 , Windows XP , Windows Vista , Windows 7 , Windows 8และWindows 10) ซึ่งใช้ UTF-16 เป็นการเข้ารหัสอักขระภายในเพียงอย่างเดียวJavaและ.NET bytecode สภาพแวดล้อมMacOSและKDEยังใช้สำหรับการแสดงภายใน การสนับสนุนบางส่วนสำหรับ Unicode สามารถติดตั้งบนWindows 9xผ่านชั้นของ Microsoft สำหรับ Unicode

UTF-8 (แต่เดิมพัฒนาขึ้นสำหรับแผน 9 ) [70]ได้กลายเป็นการเข้ารหัสหน่วยเก็บข้อมูลหลักบนระบบปฏิบัติการที่คล้าย Unixส่วนใหญ่(แม้ว่าบางไลบรารีก็ใช้ไลบรารีอื่นด้วย) เนื่องจากเป็นการแทนที่ที่ค่อนข้างง่ายสำหรับชุดอักขระASCIIแบบขยายแบบเดิมUTF-8 ยังเป็นที่พบมากที่สุด Unicode เข้ารหัสที่ใช้ในHTMLเอกสารบนเวิลด์ไวด์เว็บ

เอ็นจิ้นการแสดงข้อความหลายภาษาที่ใช้ Unicode ได้แก่UniscribeและDirectWriteสำหรับ Microsoft Windows, ATSUIและCore Textสำหรับ macOS และPangoสำหรับGTK+และเดสก์ท็อป GNOME

วิธีการป้อนข้อมูล

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

ISO/IEC 14755 , [71]ซึ่งกำหนดวิธีการมาตรฐานสำหรับการป้อนอักขระ Unicode จากจุดโค้ด ระบุวิธีการหลายวิธี มีเป็นวิธีการขั้นพื้นฐานซึ่งเป็นลำดับเริ่มต้นตามด้วยการแสดงเลขฐานสิบหกจุดรหัสและลำดับที่สิ้นสุดนอกจากนี้ยังมีการระบุวิธีการป้อนการเลือกหน้าจอโดยที่อักขระจะแสดงอยู่ในตารางในหน้าจอ เช่น ด้วยโปรแกรมผังอักขระ

เครื่องมือออนไลน์สำหรับค้นหาจุดโค้ดสำหรับอักขระที่รู้จัก ได้แก่ Unicode Lookup [72]โดย Jonathan Hedley และ Shapecatcher [73]โดย Benjamin Milde ใน Unicode Lookup ให้ป้อนคีย์ค้นหา (เช่น "เศษส่วน") และรายการอักขระที่เกี่ยวข้องพร้อมจุดโค้ดจะถูกส่งคืน ใน Shapecatcher โดยอิงตามบริบทของ Shapeหนึ่งวาดอักขระในกล่องและรายการของอักขระที่ใกล้เคียงกับภาพวาด พร้อมจุดโค้ด จะถูกส่งกลับ

อีเมล์

MIMEกำหนดกลไกที่แตกต่างกันสองแบบสำหรับการเข้ารหัสอักขระที่ไม่ใช่ ASCII ในอีเมลขึ้นอยู่กับว่าอักขระนั้นอยู่ในส่วนหัวของอีเมลหรือไม่ (เช่น "หัวเรื่อง:") หรือในเนื้อหาข้อความของข้อความ ในทั้งสองกรณี จะมีการระบุชุดอักขระดั้งเดิมและการเข้ารหัสการถ่ายโอน สำหรับการส่งอีเมลของ Unicode ขอแนะนำให้ใช้ชุดอักขระUTF-8และBase64หรือการเข้ารหัสการโอนที่พิมพ์ได้ซึ่งอ้างอิงได้ ขึ้นอยู่กับว่าข้อความส่วนใหญ่ประกอบด้วยอักขระ ASCIIหรือไม่ รายละเอียดของกลไกทั้งสองที่แตกต่างกันนั้นระบุไว้ในมาตรฐาน MIME และโดยทั่วไปแล้วจะไม่เปิดเผยให้ผู้ใช้ซอฟต์แวร์อีเมลทราบ

การนำ Unicode มาใช้ในอีเมลนั้นช้ามาก ข้อความเอเชียตะวันออกบางข้อความยังคงเข้ารหัสในการเข้ารหัส เช่นISO-2022และอุปกรณ์บางอย่าง เช่น โทรศัพท์มือถือ ยังไม่สามารถจัดการข้อมูล Unicode ได้อย่างถูกต้อง การสนับสนุนได้รับการปรับปรุงอย่างไรก็ตาม ผู้ให้บริการอีเมลรายใหญ่หลายราย เช่นYahoo , Google ( Gmail ) และMicrosoft ( Outlook.com ) รองรับ

เว็บ

คำแนะนำW3Cทั้งหมดใช้ Unicode เป็นชุดอักขระของเอกสารตั้งแต่ HTML 4.0 เว็บเบราว์เซอร์รองรับ Unicode โดยเฉพาะ UTF-8 เป็นเวลาหลายปี เคยมีปัญหาการแสดงผลที่เกิดจากปัญหาที่เกี่ยวข้องกับแบบอักษรเป็นหลัก เช่น เวอร์ชัน 6 และเก่ากว่าของ Microsoft Internet Explorerไม่ได้แสดงโค้ดหลายจุด เว้นแต่จะได้รับคำสั่งอย่างชัดเจนให้ใช้ฟอนต์ที่มีจุดเหล่านี้ [74]

แม้ว่ากฎไวยากรณ์อาจส่งผลต่อลำดับที่อักขระได้รับอนุญาตให้ปรากฏ แต่เอกสาร XML (รวมถึงXHTML ) ตามคำจำกัดความ[75]ประกอบด้วยอักขระจากจุดโค้ด Unicode ส่วนใหญ่ ยกเว้น:

  • ที่สุดของรหัสควบคุม C0 ,
  • รหัสที่ไม่ได้กำหนดอย่างถาวรชี้ D800–DFFF
  • FFFE หรือ FFFF

อักขระ HTML จะแสดงเป็นไบต์โดยตรงตามการเข้ารหัสของเอกสาร หากการเข้ารหัสรองรับ หรือผู้ใช้อาจเขียนเป็นอักขระอ้างอิงที่เป็นตัวเลขตามจุดโค้ด Unicode ของอักขระ ตัวอย่างเช่น การอ้างอิง&#916;, &#1049;, &#1511;, &#1605;, &#3671;, &#12354;, &#21494;, &#33865;, และ&#47568;(หรือค่าตัวเลขเดียวกันที่แสดงเป็นเลขฐานสิบหกโดยมี&#xคำนำหน้า) ควรแสดงบนเบราว์เซอร์ทั้งหมดเป็น Δ, Й, ק ,م, ๗, あ, 叶, 葉, และ 말.

เมื่อระบุURI ของตัวอย่างเช่นเป็นURL ที่ในHTTPร้องขออักขระที่ไม่ใช่ ASCII จะต้องเป็นร้อยละเข้ารหัส

แบบอักษร

โดยหลักการแล้ว Unicode ไม่ได้เกี่ยวข้องกับฟอนต์per seโดยมองว่าเป็นทางเลือกในการใช้งาน[76]ตัวอักษรใดๆ ก็ตามอาจมีallographsจำนวนมากตั้งแต่รูปแบบตัวอักษรตัวหนา ตัวเอียง และฐานทั่วไป ไปจนถึงรูปแบบการตกแต่งที่ซับซ้อน แบบอักษร "สอดคล้องกับ Unicode" หากเข้าถึงร่ายมนตร์ในแบบอักษรโดยใช้จุดโค้ดที่กำหนดไว้ในมาตรฐาน Unicode [77]มาตรฐานไม่ได้ระบุจำนวนอักขระขั้นต่ำที่ต้องรวมอยู่ในแบบอักษร แบบอักษรบางตัวมีรายการค่อนข้างเล็ก

แบบอักษรฟรีและขายปลีกที่ใช้ Unicode นั้นมีให้ใช้อย่างแพร่หลาย เนื่องจากTrueTypeและOpenTypeรองรับ Unicode รูปแบบฟอนต์เหล่านี้จับคู่โค้ด Unicode ชี้ไปที่ร่ายมนตร์ แต่ฟอนต์ TrueType ถูกจำกัดไว้ที่ 65,535 ร่ายมนตร์

มีแบบอักษรหลายพันแบบในท้องตลาด แต่มีแบบอักษรน้อยกว่าโหล—บางครั้งอธิบายว่าเป็นแบบอักษร "pan-Unicode"—พยายามสนับสนุนรายการอักขระส่วนใหญ่ของ Unicode โดยปกติแล้วฟอนต์ที่ใช้ Unicode จะเน้นที่การสนับสนุนเฉพาะ ASCII พื้นฐานและสคริปต์เฉพาะหรือชุดอักขระหรือสัญลักษณ์ มีเหตุผลหลายประการที่ชี้ให้เห็นถึงแนวทางนี้: แอปพลิเคชันและเอกสารแทบไม่ต้องแสดงอักขระจากระบบการเขียนมากกว่าหนึ่งหรือสองระบบ แบบอักษรมักจะต้องการทรัพยากรในสภาพแวดล้อมการคำนวณ และระบบปฏิบัติการและแอพพลิเคชั่นแสดงความฉลาดที่เพิ่มขึ้นเกี่ยวกับการรับข้อมูลสัญลักษณ์จากไฟล์ฟอนต์แยกตามความจำเป็น กล่าวคือ การแทนที่ฟอนต์. นอกจากนี้ การออกแบบชุดคำสั่งการแสดงผลที่สอดคล้องกันสำหรับร่ายมนตร์นับหมื่นถือเป็นงานที่ยิ่งใหญ่ กิจการดังกล่าวผ่านจุดผลตอบแทนที่ลดลงสำหรับแบบอักษรส่วนใหญ่

ขึ้นบรรทัดใหม่

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

ในแง่ของการขึ้นบรรทัดใหม่ Unicode ได้แนะนำU+2028 LINE SEPARATORและU+2029 PARAGRAPH SEPARATOR . นี่เป็นความพยายามในการจัดหาโซลูชัน Unicode เพื่อเข้ารหัสย่อหน้าและบรรทัดตามความหมาย ซึ่งอาจแทนที่โซลูชันแพลตฟอร์มต่างๆ ทั้งหมด ในการทำเช่นนั้น Unicode ให้วิธีการแก้ปัญหาที่ขึ้นกับแพลตฟอร์มในอดีต อย่างไรก็ตาม มีเพียงไม่กี่โซลูชันหากใช้ตัวคั่นบรรทัด Unicode และตัวคั่นวรรคเหล่านี้เป็นอักขระลงท้ายบรรทัดบัญญัติเพียงตัวเดียว อย่างไรก็ตาม วิธีการทั่วไปในการแก้ปัญหานี้คือการทำให้บรรทัดใหม่เป็นปกติ สิ่งนี้ทำได้ด้วยระบบข้อความ Cocoa ใน Mac OS X และด้วยคำแนะนำ W3C XML และ HTML ในแนวทางนี้ อักขระขึ้นบรรทัดใหม่ที่เป็นไปได้ทั้งหมดจะถูกแปลงเป็นการภายในเป็นการขึ้นบรรทัดใหม่ทั่วไป (ซึ่งไม่สำคัญจริงๆ เนื่องจากเป็นการดำเนินการภายในสำหรับการเรนเดอร์เท่านั้น) กล่าวอีกนัยหนึ่งระบบข้อความสามารถปฏิบัติต่ออักขระได้อย่างถูกต้องเหมือนขึ้นบรรทัดใหม่โดยไม่คำนึงถึงการเข้ารหัสที่แท้จริงของอินพุต

ปัญหา

การวิจารณ์เชิงปรัชญาและความครบถ้วนสมบูรณ์

การรวมชาติของฮั่น (การระบุรูปแบบในภาษาเอเชียตะวันออกที่ใครๆ ก็มองว่าเป็นรูปแบบโวหารของลักษณะทางประวัติศาสตร์เดียวกัน) ได้กลายเป็นแง่มุมที่ขัดแย้งกันมากที่สุดอย่างหนึ่งของ Unicode แม้ว่าจะมีผู้เชี่ยวชาญส่วนใหญ่จากทั้งสามภูมิภาคในIdeographic Research Group (IRG) ซึ่งให้คำแนะนำแก่ Consortium และ ISO เกี่ยวกับการเพิ่มละครและการรวม Han [78]

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

แม้ว่าละครที่มีอักขระ Han น้อยกว่า 21,000 ตัวใน Unicode เวอร์ชันแรกสุดจะจำกัดเฉพาะอักขระในการใช้งานสมัยใหม่ทั่วไป แต่ขณะนี้ Unicode มีอักขระ Han มากกว่า 92,000 ตัว และงานกำลังเพิ่มอักขระประวัติศาสตร์และภาษาถิ่นอีกหลายพันตัวที่ใช้ในประเทศจีนอย่างต่อเนื่อง ญี่ปุ่น เกาหลี ไต้หวัน และเวียดนาม

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

อักขระซีริลลิกต่างๆ ที่แสดงทั้งแบบมีและไม่มีตัวเอียง

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

การแมปกับชุดอักขระดั้งเดิม

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

ต้องจัดให้มีการแมปแบบแทรกระหว่างอักขระในชุดอักขระดั้งเดิมที่มีอยู่และอักขระใน Unicode เพื่ออำนวยความสะดวกในการแปลงเป็น Unicode และอนุญาตให้ทำงานร่วมกันได้กับซอฟต์แวร์รุ่นเก่า ความไม่สอดคล้องกันในการแมปต่างๆ ระหว่างการเข้ารหัสภาษาญี่ปุ่นก่อนหน้านี้ เช่นShift-JISหรือEUC-JPและ Unicode ทำให้การแปลงรูปแบบไปกลับไม่ตรงกัน โดยเฉพาะการจับคู่อักขระ JIS X 0208 '~' (1-33, WAVE DASH) ใช้อย่างมากในข้อมูลฐานข้อมูลแบบเก่า จนถึงU+FF5EFULLWIDTH TILDE (ในMicrosoft Windows ) หรือU+301CWAVE DASH (ผู้จำหน่ายรายอื่น) [80]

โปรแกรมเมอร์คอมพิวเตอร์ชาวญี่ปุ่นบางคนคัดค้าน Unicode เนื่องจากต้องการให้แยกการใช้U+005C \ REVERSE SOLIDUS (แบ็กสแลช) และU+00A5 ¥ YEN SIGNซึ่งจับคู่กับ 0x5C ใน JIS X 0201 และมีรหัสดั้งเดิมจำนวนมาก กับการใช้งานนี้ [81] (การเข้ารหัสนี้แทนที่เครื่องหมายตัวหนอน '~' 0x7E ด้วย macron '¯' ซึ่งปัจจุบันเป็น 0xAF) การแยกอักขระเหล่านี้มีอยู่ในISO 8859-1จากแบบยาวก่อน Unicode

สคริปต์อินดิก

Indic scripts such as Tamil and Devanagari are each allocated only 128 code points, matching the ISCII standard. The correct rendering of Unicode Indic text requires transforming the stored logical order characters into visual order and the forming of ligatures (aka conjuncts) out of components. Some local scholars argued in favor of assignments of Unicode code points to these ligatures, going against the practice for other writing systems, though Unicode contains some Arabic and other ligatures for backward compatibility purposes only.[82][83][84] Encoding of any new ligatures in Unicode will not happen, in part because the set of ligatures is font-dependent, and Unicode is an encoding independent of font variations. The same kind of issue arose for the Tibetan script in 2003 when the Standardization Administration of China proposed encoding 956 precomposed Tibetan syllables,[85] but these were rejected for encoding by the relevant ISO committee (ISO/IEC JTC 1/SC 2).[86]

Thai alphabet support has been criticized for its ordering of Thai characters. The vowels เ, แ, โ, ใ, ไ that are written to the left of the preceding consonant are in visual order instead of phonetic order, unlike the Unicode representations of other Indic scripts. This complication is due to Unicode inheriting the Thai Industrial Standard 620, which worked in the same way, and was the way in which Thai had always been written on keyboards. This ordering problem complicates the Unicode collation process slightly, requiring table lookups to reorder Thai characters for collation.[79] Even if Unicode had adopted encoding according to spoken order, it would still be problematic to collate words in dictionary order. E.g., the word แสดง [sa dɛːŋ] "perform" starts with a consonant cluster "สด" (with an inherent vowel for the consonant "ส"), the vowel แ-, in spoken order would come after the ด, but in a dictionary, the word is collated as it is written, with the vowel following the ส.

Combining characters

Characters with diacritical marks can generally be represented either as a single precomposed character or as a decomposed sequence of a base letter plus one or more non-spacing marks. For example, ḗ (precomposed e with macron and acute above) and ḗ (e followed by the combining macron above and combining acute above) should be rendered identically, both appearing as an e with a macron and acute accent, but in practice, their appearance may vary depending upon what rendering engine and fonts are being used to display the characters. Similarly, underdots, as needed in the romanization of Indic, will often be placed incorrectly.[citation needed]. Unicode characters that map to precomposed glyphs can be used in many cases, thus avoiding the problem, but where no precomposed character has been encoded the problem can often be solved by using a specialist Unicode font such as Charis SIL that uses Graphite, OpenType, or AAT technologies for advanced rendering features.

Anomalies

The Unicode standard has imposed rules intended to guarantee stability.[87] Depending on the strictness of a rule, a change can be prohibited or allowed. For example, a "name" given to a code point cannot and will not change. But a "script" property is more flexible, by Unicode's own rules. In version 2.0, Unicode changed many code point "names" from version 1. At the same moment, Unicode stated that from then on, an assigned name to a code point would never change anymore. This implies that when mistakes are published, these mistakes cannot be corrected, even if they are trivial (as happened in one instance with the spelling BRAKCET for BRACKET in a character name). In 2006 a list of anomalies in character names was first published, and, as of June 2021, there were 104 characters with identified issues,[88] for example:

  • U+2118 SCRIPT CAPITAL P: This is a small letter. The capital is U+1D4AB 𝒫 MATHEMATICAL SCRIPT CAPITAL P.[89]
  • U+034F ͏ COMBINING GRAPHEME JOINER: Does not join graphemes.[88]
  • U+A015 YI SYLLABLE WU: This is not a Yi syllable, but a Yi iteration mark.
  • U+FE18 PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRAKCET: bracket is spelled incorrectly.[90]

Spelling errors are resolved by using Unicode alias names and abbreviations.

See also

Notes

  1. ^ The Unicode Consortium uses the ambiguous term 'byte'; The International Organization for Standardization (ISO), the International Electrotechnical Commission (IEC) and the Internet Engineering Task Force (IETF) use the more specific term 'octet' in current documents related to Unicode.

References

  1. ^ "The Unicode Standard: A Technical Introduction". Retrieved 2010-03-16.
  2. ^ "Usage Survey of Character Encodings broken down by Ranking". w3techs.com. Retrieved 2020-06-09.
  3. ^ "Conformance" (PDF). The Unicode Standard. September 2021. Retrieved 2021-09-16.
  4. ^ "UAX #29: Unicode Text Segmentation §3 Grapheme Cluster Boundaries". unicode.org. 2020-02-19. Retrieved 2020-06-27.
  5. ^ "Unicode – a brief introduction (advanced) • JavaScript for impatient programmers". exploringjs.com. Retrieved 2020-06-14.
  6. ^ "Introduction to Unicode". mathias.gaunard.com. Retrieved 2020-06-14.
  7. ^ "Strings and Characters — The Swift Programming Language (Swift 5.2)". docs.swift.org. Retrieved 2020-06-14.
  8. ^ "Breaking Our Latin-1 Assumptions - In Pursuit of Laziness". manishearth.github.io. Retrieved 2020-06-14. Unicode didn't want to deal with adding new flags each time a new country or territory pops up. Nor did they want to get into the tricky business of determining what a country is, for example when dealing with disputed territories. [..] On some Chinese systems, for example, the flag for Taiwan (🇹🇼) may not render.
  9. ^ "Let's Stop Ascribing Meaning to Code Points - In Pursuit of Laziness". manishearth.github.io. Retrieved 2020-06-14. Folks start implying that code points mean something, and that O(1) indexing or slicing at code point boundaries is a useful operation.
  10. ^ The Unicode® Bulldog Award
  11. ^ a b c d e Becker, Joseph D. (1998-09-10) [1988-08-29]. "Unicode 88" (PDF). unicode.org (10th anniversary reprint ed.). Unicode Consortium. Archived (PDF) from the original on 2016-11-25. Retrieved 2016-10-25. In 1978, the initial proposal for a set of "Universal Signs" was made by Bob Belleville at Xerox PARC. Many persons contributed ideas to the development of a new encoding design. Beginning in 1980, these efforts evolved into the Xerox Character Code Standard (XCCS) by the present author, a multilingual encoding which has been maintained by Xerox as an internal corporate standard since 1982, through the efforts of Ed Smura, Ron Pellar, and others.
    Unicode arose as the result of eight years of working experience with XCCS. Its fundamental differences from XCCS were proposed by Peter Fenwick and Dave Opstad (pure 16-bit codes), and by Lee Collins (ideographic character unification). Unicode retains the many features of XCCS whose utility have been proved over the years in an international line of communication multilingual system products.
  12. ^ "Summary Narrative". Retrieved 2010-03-15.
  13. ^ History of Unicode Release and Publication Dates on unicode.org. Retrieved February 28, 2017.
  14. ^ Searle, Stephen J. "Unicode Revisited". Retrieved 2013-01-18.
  15. ^ a b "The Unicode Consortium Members". Retrieved 2019-01-04.
  16. ^ "Unicode FAQ". Retrieved 2020-04-02.
  17. ^ "Supported Scripts". unicode.org. Retrieved 2021-09-16.
  18. ^ "Roadmap to the BMP". Unicode Consortium. Retrieved 2018-07-30.
  19. ^ Unicode Roadmap
  20. ^ Script Encoding Initiative
  21. ^ "About The Script Encoding Initiative". The Unicode Consortium. Retrieved 2012-06-04.
  22. ^ "Unicode 6.1 Paperback Available". announcements_at_unicode.org. Retrieved 2012-05-30.
  23. ^ "Enumerated Versions of The Unicode Standard". Retrieved 2016-06-21.
  24. ^ a b c
  25. ^ a b "Unicode Data 1.0.1". Retrieved 2010-03-16.
  26. ^ a b
  27. ^ a b
  28. ^ a b
  29. ^ "Unicode Data-3.0.0". Retrieved 2010-03-16.
  30. ^ "Unicode Data-3.1.0". Retrieved 2010-03-16.
  31. ^ "Unicode Data-3.2.0". Retrieved 2010-03-16.
  32. ^ "Unicode Data-4.0.0". Retrieved 2010-03-16.
  33. ^ "Unicode Data-4.1.0". Retrieved 2010-03-16.
  34. ^ "Unicode Data 5.0.0". Retrieved 2010-03-17.
  35. ^ "Unicode Data 5.1.0". Retrieved 2010-03-17.
  36. ^ "Unicode Data 5.2.0". Retrieved 2010-03-17.
  37. ^ "Unicode Data 6.0.0". Retrieved 2010-10-11.
  38. ^ "Unicode Data 6.1.0". Retrieved 2012-01-31.
  39. ^ "Unicode Data 6.2.0". Retrieved 2012-09-26.
  40. ^ "Unicode Data 6.3.0". Retrieved 2013-09-30.
  41. ^ "Unicode Data 7.0.0". Retrieved 2014-06-15.
  42. ^ "Unicode 8.0.0". Unicode Consortium. Retrieved 2015-06-17.
  43. ^ "Unicode Data 8.0.0". Retrieved 2015-06-17.
  44. ^ "Unicode 9.0.0". Unicode Consortium. Retrieved 2016-06-21.
  45. ^ "Unicode Data 9.0.0". Retrieved 2016-06-21.
  46. ^ Lobao, Martim (2016-06-07). "These Are The Two Emoji That Weren't Approved For Unicode 9 But Which Google Added To Android Anyway". Android Police. Retrieved 2016-09-04.
  47. ^ "Unicode 10.0.0". Unicode Consortium. Retrieved 2017-06-20.
  48. ^ https://en.bitcoin.it/wiki/Bitcoin_symbol
  49. ^ "The Unicode Standard, Version 11.0.0 Appendix C" (PDF). Unicode Consortium. Retrieved 2018-06-11.
  50. ^ "Announcing The Unicode Standard, Version 11.0". blog.unicode.org. Retrieved 2018-06-06.
  51. ^ "The Unicode Standard, Version 12.0.0 Appendix C" (PDF). Unicode Consortium. Retrieved 2019-03-05.
  52. ^ "Announcing The Unicode Standard, Version 12.0". blog.unicode.org. Retrieved 2019-03-05.
  53. ^ "Unicode Version 12.1 released in support of the Reiwa Era". blog.unicode.org. Retrieved 2019-05-07.
  54. ^ a b
  55. ^ "The Unicode Standard, Version 13.0– Core Specification Appendix C" (PDF). Unicode Consortium. Retrieved 2020-03-11.
  56. ^ a b
  57. ^ "Glossary of Unicode Terms". Retrieved 2010-03-16.
  58. ^ "3.4 Characters and Encoding". The Unicode Standard, Version 14.0 (PDF). 2021. p. 88.
  59. ^ "2.4 Code Points and Characters". The Unicode Standard Version 14.0 – Core Specification (PDF). 2021. p. 29.
  60. ^ "Appendix A: Notational Conventions" (PDF). The Unicode Standard. Unicode Consortium. September 2021. In conformity with the bullet point relating to Unicode in MOS:ALLCAPS, the formal Unicode names are not used in this paragraph.
  61. ^ a b "Unicode Character Encoding Stability Policy". Retrieved 2010-03-16.
  62. ^ "Properties" (PDF). Retrieved 2021-09-16.
  63. ^ "Unicode Character Encoding Model". Retrieved 2010-03-16.
  64. ^ "Unicode Named Sequences". Retrieved 2010-03-16.
  65. ^ "Unicode Name Aliases". Retrieved 2010-03-16.
  66. ^ CWA 13873:2000 – Multilingual European Subsets in ISO/IEC 10646-1 CEN Workshop Agreement 13873
  67. ^ Multilingual European Character Set 2 (MES-2) Rationale, Markus Kuhn, 1998
  68. ^ "UTF-8, UTF-16, UTF-32 & BOM". Unicode.org FAQ. Retrieved 2016-12-12.
  69. ^ The Unicode Standard, Version 6.2. The Unicode Consortium. 2013. p. 561. ISBN 978-1-936213-08-5.
  70. ^ Pike, Rob (2003-04-30). "UTF-8 history".
  71. ^ "ISO/IEC JTC1/SC 18/WG 9 N" (PDF). Retrieved 2012-06-04.
  72. ^ Hedley, Jonathan (2009). "Unicode Lookup".
  73. ^ Milde, Benjamin (2011). "Unicode Character Recognition".
  74. ^ Wood, Alan. "Setting up Windows Internet Explorer 5, 5.5 and 6 for Multilingual and Unicode Support". Alan Wood. Retrieved 2012-06-04.
  75. ^ "Extensible Markup Language (XML) 1.1 (Second Edition)". Retrieved 2013-11-01.
  76. ^ Bigelow, Charles; Holmes, Kris (September 1993). "The design of a Unicode font" (PDF). Electronic Publishing. VOL. 6(3), 289–305: 292. |volume= has extra text (help)
  77. ^ "Fonts and keyboards". Unicode Consortium. 2017-06-28. Retrieved 2019-10-13.
  78. ^ A Brief History of Character Codes, Steven J. Searle, originally written 1999, last updated 2004
  79. ^ a b The secret life of Unicode: A peek at Unicode's soft underbelly, Suzanne Topping, 1 May 2001 (Internet Archive)
  80. ^ AFII contribution about WAVE DASH, "An Unicode vendor-specific character table for japanese". web.archive.org. 2011-04-22. Archived from the original on 2011-04-22.
  81. ^ ISO 646-* Problem, Section 4.4.3.5 of Introduction to I18n, Tomohiro KUBOTA, 2001
  82. ^ "Arabic Presentation Forms-A" (PDF). Retrieved 2010-03-20.
  83. ^ "Arabic Presentation Forms-B" (PDF). Retrieved 2010-03-20.
  84. ^ "Alphabetic Presentation Forms" (PDF). Retrieved 2010-03-20.
  85. ^ China (2002-12-02). "Proposal on Tibetan BrdaRten Characters Encoding for ISO/IEC 10646 in BMP" (PDF).
  86. ^ V. S. Umamaheswaran (2003-11-07). "Resolutions of WG 2 meeting 44" (PDF). Resolution M44.20.
  87. ^ Unicode stability policy
  88. ^ a b "Unicode Technical Note #27: Known Anomalies in Unicode Character Names". unicode.org. 2021-06-14.
  89. ^ Unicode chart: "actually this has the form of a lowercase calligraphic p, despite its name"
  90. ^ "Misspelling of BRACKET in character name is a known defect"

Further reading

  • The Unicode Standard, Version 3.0, The Unicode Consortium, Addison-Wesley Longman, Inc., April 2000. ISBN 0-201-61633-5
  • The Unicode Standard, Version 4.0, The Unicode Consortium, Addison-Wesley Professional, 27 August 2003. ISBN 0-321-18578-1
  • The Unicode Standard, Version 5.0, Fifth Edition, The Unicode Consortium, Addison-Wesley Professional, 27 October 2006. ISBN 0-321-48091-0
  • Julie D. Allen. The Unicode Standard, Version 6.0, The Unicode Consortium, Mountain View, 2011, ISBN 9781936213016, ([1]).
  • The Complete Manual of Typography, James Felici, Adobe Press; 1st edition, 2002. ISBN 0-321-12730-7
  • Unicode: A Primer, Tony Graham, M&T books, 2000. ISBN 0-7645-4625-2.
  • Unicode Demystified: A Practical Programmer's Guide to the Encoding Standard, Richard Gillam, Addison-Wesley Professional; 1st edition, 2002. ISBN 0-201-70052-2
  • Unicode Explained, Jukka K. Korpela, O'Reilly; 1st edition, 2006. ISBN 0-596-10121-X

External links