ISO/IEC 2022 เทคโนโลยีสารสนเทศ—โครงสร้างรหัสอักขระและเทคนิคการขยายเป็น มาตรฐาน ISO / IECในด้านการเข้ารหัสอักขระเทียบเท่ากับมาตรฐานECMA - 35 ^{[ 1 ] [ 2 ]}มาตรฐานANSI X3.41 ^{[ 3 ]}และมาตรฐานอุตสาหกรรมญี่ปุ่นJIS X 0202มีต้นกำเนิดในปี 1971 และได้รับการแก้ไขล่าสุดในปี 1994 ^{[ 4 ]}

ISO 2022 กำหนดโครงสร้างทั่วไปที่การเข้ารหัสอักขระสามารถปฏิบัติตามได้ โดยจัดสรรช่วงไบต์เฉพาะ ( 0x00–1F และ 0x7F–9F) เพื่อใช้สำหรับ รหัสควบคุมที่ไม่พิมพ์^{[ 5 ]}สำหรับการจัดรูปแบบและ คำสั่ง แบบอินแบนด์ (เช่น การขึ้นบรรทัดใหม่หรือคำสั่งการจัดรูปแบบสำหรับเทอร์มินัลข้อความ ) แทนที่จะ เป็น อักขระกราฟิกนอกจากนี้ยังกำหนดไวยากรณ์สำหรับลำดับการหลีกเลี่ยง ซึ่งเป็นลำดับหลายไบต์ที่เริ่มต้นด้วย รหัสควบคุม ESCซึ่งสามารถใช้สำหรับคำสั่งแบบอินแบนด์ได้เช่นกัน^{[ 6 ]}ชุดรหัสควบคุมและลำดับการหลีกเลี่ยงเฉพาะที่ออกแบบมาเพื่อใช้กับ ISO 2022 ได้แก่ISO/IEC 6429ซึ่งบางส่วนถูกนำไปใช้โดยANSI.SYSและโปรแกรมจำลองเทอร์มินัล

ISO 2022 เองยังกำหนดรหัสควบคุมและลำดับการหลีกเลี่ยงเฉพาะที่สามารถใช้สำหรับการสลับระหว่างชุดอักขระที่เข้ารหัส ต่างกัน (ตัวอย่างเช่น ระหว่างASCIIและJIS X 0208 ของญี่ปุ่น ) เพื่อใช้หลายชุดในเอกสารเดียว^{[ 7 ]}ซึ่งรวมเข้าด้วยกันเป็นการ เข้ารหัส แบบมีสถานะ เดียว (คุณสมบัตินี้มีความสำคัญน้อยลงนับตั้งแต่มีการเกิดขึ้นของUnicode ) ได้รับการออกแบบให้สามารถใช้งานได้ทั้งในสภาพแวดล้อม 8 บิตและสภาพแวดล้อม 7 บิต (ซึ่งมีเพียงเจ็ดบิตเท่านั้นที่สามารถใช้งานได้ในไบต์ เช่นอีเมลที่ไม่มี8BITMIME ) ^{[ 8 ]}

ชุดอักขระ ASCII รองรับเฉพาะอักษรละตินมาตรฐาน ISO (เทียบเท่ากับอักษรภาษาอังกฤษ ) และไม่รองรับภาษาที่มีตัวอักษรเพิ่มเติม หรือภาษาที่ใช้ระบบการเขียน ที่แตกต่าง ออกไปได้ดีนัก ระบบการเขียนอื่นๆ ที่มีตัวอักษรค่อนข้างน้อย เช่นกรีกซิริลลิกอาหรับหรือฮิบรูรวมถึงรูปแบบของอักษรละตินที่ใช้เครื่องหมายกำกับเสียงหรือตัวอักษรที่ไม่มีอยู่ในอักษรละตินมาตรฐาน ISO นั้น ในอดีตมักถูกแทนบนคอมพิวเตอร์ส่วนบุคคล ด้วยการเข้ารหัส ASCII แบบขยาย 8 บิตไบต์เดียวที่แตก ต่างกัน ซึ่งจะใช้ ASCII เมื่อบิตที่มีค่ามากที่สุดเป็น 0 (เช่น ไบต์ 0x00–7F เมื่อแสดงในเลขฐานสิบหก ) และจะมีตัวอักษรเพิ่มเติมสำหรับบิตที่มีค่ามากที่สุดเป็น 1 (เช่น ไบต์ 0x80–FF) บางส่วน เช่น ซีรี่ส์ ISO 8859เป็นไปตามมาตรฐาน ISO 2022 ^{[ 9 ] [ 10 ]}ในขณะที่บางส่วน เช่นรหัสเพจ DOS 437ไม่เป็นไปตามมาตรฐานดังกล่าว ซึ่งมักเกิดจากการไม่ได้สงวนไบต์ 0x80–9F ไว้สำหรับรหัสควบคุม

ภาษาเอเชียตะวันออกบาง ภาษา โดยเฉพาะ ภาษาจีนญี่ปุ่นและเกาหลี (รวมเรียกว่า " CJK ") เขียนโดยใช้ตัวอักษรมากกว่าจำนวนสูงสุด 256 ตัว ซึ่งสามารถแทนได้ในไบต์เดียว และในตอนแรกถูกแทนบนคอมพิวเตอร์ด้วยการเข้ารหัสแบบสองไบต์ เฉพาะภาษา หรือการเข้ารหัสแบบความกว้างแปรผันบางการเข้ารหัส (เช่นการเข้ารหัสภาษาจีนตัวย่อGB 2312 ) เป็นไปตามมาตรฐานISO 2022ในขณะที่บางการเข้ารหัส (เช่นการเข้ารหัสภาษาจีนตัวเต็มBig5 ) ไม่เป็นไปตามมาตรฐานดังกล่าว รหัสควบคุมใน ISO 2022 จะถูกแทนด้วยไบต์เดียวเสมอ ไม่ว่าจำนวนไบต์ที่ใช้สำหรับตัวอักษรกราฟิกจะเป็นเท่าใดก็ตาม การเข้ารหัส CJK ที่ใช้ในสภาพแวดล้อม 7 บิต ซึ่งใช้ กลไก ISO 2022ในการสลับระหว่างชุดตัวอักษร มักจะมีชื่อขึ้นต้นด้วย "ISO-2022-" โดยเฉพาะอย่างยิ่งISO-2022-JPแม้ว่าการเข้ารหัส CJK อื่นๆ เช่นEUC-JPก็ใช้กลไก ISO 2022 เช่นกัน^{[ 11 ] [ 12 ]}

เนื่องจากรหัสอักขระ 256 ตัวแรก ของUnicodeมาจากISO 8859-1ดังนั้น Unicode จึงสืบทอดแนวคิดของรหัสควบคุม C0 และ C1มาจาก ISO 2022 แม้ว่าจะเพิ่มอักขระที่ไม่สามารถพิมพ์ได้อื่นๆนอกเหนือจากรหัสควบคุมของ ISO 2022 ก็ตาม อย่างไรก็ตามรูปแบบการแปลง Unicodeเช่นUTF-8โดยทั่วไปจะแตกต่างจากโครงสร้างของ ISO 2022 ในหลายๆ ด้าน รวมถึง:

• ใช้ไบต์ 8 บิต แต่ไม่ได้แสดงรหัส C1 ในรูปแบบไบต์เดียวตามที่ระบุไว้ใน ISO 2022 (UTF ส่วนใหญ่ ยกเว้นUTF-1 ที่ล้าสมัย )
• การแสดงอักขระทั้งหมด รวมถึงรหัสควบคุม ด้วยไบต์หลายไบต์ (เช่นUTF-16 , UTF-32 )
• การผสมไบต์ที่มีบิตสำคัญที่สุดถูกตั้งค่าและไม่ได้ตั้งค่าภายในรูปแบบการเข้ารหัสสำหรับจุดรหัสเดียว (เช่น UTF-1, GB 18030 )

อย่างไรก็ตาม ลำดับการหลีกเลี่ยง ISO 2022 มีอยู่สำหรับการสลับไปมาระหว่าง UTF-8 ในฐานะ " ระบบการเข้ารหัสที่แตกต่างจาก ISO 2022 " ^{[ 13 ]}ซึ่งได้รับการสนับสนุนโดยโปรแกรมจำลองเทอร์มินัลบาง ตัว เช่นxterm ^{[ 14 ]}

มาตรฐาน ISO/IEC 2022 ระบุสิ่งต่อไปนี้:

• โครงสร้างพื้นฐานของชุดอักขระหลายชุดที่มีโครงสร้างเฉพาะซึ่งอาจรวมอยู่ในระบบการเข้ารหัสอักขระเดียว^รวมถึงชุดอักขระกราฟิกหลายชุดและชุดรหัสควบคุมหลัก (C0) และรหัสควบคุมรอง (C1) หลายชุด [ ^{15 ]}
• รูปแบบสำหรับการเข้ารหัสชุดเหล่านี้ โดยสมมติว่ามี 8 บิตต่อไบต์^{[ 16 ]}
• รูปแบบสำหรับการเข้ารหัสชุดเหล่านี้ในระบบการเข้ารหัสเดียวกันเมื่อมี 7 บิตต่อไบต์เท่านั้น^{[ 17 ]}และวิธีการแปลงข้อมูลอักขระที่สอดคล้องกันใดๆ เพื่อผ่านสภาพแวดล้อม 7 บิตดังกล่าว^{[ 8 ]}
• โครงสร้างทั่วไปของ รหัสหลีก ^{เลี่ยง} ANSI [ ^{6 ]}และ
• รูปแบบรหัสหลบหนีเฉพาะสำหรับการระบุชุดอักขระแต่ละชุด^{[ 7 ]}สำหรับการประกาศการใช้คุณลักษณะการเข้ารหัสเฉพาะหรือชุดย่อย^{[ 18 ]}และสำหรับการโต้ตอบหรือการเปลี่ยนไปใช้ระบบการเข้ารหัสอื่น^{[ 18 ]}

การใช้งานเฉพาะไม่จำเป็นต้องนำมาตรฐานทั้งหมดมาใช้ ระดับความสอดคล้องและชุดอักขระที่รองรับจะถูกกำหนดโดยการใช้งาน แม้ว่ากลไกหลายอย่างที่กำหนดโดยมาตรฐาน ISO/IEC 2022 จะไม่ค่อยได้ใช้ แต่การเข้ารหัสที่ได้รับการยอมรับหลายระบบนั้นอิงตามชุดย่อยของระบบ ISO/IEC 2022 ^{[ 19 ]}โดยเฉพาะอย่างยิ่ง ระบบการเข้ารหัส 7 บิตที่ใช้กลไก ISO/IEC 2022 ได้แก่ISO-2022-JP (หรือการเข้ารหัส JIS ) ซึ่งส่วนใหญ่ใช้ใน อีเมลภาษาญี่ปุ่นระบบการเข้ารหัส 8 บิตที่สอดคล้องกับ ISO/IEC 2022 ได้แก่ISO/IEC 4873 (ECMA- ⁴³ ) ซึ่งสอดคล้องกับISO/IEC 8859 [ ^{9 ] [ 10 ]}และExtended Unix Codeซึ่งใช้สำหรับภาษาเอเชียตะวันออก^{[ 11 ]}แอปพลิเคชันเฉพาะทางเพิ่มเติมของ ISO 2022 ได้แก่ ระบบการเข้ารหัส MARC-8ที่ใช้ในระเบียนห้องสมุดMARC 21 ^{[ 3 ]}

ลำดับการหลีกเลี่ยง (escape sequences) สำหรับการเปลี่ยนไปใช้ชุดอักขระหรือการเข้ารหัสเฉพาะนั้น จะถูกลงทะเบียนไว้ใน รีจิสทรี ISO-IR (ยกเว้นที่สงวนไว้สำหรับการใช้งานส่วนตัว ซึ่งความหมายจะถูกกำหนดโดยผู้ผลิต หรือโดยข้อกำหนดของโปรโตคอล เช่นARIB STD-B24 ) และเป็นไปตามรูปแบบที่กำหนดไว้ในมาตรฐาน การเข้ารหัสอักขระที่ใช้ลำดับการหลีกเลี่ยงเหล่านี้ จำเป็นต้องประมวลผลข้อมูลตามลำดับไปข้างหน้า เนื่องจากความถูกต้องของการตีความข้อมูลขึ้นอยู่กับลำดับการหลีกเลี่ยงที่พบก่อนหน้านี้

มาตรฐานเฉพาะ เช่น ISO-2022-JP อาจกำหนดเงื่อนไขเพิ่มเติม เช่น การรีเซ็ตชุดอักขระปัจจุบันเป็น US-ASCII ก่อนสิ้นสุดบรรทัด นอกจากนี้ ลำดับการหลีกเลี่ยงที่ประกาศชุดอักขระประจำชาติอาจไม่มีอยู่ หากการเข้ารหัสแบบ ISO-2022 เฉพาะอนุญาตหรือกำหนดให้ใช้ชุดอักขระประจำชาติเฉพาะ ตัวอย่างเช่น ISO-8859-1 ระบุว่าไม่จำเป็นต้องมีลำดับการหลีกเลี่ยงที่กำหนดไว้

เพื่อแสดงชุดอักขระขนาดใหญ่ ISO/IEC 2022 ได้พัฒนาต่อยอดจาก คุณสมบัติของ ISO/IEC 646ที่ระบุว่า การแสดงอักขระเจ็ดบิตโดยปกติจะสามารถแสดงอักขระกราฟิก (ที่พิมพ์ได้) ได้ 94 ตัว (นอกเหนือจากช่องว่างและอักขระควบคุม 33 ตัว) หากไม่นับรวมรหัสควบคุม C0 (ที่กำหนดไว้อย่างแคบ) จะสามารถขยายได้ถึง 96 ตัวอักขระ การใช้สองไบต์จึงสามารถแสดงอักขระได้มากถึง 8,836 ตัว (94×94) และการใช้สามไบต์สามารถแสดงอักขระได้มากถึง 830,584 ตัว (94×94×94) แม้ว่ามาตรฐานจะกำหนดไว้ แต่ไม่มีชุดอักขระที่ลงทะเบียนใดใช้สามไบต์ (ถึงแม้ว่าG2 ที่ไม่ได้ลงทะเบียนของEUC-TW จะใช้ และ CCCII ที่ไม่ได้ลงทะเบียนเช่นกันก็ใช้เช่นกัน )

สำหรับชุดอักขระสองไบต์จุดรหัสของแต่ละอักขระมักจะระบุในรูปแบบที่เรียกว่าแถว-เซลล์หรือคูเท็น^{[ a ]}ซึ่งประกอบด้วยตัวเลขสองตัวระหว่าง 1 ถึง 94 รวมทั้งสองค่า โดยระบุแถว^{[ b ]}และเซลล์^{[ c ]}ของอักขระนั้นภายในโซน สำหรับชุดสามไบต์ จะมีหมายเลข ระนาบ^{[ d ]} เพิ่มเติม รวมอยู่ด้วยที่จุดเริ่มต้น^{[ 20 ]}ลำดับการหลีกเลี่ยงไม่เพียงแต่ประกาศว่ากำลังใช้ชุดอักขระใด แต่ยังระบุด้วยว่าชุดนั้นเป็นแบบไบต์เดียวหรือหลายไบต์ (แม้ว่าจะไม่ได้ระบุจำนวนไบต์ที่ใช้หากเป็นแบบหลายไบต์) และยังระบุด้วยว่าแต่ละไบต์มีค่าที่อนุญาต 94 หรือ 96 ค่า

การเข้ารหัส ISO/IEC 2022 ระบุการแมปสองชั้นระหว่างรหัสอักขระและอักขระที่แสดง ลำดับการหลีกเลี่ยงอนุญาตให้ชุดอักขระกราฟิกจำนวนมากสามารถ "กำหนด" ^{[ 21 ]}ลงในชุดการทำงานสี่ชุดใดชุดหนึ่ง ซึ่งตั้งชื่อว่า G0 ถึง G3 และลำดับการควบคุมที่สั้นกว่าจะระบุชุดการทำงานที่ "เรียกใช้" ^{[ 22 ]}เพื่อตีความไบต์ในสตรีม

ค่าไบต์ที่เข้ารหัส ("ชุดบิต") มักจะแสดงในรูปแบบคอลัมน์-บรรทัดโดยที่ตัวเลขทศนิยมสองตัวในช่วง 00–15 (แต่ละตัวสอดคล้องกับตัวเลขฐานสิบหกหนึ่งหลัก) ^{[ 23 ]}จะถูกคั่นด้วยเครื่องหมายทับ^{[ 24 ]}ดังนั้น ตัวอย่างเช่น รหัส 2/0 (0x20) ถึง 2/15 (0x2F) อาจถูกเรียกว่า "คอลัมน์ 02" นี่คือสัญกรณ์ที่ใช้ในมาตรฐาน ISO/IEC 2022 / ECMA-35 เอง^{[ 25 ]}อาจมีการอธิบายในที่อื่นโดยใช้เลขฐานสิบหกดังที่มักใช้ในบทความนี้ หรือใช้ตัวอักขระ ASCII ที่สอดคล้องกัน^{[ 26 ]}แม้ว่าลำดับการหลีกเลี่ยงจะถูกกำหนดในแง่ของค่าไบต์ และกราฟิกที่กำหนดให้กับค่าไบต์นั้นอาจถูกเปลี่ยนแปลงได้โดยไม่ส่งผลกระทบต่อลำดับการควบคุม

ค่าไบต์จากช่วงกราฟิก ASCII 7 บิต (เลขฐานสิบหก 0x20–0x7F) ซึ่งอยู่ทางด้านซ้ายของตารางรหัสอักขระ เรียกว่า รหัส "GL" (โดย "GL" ย่อมาจาก "graphics left")ในขณะที่ไบต์จากช่วง "ASCII สูง" (0xA0–0xFF) หากมี (เช่น ในสภาพแวดล้อม 8 บิต) เรียกว่า รหัส "GR" ("graphics right") [ ^{5 ] คำ}ว่า "CL" (0x00–0x1F) และ "CR" (0x80–0x9F) ถูกกำหนดไว้สำหรับช่วงควบคุม แต่ช่วง CL จะเรียกใช้การควบคุมหลัก (C0) เสมอ ในขณะที่ช่วง CR จะเรียกใช้การควบคุมรอง (C1) หรือไม่ใช้งาน^{[ 5 ]}

อักขระลบ DEL (0x7F) อักขระหลีก ESC (0x1B) และอักขระเว้นวรรค SP (0x20) ถูกกำหนดให้เป็นอักขระรหัส "คงที่" ^{[ 27 ]}และจะพร้อมใช้งานเสมอเมื่อเรียกใช้ G0 ผ่าน GL โดยไม่คำนึงถึงชุดอักขระที่กำหนดไว้ อักขระเหล่านี้อาจไม่รวมอยู่ในชุดอักขระกราฟิก แม้ว่าขนาดหรือประเภทของอักขระเว้นวรรค อื่นๆ อาจจะ รวมอยู่ด้วยก็ตาม ^{[ 28 ]}

ลำดับที่ใช้ตัวอักษร ESC (escape) จะอยู่ในรูปแบบโดยที่ตัวอักษร ESC จะตามด้วยไบต์กลางศูนย์ไบต์หรือมากกว่า^{[ 29 ]} ( I ) จากช่วง 0x20–0x2F และไบต์สุดท้ายหนึ่งไบต์^{[ 30 ]} ( F ) จากช่วง 0x30–0x7E ^{[ 31 ]}ESC [I...] F

ไบต์ Iตัวแรกหรือการไม่มีไบต์ I ตัวแรก จะกำหนดประเภทของลำดับการหลีกเลี่ยง ตัวอย่างเช่น อาจกำหนดชุดการทำงาน หรือระบุฟังก์ชันควบคุมเดียว ในลำดับการหลีกเลี่ยงทุกประเภท ไบต์ Fในช่วง 0x30–0x3F จะถูกสงวนไว้สำหรับการใช้งานส่วนตัวที่ไม่ได้ลงทะเบียน ซึ่งกำหนดโดยข้อตกลงล่วงหน้าระหว่างฝ่ายต่างๆ^{[ 32 ]}

ฟังก์ชันควบคุมจากชุดบางชุดอาจใช้ไบต์เพิ่มเติมตามหลังลำดับการหลีกเลี่ยงที่เหมาะสม ตัวอย่างเช่นฟังก์ชันควบคุมISO 6429 " ตัวแนะนำลำดับควบคุม " ซึ่งสามารถแสดงได้โดยใช้ลำดับการหลีกเลี่ยง จะตามด้วยไบต์ศูนย์ไบต์ขึ้นไปในช่วง 0x30–0x3F จากนั้นไบต์ศูนย์ไบต์ขึ้นไปในช่วง 0x20–0x2F จากนั้นไบต์เดียวในช่วง 0x40–0x7E ลำดับทั้งหมดนี้เรียกว่า "ลำดับควบคุม" ^{[ 33 ]}

ชุดการทำงานทั้งสี่ชุด G0 ถึง G3 แต่ละชุดอาจเป็นชุดอักขระ 94 ตัว หรือชุดอักขระหลายไบต์ 94n ตัวนอกจาก^นี้ G1 ถึง G3 อาจเป็นชุดอักขระ 96 ตัว หรือ ^{96n ตัว}

ในชุดอักขระ 96 หรือ 96n ^ไบต์ 0x20 ถึง 0x7F เมื่อเรียกใช้ GL หรือ 0xA0 ถึง 0xFF เมื่อเรียกใช้ GR จะถูกจัดสรรให้กับชุดอักขระนั้นและอาจถูกใช้งาน ในชุดอักขระ 94 หรือ 94n ^ไบต์ 0x20 และ 0x7F จะไม่ถูกใช้งาน^{[ 34 ]}เมื่อเรียกใช้ชุดอักขระ 96 หรือ 96n ^ในพื้นที่ GL อักขระเว้นวรรคและลบ (รหัส 0x20 และ 0x7F) จะไม่สามารถใช้งานได้จนกว่าจะเรียกใช้ชุดอักขระ 94 หรือ 94n ⁽เช่น ชุด G0) ใน GL ^{[ 5 ]}ไม่สามารถกำหนดชุดอักขระ 96 ให้กับ G0 ได้

การลงทะเบียนชุดอักขระเป็นชุด 96 ตัวไม่ได้หมายความว่าไบต์ 0x20/A0 และ 0x7F/FF จะถูกจัดสรรให้กับชุดอักขระนั้นจริง ๆ ตัวอย่างของชุดอักขระกราฟิกที่ลงทะเบียนเป็นชุด 96 ตัวแต่ไม่ได้ใช้ไบต์เหล่านั้น ได้แก่ ชุด G1 ของ^IS 434 [ ^{35 ]}ชุดวาดกล่องจากISO/IEC 10367 [ ^{36 ] และ ISO -} IR-164 (ชุดย่อยของชุด G1 ของISO-8859-8ที่มีเฉพาะตัวอักษร ซึ่งใช้โดยCCITT ) ^{[ 37 ]}

คาดว่าอักขระจะเป็นอักขระเว้นวรรค ไม่ใช่อักขระรวม เว้นแต่จะระบุไว้เป็นอย่างอื่นโดยชุดกราฟิกที่เกี่ยวข้อง^{[ 38 ]} ISO 2022 / ECMA-35 ยังยอมรับการใช้ อักขระควบคุม backspaceและ carriage return เป็นวิธีการรวมอักขระเว้นวรรค รวมถึงลำดับ CSI "Graphic Character Combination" (GCC) ^{[ 38 ]} ( CSI 0x20 (SP) 0x5F (_)) ^{[ 39 ]}

การใช้ปุ่ม backspace และ carriage return ในลักษณะนี้ได้รับอนุญาตตามมาตรฐาน^ISO /IEC 646แต่ถูกห้ามโดยISO/IEC 4873 / ECMA-43 ^{[ 40 ]}และโดยISO/IEC 8859 [ ^{41 ] [ 42 ]}เนื่องจากทำให้ชุดอักขระกราฟิกไม่ได้รับการกำหนดไว้ อย่างไรก็ตาม ISO/IEC 4873 / ECMA-43 อนุญาตให้ใช้ฟังก์ชัน GCC ได้ โดยมีเงื่อนไขว่าลำดับของอักขระจะต้องคงเดิมและแสดงในพื้นที่เดียวเท่านั้น แทนที่จะถูกประทับทับเพื่อสร้างอักขระที่มีความหมายต่างกัน^{[ 43 ]}

ชุดอักขระควบคุมถูกจำแนกเป็นชุดรหัสควบคุม "หลัก" หรือ "รอง" ^{[ 44 ]}ซึ่งเรียกอีกอย่างว่าชุดรหัสควบคุม "C0" และ "C1" ^{[ 45 ]}

ชุดควบคุม C0 ต้องมีอักขระควบคุม ESC (escape) ที่ 0x1B ^{[ 46 ]} (ชุด C0 ที่มีเฉพาะ ESC จะถูกลงทะเบียนเป็น ISO-IR-104) ^{[ 47 ]}ในขณะที่ชุดควบคุม C1 อาจไม่มีอักขระควบคุม escape เลยก็ได้^{[ 34 ]}ดังนั้น จึงเป็นการลงทะเบียนที่แยกจากกันโดยสิ้นเชิง โดยชุด C0 ก็คือชุด C0 และชุด C1 ก็คือชุด C1 ^{[ 45 ]}

หากรหัสจากชุด C0 ของ ISO 6429 / ECMA-48 เช่นรหัสควบคุม ASCIIปรากฏในชุด C0 จะต้องปรากฏในตำแหน่ง ISO 6429 / ECMA-48 ^{[ 46 ]}การรวมอักขระควบคุมการส่งสัญญาณในชุด C0 นอกเหนือจากสิบตัวที่รวมอยู่ใน ISO 6429 / ECMA-48 (ได้แก่ SOH, STX, ETX, EOT, ENQ, ACK, DLE, NAK, SYN และ ETB) ^{[ 48 ]}หรือการรวมอักขระใดๆ ในสิบตัวนั้นในชุด C1 ก็เป็นสิ่งต้องห้ามตามมาตรฐาน ISO/IEC 2022 / ECMA-35 เช่นกัน^{[ 46 ] [ 34 ]}

ชุดควบคุม C0 จะถูกเรียกใช้ในช่วง CL 0x00 ถึง 0x1F ^{[ 49 ]}ในขณะที่ฟังก์ชันควบคุม C1 อาจถูกเรียกใช้ในช่วง CR 0x80 ถึง 0x9F (ในสภาพแวดล้อม 8 บิต) หรือโดยใช้ลำดับการหลีกเลี่ยง (ในสภาพแวดล้อม 7 บิตหรือ 8 บิต) ^{[ 44 ]}แต่ไม่ใช่ทั้งสองอย่าง ต้องระบุรูปแบบการเรียกใช้ C1 ที่ใช้ในคำจำกัดความของเวอร์ชันโค้ด^{[ 50 ]}ตัวอย่างเช่น ISO/IEC 4873 ระบุไบต์ CR สำหรับการควบคุม C1 ที่ใช้ (SS2 และ SS3) ^{[ 51 ]}หากจำเป็น อาจสื่อสารการเรียกใช้ที่ใช้โดยใช้ลำดับ ผู้ประกาศ

ในกรณีหลัง ฟังก์ชันควบคุมเดี่ยวจากชุดรหัสควบคุม C1 จะถูกเรียกใช้โดยใช้ลำดับการหลีกเลี่ยง "ประเภท Fe" ^{[ 34 ]}ซึ่งหมายถึงลำดับที่อักขระควบคุม ESC ตามด้วยไบต์จากคอลัมน์ 04 หรือ 05 (กล่าวคือESC 0x40 (@)ผ่านทางESC 0x5F (_)) ^{[ 52 ]}

ฟังก์ชันควบคุมเพิ่มเติมจะถูกกำหนดให้กับลำดับการหลีกเลี่ยง "ประเภท Fs" (ในช่วงESC 0x60 (`)ถึงESC 0x7E (~)); ฟังก์ชันเหล่านี้มีความหมายที่กำหนดไว้อย่างถาวรแทนที่จะขึ้นอยู่กับการกำหนด C0 หรือ C1 ^{[ 52 ] [ 53 ]}การลงทะเบียนฟังก์ชันควบคุมให้กับลำดับประเภท "Fs" ต้องได้รับการอนุมัติจากISO/IEC JTC 1/SC 2 [ ^{53 ] ฟังก์ชัน}ควบคุมเดี่ยวอื่นๆ อาจได้รับการลงทะเบียนให้กับลำดับการหลีกเลี่ยงประเภท "3Ft" (ในช่วงถึง) ^{[ 54 ]}แม้ว่าจะไม่มีการกำหนดลำดับ "3Ft" ในปัจจุบัน (ณ ปี 2019) ^{[ 55 ]}บางส่วนระบุไว้ใน ECMA-35 (ISO 2022 / ANSI X3.41) และบางส่วนใน ECMA-48 (ISO 6429 / ANSI X3.64) ^{[ 56 ]} ECMA-48 เรียกสิ่งเหล่านี้ว่า "ฟังก์ชันควบคุมอิสระ" ^{[ 57 ]}ESC 0x23 (#) [I...] 0x40 (@)ESC 0x23 (#) [I...] 0x7E (~)

ลำดับการหลีกเลี่ยงประเภท "Fp" ( ESC 0x30 (0)ถึงESC 0x3F (?)) หรือประเภท "3Fp" ( ถึง) สงวนไว้สำหรับรหัสควบคุมการใช้งานส่วนตัวเดียว โดยข้อตกลงล่วงหน้าระหว่างฝ่ายต่างๆ^{[ 59 ]}ลำดับดังกล่าวหลายลำดับทั้งสองประเภทถูกใช้โดยเทอร์ มินัล DECเช่นVT100และได้รับการสนับสนุนโดยโปรแกรมจำลองเทอร์มินัล^{[ 14 ]}ESC 0x23 (#) [I...] 0x30 (0)ESC 0x23 (#) [I...] 0x3F (?)

โดยค่าเริ่มต้น รหัส GL จะระบุอักขระ G0 และรหัส GR (ถ้ามี) จะระบุอักขระ G1 ซึ่งอาจระบุเป็นอย่างอื่นได้ตามข้อตกลงก่อนหน้านี้ ชุดที่เรียกใช้ในแต่ละพื้นที่อาจได้รับการแก้ไขด้วยรหัสควบคุมที่เรียกว่าการเลื่อน ดังแสดงในตารางด้านล่าง^{[ 60 ]}

รหัส 8 บิตอาจมีรหัส GR ที่ระบุอักขระ G1 โดยใช้รหัส 7 บิตที่สอดคล้องกันโดยใช้Shift InและShift Outเพื่อสลับระหว่างชุด (เช่นJIS X 0201 ) ^{[ 61 ]}แม้ว่าบางรหัสจะมีรหัส GR ที่ระบุอักขระ G2 โดยใช้รหัส 7 บิตที่สอดคล้องกันโดยใช้รหัส Shift เดียวเพื่อเข้าถึงชุดที่สอง (เช่นT.51 ) ^{[ 62 ]}

รหัสที่แสดงในตารางด้านล่างเป็นการเข้ารหัสที่พบบ่อยที่สุดของรหัสควบคุมเหล่านี้ ซึ่งสอดคล้องกับISO/IEC 6429การเปลี่ยน LS2, LS3, LS1R, LS2R และ LS3R จะถูกลงทะเบียนเป็นฟังก์ชันควบคุมเดี่ยวและจะถูกเข้ารหัสเป็นลำดับการหลีกเลี่ยงที่แสดงด้านล่างเสมอ^{[ 55 ]}ในขณะที่ส่วนอื่นๆ เป็นส่วนหนึ่งของชุดรหัสควบคุม C0 หรือ C1 (ดังที่แสดงด้านล่าง SI (LS0) และ SO (LS1) เป็นการควบคุม C0 และ SS2 และ SS3 เป็นการควบคุม C1) ซึ่งหมายความว่าการเข้ารหัสและความพร้อมใช้งานอาจแตกต่างกันไปขึ้นอยู่กับชุดควบคุมที่กำหนด: จะต้องมีอยู่ในชุดควบคุมที่กำหนดหากมีการใช้ฟังก์ชันการทำงาน^{[ 49 ] [ 50 ]}การควบคุม C1 เอง ดังที่กล่าวไว้ข้างต้น อาจแสดงโดยใช้ลำดับการหลีกเลี่ยงหรือไบต์ 8 บิต แต่ไม่ใช่ทั้งสองอย่าง

การเข้ารหัสทางเลือกของการเลื่อนแบบเดี่ยวเป็นรหัสควบคุม C0 นั้นมีอยู่ในชุดรหัสควบคุมบางชุด ตัวอย่างเช่น SS2 และ SS3 มักจะมีอยู่ที่ 0x19 และ 0x1D ตามลำดับในT.51 ^{[ 62 ]}และT.61 ^[ 63 ^{] ปัจจุบัน ISO/IEC 2022 / ECMA- 35}แนะนำการเข้ารหัสนี้สำหรับแอปพลิเคชันที่ต้องการการแสดง SS2 และ SS3 แบบไบต์เดียว 7 บิต^{[ 64 ]}และอาจใช้สำหรับ SS2 เท่านั้น^{[ 65 ]}แม้ว่าจะมีชุดรหัสเก่าที่มี SS2 ที่ 0x1C อยู่ด้วย^{[ 66 ] [ 67 ] [ 68 ]}และมีการกล่าวถึงเช่นนั้นในมาตรฐานฉบับก่อนหน้า^{[ 69 ]}การเข้ารหัส 0x8E และ 0x8F ของการเลื่อนแบบเดี่ยวตามที่แสดงด้านล่างเป็นข้อบังคับสำหรับISO/IEC 4873ระดับ 2 และ 3 ^{[ 70 ]}

แม้ว่าจะถือว่าเป็นรหัสการเลื่อนอย่างเป็นทางการและตั้งชื่อตามนั้น แต่รหัสการเลื่อนเดี่ยวก็ไม่ได้ถูกมองว่าเป็นการเลื่อนเสมอไป^{[ 12 ]}และอาจถูกมองว่าเป็นเพียงไบต์คำนำหน้า (เช่น ไบต์แรกในลำดับหลายไบต์) ^{[ 11 ]}เนื่องจากไม่จำเป็นต้องให้ตัวเข้ารหัสเก็บชุดที่ใช้งานอยู่ปัจจุบันเป็นสถานะซึ่งแตกต่างจากรหัสการเลื่อนแบบล็อก ในสภาพแวดล้อม 8 บิต อาจใช้ GL หรือ GR แต่ไม่ใช่ทั้งสองอย่าง เป็นพื้นที่การเลื่อนเดี่ยว ซึ่งต้องระบุไว้ในคำจำกัดความของเวอร์ชันรหัส^{[ 73 ]}ตัวอย่างเช่นISO/IEC 4873ระบุ GL ในขณะที่EUC แบบแพ็คระบุ GR ในสภาพแวดล้อม 7 บิต จะใช้ GL เป็นพื้นที่การเลื่อนเดี่ยวเท่านั้น^{[ 75 ] [ 76 ]}หากจำเป็น อาจสื่อสารว่าใช้พื้นที่การเลื่อนเดี่ยวใดโดยใช้ลำดับผู้ประกาศ

ชื่อ "การล็อกการเลื่อนศูนย์" (LS0) และ "การล็อกการเลื่อนหนึ่ง" (LS1) หมายถึงอักขระควบคุม C0 คู่เดียวกัน (0x0F และ 0x0E) เช่นเดียวกับชื่อ "เลื่อนเข้า" (SI) และ "เลื่อนออก" (SO) อย่างไรก็ตาม มาตรฐานจะอ้างถึงพวกมันเป็น LS0 และ LS1 เมื่อใช้ในสภาพแวดล้อม 8 บิต และเป็น SI และ SO เมื่อใช้ในสภาพแวดล้อม 7 บิต^{[ 60 ]}

มาตรฐาน ISO/IEC 2022 / ECMA-35 อนุญาต แต่ไม่สนับสนุนให้เรียกใช้ G1, G2 หรือ G3 ใน GL และ GR พร้อมกัน^{[ 77 ]}

ทะเบียนชุดอักขระรหัสสากลของ ISO ที่ใช้ลำดับการหลีกเลี่ยง (ISO-IR) แสดงรายการชุดอักขระกราฟิก ชุดรหัสควบคุม รหัสควบคุมเดี่ยว และอื่นๆ ที่ได้รับการลงทะเบียนเพื่อใช้กับ ISO/IEC 2022 ขั้นตอนการลงทะเบียนรหัสและชุดกับทะเบียน ISO-IR ระบุไว้ในISO/IEC 2375การลงทะเบียนแต่ละครั้งจะได้รับลำดับการหลีกเลี่ยงที่ไม่ซ้ำกัน และหมายเลขรายการทะเบียนที่ไม่ซ้ำกันเพื่อระบุ^{[ 78 ] [ 79 ]}ตัวอย่างเช่น ชุดอักขระ CCITTสำหรับภาษาจีนตัวย่อเรียกว่าISO-IR- 165

การลงทะเบียนชุดอักขระที่เข้ารหัสกับรีจิสทรี ISO-IR ระบุเอกสารที่ระบุชุดอักขระหรือฟังก์ชันควบคุมที่เกี่ยวข้องกับลำดับการหลีกเลี่ยงการใช้งานที่ไม่ใช่ส่วนตัวของ ISO/IEC 2022 ซึ่งอาจเป็นเอกสารมาตรฐาน อย่างไรก็ตาม การลงทะเบียนไม่ได้สร้างมาตรฐาน ISO ใหม่ ไม่ได้ผูกมัด ISO หรือ IEC ให้ยอมรับเป็นมาตรฐานสากล และไม่ได้ผูกมัด ISO หรือ IEC ให้เพิ่มอักขระใดๆ ลงใน ชุดอักขระ ที่เข้ารหัสสากล^{[ 80 ]}

ลำดับการหลีกเลี่ยงที่ลงทะเบียน ISO-IR ยังถูกใช้โดยห่อหุ้มไว้ในFormal Public Identifierเพื่อระบุชุดอักขระที่ใช้สำหรับการอ้างอิงอักขระตัวเลขในSGML (ISO 8879) ตัวอย่างเช่น สตริงนี้ISO 646-1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0สามารถใช้เพื่อระบุ International Reference Version ของISO 646 -1983 ^{[ 81 ]}และ ข้อกำหนด HTML 4.01 ใช้ISO Registration Number 177//CHARSET ISO/IEC 10646-1:1993 UCS-4 with implementation level 3//ESC 2/5 2/15 4/6เพื่อระบุ Unicode ^{[ 82 ]}การแสดงข้อความของลำดับการหลีกเลี่ยง ซึ่งรวมอยู่ในองค์ประกอบที่สามของ FPI จะได้รับการยอมรับโดยการใช้งาน SGML สำหรับชุดอักขระที่รองรับ^{[ 81 ]}

ลำดับการหลีกเลี่ยงเพื่อกำหนดชุดอักขระมีรูปแบบดังนี้ดังที่กล่าวไว้ข้างต้น ไบต์กลาง ( I ) อยู่ในช่วง 0x20–0x2F และไบต์สุดท้าย ( F ) อยู่ในช่วง 0x30–0x7E ไบต์ I ตัวแรก (หรือสำหรับชุดหลายไบต์ สองตัวแรก) ระบุประเภทของชุดอักขระและชุดการทำงานที่จะกำหนดให้ ในขณะที่ ไบต์ F (และไบต์ Iเพิ่มเติมใดๆ) ระบุชุดอักขระนั้นเอง ตามที่กำหนดไว้ในรีจิสเตอร์ ISO-IR (หรือสำหรับลำดับการหลีกเลี่ยงที่ใช้ส่วนตัว ตามข้อตกลงก่อนหน้านี้) ESC I [I...] F

สามารถเพิ่มไบต์Iเพิ่มเติม ก่อนไบต์ Fเพื่อขยาย ช่วงไบต์ Fปัจจุบันใช้เฉพาะกับชุดอักขระ 94 ตัวเท่านั้น โดยที่รหัสในรูปแบบดังกล่าวได้รับการกำหนดไว้^{[ 83 ]}ในทางกลับกัน ยังไม่มีการลงทะเบียนชุด 96 ไบต์แบบมัลติไบต์ ดังนั้นลำดับด้านล่างจึงเป็นเพียงทฤษฎีเท่านั้น ESC ( ! F

เช่นเดียวกับลำดับการหลีกเลี่ยงประเภทอื่นๆ ช่วง 0x30–0x3F สงวนไว้สำหรับไบต์F ที่ใช้ส่วนตัว ^{[ 32 ]}ในกรณีนี้สำหรับคำจำกัดความชุดอักขระที่ใช้ส่วนตัว (ซึ่งอาจรวมถึงชุดที่ไม่ได้ลงทะเบียนซึ่งกำหนดโดยโปรโตคอลเช่นARIB STD-B24 ^{[ 84 ]}หรือMARC-8 [ ^{3 ]}หรือชุดเฉพาะของผู้จำหน่ายเช่นDEC Special Graphics ) ^{[ 85 ]}อย่างไรก็ตาม ในลำดับการกำหนดชุดกราฟิก หาก ไบต์ I ตัวที่ ^สอง (สำหรับชุดไบต์เดียว) หรือ ไบต์ I ตัวที่สาม (สำหรับชุดสองไบต์) เป็น 0x20 (ช่องว่าง) ชุดที่ระบุจะเป็น " ชุดอักขระที่กำหนดใหม่ได้แบบไดนามิก " (DRCS) ที่กำหนดโดยข้อตกลงก่อนหน้า^{[ 86 ]}ซึ่งถือว่าเป็นการใช้ส่วนตัวเช่นกัน^{[ 32 ]}การที่ชุดกราฟิกถูกพิจารณาว่าเป็น DRCS หมายความว่าชุดนั้นแสดงถึงแบบอักษรของสัญลักษณ์ที่แน่นอน แทนที่จะเป็นชุดของอักขระนามธรรม^{[ 87 ]} ISO/IEC 2022 / ECMA-35 ไม่ได้กำหนดวิธีการส่ง จัดสรร และจัดการชุด DRCS และแบบอักษรที่เกี่ยวข้องไว้ แม้ว่าจะแนะนำให้จัดสรรตามลำดับโดยเริ่มจาก ไบต์ F 0x40 ก็ตาม ( ); ^{[ 88 ]}อย่างไรก็ตาม วิธีการส่งแบบอักษร DRCS ได้ถูกกำหนดไว้ในโปรโตคอลการสื่อสารโทรคมนาคมบางอย่าง เช่นWorld System Teletext ^{[ 89 ]}@

นอกจากนี้ยังมีกรณีพิเศษสามกรณีสำหรับรหัสหลายไบต์ ลำดับรหัสESC $ @, ESC $ A, และESC $ Bทั้งหมดได้รับการลงทะเบียนเมื่อมาตรฐานเวอร์ชันร่วมสมัยอนุญาตให้ใช้ชุดหลายไบต์เฉพาะใน G0 เท่านั้น ดังนั้นจึงต้องยอมรับแทนลำดับESC $ ( @ตั้งแต่ ถึงESC $ ( Bเพื่อกำหนดให้กับชุดอักขระ G0 ^{[ 90 ]}

มีคุณสมบัติเพิ่มเติม (ที่ใช้ไม่บ่อย) สำหรับการสลับชุดอักขระควบคุม แต่เป็นการค้นหาระดับเดียว เนื่องจาก (ดังที่กล่าวไว้ข้างต้น) ชุด C0 จะถูกเรียกใช้ผ่าน CL เสมอ และชุด C1 จะถูกเรียกใช้ผ่าน CR หรือโดยใช้รหัสหลีกเลี่ยง ดังที่กล่าวมาข้างต้น จำเป็นต้องมีชุดอักขระ C0 ใดๆ ที่มีอักขระ ESC ที่ตำแหน่ง 0x1B เพื่อให้สามารถเปลี่ยนแปลงเพิ่มเติมได้ ลำดับการกำหนดชุดควบคุม (ตรงข้ามกับลำดับชุดกราฟิก) อาจใช้จากภายในISO/IEC 10646 (UCS/Unicode) ในบริบทที่การประมวลผลรหัสหลีกเลี่ยง ANSIเหมาะสม โดยมีเงื่อนไขว่าแต่ละไบต์ในลำดับจะต้องเติมให้มีขนาดเท่ากับหน่วยรหัสของการเข้ารหัส^{[ 91 ]}

ตารางลำดับการหลีกเลี่ยงIไบต์และการกำหนดหรือฟังก์ชันอื่น ๆ ที่ดำเนินการมีดังต่อไปนี้^{[ 92 ]}

โปรดทราบว่าการลงทะเบียน ไบต์ F นั้น เป็นอิสระสำหรับประเภทต่างๆ ชุดกราฟิก 94 ตัวอักษรที่กำหนดโดยESC ( Aไม่ESC + Aเกี่ยวข้องกับชุด 96 ตัวอักษรที่กำหนดโดยESC - Aและ แต่ อย่างใด ESC / Aและทั้งสองชุดนั้นก็ไม่เกี่ยวข้องกับ ชุด ⁿตัวอักษร 94 ตัวที่กำหนดโดยESC $ ( AและESC $ + Aเป็นต้น ไบต์สุดท้ายจะต้องได้รับการตีความในบริบท (อันที่จริง โดยไม่มีไบต์กลางใดๆESC Aเป็นวิธีหนึ่งในการระบุรหัสควบคุม C1 0x81)

โปรดทราบด้วยว่าชุดอักขระควบคุม C0 และ C1 เป็นอิสระต่อกัน ชุดอักขระควบคุม C0 ที่กำหนดโดยESC ! A(ซึ่งเป็นชุดควบคุม NATS สำหรับการส่งข้อความในหนังสือพิมพ์) ไม่เหมือนกับชุดอักขระควบคุม C1 ที่กำหนดโดยESC " A( ชุดควบคุมคุณลักษณะCCITT สำหรับ Videotex )

มาตรฐานนี้ยังกำหนดวิธีการระบุระบบการเข้ารหัสที่ไม่เป็นไปตามโครงสร้างของมาตรฐานเองด้วย

นอกจากนี้ยังมีการกำหนดลำดับสำหรับการกลับไปยัง ISO/IEC 2022 ด้วย โดยการลงทะเบียนที่รองรับลำดับนี้ซึ่งเข้ารหัสใน ISO/IEC 2022 ประกอบด้วย (ณ ปี 2019) รูปแบบ Videotex ต่างๆ , UTF-8และUTF-1 [ ^{100 ] ไบต์} Iตัวที่สองของ 0x2F ( /) จะถูกรวมอยู่ในลำดับการกำหนดของรหัสที่ไม่ใช้ลำดับไบต์นั้นเพื่อกลับไปยัง ISO 2022 โดยอาจมีวิธีการของตนเองในการกลับไปยัง ISO 2022 (เช่น ลำดับที่แตกต่างกันหรือมีการเติม) หรือไม่มีเลย^{[ 101 ]}การลงทะเบียนที่มีอยู่ทั้งหมดของประเภทหลัง (ณ ปี 2019) เป็นข้อมูลดิบโปร่งใสรูปแบบ Unicode/UCSหรือชุดย่อยของรูปแบบเหล่านั้น^{[ 102 ]}

สิ่งที่น่าสนใจเป็นพิเศษคือลำดับที่เปลี่ยนไปใช้ รูปแบบ ISO/IEC 10646 ( Unicode ) ซึ่งไม่เป็นไปตามโครงสร้าง ISO/IEC 2022 ซึ่งรวมถึง UTF-8 (ซึ่งไม่ได้สงวนช่วง 0x80–0x9F สำหรับอักขระควบคุม) รุ่นก่อนหน้าคือ UTF-1 (ซึ่งผสมไบต์ GR และ GL ในรหัสหลายไบต์) และ UTF-16 และ UTF-32 (ซึ่งใช้หน่วยการเข้ารหัสที่กว้างกว่า) ^{[ 100 ] [ 102 ]}

นอกจากนี้ ยังมีการลงทะเบียนรหัสหลายรหัสสำหรับชุดย่อย (ระดับ 1 และ 2) ของ UTF-8, UTF-16 และ UTF-32 รวมถึงสำหรับUCS-2สาม ระดับด้วย ^{[ 102 ]}อย่างไรก็ตาม รหัสเดียวที่ระบุไว้ใน ISO/IEC 10646 ในปัจจุบันคือรหัสระดับ 3 สำหรับ UTF-8, UTF-16 และ UTF-32 และรหัสระดับที่ไม่ระบุสำหรับ UTF-8 ส่วนที่เหลือถูกระบุว่าเลิกใช้แล้ว^{[ 104 ]} ISO/IEC 10646 กำหนดว่า รูปแบบ big-endianของ UTF-16 และ UTF-32 ถูกกำหนดโดยลำดับการหลีกเลี่ยง^{[ 105 ]}

ในบรรดาลำดับที่เปลี่ยนไปใช้ UTF-8 ESC % Gนั้น ลำดับที่ได้รับการสนับสนุนโดยxtermเป็นต้น^{[ 14 ]}

แม้ว่าจะอนุญาตให้ใช้รูปแบบหนึ่งของลำดับการคืนค่ามาตรฐานจาก UTF-16 และ UTF-32 ได้ แต่ไบต์ของลำดับการหลีกเลี่ยงจะต้องเติมให้มีขนาดเท่ากับหน่วยรหัสของการเข้ารหัส (เช่น001B 0025 0040สำหรับ UTF-16) กล่าวคือ การเข้ารหัสของลำดับการคืนค่ามาตรฐานไม่ได้สอดคล้องกับ ISO/IEC 2022 อย่างแน่นอน ด้วยเหตุนี้ การกำหนดสำหรับ UTF-16 และ UTF-32 จึงใช้ไวยากรณ์แบบไม่มีการคืนค่ามาตรฐาน^{[ 108 ]}

สำหรับการระบุการเข้ารหัสโดยใช้ป้ายกำกับ รูปแบบ Compound TextของX Consortiumกำหนดลำดับ DOCS สำหรับการใช้งานส่วนตัวห้าลำดับ^{[ 109 ]}

ลำดับ "ประกาศโครงสร้างรหัส" ( ) ใช้เพื่อประกาศโครงสร้างรหัสเฉพาะ หรือกลุ่มเฉพาะของสิ่งอำนวยความสะดวก ISO 2022 ที่ใช้ในเวอร์ชันรหัสเฉพาะ แม้ว่าการประกาศจะสามารถรวมกันได้ แต่การรวมกันที่ขัดแย้งกันบางอย่าง (โดยเฉพาะ การใช้การประกาศการเลื่อนการล็อก 16–23 ร่วมกับการประกาศ 1, 3 และ 4) เป็นสิ่งต้องห้ามตามมาตรฐาน เช่นเดียวกับการใช้การประกาศเพิ่มเติมเหนือ การประกาศระดับ ISO/IEC 4873 12–14 ^{[ 93 ]} (ซึ่งระบุคุณลักษณะโครงสร้างที่อนุญาตอย่างครบถ้วน) ลำดับการประกาศมีดังนี้: ESC SP (0x20) F

IETF RFCs กำหนดเวอร์ชันรหัส ISO 2022 7 บิตจำนวน 6 เวอร์ชัน (ISO-2022-CN, ISO-2022-CN-EXT, ISO-2022-JP, ISO-2022-JP-1, ISO-2022-JP-2 และ ISO-2022-KR) โดยที่ ISO-2022-JP และ ISO-2022-KR เคยถูกนำมาใช้อย่างแพร่หลายในอดีต^{[ 110 ]} ผู้จำหน่าย ต่างๆ รวมถึง IBM ได้กำหนด รูปแบบอื่นๆ อีกหลายรูปแบบ^{[ 111 ]}แม้ว่า UTF-8 จะเป็นการเข้ารหัสที่นิยมใช้ในHTML5แต่เนื้อหาเดิมใน ISO-2022-JP ยังคงแพร่หลายมากพอที่ มาตรฐานการเข้ารหัส WHATWGยังคงรองรับอยู่^{[ 112 ]}ซึ่งแตกต่างจากการแมป ISO-2022-KR, ISO-2022-CN และ ISO-2022-CN-EXT ^{[ 113 ]} ไปยัง อักขระทดแทนทั้งหมด[ ^{114 ]}เนื่องจากความกังวลเกี่ยวกับ การโจมตี ด้วยการแทรกโค้ดเช่น การ ^{โจมตี}แบบ Cross-site scripting ^{[ 112 ] [ 114 ]}

เวอร์ชันโค้ด 8 บิตประกอบด้วยExtended Unix Code [ ^{11 ] [ 12 ] การ}เข้ารหัสISO/IEC 8859ยังเป็นไปตาม ISO 2022 ในส่วนย่อยที่กำหนดไว้ใน ISO/IEC 4873 ^{[ 9 ] [ 10 ]}

ISO-2022-JPเป็นการเข้ารหัสภาษาญี่ปุ่นที่ใช้กันอย่างแพร่หลาย โดยเฉพาะในอีเมลมีการนำมาใช้ในเครือข่าย JUNET และต่อมาได้ถูกกำหนดเป็นมาตรฐานในIETF RFC1468 ลงวันที่ 1993 ^{[ 115 ]}มีข้อดีเหนือกว่าการเข้ารหัสภาษาญี่ปุ่นตรงที่ไม่ต้องใช้ข้อมูลแบบ 8 บิตไมโครซอฟต์เรียกมันว่ารหัสหน้า 50220[ ^{116 ] เริ่ม}ต้นด้วย ASCII และรวมถึงลำดับการหลีกเลี่ยงต่อไปนี้:

• ESC ( Bเพื่อเปลี่ยนเป็น ASCII (1 ไบต์ต่ออักขระ)
• ESC ( Jเพื่อเปลี่ยนไปใช้ ชุดตัวอักษรโรมัน JIS X 0201-1976 (ISO/IEC 646:JP) (1 ไบต์ต่อตัวอักษร)
• ESC $ @เพื่อเปลี่ยนไปใช้มาตรฐานJIS X 0208-1978 (2 ไบต์ต่ออักขระ)
• ESC $ Bเพื่อเปลี่ยนไปใช้มาตรฐานJIS X 0208-1983 (2 ไบต์ต่ออักขระ)

อนุญาตให้ใช้อักขระสองตัวที่เพิ่มเข้ามาใน JIS X 0208-1990 ได้ แต่ไม่รวมลำดับ IRR กล่าวคือใช้ลำดับการหลีกเลี่ยงเดียวกันกับ JIS X 0208-1983 ^{[ 115 ]}นอกจากนี้ เนื่องจากมีการลงทะเบียนก่อนที่จะสามารถกำหนดชุดหลายไบต์ยกเว้น G0 ได้ การหลีกเลี่ยงสำหรับ JIS X 0208 จึงไม่รวมไบต์I(ตัว ที่สอง ^{[ 90 ]}

RFC ระบุว่าระบบที่มีอยู่บางระบบไม่ได้แยกความแตกต่างESC ( BจากESC ( Jหรือไม่ได้แยกความแตกต่างESC $ @จากESC $ Bแต่กำหนดว่าลำดับการหลีกเลี่ยงไม่ควรเปลี่ยนแปลงโดยระบบที่เพียงแค่ส่งต่อข้อความ เช่น อีเมล^{[ 115 ]}มาตรฐาน การเข้ารหัส WHATWGที่อ้างอิงโดยHTML5จัดการESC ( BและESC ( Jแยกความแตกต่าง แต่ถือว่าESC $ @เหมือนกันESC $ Bเมื่อถอดรหัส และใช้เฉพาะESC $ Bสำหรับ JIS X 0208 เมื่อเข้ารหัส^{[ 117 ]} RFC ยังระบุด้วยว่าระบบในอดีตบางระบบได้ใช้ลำดับอย่างผิดพลาดESC ( Hเพื่อเปลี่ยนจาก JIS X 0208 ซึ่งจริงๆ แล้วจดทะเบียนสำหรับISO-IR-11 (เวอร์ชันสวีเดนของISO 646และWorld System Teletext ) ^{[ 115 ] [ i ]}

การใช้เพื่อESC ( Iสลับไปใช้ ชุดคานะ JIS X 0201-1976 (1 ไบต์ต่ออักขระ) ไม่ได้เป็นส่วนหนึ่งของโปรไฟล์ ISO-2022-JP ^{[ 115 ]}แต่บางครั้งก็มีการใช้งานเช่นกันPythonอนุญาตให้ใช้ในรูปแบบที่เรียกว่าISO-2022-JP-EXT (ซึ่งรวมถึง JIS X 0212 ดังที่อธิบายไว้ด้านล่าง ทำให้ครอบคลุมEUC-JP อย่างสมบูรณ์ ) ^{[ 118 ] [ 119 ]}ซึ่งชื่อและโครงสร้างใกล้เคียงกับการเข้ารหัสที่DEC เรียกว่า ISO-2022-JPext ซึ่งยังเพิ่ม พื้นที่ที่ผู้ใช้กำหนดสองไบต์ที่เข้าถึงด้วยเพื่อให้ครอบคลุมSuper DEC Kanjiอย่าง สมบูรณ์ ^{[ 120 ]}รูปแบบ WHATWG/HTML5 อนุญาตให้ถอดรหัสคาตาคานะ JIS X 0201 ในอินพุต ISO-2022-JP แต่จะแปลงอักขระเป็นค่าเทียบเท่า JIS X 0208 เมื่อเข้ารหัส^{[ 117 ]}รหัสเพจของ Microsoft สำหรับ ISO-2022-JP ที่อนุญาตให้ใช้คานะ JIS X 0201 เพิ่มเติมคือรหัสเพจ 50221 ^{[ 116 ]}ESC $ ( 0

รูปแบบอื่นๆ ที่เก่ากว่าซึ่งรู้จักกันในชื่อJIS7 ​​และJIS8สร้างขึ้นโดยตรงจากการเข้ารหัส 7 บิตและ 8 บิตที่กำหนดโดยJIS X 0201และอนุญาตให้ใช้คานะ JIS X 0201 จาก G1 โดยไม่ต้องใช้ลำดับการหลีกเลี่ยง โดยใช้Shift Out และ Shift Inหรือการตั้งค่าบิตที่แปด (เรียกใช้โดย GR) ตามลำดับ^{[ 121 ]}ไม่ค่อยมีการใช้งานอย่างแพร่หลาย^{[ 121 ]}การสนับสนุน JIS X 0208 ใน JIS X 0201 8 บิตแบบขยายมักทำได้โดยใช้Shift JISหน้าโค้ดของ Microsoft สำหรับ ISO 2022 ที่ใช้ JIS X 0201 พร้อมคาตาคานะไบต์เดียวผ่าน Shift Out และ Shift In คือหน้าโค้ด 50222 ^{[ 116 ]}

ISO-2022-JP-2เป็นส่วนขยายหลายภาษาของ ISO-2022-JP ซึ่งกำหนดไว้ใน RFC 1554 (ลงวันที่ 1993) ซึ่งอนุญาตให้ใช้ลำดับการหลีกเลี่ยงต่อไปนี้ นอกเหนือจากลำดับของ ISO-2022-JP ส่วนของISO/IEC 8859เป็นชุดอักขระ 96 ตัว ซึ่งไม่สามารถกำหนดให้กับ G0 ได้ และสามารถเข้าถึงได้จาก G2 โดยใช้รูปแบบลำดับการหลีกเลี่ยง 7 บิตของรหัสการเลื่อนบิตเดี่ยว SS2: ^{[ 122 ]}

• ESC $ Aเพื่อเปลี่ยนไปใช้GB 2312-1980 (2 ไบต์ต่ออักขระ)
• ESC $ ( Cเพื่อเปลี่ยนไปใช้KS X 1001-1992 (2 ไบต์ต่ออักขระ)
• ESC $ ( Dเพื่อเปลี่ยนไปใช้มาตรฐานJIS X 0212-1990 (2 ไบต์ต่ออักขระ)
• ESC . Aเพื่อเปลี่ยนไปใช้ ส่วนบนของ ISO/IEC 8859-1ชุด Extended Latin 1 (1 ไบต์ต่ออักขระ) [กำหนดให้กับ G2]
• ESC . Fเพื่อเปลี่ยนไปใช้ISO/IEC 8859-7ส่วนบน ชุดภาษากรีกพื้นฐาน (1 ไบต์ต่ออักขระ) [กำหนดให้กับ G2]

ISO-2022-JP ที่มีการแสดง JIS X 0212 ในรูปแบบ ISO-2022-JP-2 แต่ไม่ใช่ส่วนขยายอื่นๆ ได้รับการขนานนามว่าISO-2022-JP-1โดย RFC 2237 ซึ่งลงวันที่ 1997 ^{[ 123 ]}

IBMใช้การเข้ารหัสแบบ ISO 2022 7 บิตจำนวน 9 แบบสำหรับภาษาญี่ปุ่น โดยแต่ละแบบใช้ชุดลำดับการหลีกเลี่ยงที่แตกต่างกัน ได้แก่ IBM-956, IBM-957, IBM-958, IBM-959, IBM-5052, IBM-5053, IBM-5054, IBM-5055 และ ISO-2022-JP ซึ่งเรียกรวมกันว่า "ชุดอักขระเข้ารหัสภาษาญี่ปุ่น TCP/IP" ^{[ 124 ]} CCSID 9148 คือมาตรฐาน (RFC 1468) ISO-2022-JP ^{[ 125 ]}

มาตรฐาน JIS X 0213ซึ่งตีพิมพ์ครั้งแรกในปี 2000 กำหนดเวอร์ชันที่ปรับปรุงใหม่ของ ISO-2022-JP โดยไม่มีส่วนขยายของ ISO-2022-JP-2 และตั้งชื่อว่าISO-2022-JP-3การเพิ่มเติมใน JIS X 0213 เมื่อเทียบกับมาตรฐานพื้นฐาน JIS X 0208 ส่งผลให้มีการลงทะเบียนใหม่สำหรับระนาบ JIS ที่ขยายออกไป 1 ในขณะที่ระนาบใหม่ 2 ได้รับการลงทะเบียนของตนเอง การเพิ่มเติมเพิ่มเติมในระนาบ 1 ในฉบับปี 2004 ของมาตรฐานส่งผลให้มีการเพิ่มการลงทะเบียนเพิ่มเติมในการแก้ไขเพิ่มเติมของโปรไฟล์ ซึ่งเรียกว่าISO-2022-JP- 2004 นอกเหนือจากรหัสการกำหนดพื้นฐานของ ISO-2022-JP แล้ว ยังมีการยอมรับการกำหนดต่อไปนี้:

• ESC ( Iเพื่อเปลี่ยนไปใช้ ชุดอักษรคะนะ JIS X 0201-1976 (1 ไบต์ต่อตัวอักษร)
• ESC $ ( Oเพื่อเปลี่ยนไปใช้มาตรฐานJIS X 0213-2000 Plane 1 (2 ไบต์ต่ออักขระ)
• ESC $ ( Pเพื่อเปลี่ยนไปใช้มาตรฐานJIS X 0213-2000 Plane 2 (2 ไบต์ต่ออักขระ)
• ESC $ ( Qเพื่อเปลี่ยนไปใช้JIS X 0213-2004 Plane 1 (2 ไบต์ต่ออักขระ, เฉพาะ ISO-2022-JP-2004)

ISO-2022-KRถูกกำหนดไว้ใน RFC 1557 ลงวันที่ 1993 ^{[ 134 ]}โดยเข้ารหัส ASCII และไบต์คู่ภาษาเกาหลีKS X 1001-1992[ ^{135 ] [ 136 ] ซึ่ง}ก่อนหน้านี้มีชื่อว่า KS C 5601-1987 แตกต่างจาก ISO-2022-JP-2 ตรงที่ใช้ตัวอักษร Shift Out และ Shift Inเพื่อสลับระหว่างกัน หลังจากรวมไว้ESC $ ) Cหนึ่งครั้งที่จุดเริ่มต้นของบรรทัดเพื่อกำหนด KS X 1001 ให้กับ G1 ^{[ 134 ]}

ISO-2022-CNและISO-2022-CN-EXTได้รับการกำหนดไว้ใน RFC 1922 ซึ่งลงวันที่ 1996 โดยเป็นการเข้ารหัส 7 บิตที่ใช้ทั้งฟังก์ชัน Shift Out และ Shift In (เพื่อเปลี่ยนระหว่าง G0 และ G1) และรูปแบบรหัสหลีกเลี่ยง 7 บิตของฟังก์ชันการเลื่อนเดี่ยว SS2 และ SS3 (เพื่อเข้าถึง G2 และ G3) ^{[ 137 ]}รองรับชุดอักขระGB 2312(สำหรับภาษาจีนตัวย่อ) และCNS 11643(สำหรับภาษาจีนตัวเต็ม)

โปรไฟล์ ISO-2022-CN พื้นฐานใช้ ASCII เป็นชุด G0 (shift in) และยังรวมถึง GB 2312 และระนาบสองระนาบแรกของ CNS 11643 (เนื่องจากระนาบทั้งสองนี้เพียงพอที่จะแสดงอักขระภาษาจีนดั้งเดิมทั้งหมดจากBig5 ทั่วไป ซึ่ง RFC ให้การเทียบเคียงไว้ในภาคผนวก): ^{[ 137 ]}

• ESC $ ) Aเพื่อเปลี่ยนไปใช้GB 2312-1980 (2 ไบต์ต่ออักขระ) [กำหนดให้เป็น G1]
• ESC $ ) Gเพื่อเปลี่ยนไปใช้CNS 11643-1992ระนาบ 1 (2 ไบต์ต่ออักขระ) [กำหนดให้กับ G1]
• ESC $ * Hเพื่อเปลี่ยนไปใช้ CNS 11643-1992 Plane 2 (2 ไบต์ต่ออักขระ) [กำหนดให้กับ G2]

โปรไฟล์ ISO-2022-CN-EXT อนุญาตให้ใช้ชุดและระนาบเพิ่มเติมดังต่อไปนี้^{[ 137 ]}

• ESC $ ) Eเพื่อเปลี่ยนไปใช้ISO-IR-165 (2 ไบต์ต่ออักขระ) [กำหนดให้กับ G1]
• ESC $ + Iเพื่อเปลี่ยนไปใช้ CNS 11643-1992 ระนาบ 3 (2 ไบต์ต่ออักขระ) [กำหนดให้กับ G3]
• ESC $ + Jเพื่อเปลี่ยนไปใช้ CNS 11643-1992 ระนาบ 4 (2 ไบต์ต่ออักขระ) [กำหนดให้กับ G3]
• ESC $ + Kเพื่อเปลี่ยนไปใช้ CNS 11643-1992 ระนาบ 5 (2 ไบต์ต่ออักขระ) [กำหนดให้กับ G3]
• ESC $ + Lเพื่อเปลี่ยนไปใช้ CNS 11643-1992 ระนาบ 6 (2 ไบต์ต่ออักขระ) [กำหนดให้กับ G3]
• ESC $ + Mเพื่อเปลี่ยนไปใช้ CNS 11643-1992 ระนาบ 7 (2 ไบต์ต่ออักขระ) [กำหนดให้กับ G3]

โปรไฟล์ ISO-2022-CN-EXT ยังระบุ ชุดกราฟิก มาตรฐาน Guobiao เพิ่มเติม ที่ได้รับอนุญาต แต่มีเงื่อนไขว่าต้องมีการกำหนดลำดับการหลีกเลี่ยง ISO 2022 ที่ลงทะเบียนไว้: ^{[ 137 ]}

• GB 12345ใน G1
• GB 7589 หรือ GB 13131 ใน G2
• GB 7590 หรือ GB 13132 ใน G3

อักขระหลังESC(สำหรับชุดอักขระแบบไบต์เดียว) หรือESC $(สำหรับชุดอักขระแบบหลายไบต์) จะระบุประเภทของชุดอักขระและชุดการทำงานที่กำหนดไว้ ในตัวอย่างข้างต้น อักขระ((0x28) กำหนดชุดอักขระ 94 ตัวให้กับชุดอักขระ G0 ในขณะที่)หรือ*( +0x29–0x2B) กำหนดให้กับชุดอักขระ G1–G3

ISO-2022-KR และ ISO-2022-CN ถูกใช้งานน้อยกว่า ISO-2022-JP และบางครั้งก็จงใจไม่รองรับเนื่องจากข้อกังวลด้านความปลอดภัย ที่น่าสังเกตคือ มาตรฐานการเข้ารหัส WHATWGที่ใช้โดยHTML5จะแมป ISO-2022-KR, ISO-2022-CN และ ISO-2022-CN-EXT (รวมถึงHZ-GB-2312 ) ไปยังตัวถอดรหัส "ทดแทน" ^{[ 113 ]}ซึ่งแมปอินพุตทั้งหมดไปยังอักขระทดแทน (�) เพื่อป้องกัน การโจมตี แบบ cross-site scriptingและการโจมตีที่เกี่ยวข้องบางประเภท ซึ่งใช้ความแตกต่างในการรองรับการเข้ารหัสระหว่างไคลเอนต์และเซิร์ฟเวอร์^{[ 114 ]}แม้ว่าข้อกังวลด้านความปลอดภัยเดียวกัน (การอนุญาตให้ลำดับของไบต์ ASCII ถูกตีความแตกต่างกัน) จะใช้กับ ISO-2022-JP และUTF-16 ด้วย แต่ก็ไม่สามารถได้รับการปฏิบัติเช่นนี้ได้เนื่องจากมีการใช้งานบ่อยกว่ามากในเนื้อหาที่เผยแพร่^{[ 112 ]}

ในเดือนเมษายน พ.ศ. 2567 พบช่องโหว่ด้านความปลอดภัย^{[ 138 ]} ในการใช้งาน ISO-2022-CN-EXT ใน glibcซึ่งนำไปสู่คำแนะนำให้ปิดใช้งานการเข้ารหัสโดยสิ้นเชิงบนระบบ Linux ^{[ 139 ]}

ชุดย่อยของ ISO 2022 ที่ใช้กับการเข้ารหัสไบต์เดียว 8 บิตถูกกำหนดโดยISO/IEC 4873ซึ่งเผยแพร่โดยEcma Internationalในชื่อ ECMA-43 เช่นกันISO/IEC 8859กำหนดรหัส 8 บิตสำหรับ ISO/IEC 4873 (หรือ ECMA-43) ระดับ 1 ^{[ 9 ] [ 10 ]}

ISO/IEC 4873 / ECMA-43 กำหนดระดับการเข้ารหัสไว้ 3 ระดับ: ^{[ 140 ]}

• ระดับ 1 ประกอบด้วยชุด C0, ชุด ASCII G0, ชุด C1 ที่เป็นตัวเลือก และชุด G1 แบบไบต์เดียว (94 หรือ 96 ตัวอักษร) ที่เป็นตัวเลือก G0 ถูกเรียกใช้ผ่าน GL และ G1 ถูกเรียกใช้ผ่าน GR ไม่อนุญาตให้ใช้ฟังก์ชันการเลื่อนบิต
• ระดับ 2 ซึ่งรวมถึงชุด G2 และ/หรือ G3 แบบไบต์เดียว (94 ตัวอักษรหรือ 96 ตัวอักษร) นอกเหนือจากชุด G1 ที่จำเป็น อนุญาตเฉพาะฟังก์ชันการเลื่อนแบบไบต์เดียว SS2 และ SS3 เท่านั้น (เช่น ห้ามการเลื่อนแบบล็อก) และเรียกใช้ผ่านภูมิภาค GL (รวมถึง0x20และ 0x7F ในกรณีของชุด 96 ตัวอักษร) SS2 และ SS3 ต้องมีอยู่ใน C1 ที่ 0x8E และ 0x8F ตามลำดับ ชุด C1 ขั้นต่ำที่จำเป็นสำหรับ ISO 4873 นี้ได้รับการจดทะเบียนเป็น ISO-IR-105 ^{[ 70 ]}
• ระดับ 3 อนุญาตให้ใช้ฟังก์ชันล็อกชิฟต์ GR LS1R, LS2R และ LS3R นอกเหนือจากการเปลี่ยนเกียร์แบบเดี่ยว แต่มีข้อจำกัดอื่นๆ เหมือนกับระดับ 2

มาตรฐานฉบับก่อนหน้าอนุญาตให้กำหนดค่าที่ไม่ใช่ ASCII ในชุด G0 ได้ โดยมีเงื่อนไขว่าต้องรักษาตำแหน่งคงที่ของ ISO/IEC 646 ไว้ และกำหนดตำแหน่งอื่นๆ ให้กับอักขระเว้นวรรค (ไม่ใช่อักขระรวม) กำหนด 0x23 ให้กับ£ หรือ#และกำหนด 0x24 ให้กับ$หรือ¤ ^{[ 141 ]}ตัวอย่างเช่น การเข้ารหัส 8 บิตของJIS X 0201เป็นไปตามมาตรฐานฉบับก่อนหน้า ต่อมาได้มีการเปลี่ยนแปลงเพื่อระบุชุด ISO/IEC 646:1991 IRV / ISO-IR No. 6 (ASCII) อย่างครบถ้วน^{[ 142 ] [ 143 ] [ 144 ]}

การใช้ISO/IEC 646 IRV (ซิงโครไนซ์กับ ASCII ตั้งแต่ปี 1991) ที่ ISO/IEC 4873 ระดับ 1 โดยไม่มีการตั้งค่า C1 หรือ G1 กล่าวคือ การใช้ IRV ในสภาพแวดล้อม 8 บิตซึ่งไม่ได้ใช้รหัสเลื่อน และบิตสูงสุดเป็นศูนย์เสมอ เรียกว่าISO 4873 DVซึ่ง DV ย่อมาจาก "Default Version" ^{[ 145 ]}

ในกรณีที่อักขระซ้ำกันมีอยู่ในเซตที่แตกต่างกัน ISO/IEC 4873 / ECMA-43 ฉบับปัจจุบันอนุญาตให้ใช้อักขระเหล่านี้เฉพาะในเซตการทำงานที่มีหมายเลขต่ำที่สุดที่ปรากฏอยู่เท่านั้น^{[ 146 ]}ตัวอย่างเช่น หากอักขระปรากฏอยู่ในทั้งเซต G1 และเซต G3 จะต้องใช้อักขระจากเซต G1 อย่างไรก็ตาม มีการระบุว่าอนุญาตให้ใช้จากเซตอื่นได้ในฉบับก่อนหน้า^{[ 144 ]}

ISO/IEC 8859กำหนดการเข้ารหัสที่สมบูรณ์ในระดับ 1 ของ ISO/IEC 4873 และไม่อนุญาตให้ใช้ส่วนต่างๆ ของ ISO/IEC 8859 หลายส่วนร่วมกัน โดยระบุว่าควรใช้ISO/IEC 10367 แทนสำหรับระดับ 2 และ 3 ของ ISO/IEC 4873 ^{[ 9 ] [ 10 ]} ISO/IEC 10367:1991 ประกอบด้วยชุด G0 และ G1 ที่ตรงกับชุดที่ใช้โดย 9 ส่วนแรกของ ISO/IEC 8859 (เช่น ชุดที่มีอยู่ ณ ปี 1991 เมื่อมีการเผยแพร่) และชุดเสริมบางชุด^{[ 147 ]}

ลำดับการหลีกเลี่ยงชุดอักขระจะใช้สำหรับการระบุหรือสลับระหว่างเวอร์ชันระหว่างการแลกเปลี่ยนข้อมูลเฉพาะเมื่อจำเป็นตามโปรโตคอลเพิ่มเติม ซึ่งในกรณีนี้มาตรฐานจะกำหนดลำดับผู้ประกาศ ISO/IEC 2022 ที่ระบุระดับ ISO/IEC 4873 ตามด้วยชุดการหลีกเลี่ยงที่สมบูรณ์ซึ่งระบุการกำหนดชุดอักขระสำหรับ C0, C1, G0, G1, G2 และ G3 ตามลำดับ (แต่ละเว้นการกำหนด G2 และ G3 สำหรับระดับ 1) โดย ไบต์ Fของ 0x7E หมายถึงชุดว่าง แต่ละระดับ ISO/IEC 4873 มีลำดับผู้ประกาศ ISO/IEC 2022 เดียวของตนเอง ซึ่งมีดังต่อไปนี้: ^{[ 148 ]}

Extended Unix Code (EUC) เป็นระบบ การเข้ารหัสอักขระแบบความกว้างแปรผัน 8 บิตซึ่งใช้เป็นหลักสำหรับภาษาญี่ปุ่นเกาหลีและจีนตัวย่อโดยอิงตามมาตรฐาน ISO 2022 และเฉพาะชุดอักขระที่สอดคล้องกับโครงสร้าง ISO 2022 เท่านั้นที่จะมีรูปแบบ EUC ได้ สามารถแสดงชุดอักขระที่เข้ารหัสได้สูงสุดสี่ชุด (ใน G0, G1, G2 และ G3) ชุด G0 จะถูกเรียกใช้ผ่าน GL ชุด G1 จะถูกเรียกใช้ผ่าน GR และชุด G2 และ G3 (ถ้ามี) จะถูกเรียกใช้โดยใช้การเลื่อนเดี่ยว SS2 และ SS3 ซึ่งใช้เป็นไบต์ CR (เช่น 0x8E และ 0x8F ตามลำดับ) และเรียกใช้ผ่าน GR (ไม่ใช่ GL) ^{[ 11 ]}ไม่มีการใช้รหัสการเลื่อนแบบล็อก^{[ 12 ]}

รหัสที่กำหนดให้กับชุด G0 คือ ASCII หรือชุดอักขระ ISO 646ของประเทศเช่น KS-Roman (KS X 1003) หรือJIS-Roman (ครึ่งล่างของJIS X 0201 ) ^{[ 11 ]}ดังนั้น 0x5C ( เครื่องหมายทับใน US-ASCII) จึงถูกใช้เพื่อแสดงสัญลักษณ์เยนใน EUC-JP บางเวอร์ชัน และสัญลักษณ์วอนใน EUC-KR บางเวอร์ชัน

G1 ใช้สำหรับชุดอักขระที่เข้ารหัสขนาด 94x94 ซึ่งแสดงด้วยสองไบต์ตัวอย่างของรหัส EUC สองไบต์ดังกล่าว ได้แก่รูปแบบEUC-CN ของ GB 2312และEUC-KR EUC-JPประกอบด้วยอักขระที่แสดงด้วยไบต์สูงสุดสามไบต์ (เช่น SS3 บวกสองไบต์) ในขณะที่อักขระเดียวในEUC-TWสามารถใช้ไบต์ได้สูงสุดสี่ไบต์ (เช่น SS2 บวกสามไบต์)

รหัส EUC เองไม่ได้ใช้ลำดับผู้ประกาศหรือการกำหนดจาก ISO 2022 อย่างไรก็ตาม มันสอดคล้องกับลำดับผู้ประกาศสี่ลำดับต่อไปนี้ โดยมีความหมายแยกย่อยดังนี้^{[ 149 ]}

X Consortiumได้กำหนดโปรไฟล์ ISO 2022 ที่ชื่อว่า Compound Text เป็นรูปแบบการแลกเปลี่ยนข้อมูลในปี 1989 ^{[ 150 ]}ซึ่งใช้รหัสควบคุมเพียงสี่รหัส ได้แก่HT ( ), NL (ขึ้นบรรทัดใหม่, เข้ารหัสเป็นLF , ) , ESC ( )และCSI (ในรูปแบบ 8 บิต) ^{[ 151 ]} โดย ใช้ลำดับ CSI SDS ( ) สำหรับการควบคุมข้อความแบบสองทิศทาง ^{[ 152 ]}เป็นรหัส 8 บิตที่ใช้ G0 และ G1 สำหรับ GL และ GR และเป็นไปตามISO-8859-1ในสถานะเริ่มต้น^{[ 153 ]}มีการใช้ไบต์ F ต่อไปนี้: 0x090x0A0x1B0x9BCSI … ]

สำหรับการระบุการเข้ารหัสโดยใช้ป้ายกำกับ X11 Compound Text กำหนดลำดับ DOCS สำหรับการใช้งานส่วนตัวห้าลำดับ: ESC % / 0( 1B 25 2F 30) สำหรับการเข้ารหัสความยาวแปรผัน และESC % / 1สำหรับESC % / 4การเข้ารหัสความยาวคงที่โดยใช้ไบต์หนึ่งถึงสี่ไบต์ตามลำดับ แทนที่จะใช้ลำดับการหลีกเลี่ยงอื่นเพื่อกลับไปยังISO 2022ไบต์สองไบต์ที่ตามหลังลำดับการหลีกเลี่ยงเริ่มต้นจะระบุความยาวที่เหลือเป็นไบต์ ซึ่งเข้ารหัสในฐาน 128 โดยใช้ไบต์0x80–FFป้ายกำกับการเข้ารหัสจะรวมอยู่ในISO 8859-1ก่อนข้อความที่เข้ารหัส และสิ้นสุดด้วยSTX ( ) ^{[ 109 ]}0x02

• เนื่องจากการเข้ารหัสอักขระแบบกราฟิกทั้งหมดของ ISO/IEC 2022 สามารถใช้งานได้ผ่าน GL ดังนั้นจำนวนอักขระที่ใช้งานได้จึงไม่ถูกจำกัดอย่างมีนัยสำคัญจากการที่ไม่สามารถแสดง GR และ C1 ได้ เช่นเดียวกับในระบบที่จำกัดอยู่ที่การเข้ารหัส 7 บิต ดังนั้นจึงช่วยให้สามารถแสดงอักขระจำนวนมากในระบบดังกล่าวได้ โดยทั่วไปแล้ว ความเข้ากันได้กับ 7 บิตนี้ไม่ได้เป็นข้อได้เปรียบมากนัก ยกเว้นความเข้ากันได้กับระบบรุ่นเก่า คอมพิวเตอร์สมัยใหม่ส่วนใหญ่ใช้ 8 บิตสำหรับแต่ละไบต์
• เมื่อเปรียบเทียบกับ Unicode แล้ว ISO/IEC 2022 หลีกเลี่ยงการรวมอักษรฮั่นโดยใช้รหัสลำดับเพื่อสลับระหว่างการเข้ารหัสที่แตกต่างกันสำหรับภาษาเอเชียตะวันออกต่างๆ ซึ่งจะช่วยหลีกเลี่ยงปัญหาที่เกี่ยวข้องกับการรวมอักษร เช่น ความยากลำบากในการรองรับ ภาษา จีน ญี่ปุ่น และเกาหลี (CJK) หลาย ภาษาพร้อมตัวอักษรที่แตกต่างกันในเอกสารและแบบอักษรเดียวกัน

• เนื่องจาก ISO/IEC 2022 เป็นการเข้ารหัสแบบมีสถานะ (stateful encoding) โปรแกรมจึงไม่สามารถกระโดดเข้าไปกลางบล็อกข้อความเพื่อค้นหา แทรก หรือลบอักขระได้ ทำให้การจัดการข้อความยุ่งยากและช้ากว่าเมื่อเทียบกับการเข้ารหัสแบบไม่มีสถานะ (non-stateful encoding) การกระโดดใดๆ กลางข้อความอาจต้องมีการสำรองลำดับการหลีกเลี่ยง (escape sequence) ก่อนหน้าไว้ก่อน จึงจะสามารถตีความไบต์ที่ตามหลังลำดับการหลีกเลี่ยงนั้นได้
• เนื่องจากลักษณะที่มีสถานะของ ISO/IEC 2022 อักขระที่เหมือนกันและเทียบเท่ากันอาจถูกเข้ารหัสในชุดอักขระที่แตกต่างกัน ซึ่งอาจกำหนดให้กับ G0 ถึง G3 ซึ่งสามารถเรียกใช้ได้โดยใช้การเลื่อนบิตเดี่ยวหรือโดยการเลื่อนบิตแบบล็อกไปยัง GL หรือ GR ดังนั้น อักขระจึงสามารถแสดงได้หลายวิธี หมายความว่าสตริงสองสตริงที่เหมือนกันและเทียบเท่ากันทางสายตาไม่สามารถเปรียบเทียบความเท่าเทียมกันได้อย่างน่าเชื่อถือ
• ระบบบางระบบ เช่นDICOMและไคลเอนต์อีเมลหลายตัว ใช้ ISO-2022 เวอร์ชันหนึ่ง (เช่น "ISO 2022 IR 100" ^{[ 155 ]} ) นอกเหนือจากการรองรับการเข้ารหัสอื่นๆ อีกหลายแบบ^{[ 156 ]}การเปลี่ยนแปลงประเภทนี้ทำให้การถ่ายโอนข้อความระหว่างระบบคอมพิวเตอร์ทำได้ยาก
• UTF-1 ซึ่งเป็นรูปแบบการแปลง Unicodeแบบหลายไบต์ที่เข้ากันได้กับการแสดงอักขระควบคุม 8 บิตของ ISO/IEC 2022 มีข้อเสียหลายประการเมื่อเทียบกับUTF-8และโดยทั่วไปแล้ว การสลับไปมาระหว่างชุดอักขระต่างๆ ที่ ISO/IEC 2022 รองรับนั้นไม่จำเป็นในเอกสาร Unicode
• เนื่องจากลำดับการหลีกเลี่ยง ทำให้สามารถสร้างลำดับไบต์โจมตีซึ่งสตริงที่เป็นอันตราย (เช่นสคริปต์ข้ามไซต์ ) จะถูกปิดบังไว้จนกว่าจะถูกถอดรหัสเป็น Unicode ซึ่งอาจทำให้สามารถหลีกเลี่ยงการกรองได้^{[ 157 ]}การใช้การเข้ารหัสนี้จึงถูกมองว่าน่าสงสัยโดยชุดโปรแกรมป้องกันมัลแวร์^{[ 158 ]}และข้อมูล ISO 2022 7 บิต (ยกเว้น ISO-2022-JP) จะถูกแมปทั้งหมดไปยังอักขระทดแทนในHTML5เพื่อป้องกันการโจมตี^{[ 113 ] [ 114 ]}เวอร์ชันรหัส ISO 2022 8 บิตแบบจำกัดซึ่งไม่ใช้การหลีกเลี่ยงการกำหนดหรือรหัสเลื่อนล็อก เช่นExtended Unix Codeจะไม่มีปัญหาดังกล่าว
• การต่อกันอาจก่อให้เกิดปัญหาได้ โปรไฟล์เช่น ISO-2022-JP ระบุว่าสตรีมเริ่มต้นในสถานะ ASCII และต้องสิ้นสุดในสถานะ ASCII ^{[ 115 ]}นี่เป็นสิ่งจำเป็นเพื่อให้แน่ใจว่าอักขระในสตรีม ISO-2022-JP และ/หรือ ASCII ที่ต่อกันจะถูกตีความในชุดที่ถูกต้อง ซึ่งมีผลทำให้หากสตรีมที่สิ้นสุดด้วยอักขระหลายไบต์ถูกต่อกับสตรีมที่เริ่มต้นด้วยอักขระหลายไบต์ จะมีการสร้างรหัสหลีกเลี่ยงคู่หนึ่งที่เปลี่ยนไปเป็น ASCII และออกจาก ASCII ทันที อย่างไรก็ตาม ตามที่ระบุไว้ในรายงานทางเทคนิคของ Unicode #36 ("ข้อควรพิจารณาด้านความปลอดภัยของ Unicode") คู่ของลำดับหลีกเลี่ยง ISO 2022 ที่ไม่มีอักขระอยู่ระหว่างกันควรสร้างอักขระทดแทน ("�") เพื่อป้องกันไม่ให้ถูกนำไปใช้เพื่อปกปิดลำดับที่เป็นอันตราย เช่นการโจมตีแบบ Cross-site scripting ^{[ 159 ]}การนำมาตรการนี้ไปใช้ เช่น ในMozilla Thunderbirdส่งผลให้เกิดปัญหาการทำงานร่วมกัน โดยมีการสร้างอักขระ "�" ที่ไม่คาดคิดขึ้นเมื่อมีการรวมสตรีม ISO-2022-JP สองสตรีมเข้าด้วยกัน^{[ 157 ]}

• ไอโอเอส 2709
• ไอโซ/อีอีซี 646
• ไอโซ-เออร์-102
• รหัสควบคุม C0 และ C1
• ตัวอักษร CJK
• มาตรฐาน MARC
• โมจิเบค
• ลูอิท
• ISO/IEC JTC 1/SC 2

• ลุนเด, เคน (1998). การประมวลผลข้อมูล CJKV . เคมบริดจ์, แมสซาชูเซตส์: โอไรลีย์ แอนด์ แอสโซซิเอทส์ . ISBN 1-56592-224-7.

• ISO/IEC 2022:1994
• ISO/IEC 2022:1994/Cor 1:1999
• ECMA-35เทียบเท่ากับ ISO/IEC 2022 และสามารถดาวน์โหลดได้ฟรี
• ทะเบียนชุดอักขระรหัสสากลที่ใช้ร่วมกับลำดับการหลีกเลี่ยง (International Register of Coded Character Sets to be Used with Escape Sequences)รายการชุดอักขระที่กำหนดไว้ทั้งหมดและลำดับการหลีกเลี่ยงของแต่ละชุด
• ประวัติความเป็นมาของรหัสตัวอักษรในอเมริกาเหนือ ยุโรป และเอเชียตะวันออก ตั้งแต่ปี 1999 ฉบับปรับปรุงปี 2004
• เอกสาร CJK.INF ของKen Lunde ที่เก็บถาวรเมื่อวันที่ 15 พฤษภาคม 2021 บนWayback Machine : เอกสารเกี่ยวกับการเข้ารหัสภาษาจีน ญี่ปุ่น และเกาหลี (CJK) รวมถึงการอภิปรายเกี่ยวกับมาตรฐาน ISO/IEC 2022 ในรูปแบบต่างๆ