ISO/IEC 2022

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 역사
3. 코드 구조
- 3.1. 제어 기능
- 3.2. 문자 집합의 지정
4. 응용
5. 한계
참조

1. 개요

ISO/IEC 2022는 다양한 언어의 문자를 단일 문자 인코딩 시스템에서 사용할 수 있도록 개발된 문자 인코딩 표준이다. 여러 부호화 문자 집합을 하나의 시스템으로 통합하기 위해 설계되었으며, 7비트 및 8비트 환경 모두에서 사용될 수 있다. ISO/IEC 646을 기반으로 하며, 이스케이프 시퀀스를 사용하여 문자 집합을 지정하고 호출하는 방식을 사용한다. ISO-2022-JP, EUC-JP, EUC-KR 등 다양한 인코딩 방식의 기반이 되었으며, 7비트 환경에서는 일본어 전자 메일에, 8비트 환경에서는 확장 유닉스 코드(EUC) 등에 활용되었다. 그러나 상태 기반 인코딩 방식의 한계로 인해 텍스트 조작의 어려움, 문자열 비교의 문제, 보안 취약성 등의 단점이 존재한다.

더 읽어볼만한 페이지

문자 집합 - 점자
점자는 루이 브라이유가 개발한 시각 장애인용 촉각 문자 체계로, 6점 점자를 사용하여 133개 이상의 언어에 적용되었으며, 교육, 정보 접근, 사회 참여에 필수적인 역할을 수행하지만 문해력 저하와 교육의 어려움이라는 과제도 안고 있다.
문자 집합 - ISO/IEC 646
ISO/IEC 646는 ASCII 기반의 7비트 문자 인코딩 표준으로, 국가별 변형이 존재했으나, 최종 개정판은 ASCII와 호환되도록 정의되었고, 현재는 ITU-T 권고 T.50 IRA가 현행 표준으로 유지되고 있다.
Ecma 표준 - ISO/IEC 646
ISO/IEC 646는 ASCII 기반의 7비트 문자 인코딩 표준으로, 국가별 변형이 존재했으나, 최종 개정판은 ASCII와 호환되도록 정의되었고, 현재는 ITU-T 권고 T.50 IRA가 현행 표준으로 유지되고 있다.
Ecma 표준 - 유니버설 미디어 디스크
유니버설 미디어 디스크(UMD)는 소니 PSP에 사용된 60mm 광 디스크로, 게임, 영상, 음악 콘텐츠를 최대 1.8GB까지 저장하며, DVD와 유사한 지역 코드와 AES 128 비트 암호화를 사용했지만, PSP 외 다른 기기에서 사용 불가 및 디지털 미디어의 발달로 인해 2010년대 초반에 지원이 중단되었다.
IEC 표준 - ISO/IEC 646
ISO/IEC 646는 ASCII 기반의 7비트 문자 인코딩 표준으로, 국가별 변형이 존재했으나, 최종 개정판은 ASCII와 호환되도록 정의되었고, 현재는 ITU-T 권고 T.50 IRA가 현행 표준으로 유지되고 있다.
IEC 표준 - POSIX
POSIX는 유닉스 기반의 이식 가능한 운영체제 인터페이스를 표준화하기 위한 IEEE 표준군으로, 프로세스 관리, 파일 시스템 접근, 스레드 처리 등 핵심 서비스들을 규정하며 운영체제 간 호환성을 높이는 데 기여한다.

ISO/IEC 2022
개요
이름	ISO 2022
MIME	해당 없음
다른 이름	해당 없음
표준	ISO/IEC 2022 ECMA-35 ANSI X3.41 JIS X 0202 GB/T 2311
언어	다양함
확장	해당 없음
인코딩	US-ASCII 및 구현체에 따라 다름: GB 2312 JIS X 0201 JIS X 0208 JIS X 0212 JIS X 0213 KS X 1001 CNS 11643 ISO/IEC 646 ISO/IEC 8859 / 10367 기타
상태	해당 없음
이전	해당 없음
다음	ISO/IEC 10646 (유니코드)
분류	스테이트풀 시스템의 인코딩 (스테이트리스 사전 구성 하위 집합 포함)
관련	스테이트풀 하위 집합: ISO-2022-JP ISO-2022-CN ISO-2022-KR Compound Text 사전 구성 버전: ISO/IEC 4873 EUC

2. 역사

컴퓨터를 이용해 문자 정보를 처리하기 시작하면서, 다양한 언어를 표현하기 위해 수많은 부호화 문자 집합이 만들어졌다. 그러나 이러한 문자 집합이 여러 개 존재하면서 정보 교환에 어려움이 발생했다. 특히, 서로 다른 문자 집합을 사용하는 경우 사전에 합의가 필요했고, 정보 교환 중에 여러 문자 집합을 사용하는 것도 쉽지 않았다.

ISO/IEC 2022는 이러한 문제를 해결하기 위해 개발되었다. 즉, 여러 문자 집합을 단일 문자 인코딩 시스템에서 사용할 수 있도록 하는 기술이다.

ASCII는 7비트 라틴 알파벳 문자 집합으로, 최대 94개의 그래픽 문자(공백 문자 제외)만을 표현할 수 있었다. ISO/IEC 646(1967년 초판)^[160]은 그래픽 문자 표현 영역을 ASCII와 동일하게 유지하면서, 12개의 부호 위치를 각 국가에서 자유롭게 사용할 수 있도록 허용하고, 국가별 문자 집합을 정의하는 방식을 채택했다.

ISO/IEC 2022 (1973년 초판)^[161]는 ISO/IEC 646에 기반한 여러 부호표를 전환하여 다양한 언어를 처리할 수 있도록 제정되었다. 그러나 ISO/IEC 646 방식으로는 라틴 알파벳 범위 내에서도 다양한 분음 부호가 붙은 문자나 언어별로 필요한 기호 등을 충분히 표현할 수 없었다.

이러한 문제를 해결하기 위해 ISO/IEC 646과 호환성을 유지하면서 8비트 부호화를 지원하는 ISO/IEC 4873 (1979년 초판)^[162]이 제정되었다. 특히 유럽에서는 1980년대에 들어 다국어 텍스트 데이터를 공통된 방식으로 처리하려는 요구가 높아졌고,^[163] 1987년부터 ISO/IEC 4873에 대응하는 ISO/IEC 8859 시리즈가 제정되기 시작했다. ISO/IEC 8859 시리즈는 96개의 그래픽 문자를 추가로 표현할 수 있게 했고, 언어별 문자 집합을 정의하는 방식을 채택했다.

그리스어, 러시아어, 아랍어, 히브리어와 같이 라틴 알파벳에 기반하지 않은 언어들은 역사적으로 ISO/IEC 4873에 준거한 "확장 ASCII"를 이용하여 컴퓨터에서 표현되었다. (일부는 후에 ISO/IEC 8859 시리즈에도 규정되었으며, 많은 국가 및 지역의 부호화 문자 집합 규격이 ISO/IEC 4873에 준거하고 있다).

동아시아 언어, 특히 중국어, 일본어, 한국어는 8비트의 1바이트로 표현 가능한 범위를 훨씬 넘어서는 수의 문자를 사용하며, 초기에는 언어별 2바이트 문자 집합으로 컴퓨터에서 표현되었다. ISO/IEC 2022는 이러한 다양한 문자 집합을 단일 부호화 방식에서 처리할 수 있도록 지원한다.

ISO/IEC 2022에 기반한 부호화 표현은 현재도 널리 사용되고 있다. 예를 들어 일본어 전자 메일용 ISO-2022-JP, UNIX 환경에서 사용되는 EUC-JP, 중국의 GB 2312인 EUC-CN, 한국의 EUC-KR 등이 있다. ISO/IEC 8859 시리즈도 ISO/IEC 2022의 구조를 따른다. 한편, 이 규격에 따르지 않는 부호화 방식 (예: Shift_JIS, 대만의 Big5)도 널리 사용되고 있다.

제2차 규격 이후의 주요 개정 사항은 다음과 같다.

제2차 규격
8비트 부호에 대응.
버퍼 G2 및 G3 신설.
멀티바이트 문자 집합에 대응.
제3차 규격
96문자 집합 및 96ⁿ 문자 집합에 대응.
(JIS만 해당) JIS X 0201을 확장하는 규격에서 ISO/IEC 646을 확장하는 규격으로 변경되어 국제 일치 규격이 됨.
제4차 규격
7비트 부호 중심 기술에서 8비트 부호 중심 기술로 변경.

각 판별 규격 번호, 제정일 등은 아래 표와 같다.

ISO/IEC 2022 각 판별 규격 번호·제정일 등
판	ISO 규격 번호	ISO 제정·개정일	JIS 번호	JIS 제정·개정일
제1차 규격	ISO 2022:1973	1973년 5월 제정	JIS C 6228:1975	1975년 3월 1일 제정
제2차 규격	ISO 2022:1982	1982년 12월 개정	JIS C 6228:1984	1984년 11월 1일 개정
제3차 규격	ISO 2022:1986	1986년 5월 개정	JIS X 0202:1991	1991년 1월 1일 개정
제4차 규격	ISO/IEC 2022:1994	1994년 12월 개정	JIS X 0202:1998	1998년 1월 20일 개정

1987년 3월 1일 부문 X(정보 처리) 신설에 따라 JIS C 6228:1984는 JIS X 0202:1984로 개칭되었다.

3. 코드 구조

ISO/IEC 2022는 제어 문자 영역(C0, C1)과 그래픽 문자 영역(GL, GR)으로 구성된 부호표를 사용한다. 7비트 부호화에서는 C0 및 GL 영역을 사용하고, 8비트 부호화에서는 C0, C1, GL, GR 영역을 모두 사용한다.^[4]

7비트 부호는 32개의 제어 문자 기본 집합(C0)과 94개 또는 96개의 도형 문자 집합(GL)을 가지며, 8비트 부호는 추가로 32개의 제어 문자 보조 집합(C1)과 94개 또는 96개의 도형 문자 집합(GR)을 갖는다.

부호표상의 문자 위치는 행과 열로 나타낸다. 예를 들어 ASCII의 "Z"는 05/10에 해당하며, 16진수로는 5A이다.

복수 바이트 문자 집합에서는 여러 바이트로 하나의 문자를 부호화한다. 예를 들어 94ⁿ 문자 집합에서는 2바이트로 8836개(94x94), 3바이트로 830584개(94x94x94)의 문자를 표현할 수 있다. 2바이트 문자 집합에서 각 문자의 부호 위치는 구점(3바이트는 면구점)으로 지정된다. 예를 들어, JIS X 0208의 "字"는 27구 90점이므로, GL 영역에서는 03/11 07/10, GR 영역에서는 11/11 15/10으로 표현된다.

제어 기능과 문자 집합의 지정은 하위 섹션에서 자세히 다룬다.

3. 1. 제어 기능

ISO/IEC 2022는 문자 집합의 지정 및 호출, 코드 구조 알림 등 다양한 제어 기능을 제공한다. 제어 기능은 7비트 환경에서는 이스케이프 시퀀스(ESC 문자로 시작)를 사용하고, 8비트 환경에서는 C1 제어 문자를 사용할 수 있다.^[164]

7비트 환경에서 C0 제어 문자 외에 ESCAPE 제어 문자(01/11, 16진수로 1B, 10진수로 27)로 시작하는 2~4바이트의 이스케이프 시퀀스를 사용한다. 8비트 환경에서는 C1 제어 문자도 사용한다.

ISO/IEC 2022의 제어 기능은 데이터의 올바른 해석을 위해 마지막으로 나타난 제어 기능에 의존하므로, 데이터를 처음부터 순서대로 처리해야 한다.

코드	16진수	약어	이름	효과^[48]
ESC `	`1B 60`	DMI	수동 입력 비활성화	장치의 수동 입력 기능을 일부 또는 전부 비활성화한다.
`ESC a`	`1B 61`	INT	인터럽트	현재 프로세스를 인터럽트한다.
`ESC b`	`1B 62`	EMI	수동 입력 활성화	장치의 수동 입력 기능을 활성화한다.
`ESC c`	`1B 63`	RIS	초기 상태로 재설정	장치를 전원 켜기 후의 상태로 재설정한다.^[51]
`ESC d`	`1B 64`	CMD	코딩 방식 구분 기호	외부 코딩/표현 시스템과 상호 작용할 때 사용한다. 자세한 내용은 아래 참조.
`ESC n`	`1B 6E`	LS2	잠금 시프트 2	시프트 기능, 자세한 내용은 아래 참조.
`ESC o`	`1B 6F`	LS3	잠금 시프트 3	시프트 기능, 자세한 내용은 아래 참조.
`ESC \|`	`1B 7C`	LS3R	잠금 시프트 3 오른쪽	시프트 기능, 자세한 내용은 아래 참조.
`ESC }`	`1B 7D`	LS2R	잠금 시프트 2 오른쪽	시프트 기능, 자세한 내용은 아래 참조.
`ESC ~`	`1B 7E`	LS1R	잠금 시프트 1 오른쪽	시프트 기능, 자세한 내용은 아래 참조.

코드	16진수	약자	이름	효과
`SI`	`0F`	SI LS0	Shift In 고정 시프트 0	GL은 이제부터 G0을 인코딩한다.^[64]^[65]
`SO`	`0E`	SO LS1	Shift Out 고정 시프트 1	GL은 이제부터 G1을 인코딩한다.^[64]^[65]
`ESC n`	`1B 6E`	LS2	고정 시프트 2	GL은 이제부터 G2를 인코딩한다.^[64]^[65]
`ESC o`	`1B 6F`	LS3	고정 시프트 3	GL은 이제부터 G3를 인코딩한다.^[64]^[65]
CR 영역: `SS2` 이스케이프 코드: `ESC N`	CR 영역: `8E` 이스케이프 코드: `1B 4E`	SS2	단일 시프트 2	GL 또는 GR (아래 참조)은 즉시 뒤따르는 문자 하나에 대해서만 G2를 인코딩한다.^[67]
CR 영역: `SS3` 이스케이프 코드: `ESC O`	CR 영역: `8F` 이스케이프 코드: `1B 4F`	SS3	단일 시프트 3	GL 또는 GR (아래 참조)은 즉시 뒤따르는 문자 하나에 대해서만 G3를 인코딩한다.^[67]
`ESC ~`	`1B 7E`	LS1R	고정 시프트 1 오른쪽	GR은 이제부터 G1을 인코딩한다.^[66]
`ESC }`	`1B 7D`	LS2R	고정 시프트 2 오른쪽	GR은 이제부터 G2를 인코딩한다.^[66]
`ESC \|`	`1B 7C`	LS3R	고정 시프트 3 오른쪽	GR은 이제부터 G3를 인코딩한다.^[66]

번호	코드	16진수	코드 버전 기능 알림^[86]
1	`ESC SP A`	`1B 20 41`	GL의 G0, GR 부재 또는 미사용, 잠금 시프트 없음.
2	`ESC SP B`	`1B 20 42`	잠금 시프트로 GL에 G0 및 G1 호출, GR 부재 또는 미사용.
3	`ESC SP C`	`1B 20 43`	GL의 G0, GR의 G1, 잠금 시프트 없음, 8비트 환경 필요.
4	`ESC SP D`	`1B 20 44`	GL의 G0, 8비트인 경우 GR의 G1, 7비트 환경이 아닌 경우 잠금 시프트 없음.
5	`ESC SP E`	`1B 20 45`	7비트/8비트 변환 중 시프트 기능 유지.
6	`ESC SP F`	`1B 20 46`	이스케이프 시퀀스를 사용하여 C1 제어.
7	`ESC SP G`	`1B 20 47`	8비트 환경에서 CR 영역의 C1 제어, 그렇지 않으면 이스케이프 시퀀스.
8	`ESC SP H`	`1B 20 48`	94자 그래픽 세트만.
9	`ESC SP I`	`1B 20 49`	94자 및/또는 96자 그래픽 세트.
10	`ESC SP J`	`1B 20 4A`	여덟 번째 비트를 사용할 수 있더라도 7비트 코드를 사용.
11	`ESC SP K`	`1B 20 4B`	8비트 코드 필요.
12	`ESC SP L`	`1B 20 4C`	ISO/IEC 4873 (ECMA-43) 레벨 1 준수.
13	`ESC SP M`	`1B 20 4D`	ISO/IEC 4873 (ECMA-43) 레벨 2 준수.
14	`ESC SP N`	`1B 20 4E`	ISO/IEC 4873 (ECMA-43) 레벨 3 준수.
16	`ESC SP P`	`1B 20 50`	SI / LS0 사용.
18	`ESC SP R`	`1B 20 52`	SO / LS1 사용.
19	`ESC SP S`	`1B 20 53`	8비트 환경에서 LS1R 사용, 7비트 환경에서 SO 사용.
20	`ESC SP T`	`1B 20 54`	LS2 사용.
21	`ESC SP U`	`1B 20 55`	8비트 환경에서 LS2R 사용, 7비트 환경에서 LS2 사용.
22	`ESC SP V`	`1B 20 56`	LS3 사용.
23	`ESC SP W`	`1B 20 57`	8비트 환경에서 LS3R 사용, 7비트 환경에서 LS3 사용.
26	`ESC SP Z`	`1B 20 5A`	SS2 사용.
27	`ESC SP [`	`1B 20 5B`	SS3 사용.
28	`ESC SP \`	`1B 20 5C`	단일 시프트는 GR을 통해 호출.

3. 2. 문자 집합의 지정

ISO/IEC 2022는 여러 문자 집합을 표현하기 위해 이스케이프 시퀀스(escape sequence)를 사용하며, 이는 뒤에 오는 문자들의 문자 집합을 나타낸다.^[135]^[136] 이스케이프 시퀀스는 ISO에 등록되어 있으며, 표준에 의해 정의된 패턴을 따른다.^[12]^[146]

특정 문자 집합을 사용하려면 지정(designation)과 호출(invocation)이라는 두 단계를 거쳐야 한다.

지정: 이스케이프 시퀀스를 사용하여 사용할 문자 집합을 G0, G1, G2, G3 중 하나에 할당한다.
호출: 시프트(shift) 제어 기능을 사용하여 지정된 문자 집합을 GL 또는 GR 영역에 할당하여 실제로 사용할 수 있도록 한다.

ISO-IR(ISO International Register)은 ISO/IEC 2022와 함께 사용하도록 등록된 그래픽 문자 집합, 제어 코드 집합 등을 나열한다. 각 등록에는 고유한 이스케이프 시퀀스와 레지스트리 항목 번호가 할당된다.^[71]^[72]

문자 집합 지정을 위한 이스케이프 시퀀스는 다음 형식을 따른다.

`ESC [...] `
``: 중간 바이트 (0x20–0x2F 범위)
``: 최종 바이트 (0x30–0x7E 범위)

첫 번째 `` 바이트(또는 멀티바이트 집합의 경우 처음 두 바이트)는 문자 집합의 유형과 해당 문자 집합이 지정될 작업 집합(G0-G3)을 식별한다. `` 바이트(및 추가 `` 바이트)는 ISO-IR 레지스터에 할당된 문자 집합 자체를 식별한다.

G0부터 G3까지의 네 가지 작업 집합 각각은 94자 집합 또는 94ⁿ자 멀티 바이트 집합일 수 있다. 또한 G1에서 G3까지는 96자 또는 96ⁿ자 집합일 수 있다.

96자 또는 96ⁿ자 집합에서 GL이 호출될 때는 바이트 0x20부터 0x7F까지, GR이 호출될 때는 0xA0부터 0xFF까지가 해당 집합에 할당되어 사용될 수 있다. 94자 또는 94ⁿ자 집합에서는 바이트 0x20과 0x7F가 사용되지 않는다.^[40]

이스케이프 시퀀스 `` 바이트 및 해당 바이트가 수행하는 지정 또는 기타 기능의 표는 아래와 같다.^[85]

코드	16진수	약어	이름	효과	예시
`ESC (`	`1B 28`	GZD4	G0-지정 94자 집합	G0에 사용할 94자 집합을 선택한다.^[83]	`ESC ( B` (ASCII in G0)
`ESC )`	`1B 29`	G1D4	G1-지정 94자 집합	G1에 사용할 94자 집합을 선택한다.^[83]	`ESC ) I` (JIS X 0201 가나 in G1)
`ESC *`	`1B 2A`	G2D4	G2-지정 94자 집합	G2에 사용할 94자 집합을 선택한다.^[83]	`ESC * v` (ITU T.61 RHS in G2)
`ESC +`	`1B 2B`	G3D4	G3-지정 94자 집합	G3에 사용할 94자 집합을 선택한다.^[83]	`ESC + D` (NATS-SEFI-ADD in G3)
`ESC -`	`1B 2D`	G1D6	G1-지정 96자 집합	G1에 사용할 96자 집합을 선택한다.^[83]	`ESC - A` (ISO 8859-1 RHS in G1)
`ESC .`	`1B 2E`	G2D6	G2-지정 96자 집합	G2에 사용할 96자 집합을 선택한다.^[83]	`ESC . B` (ISO 8859-2 RHS in G2)
`ESC /`	`1B 2F`	G3D6	G3-지정 96자 집합	G3에 사용할 96자 집합을 선택한다.^[83]	`ESC / b` (ISO 8859-15 RHS in G3)
`ESC $ ( `	`1B 24 28 `	GZDM4	G0-지정 멀티바이트 94자 집합	G0에 사용할 94ⁿ 문자 집합을 선택한다.^[83]	`ESC $ ( C` (KS X 1001 in G0)
`ESC $ )`	`1B 24 29`	G1DM4	G1-지정 멀티바이트 94자 집합	G1에 사용할 94ⁿ 문자 집합을 선택한다.^[83]	`ESC $ ) A` (GB 2312 in G1)
`ESC $ *`	`1B 24 2A`	G2DM4	G2-지정 멀티바이트 94자 집합	G2에 사용할 94ⁿ 문자 집합을 선택한다.^[83]	`ESC $ * B` (JIS X 0208 in G2)
`ESC $ +`	`1B 24 2B`	G3DM4	G3-지정 멀티바이트 94자 집합	G3에 사용할 94ⁿ 문자 집합을 선택한다.^[83]	`ESC $ + D` (JIS X 0212 in G3)
`ESC $ -`	`1B 24 2D`	G1DM6	G1-지정 멀티바이트 96자 집합	G1에 사용할 96ⁿ 문자 집합을 선택한다.^[83]	`ESC $ - 1` (개인 사용)
`ESC $ .`	`1B 24 2E`	G2DM6	G2-지정 멀티바이트 96자 집합	G2에 사용할 96ⁿ 문자 집합을 선택한다.^[83]	`ESC $ . 2` (개인 사용)
`ESC $ /`	`1B 24 2F`	G3DM6	G3-지정 멀티바이트 96자 집합	G3에 사용할 96ⁿ 문자 집합을 선택한다.^[83]	`ESC $ / 3` (개인 사용)

4. 응용

ISO/IEC 2022는 Ecma 인터내셔널의 ECMA-35와 대응되며, 다양한 문자 인코딩 방식에서 활용된다.

ASCII 문자 집합은 ISO 기본 라틴 알파벳(영어 알파벳과 동일)을 지원하지만, 추가 문자가 필요한 언어에는 적합하지 않다. 그리스 문자, 키릴 문자, 아랍 문자, 히브리 문자 등은 8-비트 단일 바이트 확장 ASCII 인코딩을 사용하여 표현되었는데, 일부는 ISO 2022를 준수하지만(ISO 8859 시리즈^[135]^[136]) 코드 페이지 437과 같은 다른 인코딩은 그렇지 않다.

중국어, 일본어, 한국어 (CJK 문자)는 더블 바이트 문자 집합 또는 가변 폭 인코딩으로 표현되었으며, 일부는 ISO 2022를 준수한다(예: 중국어 간체 인코딩 GB 2312). ISO 2022의 제어 코드는 그래픽 문자의 바이트 수에 관계없이 항상 단일 바이트로 표현된다. CJK 인코딩 중 7비트 환경에서 문자 집합 간 전환에 ISO 2022 메커니즘을 사용하는 경우는 "ISO-2022-"로 시작하는 이름을 갖는다(예: ISO-2022-JP). EUC-JP와 같은 다른 CJK 인코딩도 ISO 2022 메커니즘을 사용한다.^[12]^[146]

유니코드는 ISO 2022에서 C0 및 C1 제어 코드 개념을 상속받았지만, 유니코드 제어 문자를 추가했다. UTF-8은 ISO 2022 구조에서 벗어나는 방식을 사용하지만, ISO 2022 이스케이프 시퀀스는 xterm과 같은 특정 터미널 에뮬레이터에서 지원된다.^[103]

ISO/IEC 2022는 대규모 문자 집합을 표현하기 위해 7비트 문자 표현이 94개의 그래픽 문자를 나타낼 수 있다는 ISO/IEC 646의 속성을 기반으로 한다. 2바이트를 사용하면 최대 8,836개의 문자를, 3바이트를 사용하면 최대 830,584개의 문자를 나타낼 수 있다.

ISO/IEC 2022는 다른 코딩 시스템으로 전환하고 돌아오기 위한 시퀀스도 정의한다. ISO/IEC 2022로 돌아가기 위한 시퀀스를 지원하는 등록에는 비디오텍스 형식, UTF-8, UTF-1 등이 있다.^[95]

코드	16진수	약어	이름	효과
`ESC % @`	`1B 25 40`	DOCS	다른 코딩 시스템 지정("표준 반환")	다른 인코딩에서 ISO/IEC 2022로 반환.^[94]
`ESC % F`	`1B 25 F`		다른 코딩 시스템 지정("표준 반환 포함")^[95]	F는 8비트 코드를 선택. `ESC % @`를 사용하여 반환.^[94]
`ESC % / F`	`1B 25 2F F`		다른 코딩 시스템 지정("표준 반환 없음")^[96]	F는 8비트 코드를 선택. 반환하는 표준 방법이 없음.^[94]
`ESC d`	`1B 64`	CMD	코딩 방식 구분 기호	ISO/IEC 2022 코딩 시퀀스의 끝.^[97]

ISO/IEC 10646(유니코드) 형식으로 전환하는 시퀀스도 있으며, UTF-8, UTF-16, UTF-32 등이 포함된다.^[95]^[96]

유니코드 형식	코드	16진수^[99]	사용 중단된 코드	사용 중단된 16진수^[95]^[96]^[99]
UTF-1	(UTF-1은 현재 ISO/IEC 10646에 없음)		`ESC % B`	`1B 25 42`
UTF-8	`ESC % G`, `ESC % / I`	`1B 25 47`,^[100] `1B 25 2F 49`^[101]	`ESC % / G`, `ESC % / H`	`1B 25 2F 47`, `1B 25 2F 48`
UTF-16	`ESC % / L`	`1B 25 2F 4C`^[102]	`ESC % / @`, `ESC % / C`, `ESC % / E`, `ESC % / J`, `ESC % / K`	`1B 25 2F 40`, `1B 25 2F 43`, `1B 25 2F 45`, `1B 25 2F 4A`, `1B 25 2F 4B`
UTF-32	`ESC % / F`	`1B 25 2F 46`	`ESC % / A`, `ESC % / D`	`1B 25 2F 41`, `1B 25 2F 44`

X 컨소시엄의 복합 텍스트 형식은 레이블별로 인코딩을 지정하기 위해 5개의 개인용 DOCS 시퀀스를 정의한다.^[153]

2004년 현재 모질라 파이어폭스(Mozilla Firefox)가 지원하는 ISO 2022 및 기타 CJK 인코딩

ISO 2022 코드 버전에는 7비트 버전(ISO-2022-CN, ISO-2022-CN-EXT, ISO-2022-JP, ISO-2022-JP-1, ISO-2022-JP-2, ISO-2022-KR)과 8비트 버전(확장 유닉스 코드)이 있다.^[12]^[146] ISO/IEC 8859 인코딩도 ISO 2022를 따른다.^[135]^[136]

ISO/IEC 2022는 여러 문자 집합을 단일 문자 인코딩으로 다루기 위한 기술로 개발되었다. ASCII는 7비트 라틴 알파벳 문자 집합으로 94개의 그래픽 문자만 수용 가능했다. ISO/IEC 646은 ASCII를 따르면서 국가별 문자 집합을 정의하는 방식을 취했다.

ISO/IEC 2022는 ISO/IEC 646에 준거한 여러 부호표를 전환하여 다언어 처리를 실현하고자 제정되었다. 유럽에서는 8비트 부호를 채용한 ISO/IEC 4873과 ISO/IEC 8859 시리즈가 제정되어 다언어 텍스트 데이터 처리를 가능하게 했다.

동아시아 언어는 8비트로 표현 가능한 범위를 넘어서는 문자를 사용하며, 언어별 2바이트 문자 집합으로 표현되었다. ISO/IEC 2022는 이러한 문자 집합들을 단일 부호화 방식으로 다룰 수 있게 한다.

ISO/IEC 2022 기반 부호화 표현은 일본어 전자 메일용 ISO-2022-JP, UNIX 환경에서 사용되는 EUC-JP, 중국의 GB 2312인 EUC-CN, 한국의 EUC-KR 등에서 널리 사용된다. ISO/IEC 8859 시리즈도 ISO/IEC 2022의 구조를 따른다.

4. 1. 7비트 부호화 멀티바이트 문자 집합

ISO-2022-JP는 일본어 전자 메일 등에서 널리 사용되는 7비트 인코딩 방식이다. 1993년 IETF RFC 1468에 명시되었다.^[106] 이 인코딩은 8비트 전송을 필요로 하지 않는다는 장점이 있다. 마이크로소프트는 이를 코드 페이지 50220이라고 부른다.^[107] ISO-2022-JP는 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과 동일한 이스케이프 시퀀스를 사용한다.^[106]

RFC는 일부 기존 시스템이 `ESC ( B`와 `ESC ( J`를 구분하지 않거나, `ESC $ @`와 `ESC $ B`를 구분하지 않았지만, 전자 메일과 같은 메시지를 단순히 중계하는 시스템에서는 이스케이프 시퀀스를 변경해서는 안 된다고 규정하고 있다.^[106]

ISO-2022-KR은 한국어 문자 인코딩을 위한 7비트 방식이다. 1993년에 발행된 RFC 1557에 정의되어 있다.^[126] 이는 ASCII와 한국의 2바이트 KS X 1001-1992^[127]^[128]를 인코딩한다. ISO-2022-JP-2와 달리, 줄의 시작 부분에 `ESC $ ) C`를 한 번 포함하여 KS X 1001을 G1으로 지정한 후, 시프트 아웃 및 시프트 인 문자를 사용하여 이를 전환한다.^[126] HTML5에서 사용되는 WHATWG 인코딩 표준은 사이트 간 스크립팅과 같은 코드 인젝션 공격에 대한 우려 때문에 ISO-2022-KR을 대체 문자(replacement character)로 매핑한다.^[130]^[132]^[131]

ISO-2022-CN과 ISO-2022-CN-EXT는 중국어 문자 인코딩을 위한 7비트 방식이다. 1996년에 발행된 RFC 1922에 정의되어 있다.^[129] 이들은 시프트 아웃 및 시프트 인 기능과 SS2 및 SS3의 7비트 이스케이프 코드 형태를 사용한다.^[129] 이들은 문자 집합 GB 2312 (중국어 간체용)와 CNS 11643 (중국어 번체용)를 지원한다.

기본 ISO-2022-CN 프로파일은 ASCII를 G0(시프트 인) 세트로 사용하며, GB 2312 및 CNS 11643의 처음 두 개 평면도 포함한다.^[129]

`ESC $ ) A`는 GB 2312-1980로 전환 (문자당 2바이트) ''[G1으로 지정]''
`ESC $ ) G`는 CNS 11643-1992 평면 1로 전환 (문자당 2바이트) ''[G1으로 지정]''
`ESC $ * H`는 CNS 11643-1992 평면 2로 전환 (문자당 2바이트) ''[G2로 지정]''

ISO-2022-CN-EXT 프로파일은 다음과 같은 추가 세트 및 평면을 허용한다.^[129]

`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 프로파일은 또한 추가 국표 표준 그래픽 세트가 허용됨을 나열하지만, ISO 2022 이스케이프 시퀀스가 등록되어 할당된 경우에 한정된다.^[129]

G1의 GB 12345
G2의 GB 7589 또는 GB 13131
G3의 GB 7590 또는 GB 13132

`ESC` (1바이트 문자 세트의 경우) 또는 `ESC $` (멀티바이트 문자 세트의 경우) 뒤의 문자는 지정된 문자 세트와 작업 세트의 유형을 지정한다.

HTML5에서 사용되는 WHATWG 인코딩 표준은 ISO-2022-CN 및 ISO-2022-CN-EXT ( HZ-GB-2312 뿐만 아니라)를 "대체" 디코더에 매핑한다.^[130] 이는 모든 입력을 대체 문자 (�)에 매핑하여 크로스 사이트 스크립팅 및 관련 공격을 방지하기 위한 것이다.^[131]

2024년 4월, glibc에서 ISO-2022-CN-EXT 구현에 보안 결함^[133]이 발견되었으며, 이로 인해 Linux 시스템에서 해당 인코딩을 완전히 비활성화하라는 권고가 나왔다.^[134]

4. 2. 8비트 부호화

확장 유닉스 코드(EUC)는 주로 일본어, 한국어, 중국어 간체에 사용되는 8비트 가변폭 문자 인코딩 시스템이다. ISO/IEC 2022를 기반으로 하며, ISO/IEC 2022 구조를 따르는 문자 집합만 EUC 형식을 가질 수 있다. 최대 4개의 코드화된 문자 집합(G0, G1, G2, G3)을 나타낼 수 있다. G0 집합은 GL을 통해 호출되고, G1 집합은 GR을 통해 호출되며, G2 및 G3 집합은 (존재하는 경우) 단일 시프트 SS2 및 SS3을 사용하여 호출되는데, 이는 CR 바이트(각각 0x8E 및 0x8F)로 사용되며 GR(GL이 아님)을 통해 호출된다.^[12] 잠금 시프트 코드는 사용되지 않는다.^[146]

G0 집합에 할당된 코드는 ASCII 또는 KS X 1003(KS-Roman) 또는 JIS X 0201의 하위 절반(JIS-Roman)과 같은 해당 국가의 국가 ISO/IEC 646 문자 집합이다.^[12] 따라서 0x5C(백슬래시)는 EUC-JP의 일부 버전에서는 엔 기호를 나타내는 데 사용되고, EUC-KR의 일부 버전에서는 원 기호를 나타내는 데 사용된다.

G1은 2바이트로 표현되는 94x94 코드화된 문자 집합에 사용된다. EUC-CN(GB 2312의 EUC 형식)과 EUC-KR이 이러한 2바이트 EUC 코드의 예이다. EUC-JP는 최대 3바이트(SS3 + 2바이트)로 표현되는 문자를 포함하는 반면, EUC-TW의 단일 문자는 최대 4바이트(SS2 + 3바이트)를 차지할 수 있다.

EUC 코드는 ISO/IEC 2022의 발표자 또는 지정 시퀀스를 사용하지 않는다. 그러나 이는 다음과 같이 네 가지 발표자 시퀀스에 해당하며, 의미는 다음과 같다.^[147]

개별 시퀀스	16진수	EUC의 기능 표기
`ESC SP C`	`1B 20 43`	ISO-8 (8비트, G0는 GL에, G1은 GR에)
`ESC SP Z`	`1B 20 5A`	SS2를 사용하여 G2 접근
`ESC SP [`	`1B 20 5B`	SS3을 사용하여 G3 접근
`ESC SP \`	`1B 20 5C`	단일 시프트는 GR을 통해 호출

8비트 단일 바이트 인코딩에 적용된 ISO 2022의 하위 집합은 '''ISO/IEC 4873'''에 의해 정의되며, Ecma International에 의해 ECMA-43으로도 출판되었다. ISO/IEC 8859는 ISO/IEC 4873(또는 ECMA-43) 레벨 1에 대한 8비트 코드를 정의한다.^[135]^[136]

4. 3. 기타

확장 ASCII는 8비트 부호를 사용하는 싱글바이트 문자 집합으로, ASCII에 대해 상위 호환되는 것을 가리킨다. ISO/IEC 4873에 준거한 부호표를 가지면 그 문자 집합은 ISO/IEC 2022에 준거한다고 말할 수 있다. 확장 ASCII는 일반적으로 다음과 같은 특징을 가진다.

공지 기능의 이스케이프 시퀀스는 생략한다.
G0에 ISO/IEC 646의 각국 버전 또는 ASCII를, G1에 기타 싱글 바이트 문자 집합을 지시하고, G0을 GL 영역에, G1을 GR 영역에 호출한 상태로 시작한다 (이를 위한 제어 기능은 생략한다).
지시 상태도 호출 상태도 고정적으로 정해져 있으며, 변경은 하지 않는다.

이러한 방식을 통해 8비트 부호로 최대 188개 내지 190개의 그림 문자를 이용할 수 있으며, 모든 문자가 1바이트의 고정 길이로 표현된다.

확장 ASCII의 예는 다음과 같다.

ARMSCII (아르메니아 문자)
ASMO 449+ (아랍 문자)
ISCII (인도 문자)
ISO/IEC 8859 시리즈 (유럽 언어, 아랍 문자, 그리스 문자, 키릴 문자, 타이 문자, 히브리 문자)
JIS X 0201 (일본어 가타카나)
PASCII (아랍 문자)
TIS 620 (타이 문자)
TSCII (타밀 문자)

VISCII와 KOI8 계열 문자 집합 (키릴 문자)처럼 도형 문자를 GR 영역이나 GL 영역 밖으로까지 배치하는 경우도 있다.

Compound Text Encoding(CTEXT)는 X Window System에서 클라이언트 간의 텍스트 정보 전달 및 자원 내 텍스트 정보 표현에 사용되는 부호화 방식이다. CTEXT는 다음과 같은 특징을 갖는다.

아나운스 기능의 이스케이프 시퀀스는 생략한다.
8비트 부호이므로 GR 영역도 사용한다.
G0에 ASCII를, G1에 ISO/IEC 8859-1의 오른쪽 절반을 지정하고, G0을 GL 영역에, G1을 GR 영역에 호출한 상태로 시작한다(이러한 제어 기능은 생략한다). 즉, 처음에는 ISO/IEC 8859-1로 시작한다.
G0 및 G1에 대한 지정이 GL 영역 및 GR 영역에 대한 호출을 겸한다. 호출 제어 기능은 사용하지 않는다. 즉, 문자 집합 선택은 지정의 이스케이프 시퀀스만으로 수행한다.
ISO/IEC 2022의 DOCS와 사적 종료 바이트에 의해, 사용자 고유의 문자 집합 및 UTF-8처럼 ISO/IEC 2022에 준거한 구조의 부호표를 갖지 않는 부호화 시스템을 지정한다.
ISO/IEC 6429의 SDS에 의해 문자 쓰기 방향을 지정한다.

CTEXT는 여러 부호화 시스템 및 문자 집합이 혼재하는 경우에도 문자 코드 변환에 의한 정보 열화를 일으키지 않으며, 클라이언트가 지원하지 않는 부호화 시스템 및 문자 집합의 정보도 전달할 수 있게 되었다.

5. 한계

ISO/IEC 2022는 상태 기반 인코딩 방식을 사용하므로, 다음과 같은 몇 가지 한계점이 존재한다.

텍스트 처리의 어려움: 텍스트 블록 중간에서 검색, 삽입, 삭제 등의 작업을 하기가 어렵다. 상태 비저장(stateless) 인코딩에 비해 텍스트 조작이 번거롭고 느리다. 텍스트 중간 부분으로 이동하면, 이스케이프 시퀀스 뒤의 바이트를 해석하기 전에 이전 이스케이프 시퀀스를 찾아야 할 수도 있다.^[158]
문자열 비교의 어려움: ISO/IEC 2022는 상태 기반 특성 때문에, 동일한 문자가 G0부터 G3까지 지정될 수 있는 다양한 문자 집합으로 인코딩될 수 있다. 이는 단일 시프트 또는 GL/GR로의 잠금 시프트를 사용하여 호출될 수 있다. 결과적으로 문자는 여러 방식으로 표현될 수 있으며, 이는 시각적으로 동일하고 동등한 두 문자열을 동일성 여부를 신뢰성 있게 비교할 수 없음을 의미한다.
텍스트 이식성 문제: DICOM이나 여러 전자 메일 클라이언트와 같은 일부 시스템은 여러 다른 인코딩을 지원하는 것 외에도 "ISO 2022 IR 100"^[154]과 같은 ISO-2022 변형을 사용한다.^[155] 이러한 변형은 컴퓨터 시스템 간에 텍스트를 이식 가능하게 전송하는 것을 어렵게 만든다.
보안 취약점: 이스케이프 시퀀스 때문에, 유해한 문자열(예: 크로스 사이트 스크립팅)이 유니코드로 디코딩될 때까지 가려져서 보안 처리를 우회할 수 있는 공격 바이트 시퀀스를 구성할 수 있다.^[158] 따라서 이 인코딩의 사용은 멀웨어 방지 프로그램에서 의심스러운 것으로 간주되며,^[156] ISO 2022 7비트 데이터(ISO-2022-JP 제외)는 공격을 방지하기 위해 HTML5에서 전체적으로 대체 문자로 변환된다.^[130]^[131] 지정 이스케이프 또는 잠금 시프트 코드를 사용하지 않는 확장 유닉스 코드와 같은 제한된 ISO 2022 8비트 코드 버전은 이러한 문제를 겪지 않는다.
연결 문제: ISO-2022-JP와 같은 프로필은 스트림이 ASCII 상태로 시작하고 끝나야 한다고 명시한다.^[106] 이는 연결된 ISO-2022-JP 및/또는 ASCII 스트림의 문자가 올바른 집합으로 해석되도록 하는 데 필요하다. 이는 멀티 바이트 문자로 끝나는 스트림이 멀티 바이트 문자로 시작하는 스트림과 연결될 경우 ASCII로 전환하고 즉시 전환하는 한 쌍의 이스케이프 코드가 생성되는 결과를 초래한다. 그러나 유니코드 기술 보고서 #36("유니코드 보안 고려 사항")에 명시된 바와 같이, 사이에 문자가 없는 ISO 2022 이스케이프 시퀀스 쌍은 크로스 사이트 스크립팅과 같은 악성 시퀀스를 숨기는 데 사용되지 않도록 대체 문자("�")를 생성해야 한다.^[157] 예를 들어 모질라 선더버드에서 이 조치를 구현하면 두 개의 ISO-2022-JP 스트림이 연결된 경우 예상치 못한 "�" 문자가 생성되어 상호 운용성 문제가 발생했다.^[158]

참조

_[3] 웹사이트 ECMA-35: Character code structure and extension techniques (web page) https://www.ecma-int[...] Ecma International 2022-04-27
_[31] 웹사이트 ansi.go, line 134 https://github.com/p[...] 2014
_[1] 간행물 ECMA-35 1994
_[2] 간행물 ECMA-35 1994
_[4] 간행물 ECMA-35 1994
_[5] 간행물 ECMA-35 1994
_[6] 간행물 ECMA-35 1994
_[7] 간행물 ECMA-35 1994
_[8] 간행물 ECMA-35 1994
_[9] 간행물 ECMA-35 1994
_[10] 간행물 ECMA-35 1994
_[11] 간행물 Lunde 2008
_[12] 간행물 Lunde 2008
_[13] 간행물 Lunde 2008
_[14] 간행물 ECMA-35 1994
_[15] 간행물 ECMA-35 1994
_[16] 간행물 ISO-IR-14 1975
_[17] 간행물 ECMA-35 1994
_[18] 간행물 RFC 1468 1993
_[19] 간행물 ECMA-35 1994
_[20] 간행물 ECMA-35 1994
_[21] 간행물 ECMA-35 1994
_[22] 간행물 ECMA-35 1994
_[23] 간행물 ECMA-35 1994
_[24] 간행물 ECMA-35 1994
_[25] 간행물 ECMA-35 1994
_[26] 간행물 ECMA-48 1991
_[27] 간행물 ISO-IR-208 1999
_[28] 간행물 ISO-IR-155 1990
_[29] 간행물 ISO-IR-164 1992
_[30] 간행물 ECMA-35 1994
_[32] 간행물 ECMA-43 1991
_[33] 간행물 ISO/IEC FDIS 8859-10 1998
_[34] 간행물 ECMA-144 2000
_[35] 간행물 ECMA-43 1991
_[36] 간행물 1994
_[37] 간행물 1994
_[38] 간행물 1994
_[39] 간행물 1985
_[40] 간행물 1994
_[41] 간행물 1975
_[42] 간행물 1994
_[43] 간행물 1994
_[44] 간행물 1991
_[45] 간행물 1994
_[46] 간행물 1994
_[47] 간행물 1994
_[48] 간행물
_[49] 간행물 1994
_[50] 간행물 1991
_[51] iso-ir Reset to Initial State (RIS) 1976-12-30
_[52] 간행물 1994
_[53] 간행물 1994
_[54] 간행물 1975
_[55] citation Recommendation T.51 (1992) Amendment 1 https://www.itu.int/[...] 1995-08-11
_[56] 간행물 1985
_[57] 간행물 1994
_[58] 간행물 1987
_[59] 간행물 1975
_[60] 간행물 1976
_[61] 간행물 1977
_[62] 간행물 1980
_[63] 간행물 1985
_[64] 간행물 1994
_[65] 간행물 1994
_[66] 간행물 1994
_[67] 간행물 1994
_[68] 간행물 1994
_[69] 간행물 1994
_[70] 간행물 1994
_[71] 간행물 ECMA-35 1994
_[72] 간행물 ISO-IR
_[73] 간행물 ISO/IEC 2375 2003
_[74] 웹사이트 Handling of the SGML declaration in SP http://www.jclark.co[...]
_[75] 웹사이트 20: SGML Declaration of HTML 4 https://www.w3.org/T[...] W3C
_[76] 간행물 ISO-IR
_[77] 간행물 ARIB STD-B24 2008
_[78] 웹사이트 About the 'alternate linedrawing character set' https://www.in-ulm.d[...] 2020-01-08
_[79] 간행물 ECMA-35 1994
_[80] 간행물 ECMA-35 1994
_[81] 간행물 ECMA-35 1994
_[82] 간행물 ETS 300 706 1997
_[83] 간행물 ECMA-35 1994
_[84] 간행물 ISO/IEC 10646 2017
_[85] 간행물 ECMA-35 1994
_[86] 간행물 ECMA-35 1994
_[87] 간행물 ECMA-35 1994
_[88] 간행물 ECMA-35 1994
_[89] 간행물 DECDWL—Double-Width, Single-Height Line https://vt100.net/do[...] 2020-01-17
_[90] 웹사이트 Encode::JP::Emoji::Encoding https://github.com/k[...] 2020-05-28
_[91] 간행물 ECMA-35 1994
_[92] 간행물 ECMA-35 1980
_[93] 웹사이트 Technique 2: Using standard alternate graphic character sets https://www.loc.gov/[...] Library of Congress 2020-07-19
_[94] 간행물 ECMA-35 1994
_[95] 간행물 ISO-IR
_[96] 간행물 ISO-IR
_[97] 간행물 ECMA-35 1994
_[98] 간행물 ISO/IEC 10646 2017
_[99] 간행물 ISO/IEC 10646 2017
_[100] 간행물 ISO-IR-196 1996
_[101] 간행물 ISO-IR-192 1996
_[102] 간행물 ISO-IR-195 1996
_[103] 웹사이트 Controls beginning with ESC https://invisible-is[...] 2019-10-04
_[104] 간행물 ISO/IEC 10646 2017
_[105] 서적 Lunde 2008
_[106] 간행물 RFC 1468 1993
_[107] 웹사이트 Code Page Identifiers https://docs.microso[...] Microsoft 2019-09-16
_[108] 간행물 WHATWG Encoding Standard
_[109] 웹사이트 Modules/cjkcodecs/_codecs_iso2022.c, line 1122 https://github.com/p[...] Python Software Foundation 2019-09-15
_[110] 웹사이트 codecs — Codec registry and base classes § Standard Encodings https://docs.python.[...] Python Software Foundation 2019-09-16
_[111] 웹사이트 2: Codesets and Codeset Conversion http://www.itec.suny[...] Digital Equipment Corporation, Compaq
_[112] 간행물 Lunde 2008
_[113] 간행물 RFC 1554 1993
_[114] 간행물 RFC 2237 1997
_[115] 웹사이트 PQ02042: New Function to Provide C/370 iconv() Support for Japanese ISO-2022-JP https://www.ibm.com/[...] IBM 2021-01-19
_[116] 웹사이트 Additional Coding-related Required Information https://web.archive.[...] IBM
_[117] 웹사이트 CCSID 956 https://web.archive.[...] IBM
_[118] 웹사이트 CCSID 957 https://web.archive.[...] IBM
_[119] 웹사이트 CCSID 958 https://web.archive.[...] IBM
_[120] 웹사이트 CCSID 959 https://web.archive.[...] IBM
_[121] 웹사이트 CCSID 5052 https://web.archive.[...] IBM
_[122] 웹사이트 CCSID 5053 https://web.archive.[...] IBM
_[123] 웹사이트 CCSID 5054 https://web.archive.[...] IBM
_[124] 웹사이트 CCSID 5055 https://web.archive.[...] IBM
_[125] 웹사이트 CCSID 9148 https://web.archive.[...] IBM
_[126] 간행물 RFC 1557 1993
_[127] 웹사이트 KS X 1001:1992 http://examples.orei[...] 2007-07-12
_[128] 간행물 ISO-IR-149 1988
_[129] 간행물 RFC 1922 1996
_[130] 간행물 WHATWG Encoding Standard
_[131] 간행물 WHATWG Encoding Standard
_[132] 간행물 WHATWG Encoding Standard
_[133] 웹사이트 CVE-2024-2961 https://nvd.nist.gov[...]
_[134] 웹사이트 GLIBC Vulnerability on Servers Serving PHP https://rockylinux.o[...]
_[135] 간행물 ISO/IEC FDIS 8859-10 1998
_[136] 간행물 ECMA-144 2000
_[137] 간행물 ECMA-43 1991
_[138] 간행물 ECMA-43 1985
_[139] 간행물 ECMA-43 1991
_[140] 간행물 ECMA-43 1991
_[141] 간행물 The IPTC Recommended Message Format https://www.iptc.org[...] 1995
_[142] 서적 chapter 9.2 ("Unique coding of characters") 1991
_[143] 서적 annex E ("Main differences between the second edition (1985) and the present (third) edition of this ECMA Standard") 1991
_[144] 웹사이트 8. Code Extension, ISO 2022 and 2375, ISO 4873 and 10367 https://www.terena.o[...] Terena 1999
_[145] 서적 chapter 10 ("Identification of version and level") 1991
_[146] 서적 Chapter 4 ("Encoding Methods"), section "EUC versus ISO-2022 encodings" 2008
_[147] 웹사이트 Character Data Representation Architecture (CDRA) https://www.ibm.com/[...]
_[148] 서적 1989
_[149] 서적 Control Characters 1989
_[150] 서적 Directionality 1989
_[151] 서적 Standard Character Set Encodings 1989
_[152] 서적 Approved Standard Encodings 1989
_[153] 서적 Non-Standard Character Set Encodings 1989
_[154] 웹사이트 DICOM PS3.2 2016d - Conformance; D.6.2 Character Sets; D.6 Support of Character Sets http://dicom.nema.or[...]
_[155] 웹사이트 DICOM ISO 2022 variation http://sourceforge.n[...]
_[156] 웹사이트 935453 - Gather telemetry about HZ and other encodings we might try to remove https://bugzilla.moz[...]
_[157] 웹사이트 3.6.2 Some Output For All Input https://www.unicode.[...] Unicode Consortium 2014-09-19
_[158] 웹사이트 (UNSUBMITTED DRAFT) No U+FFFD Generation for Zero-Length ASCII-State Content between ISO-2022-JP Escape Sequences https://hsivonen.fi/[...] 2018-12-17
_[159] 문서 第3次規格までの標題は「情報交換用符号の拡張法」であった。
_[160] 문서 初版制定当時の名称は ISO/R 646。その後 ISO 646、さらに ISO/IEC 646 と改称された。しかし、本項では原則として ISO/IEC 646 と表記する。
_[161] 문서 初版制定当時の名称は ISO 2022:1973。その後1994年の第4版で ISO/IEC 2022 と改称。初版に対するJISの対応規格は JIS C 6228:1975。1982年第2版の JIS C 6228:1982 はその後 JIS X 0202:1982 と改称された。しかし、本項では原則として ISO/IEC 2022 および JIS X 0202 と表記する。
_[162] 문서 初版制定当時の名称は ISO 4873。後に ISO/IEC 4873 と改称された。しかし、本項では原則として ISO/IEC 4873 と表記する。
_[163] 문서 これは今日では ''internationalization'' ([[국제화と地域化|i18n]]。国際化) あるいは ''multilingualization'' ([[다언어화|m17n]]。多言語化) と呼ばれる考えかたであるが、当時はヨーロッパの諸言語にまたがるという意味で ''harmonization'' (調和) と呼ばれた。後に ISO/IEC 8859 はヨーロッパ諸語以外も包含するものになる。
_[164] 문서 論理的には5バイト以上のエスケープシーケンスも用いられ得るが、現時点では ISO/IEC 2022 で規定されているものはない。
_[165] 문서 ISO/IEC 2022が定められた当初は、呼び出しの制御機能には SI (G1からGL領域への呼び出し) と SO (G0からGL領域への呼び出し) しかなかった。そのため、SIを「漢字イン」(制御文字やローマ字の符号表から漢字の符号表にシフトする)、SOを「漢字アウト」(漢字の符号表へのシフトから復する) とする理解が生まれ、ほかの呼び出し制御機能が定められた際には混乱を招いた。実際にはロッキングシフトでは、前の呼び出しを記憶しているわけではない。ちなみに、当時開発されたプリンタ記述言語 ([[프린터|프린타]]を制御するための通信手順) には、この漢字イン/漢字アウトの発想が残っているものがある。
_[166] 문서 シングルシフトには、G2かG3から呼び出しするものしかない。また、8ビット符号の場合、GL領域に呼び出すかGR領域に呼び出すかは最初にアナウンス機能によって決定することになっている。
_[167] 문서 JIS X 0202:1991 解説「登録」による
_[168] 문서 ISO-2022-JPの場合は、JIS X 0201-1976のラテン文字集合でもよい。
_[169] 문서 日本の国コード ''JP'' が含まれる名称であるのは、ネットニューズのfj.*グループの利用者およびホストコンピュータのjpドメイン名を電子メールアドレスに含む利用者らの議論による。なお文字集合として使う JIS X 0208 は日本工業規格であり、[[漢字]]や[[仮名 (文字)|仮名]]といった日本語に必須の[[文字|文字体系]]のほかに、アラビア数字や種々の記号とともに頭字語用途を主として{{要出典|date=2010年4月|title=たとえばJIS C 6226-1978最終原案『情報交換のための漢字符号の標準化に関する調査研究報告書』(日本情報処理開発センター, 1976年3月) にそのような記載はないもよう}}一部の[[ラテン文字]]、[[ギリシア文字]]、[[キリル文字]]も含んでいる。そのため、日本語以外の言語を部分的に表現できる。{{IETF RFC|1468}} の表題は ''Japanese Character Encoding for Internet Messages'' (インターネットメッセージのための日本語文字符号化) であることから、特に日本国内にかぎった利用を想定していたわけでもなく、日本語コミュニティでの利用を想定していた。
_[170] 문서 JIS X 0208:1997 附属書2より引用。また、同解説 3.11 も参照。
_[171] 문서 [[Extended Unix Code|EUC]]では''文字コード'' (英: ''codeset'')、[[日本工業規格|JIS]]では''符号化表現''と呼ぶ。また、一部は[[文字符号化方式#キャラクタセット|キャラクタセット]]としてIANAが登録している。

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com