ISO/IEC 2022

ISO/IEC 2022
ISO 2022
언어여러가지.
표준.ISO/IEC 2022,
ECMA-35,
ANSI X3.41,
JIS X 0202
분류스테이트풀한 인코딩 시스템(스테이트리스 설정 서브셋 포함)
변환/인코딩US-ASCII 및 구현에 따라 다음 중 하나:
에 의해 성공자ISO/IEC 10646(유니코드)
기타 관련 부호화스테이트풀 서브셋: ISO-2022-JP, ISO-2022-CN, ISO-2022-KR
사전 구성 버전: ISO/IEC 4873, EUC

ISO/IEC 2022 정보 기술—문자 코드 구조와 확장 기술문자 인코딩 분야에서 ISO/IEC 표준(ECMA 표준 ECMA-35,[1][2] ANSI 표준 ANSI X3.41[3]일본 산업 표준 JIS X 0202)입니다.1971년에 시작되었으며,[4] 가장 최근에 개정된 것은 1994년이다.

ISO 2022는 문자 인코딩이 적합할 수 있는 일반적인 구조를 규정하며, 특정 바이트 범위(0x00~1F 및 0x7F~9F)를 지정함으로써 그래픽 문자가 아닌 포맷 및 인밴드 명령(예를 들어 줄 바꿈 또는 텍스트 단말기의 포맷 명령)을 위한 비인쇄 제어[5] 코드에 사용된다.또한 이스케이프 시퀀스의 구문을 지정합니다.다중 바이트 시퀀스는ESC 제어 코드: 인밴드명령에도 [6]사용할 수 있습니다.ISO 2022에서 사용하도록 설계된 제어 코드 및 이스케이프 시퀀스의 특정 세트에는 ISO/IEC 6429가 포함되며, 그 일부는 ANSI에 의해 구현된다.SYS터미널 에뮬레이터

IS02022년 그 자체도 이렇게 그것은 단일 document,[7]에 효과적으로 단일 네트워크 인코딩에(형상을 덜 adven 매우 중요하게 결합하여 다중 사용할 다른 코드화 문자 집합 사이에(예를 들어, 아스키와 일본 사이에 JISX0208)전환을 위해 사용할 수 있는 특정한 제어 코드 및 탈출 순서를 정의합니다.로.f Unicode).8비트 환경과 7비트 환경 모두에서 사용할 수 있도록 설계되어 있습니다(8B가 없는 이메일 등, 바이트 단위로 7비트만 사용할 수 있는 환경).ITMIME)[8]

암호화 및 적합성

그리스어, 키릴어, 아랍어, 히브리어 등 비교적 적은 문자와 분음 부호 또는 ISO Basic Latin 알파벳에 없는 문자를 사용하는 라틴 알파벳 형식은 역사적으로 서로 다른 8비트, 단일 바이트, 확장 ASCII 인코딩을 사용하는 컴퓨터에서 표현되어 왔습니다.ISO 8859 시리즈와 같은 일부는 [9][10]ISO 2022에 준거하지만 DOS 코드 페이지 437과 같은 일부는 일반적으로 제어 코드를 위해 0x80-9F 바이트를 예약하지 않기 때문에 ISO 2022에 준거하지 않습니다.

특정 동아시아 언어, 특히 중국어, 일본어한국어(통칭 "CJK")는 1바이트로 나타낼 수 있는 최대 256자보다 훨씬 더 많은 문자를 사용하여 작성되며 언어 고유더블바이트 인코딩 또는 가변인코딩을 사용하는 컴퓨터에서 처음 표현되었습니다.d 중국어 인코딩 GB 2312)는 ISO 2022에 준거하지만 다른 중국어 인코딩 Big5 등에서는 준거하지 않습니다.ISO 2022의 제어 코드는 그래픽 문자에 사용되는 바이트 수에 관계없이 항상 단일 바이트로 표시됩니다.ISO 2022 메커니즘을 사용하여 문자 집합을 전환하는 7비트 환경에서 사용되는 CJK 인코딩은 ISO-2022-로 시작하는 이름이 종종 지정되지만, 특히 ISO-2022-JP로 시작하는 경우가 많습니다. 단 EUC-JP와 같은 일부 다른 CJK 인코딩도 ISO 2022 [11][12]메커니즘을 사용합니다.

유니코드의 첫 번째 256개의 코드 포인트가 ISO 8859-1에서 가져온 것이므로 유니코드는 ISO 2022의 C0C1 제어 코드 개념을 계승하지만 ISO 2022 제어 코드 외에 인쇄되지 않는 다른 문자를 추가합니다.그러나 UTF-8과 같은 Unicode 변환 포맷은 일반적으로 다음과 같은 다양한 방법으로 ISO 2022 구조에서 벗어납니다.

  • 8비트 바이트를 사용하지만 ISO 2022에서 지정된 싱글바이트 형식으로 C1 코드를 나타내지 않음(대부분의 UTF, 1개의 예외는 구식 UTF-1)
  • 제어 코드를 포함한 모든 문자를 여러 바이트로 나타냅니다(: UTF-16, UTF-32).
  • 단일 코드 포인트에 대해 코드화된 표현 내에서 최상위 비트 세트 및 설정 해제된 바이트 혼합(예: UTF-1, GB 18030)

그러나 ISO 2022 이스케이프 시퀀스는 xterm[14]같은 특정 단말 에뮬레이터에 의해 지원되는 "ISO [13]2022와 다른 코드 시스템"으로서 UTF-8로 전환하거나 UTF-8에서 전환하기 위해 존재한다.

개요

요소들

ISO/IEC 2022는 다음을 규정한다.

  • 복수의 그래피컬 문자 세트 및 복수의 프라이머리(C0) 및 세컨더리(C1) 제어 [15]코드 세트를 포함한 단일 문자 부호화 시스템에 포함될 수 있는 특정 구조를 가진 복수의 문자 세트의 인프라스트럭처,
  • 바이트당 [16]8비트를 사용할 수 있다고 가정할 때 이러한 세트를 인코딩하는 형식입니다.
  • 바이트당 [17]7비트밖에 이용할 수 없는 경우에 이들 세트를 같은 부호화 시스템으로 부호화하는 포맷 및 이러한 7비트 [8]환경을 통과하도록 적합 문자 데이터를 변환하는 방법.
  • ANSI 이스케이프 [6]코드의 일반적인 구조 및
  • 개개의 문자 [7]세트를 식별하거나 특정 부호화 기능 [18]또는 서브셋의 사용을 통지하거나 다른 부호화 시스템과 [18]대화 또는 전환하기 위한 특정 이스케이프 코드 형식.

코드 버전

특정 구현이 모든 표준을 구현할 필요는 없습니다.준수 수준과 지원되는 문자 세트는 구현에 의해 정의됩니다.ISO/IEC 2022 표준에 의해 정의된 메커니즘의 대부분은 자주 사용되지 않지만, 몇몇 확립된 인코딩은 ISO/IEC 2022 시스템의 [19]하위 집합에 기초한다.특히7-bit 인코딩 시스템/IEC2022년 메커니즘을 사용할 때 ISO-2022-JP(또는 JIS인코딩),Japanese-language 전자 메일로. 8비트 인코딩 시스템/IEC2022년에 적합하고 그 다음에/IEC8859,[9][10]에 의해 일치하는 동 A에 사용된다/IEC4873(ECMA-43), 및 확장 유닉스 코드 포함한다 사용되어 왔다 등나는sian괴로움[11]ISO 2022의 보다 전문적인 응용 프로그램에는 MARC 21 라이브러리 [3]레코드에 사용되는 MARC-8 인코딩 시스템이 포함됩니다.

지정 이스케이프 시퀀스

특정 문자 세트 또는 인코딩으로 전환하기 위한 이스케이프 시퀀스는 ISO-IR 레지스트리에 등록되며(벤더에 의해 의미가 정의되거나 ARIB STD-B24 등의 프로토콜 사양에 의해 정의된 것은 제외), 표준 내에서 정의된 패턴을 따릅니다.이러한 이스케이프 시퀀스를 이용한 문자 부호화에서는 데이터의 올바른 해석은 이전에 발생한 이스케이프 시퀀스에 의존하기 때문에 데이터가 전진 방향으로 순차적으로 처리되어야 합니다.

ISO-2022-JP 등의 특정 프로파일에는 행의 종료전에 현재의 문자 세트가 US-ASCII 로 리셋 되는 등, 추가 조건이 부과되는 일이 있습니다.또, 특정의 ISO-2022 베이스의 부호화가 이것을 허가 또는 필요로 하고, 특정의 국내 문자 세트를 사용하도록 지시하는 경우, 국내 문자 세트를 선언하는 이스케이프 시퀀스는 존재하지 않는 경우가 있습니다.예를 들어 ISO-8859-1에서는 이스케이프 시퀀스를 정의할 필요가 없다고 기술되어 있으며, ISO-2022-CN을 정의하는 RFC 1922에서는 이스케이프 시퀀스를 명시적으로 사용하지 않고 ISO-2022 SHIFT 문자를 사용할 수 있습니다.

멀티바이트 문자

ISO/IEC 2022는 ISO/IEC 646의 특성을 기반으로 7비트 문자 1개가 보통 94개의 그래픽(인쇄 가능) 문자(스페이스 및 33개의 제어 문자)를 정의하며, C0 제어 코드(좁게 정의)만 제외하면 96자로 확장할 수 있습니다.따라서 2바이트를 사용하면 최대 8,836자(94×94)의 문자를 나타낼 수 있으며, 3바이트를 사용하면 최대 830,584자(94×94×94)의 문자를 나타낼 수 있습니다.표준에서는 정의되어 있습니다만, 3 바이트를 사용하는 등록 문자 집합은 없습니다(, EUC-TW의 미등록 G2는 마찬가지로 미등록 CCII와 같습니다).

2바이트 문자 집합의 경우, 각 문자의 코드 포인트는 보통 1부터 94까지의 2개의 숫자를 포함하는 이른바 로우 셀 또는 쿠텐[a] 형식으로 지정되며, 존 내의 해당 문자의 행과[b][c] 셀을 지정한다.3바이트 세트의 경우 [20]시작 부분에 추가 평면[d] 번호가 포함됩니다.이스케이프 시퀀스는 사용되는 문자 세트뿐만 아니라 세트가 싱글바이트인지 멀티바이트인지 여부(다만 멀티바이트인 경우 사용되는 바이트 수는 아님), 각 바이트에 94 또는 96의 허용 값이 있는지 여부도 나타냅니다.

코드 구조

표기법 및 명명법

ISO/IEC 2022 부호화는 문자 코드와 표시된 문자 사이의 2층 매핑을 지정합니다.이스케이프 시퀀스를 사용하면 그래픽 문자 세트의 큰 레지스트리 중 하나를 G0 ~ G3라는 이름의 4개의 작업 세트 중 하나로 "지정"[21]할 수 있습니다.또한 짧은 제어 시퀀스는 스트림 내의 바이트를 해석하기 위해 "부팅"[22]되는 작업 세트를 지정합니다.

인코딩 바이트 값("비트 조합")은 종종 열 표기로 지정되며 00 ~15 범위의 2개의 10진수(각각 1자리 16진수에 대응)는 [23]슬래시로 구분됩니다.따라서 예를 들어 코드 2/0(0x20)~2/15(0x2F)는 "column 02"라고 할 수 있습니다.이것은 ISO/IEC 2022/EMA-35 표준 [24]자체에서 사용되는 표기법입니다.이스케이프 시퀀스는 실제로 바이트 값으로 정의되어 있으며 제어 시퀀스에 영향을 주지 않고 해당 바이트 값에 할당된 그래픽을 변경할 수 있습니다.단, 이 문서에서 자주 사용되는 16진수 또는 대응하는 ASCII [25]문자를 사용합니다.

문자 코드 테이블의 왼쪽에 있는7비트 ASCII 그래픽스 범위(16진수 0x20~0x7F)의 바이트 값은 GL 코드(GL은 "그래픽스 왼쪽"을 나타냄)라고 불리며, "높은 ASCII 범위(0xA0~0x)의 바이트는 "GL" 코드라고 불립니다.FF)를 사용할 수 있는 경우(즉, 8비트 환경에서)는 "GR" 코드("그래픽 권리")[5]라고 합니다.제어 범위에 대해 "CL"(0x00–0x1F) 및 "CR"(0x80–0x9F)이라는 용어가 정의되지만 CL 범위는 항상 기본(C0) 컨트롤을 호출하는 반면 CR 범위는 항상 보조(C1) 컨트롤을 호출하거나 사용되지 않습니다.[5]

코드화된 고정 문자

삭제 문자 DEL(0x7F), 이스케이프 문자 ESC(0x1B) 및 스페이스 문자 SP(0x20)는 "고정" 코드화된[26] 문자이며 G0이 GL을 통해 호출될 때 지정된 문자 세트에 관계없이 항상 사용할 수 있습니다.그래픽 문자 집합에는 포함되지 않을 수 있지만 다른 크기나 유형의 공백 문자가 포함될 [27]수 있습니다.

이스케이프 시퀀스의 일반적인 구문

ESC(에스케이프) 문자를 사용하는 시퀀스는 다음 형식을 취합니다.ESC [I...] FESC 문자 뒤에 0 이상의 중간[28] 바이트가 붙습니다( ).I0x20 ~ 0x2F 범위에서 마지막 바이트[29](F)의 범위는 0x30 ~0x7E [30]입니다.

첫 번째I바이트 또는 그 부재는 이스케이프 시퀀스의 유형을 결정합니다.예를 들어 작업 세트를 지정하거나 단일 제어 기능을 나타낼 수 있습니다.모든 종류의 탈출 장면에서F0x30 ~ 0x3F 범위의 바이트는 [31]당사자 간의 사전 합의에 의해 정의된 미등록 프라이빗 용도로 예약됩니다.

일부 세트의 제어 기능은 적절한 이스케이프 시퀀스에 이어 추가 바이트를 사용할 수 있습니다.예를 들어 ISO 6429 제어 함수 "Control Sequence Introcher"는 이스케이프 시퀀스를 사용하여 나타낼 수 있으며, 그 뒤에 0x30~0x3F 범위의 0바이트 이상, 0x20~0x2F 범위의 0x40~0x7E 범위의 1바이트가 이어지며 시퀀스 전체가 제어됩니다.[32]

그래픽 문자 세트

4개의 작업 세트 G0~G3 각각은 94 문자 세트 또는 94 문자n 멀티 바이트 세트입니다.또, G1 ~ G3 는 96 문자 또는 96n 문자 세트입니다.

96 문자 또는 96n 문자 집합에서는 GL 호출 시 0x20 ~0x7F 또는 GR 호출 시 0xA0 ~0xFF 바이트가 할당되어 세트에 의해 사용될 수 있습니다.94 문자 또는 94n 문자 집합에서는 0x20 및 0x7F 바이트는 [33]사용되지 않습니다.GL 영역에서 96 문자 또는 96n 문자 세트가 호출되면 [5]GL에서 94 문자 또는 94n 문자 세트(G0 세트 등)가 호출될 때까지 공백 문자 및 삭제 문자(코드 0x20 및 0x7F)를 사용할 수 없습니다.96 문자 세트를 G0으로 지정할 수 없습니다.

세트를 96 문자 세트로 등록한다고 해서 반드시 0x20/A0 및 0x7F/가 되는 것은 아닙니다.FF 바이트는 실제로 세트에 의해 할당됩니다.그래픽 문자 집합의 예로는 96 세트로 등록되어 있지만 이러한 바이트를 사용하지 않는 것이 있습니다.I.[34]S. 434의 G1 세트, ISO/IEC 10367[35]상자 그리기 세트, ISO-IR-164(ISO-8859-8의 G1 세트의 서브셋 중 [36]CCT만 사용됨) 등이 있습니다.

문자 조합

문자는 해당 그래픽 [37]세트에 의해 달리 지정되지 않는 한 문자를 조합하지 않고 공백 문자를 사용해야 합니다.ISO 2022 / ECMA-35는 백스페이스 및 캐리지 리턴 제어 문자를 CSI 시퀀스 "그래픽 문자 조합"(GCC)[37]과 조합하는 수단으로서도 인식하고 있습니다.CSI 0x20 (SP) 0x5F (_)를 참조해 주세요.[38]

이러한 방식으로 백스페이스와 캐리지 리턴을 사용하는 것은 ISO/IEC 646에서는 허용되지만 ISO/IEC 4873/ECMA-43[39]ISO/IEC [40][41]8859에서는 그래픽 문자 레퍼토리가 정의되지 않은 상태로 유지된다는 이유로 금지되어 있습니다.다만, ISO/IEC 4873/ECMA-43은, 문자의 순서가 같게 유지되어 다른 [42]의미를 가지는 문자를 형성하기 위해서 오버 스탬프 되는 것이 아니라, 1개의 스페이스에 표시되었을 경우, GCC 기능을 사용할 수 있습니다.

문자 집합 제어

제어 문자 세트는 각각 "C0" 및 "C1" 제어 코드 [44]세트라고도 하는 "기본" 또는 "보조" 제어 코드 [43]세트로 분류됩니다.

C0 제어 세트는 0x1B[45](ESC만을 포함하는 C0 세트는 ISO-IR-104로 [46]등록됨)에 ESC(에스케이프) 제어 문자를 포함해야 하지만 C1 제어 세트에는 이스케이프 제어가 전혀 포함되지 [33]않을 수 있습니다.따라서 C0 세트는 C0 세트만, C1 세트는 C1 [44]세트만 되는 완전히 별개의 등록입니다.

ISO 6429 / ECMA-48 의 C0 세트의 코드, 즉 ASCII 제어 코드가 C0 세트에 표시되는 경우는, ISO 6429 / ECMA-48 로케이션에 [45]표시할 필요가 있습니다.ISO 6429 / ECMA-48에 의해 포함된 10개 문자(즉, SOH, STX, ETX, EOT, ENQ, ACK, DLE, NAK, SYN 및 ETB)[47] 외에 C0 세트에 전송 제어 문자를 포함하거나, ISO1에 설정된 10개 문자를 포함하는 것도 금지됩니다.

C0 컨트롤 세트는 CL 범위 0x00~[48]0x1F에서 호출되며 C1 컨트롤 기능은 CR 범위 0x80~0x9F(8비트 환경에서)[43] 또는 이스케이프 시퀀스를 사용하여 호출할 수 있지만 둘 다 호출할 수 없습니다.사용되는 [49]C1 호출 스타일은 코드 버전의 정의에서 지정해야 합니다.예를 들어 ISO/IEC 4873은 사용하는 C1의 CR 바이트를 지정합니다(SS2 및 SS3).[50]필요에 따라서, 어느 호출이 사용되고 있는지를 아나운서 시퀀스를 사용해 전달할 수 있다.

후자의 경우, C1 제어 코드 세트의 단일 제어 함수는 "type Fe" 이스케이프 [33]시퀀스를 사용하여 호출됩니다.즉, ESC 제어 문자 뒤에 열 04 또는 05의 바이트가 이어지는 것을 의미합니다.ESC 0x40 (@)통해.ESC 0x5F (_)를 참조해 주세요.[51]

기타 제어 기능

추가 제어 기능은 "유형 F" 이스케이프 시퀀스에 할당됩니다(범위 내).ESC 0x60 (`)통해.ESC 0x7E (~)C0 또는 C1의 [51][52]지정에 의존하지 않고 영속적으로 할당된 의미를 가집니다."Fs" 시퀀스에 대한 제어 기능의 등록은 ISO/IEC JTC 1/SC [52]2의 승인을 받아야 합니다.다른 단일 제어 기능은 유형 "3Ft" 이스케이프 시퀀스에 등록할 수 있습니다(범위 내).ESC 0x23 (#) [I...] 0x40 (@)통해.ESC 0x23 (#) [I...] 0x7E (~)).[53] 단, 현재 할당된 "3Ft" 시퀀스는 없습니다(2019년 [54]기준).

단일 제어 [54]기능에 대해 다음 이스케이프 시퀀스가 할당됩니다.

코드 16진수 에이브러 이름. 영향
ESC ` 1B 60 DMI 수동 입력 사용 안 함 디바이스의 수동 입력 기능의 일부 또는 전부를 디세블로 합니다.
ESC a 1B 61 인트 방해하다 현재 프로세스를 중단합니다.
ESC b 1B 62 EMI 수동 입력 사용 디바이스의 수동 입력 기능을 유효하게 합니다.
ESC c 1B 63 RIS 초기 상태로 리셋 전원을 켜면 디바이스를 해당 상태로 리셋합니다.
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 우측 시프트 잠금 시프트 함수, 아래 참조.

타입 "Fp"의 이스케이프 시퀀스(ESC 0x30 (0)통해.ESC 0x3F (?)) 또는 타입 "3Fp" (ESC 0x23 (#) [I...] 0x30 (0)통해.ESC 0x23 (#) [I...] 0x3F (?))[55]는 당사자 간의 사전 합의에 따라 단일 개인 사용 관리 코드용으로 예약되어 있습니다.VT100 등의 DEC 단말기는 이러한 두 유형의 여러 시퀀스를 사용하며, 따라서 단말 [14]에뮬레이터에 의해 지원됩니다.

시프트 함수

기본적으로는 GL 코드는 G0 문자를 지정하고 GR 코드(사용 가능한 경우)는 G1 문자를 지정합니다.그렇지 않으면 사전 계약에 의해 지정될 수 있습니다.각 영역에 걸쳐 호출되는 세트는 아래 [56]표에 표시된 것처럼 시프트라고 하는 제어 코드를 사용하여 수정할 수도 있습니다.

8비트 코드에는 G1 문자를 지정하는 GR 코드, 즉 Shift InShift Out을 사용하여 세트 사이를 전환하는 GR 코드(들어 JIS X [57]0201)가 있을 수 있지만, 대신 G2 문자를 지정하는 GR 코드가 있으며, 이에 대응하는 7비트 코드는 2번째 TG에 대한 액세스(예를 들어 JIS X 0201)가 설정됩니다.

다음 표에 나타낸 코드는 ISO/IEC 6429에 준거한 가장 일반적인 제어 코드 인코딩입니다.그 LS2, LS3, LS1R, LS2R과 LS3R 전후 단독 제어 기능을 하고, 이 이스케이프 시퀀스 below,[54] C0또는 C1통제 부호(아래와 같이, SI(LS0)의 반면에 다른 사람들 일부이고 그래서(LS1)은 C0에 의한 통제와 SS2과 SS3이 C1컨트롤)상장 항상 암호화된 사람들은 코딩 및 가용성 d. 다를 수 있다는 의미로 등록됩니다.epending 어떤 제어 세트가 지정된 제어 세트에 해당 기능이 [48][49]사용되는 경우 해당 제어 세트가 반드시 있어야 합니다.C1 제어 자체는 위에서 설명한 바와 같이 이스케이프 시퀀스 또는8비트 바이트를 사용하여 나타낼 수 있지만 둘 다 사용할 수는 없습니다.

특정 제어 코드 세트에서는 C0 제어 코드로서 단일 시프트의 대체 인코딩을 사용할 수 있습니다.예를 들어, SS2와 SS3는 보통[58] T.51[59]T.61에서 각각 0x19와 0x1D로 사용할 수 있습니다.이 코딩은 현재 SS2 및 SS3의 [60]7비트 싱글바이트 표현을 필요로 하는 애플리케이션에 대해 ISO/IEC 2022/ECMA-35에 의해 권장되고 있으며, SS2에만 사용할 수도 [61]있습니다.단, SS2가 0x1C인 오래된 코드 세트도 존재하며,[62][63][64] 표준 [65]이전 버전에서와 같이 언급되었습니다.ISO/IEC 4873 레벨 2 및 [66]3에서는 아래와 같이 단일 시프트의 0x8E 및 0x8F 코딩이 필수입니다.

코드 16진수 에이브러 이름. 영향
SI 0F SI
LS0
Shift In(Shift In)
시프트 0 잠금
GL은 앞으로[67][68] G0을 인코딩합니다.
SO 0E 그렇게
LS1
시프트 아웃
시프트 1 잠금
GL은 앞으로[67][68] G1을 부호화한다.
ESC n 1B 6E LS2 잠금 시프트 2 GL은 앞으로[67][68] G2를 인코딩합니다.
ESC o 1B 6F LS3 잠금 시프트 3 GL은 앞으로[67][68] G3를 부호화한다.
CR 영역: SS2
이스케이프 코드: ESC N
CR 영역: 8E
이스케이프 코드: 1B 4E
SS2 1교대 2 GL 또는 GR(아래 참조)은 바로 다음 문자에[69] 대해서만 G2를 인코딩합니다.
CR 영역: SS3
이스케이프 코드: ESC O
CR 영역: 8F
이스케이프 코드: 1B 4F
SS3 1교대 3 GL 또는 GR(아래 참조)은 바로 다음 문자에[69] 대해서만 G3을 인코딩합니다.
ESC ~ 1B 7E LS1R 우측 시프트 잠금 GR은 앞으로[70] G1을 부호화한다.
ESC } 1B 7D LS2R 우측 시프트 2 잠금 GR은 앞으로[70] G2를 인코딩합니다.
ESC 1B 7C LS3R 시프트 3 우측 잠금 GR은 앞으로[70] G3를 부호화한다.

공식적으로 시프트 코드로 간주되어 그에 따라 명명되었지만, 싱글 시프트 코드는 항상 [12]시프트로 간주되지 않으며, 단순히 프리픽스 바이트(즉, 멀티바이트 [11]시퀀스의 첫 번째 바이트)로 간주될 수 있습니다.이는 잠금 시프트 코드와 달리 인코더가 현재 활성 상태를 유지할 필요가 없기 때문입니다.8비트 환경에서는 GL 또는 GR 중 하나를 단일 시프트 영역으로 사용할 수 있습니다.이것은 코드 [69]버전의 정의에서 지정해야 합니다.예를 들어 ISO/IEC 4873은 GL을 지정하고 패킹된 EUC는 GR을 지정합니다.7비트 환경에서는 GL만 단일 시프트 [71][72]영역으로 사용됩니다.필요에 따라서, 어느 1 시프트 영역이 사용되고 있는지를 아나운서 시퀀스를 사용해 통신할 수 있습니다.

"잠금 변속 0"(LS0) 및 "잠금 변속 1"(LS1)이라는 이름은 "shift in"(SI) 및 "shift out"(SO)이라는 이름과 동일한 C0 제어 문자 쌍(0x0F 및 0x0E)을 나타냅니다.단, 표준에서는 8비트 환경에서 사용되는 경우에는 LS0 및 LS1로, 7비트 [56]환경에서 사용되는 경우에는 SI 및 SO로 칭합니다.

ISO/IEC 2022/EMA-35 규격에서는 GL과 GR에서 [73]동시에 G1, G2 또는 G3를 호출하는 것은 허용되지만 권장되지는 않습니다.

그래픽 코드 세트 및 제어 코드 세트

이스케이프 시퀀스(ISO-IR)에 사용되는 부호화 문자 집합의 ISO 국제 레지스터는 ISO/IEC 2022에 사용하도록 등록된 그래픽 문자 집합, 제어 코드 집합, 단일 제어 코드 등을 나열합니다.ISO-IR 레지스트리에 코드 및 세트를 등록하는 절차는 ISO/IEC 2375에 의해 규정되어 있습니다.각 등록은 하나의 이스케이프 시퀀스와 이를 [74][75]식별하기 위한 하나의 레지스트리 엔트리 번호를 받습니다.예를 들어 간체 중국어용 CCITT 문자 집합은 ISO-IR-165로 알려져 있습니다.

ISO-IR 레지스트리에 코드화된 문자 세트를 등록함으로써 ISO/IEC 2022 비개인용 이스케이프 시퀀스와 관련된 문자 세트 또는 제어 기능을 지정하는 문서를 식별할 수 있다.이것은 표준 문서일 수 있습니다.다만, 등록에 의해서 새로운 ISO 표준이 작성되지 않고, ISO 또는 IEC가 국제 표준으로 채택되지 않으며, ISO 또는 IEC가 범용 코드 문자 집합[76]문자를 추가하지 않습니다.

ISO-IR 등록 이스케이프 시퀀스는 SGML(ISO 8879)의 문자 세트를 식별하기 위해서도 Formal Public Identifier에 캡슐화되어 사용됩니다.예를 들어 문자열은ISO 646-1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0ISO 646-1983의 [77]International Reference Version 식별에 사용할 수 있으며 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/6Unicode를 [78]식별합니다.FPI의 세 번째 요소에 포함된 이스케이프 시퀀스의 텍스트 표현은 지원되는 문자 [77]집합에 대한 SGML 구현에 의해 인식됩니다.

문자 집합 지정

문자 세트를 지정하는 이스케이프 시퀀스는 다음 형식을 취합니다.ESC I [I...] F상기와 같이 중간자(I) 바이트의 범위는 0x20 ~0x2F 입니다.최종 ( )F) 바이트의 범위는 0x30 ~0x7E 입니다.첫 번째I바이트(또는 멀티바이트 집합의 경우 처음 2개)는 문자 집합의 유형과 지정할 작업 집합을 나타냅니다.F바이트(및 기타)Ibytes)는 ISO-IR 레지스터에 할당되어 있는 문자 세트 자체를 식별합니다(또는 사전 계약에 의해 프라이빗 용도의 이스케이프 시퀀스에 대해서는).

추가의I바이트를 추가할 수 있습니다.F확장 바이트F바이트 범위이것은 현재 94자 집합에서만 사용되고 있습니다.여기서 폼의 코드는ESC ( ! F[79]할당되었습니다.한편, 멀티바이트 96-set은 등록되어 있지 않기 때문에, 다음의 시퀀스는 엄밀하게 이론적입니다.

다른 이스케이프 시퀀스유형과 마찬가지로 범위 0x30~0x3F는 프라이빗용으로 예약되어 있습니다.F바이트([31]이 경우, 개인용 문자 집합 정의의 경우, ARIB STD-B24[80] MARC-8 [3]등의 프로토콜에 의해 정의된 미등록 집합 [81]또는 DEC 특수 그래픽스 의 벤더 고유 집합이 포함될 수 있습니다).그러나 그래픽 세트 지정 순서에서 두 번째 항목은I바이트(싱글바이트 세트의 경우) 또는 세 번째I바이트(이중 바이트 집합의 경우)는 0x20(스페이스)입니다.이 세트는 사전 [82]계약에 의해 정의된 "Dynamically Redefinable Character Set"(DRCS; 동적으로 재정의 가능한 문자 집합)으로, 개인 [31]용도로도 간주됩니다.DRCS로 간주되는 그래픽 세트는 추상적인 문자 세트가 아니라 정확한 문자의 [83]글꼴을 나타낸다는 것을 의미합니다.DRCS 세트 및 관련 글꼴을 전송, 할당 및 관리하는 방법은 ISO/IEC 2022/EMA-35 자체에서 규정되어 있지 않습니다.다만, 다음의 순서로 할당하는 것을 추천합니다.F바이트 0x40 (@단,[84] DRCS 글꼴을 전송하는 방법은 World System Teletext[85]같은 일부 통신 프로토콜에 정의되어 있습니다.

또한 멀티바이트 코드에 대한 세 가지 특별한 경우가 있습니다.코드 시퀀스ESC $ @,ESC $ A,그리고.ESC $ B표준 버전의 최신 버전이 G0에서만 다중 바이트 집합을 허용했을 때 모두 등록되었으므로 시퀀스 대신 허용되어야 합니다.ESC $ ( @통해.ESC $ ( BG0 문자 [86]세트에 지정합니다.

스위칭 제어 문자 세트에는 (적게 사용되는) 추가 기능이 있습니다만, 이것은 싱글 레벨의 룩업입니다.즉, C0 세트는 항상 CL 경유로 호출되며, C1 세트는 항상 CR 경유 또는 이스케이프 코드를 사용하여 호출됩니다.위에서 설명한 바와 같이 C0 문자 집합에는 위치 0x1B에 ESC 문자가 포함되어 있어야 추가 변경이 가능합니다.제어 세트 지정 시퀀스(그래픽 세트와는 반대)는, 시퀀스내의 각 바이트가 [87]부호화의 부호 단위 사이즈에 패딩 되어 있는 한, ANSI 이스케이프 코드를 처리하는 것이 적절한 컨텍스트에서 ISO/IEC 10646(UCS/Unicode)내에서 사용할 수도 있다.

이스케이프 시퀀스 테이블I바이트 및 바이트가 수행하는 지정 또는 기타 기능은 [88]다음과 같습니다.

코드 16진수 에이브러 이름. 영향
ESC SP F 1B 20 F ACS 공지 코드 구조 사용되는 코드 피쳐(예: 작업 세트)를 지정합니다(아래 [89]참조). ESC SP L
(ISO 4873 레벨 1)
ESC ! F 1B 21 F CZD C0 지정 F사용할 [90]C0 제어 문자 세트를 선택합니다. ESC ! @
(ASCII C0 코드)
ESC " F 1B 22 F C1D C1-designate F는 C1제어 문자 사용될 예정을 선택합니다.[91] ESC " C
(ISO6429 C1코드)
ESC # F 1B 23 F - (단일 제어 기능) (제어 기능을 위해 시퀀스에, 위를 참조하십시오 예약되었습니다.). ESC # 6
(개인용:DEC더블 폭 선)[92].
  • ESC $ F[e]
  • ESC $ ( F
  • 1B 24 F[e]
  • 1B 24 28 F
GZDM4 G0-designatemultibyte 94-set F한 G0에 사용될 예정94n-character를 선택합니다.[86] ESC $ ( C
(KSX1001G0에).
ESC $ ) F 1B 24 29 F G1DM4 G1-designatemultibyte 94-set F는 G1에 사용될 예정94n-character를 선택합니다.[86] ESC $ ) A
(G1의 GB 2312)
ESC $ * F 1B 24 2A F G2DM4 G2 지정 멀티바이트94 세트 F는 G2에 [86]사용할94 문자n 세트를 선택합니다. ESC $ * B
(G2의 JIS X 0208)
ESC $ + F 1B 24 2B F G3DM4 G3 지정 멀티바이트94 세트 F는, G3 [86]에 사용하는94n 문자 세트를 선택합니다. ESC $ + D
(G3의 JIS X 0212)
ESC $ , F 1B 24 2C F - (미사용) (미사용)[f] -
ESC $ - F 1B 24 2D F G1DM6 G1 지정 멀티바이트96 세트 F는 G1에 [86]사용할96 문자n 세트를 선택합니다. ESC $ - 1
(개인용도)
ESC $ . F 1B 24 2E F G2DM6 G2 지정 멀티바이트96 세트 F는, G2 [86]에 사용할n 96 문자 세트를 선택합니다. ESC $ . 2
(개인용도)
ESC $ / F 1B 24 2F F G3DM6 G3 지정 멀티바이트96 세트 F는, G3 [86]에 사용할 96n 문자 세트를 선택합니다. ESC $ + 3
(개인용도)
ESC % F 1B 25 F DOCS 기타 코딩 시스템 지정 코드화 시스템을 전환합니다(아래 참조). ESC % G
(UTF-8)
ESC & F 1B 26 F 인스트 수정된 등록 확인 리비전을 [g]나타내는 프리픽스 지정 이스케이프. ESC & @ ESC $ B
(G0의 JIS X 0208:1990)
ESC ' F 1B 27 F - (미사용) (미사용) -
ESC ( F 1B 28 F GZD4 G0 지정 94 세트 F는, [86]G0 에 사용할 94 문자 세트를 선택합니다. ESC ( B
(G0의 ASCII)
ESC ) F 1B 29 F G1D4 G1 지정 94 세트 F는 G1에 [86]사용할94 문자 세트를 선택합니다. ESC ) I
(G1의 JIS X 0201 가나)
ESC * F 1B 2A F G2D4 G2 지정 94 세트 F는 G2에 [86]사용할94 문자 세트를 선택합니다. ESC * v
(G2의 ITU T.61 RHS)
ESC + F 1B 2B F G3D4 G3 지정 94 세트 F는, G3 [86]에 사용하는94 문자 세트를 선택합니다. ESC + D
(G3의 NATS-SEFI-ADD)
ESC , F 1B 2C F - (미사용) (미사용)[h] -
ESC - F 1B 2D F G1D6 G1 지정 96 세트 F는 G1에 [86]사용할96 문자 세트를 선택합니다. ESC - A
(G1의 ISO 8859-1 RHS)
ESC . F 1B 2E F G2D6 G2 지정 96 세트 F는, G2 [86]에 사용할 96 문자 세트를 선택합니다. ESC . B
(G2의 ISO 8859-2 RHS)
ESC / F 1B 2F F G3D6 G3 지정 96 세트 F는, G3 [86]에 사용할 96 문자 세트를 선택합니다. ESC / b
(G3의 ISO 8859-15 RHS)

의 레지스트리는F바이트는 다른 유형에 대해 독립적입니다.94글자의 그래픽 세트는ESC ( A통해.ESC + A는 에 의해 지정된96 문자 세트와는 전혀 관계가 없습니다.ESC - A통해.ESC / A이 중 어느 것도 에 의해 지정된94 문자n 집합과는 관련이 없습니다.ESC $ ( A통해.ESC $ + A마지막 바이트는 컨텍스트에서 해석해야 합니다.(실제로 중간 바이트가 없으면ESC A는 C1 제어 코드 0x81 을 지정하는 방법입니다).

또한 C0 및 C1 제어 문자 세트는 독립적이며 C0 제어 문자 세트는 에 의해 지정됩니다.ESC ! A(우연히 신문 텍스트 전송용으로 설정된NATS 컨트롤 세트)는, 에 의해서 지정된 C1 컨트롤 문자 세트와는 다릅니다.ESC " A(VideotexCCITT 속성 제어 세트).

다른 코딩 시스템과의 상호작용

이 표준은 또한 자체 구조를 따르지 않는 코딩 시스템을 규정하는 방법을 정의합니다.

ISO/IEC 2022로 돌아가기 위한 시퀀스도 정의됩니다. ISO/IEC 2022에서 인코딩된 이 시퀀스를 지원하는 등록은 다양한 Videotex 형식, UTF-8[96]UTF-1로 구성됩니다.I0x2F 바이트 (/)는 ISO 2022로 돌아가기 위해 해당 바이트 시퀀스를 사용하지 않는 코드 지정 시퀀스에 포함되어 있습니다.코드에는 ISO 2022로 돌아가기 위한 자체 수단(다른 시퀀스 또는 패딩 시퀀스 등)[97]이 있거나 전혀 없습니다.후자 유형의 모든 기존 등록(2019년 기준)은 투명한 원시 데이터, 유니코드/UCS 형식 또는 하위 [98]집합입니다.

코드 16진수 에이브러 이름. 영향
ESC % @ 1B 25 40 DOCS 기타 코딩 시스템("표준 반환") 지정 다른 [97]인코딩에서 ISO/IEC 2022로 돌아갑니다.
ESC % F 1B 25 F 기타 코딩 시스템 지정("표준 [96]반품 포함") F8비트 코드를 선택합니다.ESC % @되돌아가다[97]
ESC % / F 1B 25 2F F 다른 부호화 체계("표준 수익 없이")[98]자를 지정하라. F; 어떠한 표준 방식을 돌려주는 것임을 8비트 코드를 선택합니다.[97]
ESC d 1B 64 CMD 부호화 방식 구분 기호 한ISO/IEC 2022년 코드화 시퀀스의 끝 Denotes.[99]

특별한 관심은ISO/IEC 2022년 구조를 따르지 않는/IEC10646(유니 코드)형식으로 스위치 배열이 있다.이러한 UTF-8(는 제어 문자의 한도 0x80–0x9F을 예약하지 않는다), 그의 선배 UTF-1(는multi-byte 코드에서 GR과 GL바이트가 공존), 16과 UTF-32(는 더 넓은 코딩 장치를 사용한다)을 포함한다.[96][98]

UTF-8, UTF-16 및 UTF-32의 서브셋(레벨 1 및 2) 및 UCS-2의 3가지 [98]레벨에 대해서도 몇 가지 코드가 등록되었습니다.단, 현재 ISO/IEC 10646에서 지정되어 있는 코드는 UTF-8, UTF-16 및 UTF-32의 레벨 3 코드와 UTF-8의 미지정 레벨 코드뿐이며, 나머지는 폐지된 것으로 [100]기재되어 있습니다.ISO/IEC 10646에서는 UTF-16 및 UTF-32의 빅엔디안 포맷은 이스케이프 [101]시퀀스에 의해 지정되도록 규정되어 있습니다.

유니코드 형식 코드 16진수[100] 폐지된 코드 권장되지[96][98][100] 않는 16진수
UTF-1 (현재 ISO/IEC 10646에는 UTF-1이 없습니다.) ESC % B 1B 25 42
UTF-8 ESC % G,
ESC % / I
1B 25 47,[13]
1B 25 2F 49[102]
ESC % / G,
ESC % / H
1B 25 2F 47,
1B 25 2F 48
16 ESC % / L 1B 25 2F 4C[103] 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

UTF-8로 전환되는 시퀀스 중ESC % G예를 들어 [14]xterm에 의해 지원되는 것입니다.

UTF-16 및 UTF-32로부터의 표준 리턴 시퀀스의 배리언트 사용은 허용되지만, 이스케이프 시퀀스의 바이트는 부호화의 코드 유닛의 사이즈에 맞추어 패딩할 필요가 있습니다(즉,001B 0025 0040UTF-16)의 경우, 즉 표준 반환 시퀀스의 부호화가 ISO/IEC 2022에 정확히 부합하지 않는다.따라서 UTF-16 및 UTF-32 지정에서는 without-standard-return [104]구문을 사용합니다.

코드 구조 발표

「Announce code structure」시퀀스(ESC SP (0x20) F)는 특정 코드 구조 또는 특정 코드 버전에서 사용되는 ISO 2022 퍼실리티의 특정 그룹을 알리기 위해 사용됩니다.공고를 조합할 수 있지만, ISO/IEC 4873 수준 공고 12-14[89] 에 추가 공고를 사용하는 것과 마찬가지로 특정 모순된 조합(특히, 공고 1, 3, 4와 함께 잠금 교대 공고를 사용하는 것)은 표준에 의해 금지된다.아나운스 시퀀스는 다음과 같습니다.

번호 코드 16진수 코드 버전 기능[89] 발표
1 ESC SP A 1B 20 41 GL의 G0, GR 부재 또는 미사용, 잠금 이동 없음.
2 ESC SP B 1B 20 42 G0 및 G1은 잠금 시프트에 의해 GL로 호출되며 GR이 없거나 사용되지 않습니다.
3 ESC SP C 1B 20 43 GL의 G0, GR의 G1, 잠금 시프트가 없는 경우 8비트 환경이 필요합니다.
4 ESC SP D 1B 20 44 GL의 G0, GR의 G1(8비트인 경우), 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 C1은 8비트 환경의 CR 영역에서 제어하며, 그렇지 않은 경우에는 이스케이프 시퀀스로 제어합니다.
8 ESC SP H 1B 20 48 94 문자의 그래픽 세트만.
9 ESC SP I 1B 20 49 94 문자 및/또는 96 문자 그래픽 세트.
10 ESC SP J 1B 20 4A 8비트를 사용할 수 있는 경우에도 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 LS1R은 8비트 환경에서 사용되며, 따라서 7비트 환경에서 사용됩니다.
20 ESC SP T 1B 20 54 LS2가 사용되었습니다.
21 ESC SP U 1B 20 55 LS2R은 8비트 환경에서 사용되고 LS2는 7비트 환경에서 사용됩니다.
22 ESC SP V 1B 20 56 LS3 사용.
23 ESC SP W 1B 20 57 LS3R은 8비트 환경에서 사용되고 LS3는 7비트 환경에서 사용됩니다.
26 ESC SP Z 1B 20 5A SS2 사용.
27 ESC SP [ 1B 20 5B SS3 사용.
28 ESC SP \ 1B 20 5C 단일 시프트는 GR을 통해 호출됩니다.

ISO/IEC 2022 코드 버전

(A screenshot of an old version of Firefox showing Big5, GB 2312, GBK, GB 18030, HZ, ISO-2022-CN, Big5-HKSCS, EUC-TW, EUC-JP, ISO-2022-JP, Shift_JIS, EUC-KR, UHC, Johab and ISO-2022-KR as available encodings under the CJK sub-menu.)
2004년 현재 Mozilla Firefox에서 지원되는 다양한 ISO 2022 및 기타 CJK 인코딩(이 지원은 특정 사이트 간 스크립팅 공격을 방지하기 위해 이후 버전에서 감소되었습니다.)

6개의 7비트 ISO 2022 코드버전(ISO-2022-CN, ISO-2022-CN-EXT, ISO-2022-JP-1, ISO-2022-JP-2 및 ISO-2022-KR)은 ISO-20PJ의 IETF RFC에 의해 정의되어 있습니다.IBM을 [106]비롯한 여러 다른 변종들이 공급업체에 의해 정의됩니다.HTML5에서 UTF-8은 선호되는 인코딩, ISO-2022-JP에 유산 콘텐츠가 충분하게 그 WHATWG 인코딩 표준하 it,[107]에 ISO-2022-KR, ISO-2022-CN과 ISO-2022-CN-EXT[108]교체 character,[109]cros과 같은 코드 주입 공격에 대한 우려 때문에 전혀 사상과는 대조적으로 지원 광범위하게 퍼져 있다.s-site scripting.[107][109]

8비트 코드 버전에는 확장 UNIX [11][12]코드가 포함되어 있습니다.ISO/IEC 8859 인코딩도 ISO/IEC 4873에 규정된 [9][10]하위 집합에서 ISO 2022를 따릅니다.

일본어판 이메일

ISO-2022-JP

ISO-2022-JP는 일본어, 특히 이메일에서 널리 사용되는 부호화입니다.JUNET 네트워크에서 사용하기 위해 도입되어 나중에 IETF RFC 1468(1993년)[110]에 코드화되어 있습니다.8비트의 클린 전송이 필요 없다는 점에서 다른 일본어 인코딩에 비해 유리하다.마이크로소프트는 이것을 코드 페이지 50220이라고 [111]부른다.ASCII로 시작하여 다음 이스케이프 시퀀스를 포함합니다.

JIS X 0208~1990에 부가된 두 문자를 사용할 수 있지만 IR 시퀀스를 포함하지 않고 즉 JIS X 0208~[110]1983과 동일한 이스케이프 시퀀스를 사용한다.또한 G0 이외의 멀티바이트 세트를 지정하기 전에 등록되었기 때문에 JIS X 0208의 이스케이프에는 두 번째가 포함되어 있지 않습니다.I-바이트(를 클릭합니다.[86]

RFC에서는 일부 기존 시스템이 이 시스템을 구별하지 못했다고 기술하고 있습니다.ESC ( B부터ESC ( J, 또는 구별하지 않음ESC $ @부터ESC $ B단, E-메일 [110]등의 메시지를 단순히 중계하는 시스템에 의해 이스케이프 시퀀스를 변경하지 않도록 규정되어 있습니다.HTML5에 의해 참조되는 WHATWG 인코딩 규격은ESC ( B그리고.ESC ( J분명히, 하지만 대접은ESC $ @와 같은ESC $ B디코딩 시 및 사용만ESC $ BJIS X 0208의 경우.[112]또한 RFC에서는 일부 과거의 시스템이 이 시퀀스를 잘못 사용했음을 나타내고 있습니다.ESC ( H실제로는 ISO-IR-11(ISO 646 World System Text의 스웨덴 [110][i]버전)에 등록되어 있는 JIS X 0208에서 전환합니다.

반폭 가타카나 버전

사용방법ESC ( IJIS X 0201-1976 가나 세트로 전환하기(문자당 1바이트)는 ISO-2022-JP [110]프로파일의 일부가 아니지만 사용되는 경우도 있습니다.Python은 ISO-2022-JP-EXT(아래 설명과 같이 JIS X 0212를 통합하여 EUC-JP 커버리지를 완성함)[113][114]라는 라벨을 붙이는 변종에서 그것을 허용합니다.이것은 이름과 구조 모두에서 DEC에 의해 ISO-2022-JPext로 명명된 인코딩에 가깝고, 더 나아가 2바이트 사용자 정의 영역을 추가합니다.ESC $ ( 0Super DEC [115]Kanji의 커버리지가 완성되었습니다.WHATWG/HTML5 배리언트에서는 ISO-2022-JP 입력으로 JIS X 0201 가타카나를 디코딩할 수 있지만 인코딩 [112]시 문자를 JIS X 0208과 동등한 문자로 변환합니다.Microsoft의 ISO-2022-JP 코드 페이지(JIS X 0201 가나 추가 허용)는 코드 페이지 50221입니다.[111]

JIS7JIS8로 알려진 다른 변형은 JIS X 0201에 의해 정의된7비트 및 8비트 인코딩을 직접 기반으로 하며 각각 [116]Shift Out Shift In을 사용하거나 8비트(GR 호출)를 설정하는 이스케이프 시퀀스 없이 G1에서 JIS X 0201 kana를 사용할 수 있습니다.이러한 기능은 널리 [116]사용되지 않습니다.확장 8비트 JIS X 0201에서의 JIS X 0208 지원은 Shift JIS를 통해 실현됩니다.Shift Out 및 Shift In을 통해 싱글 바이트 가타카나를 사용하는 JIS X 0201 기반 ISO 2022의 마이크로소프트 코드 페이지는 코드 페이지 50222입니다.[111]

ISO-2022-JP-2

ISO-2022-JP-2는 ISO-2022-JP의 다국어 확장으로 RFC 1554(1993년 날짜)에 정의되어 있습니다.이것에 의해, ISO-2022-JP 에 가세해 다음의 이스케이프 시퀀스를 사용할 수 있습니다.ISO/IEC 8859 부품은 G0으로 지정할 수 없는96 문자 세트이며, G2에서 싱글 시프트 코드 SS2의 [117]7비트 이스케이프 시퀀스 형식을 사용하여 액세스합니다.

JIS X 0212의 ISO-2022-JP-2를 사용한 ISO-2022-JP는 이후 [118]1997년 RFC 2237에 의해 ISO-2022-JP-1로 명명되었습니다.

IBM 일본어 TCP

IBM은 일본어를 위한 9개의 7비트 ISO 2022 기반 인코딩을 구현하고 있으며, 각각은 IBM-956, IBM-957, IBM-952, IBM-5053, IBM-5054, IBM-5055 및 ISO-2022-JP의 서로 다른 이스케이프 시퀀스를 사용합니다. 각 시퀀스는 "TCIP"로 통칭됩니다.CCSID 9148은 표준(RFC 1468) ISO-2022-JP입니다.[120]

IBM의 ISO-2022-JP 버전
코드 페이지 / CCSID ACRI 정의 번호 ACRI[106] 이스케이프 시퀀스
956[121] TCP-01
  • ESC ( J(JIS X 0201 로마어)
  • ESC $ ( B(JIS X 0208, 1983+, 롱 이스케이프 시퀀스)
  • ESC $ I(JIS X 0201 가타카나)
  • ESC $ ( D
957[122] TCP-02
  • ESC ( J(JIS X 0201 로마어)
  • ESC $ ( @(JIS X 0208, 1978, 롱 이스케이프 시퀀스)
  • ESC $ I(JIS X 0201 가타카나)
  • ESC $ ( D(JIS X 0212)
958[123] TCP-03
  • ESC ( A(ASCII)
  • ESC $ ( B(JIS X 0208, 1983+, 롱 이스케이프 시퀀스)
  • ESC $ I(JIS X 0201 가타카나)
  • ESC $ ( D(JIS X 0212)
959[124] TCP-04
  • ESC ( A(ASCII)
  • ESC $ ( @(JIS X 0208, 1978, 롱 이스케이프 시퀀스)
  • ESC $ I(JIS X 0201 가타카나)
  • ESC $ ( D(JIS X 0212)
5052[125] TCP-05
  • ESC ( J(JIS X 0201 로마어)
  • ESC $ B(JIS X 0208, 1983+)
  • ESC $ I(JIS X 0201 가타카나)
  • ESC $ ( D(JIS X 0212)
5053[126] TCP-06
  • ESC ( J(JIS X 0201 로마어)
  • ESC $ @(JIS X 0208, 1978)
  • ESC $ I(JIS X 0201 가타카나)
  • ESC $ ( D(JIS X 0212)
5054[127] TCP-07
  • ESC ( A(ASCII)
  • ESC $ B(JIS X 0208, 1983+)
  • ESC $ I(JIS X 0201 가타카나)
  • ESC $ ( D(JIS X 0212)
5055[128] TCP-08
  • ESC ( A(ASCII)
  • ESC $ @(JIS X 0208, 1978)
  • ESC $ I(JIS X 0201 가타카나)
  • ESC $ ( D(JIS X 0212)
9148[120] TCP-16
  • ESC ( A(ASCII)
  • ESC ( J(JIS X 0201 로마어)
  • ESC $ @(JIS X 0208, 1978)
  • ESC $ B(JIS X 0208, 1983+)

JIS X 0213

2000년에 처음 공개된 JIS X 0213 규격에서는 ISO-2022-JP-3이라는 이름의 ISO-2022-JP-2 확장자를 사용하지 않고 ISO-2022-JP 업데이트버전을 정의하고 있습니다.JIS X 0213이 베이스 JIS X 0208 규격과 비교하여 추가된 결과, 새로운 JIS 평면 1에 대한 신규 등록이 이루어졌고, 새로운 평면 2는 자체 등록을 받았다.2004년판 표준의 플레인 1에 추가된 추가 등록은 ISO-2022-JP-2004라고 불리는 프로파일의 추가 개정판에 추가되었다.기본적인 ISO-2022-JP 지정 코드와 더불어, 다음의 지정이 인정되고 있습니다.

기타 7비트 버전

ISO-2022-KR은 RFC 1557(1993년)[129]에 정의되어 있습니다.ASCII 및 KS X 1001-1987([130][131]이전 이름은 KS C 5601-1987)의 한글 더블바이트 KS X 1001-1992를 인코딩합니다.ISO-2022-JP-2와는 달리 Shift Out Shift In 문자를 사용하여 다음 중 하나를 선택한 후 전환합니다.ESC $ ) CKS X 1001을 [129]G1로 지정한다.

ISO-2022-CNISO-2022-CN-EXT는 1996년 RFC 1922에 정의되어 있습니다.이들은 Shift Out 및 Shift In 기능(G0 및 G1 간 전환)을 모두 사용하는 7비트 인코딩이며, 싱글 시프트 기능 SS2 및 SS3의 7비트 이스케이프 코드 형식(G2 및 [132]G3에 액세스하기 위해)입니다.이들은 GB 2312(간체 중국어) 및 CNS 11643(번체 중국어) 문자 집합을 지원합니다.

기본 ISO-2022-CN 프로파일에서는 G0(shift in) 세트로 ASCII가 사용되며 GB 2312와 CNS 11643의 첫 번째 2개의 플레인도 포함됩니다(이들2개의 플레인은 공통 Big5의 모든 번체 한자를 나타내기에 충분하기 때문에 RFC는 부록에 대응하고 있습니다).[132]

  • ESC $ ) AGB 2312-1980(문자당 2바이트)으로 전환 [G1 지정]
  • ESC $ ) GCNS 11643-1992 플레인1(문자당 2바이트)로 전환하다[G1 지정]
  • ESC $ * HCNS 11643-1992 플레인2(문자당 2바이트)로 전환하다[G2 지정]

ISO-2022-CN-EXT 프로파일은 다음과 같은 추가 세트와 [132]플레인을 허용합니다.

  • ESC $ ) EISO-IR-165(문자당 2바이트)로 전환하다[G1 지정]
  • ESC $ + ICNS 11643-1992 플레인3(문자당 2바이트)으로 전환하다[G3 지정]
  • ESC $ + JCNS 11643-1992 플레인4(문자당 2바이트)로 전환하다[G3 지정]
  • ESC $ + KCNS 11643-1992 플레인5(문자당 2바이트)로 전환하다[G3 지정]
  • ESC $ + LCNS 11643-1992 플레인6(문자당 2바이트)으로 전환하다[G3 지정]
  • ESC $ + MCNS 11643-1992 플레인7(문자당 2바이트)로 전환하다[G3 지정]

ISO-2022-CN-EXT 프로파일에는 추가 Guobiao 표준 그래픽세트가 허용되지만 등록된 ISO 2022 이스케이프 [132]시퀀스에 따라 달라집니다.

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

다음 문자ESC(싱글 바이트 문자 집합의 경우) 또는ESC $(멀티바이트 문자 집합의 경우) 에 지정된 문자 집합 및 작업 집합의 유형을 지정합니다.위의 예에서 캐릭터는((0x28)은 94 문자 세트를 G0 문자 세트에 지정합니다.),*또는+(0x29~0x2B)는 G1~G3 문자 세트를 지정합니다.

ISO-2022-KR 및 ISO-2022-CN은 ISO-2022-JP보다 사용 빈도가 낮으며 보안상의 문제로 인해 의도적으로 지원되지 않을 수 있습니다.를 수매 clien 사이에 지원 부호화의 차이가 이용하여 특정이 스크립트와 관련 공격을 막기 위해, 특히, WHATWG 인코딩 표준 HTML5매핑 ISO-2022-KR, ISO-2022-CN과 ISO-2022-CN-EXT(뿐만 아니라 HZ-GB-2312)이는 대체 문자(�)모든 입력 모두 그"교체"decoder,[108]에 익숙해 있다.옆은d서버[109]ISO-2022-JP 및 UTF-16에도 동일한 보안상의 문제(ASCII 바이트의 시퀀스를 다르게 해석할 수 있음)가 적용되지만 전개된 [107]콘텐츠에서 훨씬 더 자주 사용되고 있기 때문에 이 처리를 할 수 없었습니다.

ISO/IEC 4873

ECMA-43(ISO/IEC 4873) 에디션과 레벨, EUC와의 관계.

8비트 싱글바이트 인코딩에 적용되는 ISO 2022의 서브셋은 ISO/IEC 4873에 의해 정의되며 ECMA-43으로도 발행됩니다.ISO/IEC 8859는 ISO/IEC 4873(또는 ECMA-43) 레벨 1의 [9][10]8비트 코드를 정의합니다.

ISO/IEC 4873/EMA-43 에서는,[133] 다음의 3 레벨의 부호화가 정의되고 있습니다.

  • 레벨 1: C0 세트, ASCII G0 세트, 옵션의 C1 세트 및 옵션의 싱글 바이트(94 문자 또는 96 문자) G1 세트를 포함합니다.G0은 GL을 통해 호출되며 G1은 GR을 통해 호출됩니다.시프트 기능은 사용할 수 없습니다.
  • 레벨 2: 필수 G1 세트와 더불어 (94 문자 또는 96 문자)싱글 바이트 G2 및/또는 G3 세트를 포함합니다.단일 변속 기능 SS2 및 SS3만 허용되며(즉, 잠금 변속은 금지됨), GL 영역(96 세트의 경우 0x20 및 0x7F 포함)에서 호출됩니다.SS2와 SS3는 각각 0x8E와 0x8F의 C1에서 사용할 수 있어야 합니다.ISO 4873에 필요한 최소한의 C1 세트는 ISO-IR-105로 [66]등록됩니다.
  • 레벨 3: 싱글 시프트에 더해 GR 잠금 시프트 기능 LS1R, LS2R 및 LS3R이 허용되지만 그 이외의 경우에는 레벨 2와 같은 제한이 있습니다.

이전 버전의 표준에서는 ISO/IEC 646 불변 위치가 유지되고 다른 위치가 공백(결합되지 않음) 문자에 할당되며 0x23이 £ 또는 #에 할당되며 0x24가 $ 또는 [134]에 할당되는 경우 G0 세트에 ASCII 이외의 할당이 허용되었습니다.예를 들어 JIS X 0201의 8비트 부호화는 이전 버전에 준거하고 있습니다.이후 ISO/IEC 646:1991 IRV/ISO-IR No.6 세트(ASCII)[135][136][137]를 완전히 지정하도록 변경되었습니다.

C1 또는 G1이 설정되지 않은 ISO/IEC 4873 레벨1에서 ISO/IEC 646 IRV(1991년 이후 ASCII와 동기화됨)를 사용하는 것, 즉 시프트 코드가 사용되지 않고 하이비트가 항상 제로인 8비트 환경에서 IRV를 사용하는 것을 ISO 4873 DV(디폴트 버전)라고 합니다.

중복된 문자를 다른 세트로 사용할 수 있는 경우 ISO/IEC 4873/ECMA-43의 현재 버전은 이러한 문자가 [139]표시되는 가장 작은 번호의 작업 집합에서만 사용할 수 있습니다.예를 들어, G1 세트와 G3 세트 모두에 문자가 표시되는 경우는, G1 세트로부터 사용할 필요가 있습니다.그러나 다른 집합의 사용은 이전 [137]판에서 허용된 것으로 기록된다.

ISO/IEC 8859는 ISO/IEC 4873의 레벨 1에서 완전한 인코딩을 정의하며 여러 ISO/IEC 8859 부품을 함께 사용할 수 없습니다.ISO/IEC 4873의 레벨 2와 레벨 3에는 ISO/[9][10]IEC 10367을 사용해야 한다고 규정되어 있습니다.ISO/IEC 10367:1991은 ISO/IEC 8859의 처음 9개 파트에서 사용한 것과 일치하는 G0 및 G1 세트와 일부 보조 [140]세트를 포함한다.

문자 집합 지정 이스케이프 시퀀스는 추가 프로토콜에 의해 요구되는 경우에만 정보 교환 중에 버전을 식별하거나 전환하기 위해 사용됩니다. 이 경우 표준에는 ISO/IEC 4873 레벨을 지정하는 ISO/IEC 2022 아나운서 시퀀스가 필요하며, 그 뒤에 문자 집합 지정자를 지정하는 완전한 이스케이프 시퀀스가 필요합니다.C0, C1, G0, G1, G2 및 G3에 대한 이온(단, 레벨 1에 대한 G2 및 G3 지정 제외),F0x7E 바이트는 빈 세트를 나타냅니다.각 ISO/IEC 4873 레벨에는 다음과 [141]같은 단일 ISO/IEC 2022 아나운서 시퀀스가 있습니다.

코드 16진수 알리다
ESC SP L 1B 20 4C ISO 4873 레벨 1
ESC SP M 1B 20 4D ISO 4873 레벨 2
ESC SP N 1B 20 4E ISO 4873 레벨 3

확장 UNIX 코드

Extended Unix Code(EUC; 확장유닉스 코드)는 주로 일본어, 한국어중국어 간체용으로 사용되는 8비트 가변폭 문자 인코딩 시스템입니다.ISO 2022를 기반으로 하며 ISO 2022 구조를 준수하는 문자 집합만 EUC 형식을 가질 수 있습니다.최대 4개의 코드화된 문자 세트를 나타낼 수 있습니다(G0, G1, G2 및 G3).G0 세트는 GL을 통해 호출되고, G1 세트는 GR을 통해 호출되며, G2 세트와 G3 세트는 각각 CR 바이트(즉, 0x8E 및 0x8F)로 사용되며, GR을 통해 호출됩니다(GL이 [11]아님).잠금 시프트 코드는 [12]사용되지 않습니다.

G0 세트에 할당된 코드는 ASCII 또는 KS-Roman(KS X 1003) 또는 JIS-Roman(JIS X 0201[11]하반부)과 같은 국가의 ISO 646 문자 집합입니다.따라서 EUC-JP 일부 버전에서는 0x5C(US-ASCII에서는 백슬래시)가 Yen 부호를 나타내며 EUC-KR 일부 버전에서는 Won 부호를 나타냅니다.

G1은 2바이트로 표시되는 94x94 부호화 문자 세트에 사용됩니다.이러한 2바이트 EUC 코드의 예는 GB 2312 및 EUC-KR의 EUC-CN 형식입니다.EUC-JP에는 최대 3바이트(SS3+2바이트)로 표시되는 문자가 포함되어 있습니다만, EUC-TW에서는 1개의 문자가 최대 4바이트(SS2+3바이트)를 차지할 수 있습니다.

EUC 코드 자체는 ISO 2022의 아나운서 또는 지명 시퀀스를 사용하지 않지만,[142] 다음과 같이 세분화된 의미를 갖는 4개의 아나운서 시퀀스의 다음 시퀀스에 대응합니다.

개별 시퀀스 16진수 EUC의 특징
ESC SP C 1B 20 43 ISO-8(8비트, GL의 G0, GR의 G1)
ESC SP Z 1B 20 5A SS2를 사용하여 G2에 액세스
ESC SP [ 1B 20 5B SS3를 사용하여 G3에 액세스
ESC SP \ 1B 20 5C GR을 통한 단일 교대 호출

다른 인코딩과의 비교

이점

  • ISO/IEC 2022의 모든 범위의 그래픽 문자 인코딩이 GL을 통해 호출될 수 있기 때문에 7비트 인코딩으로 제한된 시스템처럼 GR 및 C1을 나타낼 수 없다고 해서 사용 가능한 문자 인코딩이 크게 제한되지는 않습니다.따라서 이러한 시스템에서 큰 문자 집합을 표현할 수 있습니다.일반적으로 이 7비트 호환성은 오래된 시스템과의 하위 호환성을 제외하고는 그다지 좋은 점이 아닙니다.현대 컴퓨터의 대부분은 각 바이트당 8비트를 사용합니다.
  • ISO/IEC 2022는 유니코드와 달리 시퀀스 코드를 사용하여 동아시아 언어의 이산 부호화를 전환함으로써 한 통일을 회피한다.이렇게 하면 단일 문서 및 글꼴에서 여러 CJK 언어를 지원하는 데 어려움이 있는 것과 같은 통일과 관련된 문제를[citation needed] 피할 수 있습니다.

단점들

  • ISO/IEC 2022는 스테이트풀 인코딩이기 때문에 프로그램은 텍스트 블록의 중간에 들어가 문자를 검색, 삽입 또는 삭제할 수 없습니다.따라서 스테이트풀하지 않은 인코딩에 비해 텍스트 조작이 매우 번거롭고 느립니다.텍스트 중간에 점프를 하면 이스케이프 시퀀스에 이은 바이트를 해석하기 전에 이전 이스케이프 시퀀스로의 백업이 필요할 수 있습니다.
  • ISO/IEC 2022의 스테이트풀 특성으로 인해 동일하고 동등한 문자를 다른 문자 세트로 인코딩할 수 있으며, G0에서 G3까지의 임의의 문자로 지정할 수 있으며, GL 또는 GR에 대한 잠금 시프트를 사용하여 호출할 수 있습니다.따라서 문자를 여러 가지 방법으로 표현할 수 있으며, 이는 시각적으로 동일하고 동등한 2개의 문자열을 확실하게 비교할 수 없음을 의미한다.
  • DICOM 및 여러 전자 메일 클라이언트와 같은 일부 시스템에서는 다른 여러 [144]인코딩을 지원할 뿐만 아니라 ISO-2022(예: "ISO 2022 IR 100")[143]를 사용합니다.이러한 유형의 변화는 컴퓨터 시스템 간에 텍스트를 이동하기 어렵게 만듭니다.
  • UTF-1은 ISO/IEC 2022의 8비트 제어 문자의 표현과 호환되는 멀티바이트 유니코드 변환 형식이며 UTF-8과 비교하여 다양한 단점을 가지고 있으며, ISO/IEC 2022에서 지원되는 다른 문자 집합과의 전환은 일반적으로 유니코드 문서에서 필요하지 않습니다.
  • 이스케이프 시퀀스를 통해 Unicode로 디코딩될 때까지 악의적인 문자열(사이트 간 스크립팅 등)이 마스크되어 위생을 [145]우회할 수 있는 공격 바이트시퀀스를 구축할 수 있습니다.따라서 이 인코딩 사용은 멀웨어 보호 [146][better source needed]스위트에서는 의심스러운 것으로 간주되며 공격을 [108][109]방지하기 위해 7비트 ISO 2022 데이터(ISO-2022-JP 제외) 전체가 HTML5대체 문자에 매핑됩니다.확장 UNIX 코드와 같이 지정 이스케이프 또는 잠금 시프트 코드를 사용하지 않는 제한된 ISO 2022 8비트 코드 버전은 이 문제를 공유하지 않습니다.
  • 연결 시 문제가 발생할 수 있습니다.ISO-2022-JP 등의 프로파일은 스트림이 ASCII 상태로 시작하여 ASCII 상태로 [110]종료되도록 지정합니다.이는 연결된 ISO-2022-JP 및/또는 ASCII 스트림의 문자가 올바른 집합으로 해석되도록 하기 위해 필요합니다.이로 인해 멀티바이트 문자로 끝나는 스트림이 멀티바이트 문자로 시작하는 스트림을 연결하면 ASCII로 전환되고 즉시 분리되는 이스케이프 코드 쌍이 생성됩니다.단, Unicode Technical Report #36("Unicode Security 고려사항")에서 규정하는 바와 같이 ISO 2022 이스케이프 시퀀스 쌍 사이에 문자가 없는 경우 사이트 [147]스크립팅 등의 악의적인 시퀀스를 마스킹하기 위해 대체 문자("")를 생성해야 합니다.예를 들어 Mozilla Thunderbird에서 이 조치를 구현하면 2개의 ISO-2022-JP 스트림이 [145]연결된 곳에서 예기치 않은 """ 문자가 생성되는 상호 운용성 문제가 발생합니다.

「 」를 참조해 주세요.

각주

  1. ^ 일본어: roman, 로마자: kuten, 중국어: y pin, pinyin: ū;, 한국어: ū han, 한자: ū rr, RR: 행렬
  2. ^ 일본어: ,, 로마자: ku, litted. 'zone', 중국어: ū, pinyin: qu, 한국어: ;, 한자: ;, RR: hang
  3. ^ 일본어: ,, 로마자: 10, light. '', 중국어: ;, pinyin: wyi, light.'포지션'; 한국어: ;; 한자: ;; RR:
  4. ^ 일본어: ,, 로마자: men, light. '얼굴'
  5. ^ a b 지정 대상F바이트 수 0x40 (@, 0x41 (A및 0x42 ( )B)만, 이력상의 [86]이유로 합니다.SoftBank 2G 이모티콘 인코딩과 같은 일부 구현에서는 ISO-2022에 준거하지 않는 목적으로 [93]이 폼의 이스케이프를 추가로 사용합니다.
  6. ^ MARC-8[3]의해 리스트 됩니다.각주를 참조해 주세요.ESC , F아래를 참조해 주세요.
  7. ^ F는, 1 ~ 63 의 범위로 조정됩니다.즉각적으로 호환성이 있는 등록의 리비전이 필요한 것을 나타냅니다.이것에 의해, 낡은 시스템이 오래된 [94]것을 인식할 수 있게 됩니다.
  8. ^ 이전 에디션에서는 96 문자 세트가 존재하지 않았으며 현재 96 문자 세트에 사용되는 이스케이프 코드는 94 문자 세트를 추가하기 위한 공간으로 예약되어 있었습니다.그 때문에,ESC 0x1B 0x2C순서는 G0에 94자 세트를 [95]추가로 지정하는 것으로 표준의 초기 버전에서 정의되었다.96 문자 세트를 G0 에 지정할 수 없기 때문에, 이것은 첫 번째입니다.I바이트는 현재 표준 에디션에서 사용되지 않습니다.다만, MARC-8[3]기재되어 있습니다.
  9. ^ 예를 들면, 「」를 참조해 주세요.Printronix (2012), OKI® Programmer's Reference Manual (PDF), p. 26 를 사용하는 보다 최근의 시스템에 대해서ESC ( HDBCS에서 ASCII로 전환합니다.

레퍼런스

  1. ^ ECMA-35(1994), 개요 이력
  2. ^ ECMA-35(1994), 페이지 51, 부속서 D
  3. ^ a b c d e "Technique 2: Using standard alternate graphic character sets". MARC 21 Specifications for Record Structure, Character Sets, and Exchange Media. Library of Congress. 2007-12-05. Archived from the original on 2020-07-22. Retrieved 2020-07-19.
  4. ^ "ECMA-35: Character code structure and extension techniques (web page)". Ecma International. Archived from the original on 2022-04-25. Retrieved 2022-04-27.
  5. ^ a b c d ECMA-35(1994), 페이지 15-16, 8.1장
  6. ^ a b ECMA-35(1994), 13장
  7. ^ a b ECMA-35(1994), 12장, 14장
  8. ^ a b ECMA-35(1994), 제11장
  9. ^ a b c d e ISO/IEC FDIS 8859-10 (1998), 페이지 1, 1장 ('범위')
  10. ^ a b c d e ECMA-144 (2000), 페이지 1, 장 ('범위')
  11. ^ a b c d e f Lunde (2008), 페이지 242–245, 제4장("인코딩 방법", 섹션 "EUC 인코딩"
  12. ^ a b c d 룬드(2008), 페이지 253–255, 제4장("인코딩 방법") , 섹션 "EUC 대 ISO-2022 인코딩"
  13. ^ a b ISO-IR-196(1996)
  14. ^ a b c Moy, Edward; Gildea, Stephen; Dickey, Thomas. "Controls beginning with ESC". XTerm Control Sequences. Archived from the original on 2019-10-10. Retrieved 2019-10-04.
  15. ^ ECMA-35(1994), 6, 7장
  16. ^ ECMA-35(1994), 제8장
  17. ^ ECMA-35(1994), 제9장
  18. ^ a b ECMA-35(1994), 제15장
  19. ^ Lunde (2008), 페이지 228–234, 제4장("인코딩 방법") 섹션 "ISO-2022 인코딩"
  20. ^ Lunde(2008), 페이지 19-20, 제1장("CJKV 정보처리 개요", 섹션 "Row-Cell 및 Plane-Row-Cell이란?"
  21. ^ ECMA-35(1994), 페이지 4, 정의 4.11
  22. ^ ECMA-35(1994), 페이지 5, 정의 4.18
  23. ^ 예를 들어 ISO-IR-14(1975) : target: JIS X 0201 Roman 세트의 G0 지정을 다음과 같이 정의합니다.ESC 2/8 4/10.
  24. ^ ECMA-35(1994), 페이지 5, 5.1장
  25. ^ 를 들어, JIS X 0201 Roman 세트의 G0 명칭을 다음과 같이 정의하는 RFC 1468(1993)을 참조하십시오.ESC ( J.
  26. ^ ECMA-35(1994), 페이지 7, 6.2장
  27. ^ ECMA-35(1994), 페이지 10, 6.3.2장
  28. ^ ECMA-35(1994), 페이지 4, 정의 4.17
  29. ^ ECMA-35(1994), 페이지 4, 정의 4.14
  30. ^ ECMA-35(1994), 페이지 28, 13.1장
  31. ^ a b c ECMA-35(1994), 페이지 33, 13.3.3장
  32. ^ ECMA-48 (1991), 페이지 24-26, 5.4장
  33. ^ a b c d ECMA-35(1994), 페이지 11, 6.4.3장
  34. ^ ISO-IR-208(1999)
  35. ^ ISO-IR-155(1990)
  36. ^ ISO-IR-164(1992)
  37. ^ a b ECMA-35(1994), 페이지 10, 6.3.3장
  38. ^ Google Inc. (2014). "ansi.go, line 134". ANSI escape sequence library for Go. Archived from the original on 2022-04-30. Retrieved 2019-09-14. {{cite web}}: author=범용명(도움말)이 있습니다.
  39. ^ ECMA-43(1991), 페이지 5, 7장 ('8비트 코드 문자 지정')
  40. ^ ISO/IEC FDIS 8859-10(1998), 페이지 3, 6장("코드화된 문자 집합의 사양")
  41. ^ ECMA-144(2000), 페이지 3, 6장("코드화된 문자 집합의 사양")
  42. ^ ECMA-43(1991), 페이지 19, 부록 C("복합 그래픽 문자")
  43. ^ a b ECMA-35(1994), 페이지 10, 6.4.1장
  44. ^ a b ECMA-35(1994), 페이지 11, 6.4.4장
  45. ^ a b c ECMA-35(1994), 페이지 11, 6.4.2장
  46. ^ ISO-IR-104(1985)
  47. ^ ISO-IR-1(1975)
  48. ^ a b ECMA-35(1994), 19페이지, 8.5.1장
  49. ^ a b ECMA-35(1994), 19페이지, 8.5.2장
  50. ^ ECMA-43 (1991), 페이지 8, 7.6장("C1 세트")
  51. ^ a b ECMA-35(1994), 페이지 29, 13.2.1장
  52. ^ a b ECMA-35(1994), 페이지 12, 6.5.1장
  53. ^ ECMA-35(1994), 페이지 12, 6.5.2장
  54. ^ a b c ISO-IR, 19페이지, 2.7장("단일 제어 기능")
  55. ^ ECMA-35(1994), 페이지 12, 6.5.3장
  56. ^ a b ECMA-35(1994), 페이지 14, 7.3장, 표 2
  57. ^ ISO-IR-14(1975)
  58. ^ a b ITU-T (1995-08-11). Recommendation T.51 (1992) Amendment 1. Archived from the original on 2020-08-02. Retrieved 2019-12-25.
  59. ^ ISO-IR-106(1985)
  60. ^ ECMA-35(1994), 페이지 15, 7.3장, 주 23
  61. ^ ISO-IR-140(1987)
  62. ^ ISO-IR-7(1975)
  63. ^ ISO-IR-26(1976)
  64. ^ ISO-IR-36(1977)
  65. ^ ECMA-35(1980), 페이지 8, 5.1.7장
  66. ^ a b ISO-IR-105(1985)
  67. ^ a b c d ECMA-35(1994), 페이지 17, 제8.3.1장
  68. ^ a b c d ECMA-35(1994), 페이지 23, 9.3.1장
  69. ^ a b c ECMA-35(1994), 페이지 19, 8.4장
  70. ^ a b c ECMA-35(1994), 페이지 17, 제8.3.2장
  71. ^ ECMA-35(1994), 페이지 23-24, 9.4장
  72. ^ ECMA-35(1994), 페이지 27, 11.1장
  73. ^ ECMA-35(1994), 페이지 17, 8.3.3장
  74. ^ ECMA-35(1994), 페이지 47, 부속서 B
  75. ^ ISO-IR, 페이지 2, 1장("개요")
  76. ^ ISO/IEC 2375 (2003)
  77. ^ a b "Handling of the SGML declaration in SP". SP: an SGML System Conforming to International Standard ISO 8879.
  78. ^ "20: SGML Declaration of HTML 4". HTML 4.01 Specification. W3C.
  79. ^ ISO-IR, 페이지 10, 2.2장("94-두 번째 중간 바이트와 함께 그래픽 문자 세트")
  80. ^ ARIB STD-B24 (2008), 페이지 39, 파트 2, 표 7-3
  81. ^ Mascheck, Sven; Le Breton, Stefan; Hamilton, Richard L. "About the 'alternate linedrawing character set'". ~sven_mascheck/. Archived from the original on 2019-12-29. Retrieved 2020-01-08.
  82. ^ ECMA-35(1994), 36페이지, 14.4장
  83. ^ ECMA-35(1994), 페이지 36, 14.4.2장, 주 48
  84. ^ ECMA-35(1994), 페이지 36, 14.4.2장, 주 47
  85. ^ ETS 300 706 (1997), 페이지 103, 14장("동적으로 재정의 가능한 문자")
  86. ^ a b c d e f g h i j k l m n o p q ECMA-35(1994), 페이지 35-36, 14.3.2
  87. ^ ISO/IEC 10646 (2017), 페이지 19-20, 12.4장("제어 기능 세트의 식별")
  88. ^ ECMA-35(1994), 페이지 32, 표 5
  89. ^ a b c ECMA-35(1994), 37-41, 15.2장
  90. ^ ECMA-35(1994), 페이지 34, 14.2.2장
  91. ^ ECMA-35(1994), 페이지 34, 14.2.3장
  92. ^ Digital. "DECDWL—Double-Width, Single-Height Line". VT510 Video Terminal Programmer Information. Archived from the original on 2020-08-02. Retrieved 2020-01-17.
  93. ^ Kawasaki, Yusuke (2010). "Encode::JP::Emoji::Encoding". Encode-JP-Emoji. Line 268. Archived from the original on 2022-04-30. Retrieved 2020-05-28.
  94. ^ ECMA-35(1994), 36-37페이지, 14.5장
  95. ^ ECMA-35 (1980), 페이지 14-15, 5.3.7장
  96. ^ a b c d ISO-IR, 페이지 20, 2.8.1장("표준 리턴을 포함한 코드 시스템")
  97. ^ a b c d ECMA-35(1994), 페이지 41-42, 15.4장
  98. ^ a b c d e ISO-IR, 페이지 21, 2.8.2장("표준 리턴이 없는 코드 시스템")
  99. ^ ECMA-35(1994), 페이지 41, 15.3장
  100. ^ a b c ISO/IEC 10646 (2017), 페이지 19, 12.2 장("UCS 인코딩 방식의 식별")
  101. ^ ISO/IEC 10646 (2017), 페이지 18-19, 12.1장("식별의 목적과 맥락")
  102. ^ ISO-IR-192(1996)
  103. ^ ISO-IR-195(1996)
  104. ^ ISO/IEC 10646 (2017), 페이지 20, 12.5장("ISO/IEC 2022의 부호화 시스템 식별")
  105. ^ Lunde(2008), 페이지 229~230, 제4장("인코딩 방법") 섹션 "ISO-2022 인코딩" "과거에 광범위하게 사용되었거나 오늘날 어떤 목적으로 계속 사용되고 있는 인코딩이 강조 표시되었습니다."
  106. ^ a b "Additional Coding-related Required Information". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2015-01-07.
  107. ^ a b c WHATWG 인코딩 표준, 섹션 2 ('보안 배경')
  108. ^ a b c WHATWG 인코딩 표준, 4.2장("이름 및 라벨") 앵커 "교체"
  109. ^ a b c d WHATWG 인코딩 표준, 섹션 14.1 ('대체')
  110. ^ a b c d e f RFC 1468 (1993)
  111. ^ a b c "Code Page Identifiers". Windows Dev Center. Microsoft. Archived from the original on 2019-06-16. Retrieved 2019-09-16.
  112. ^ a b WHATWG 인코딩 표준, 섹션 12.2 (ISO-2022-JP)
  113. ^ Chang, Hye-Shik. "Modules/cjkcodecs/_codecs_iso2022.c, line 1122". cPython source tree. Python Software Foundation. Archived from the original on 2022-04-30. Retrieved 2019-09-15.
  114. ^ "codecs — Codec registry and base classes § Standard Encodings". Python 3.7.4 documentation. Python Software Foundation. Archived from the original on 2019-07-28. Retrieved 2019-09-16.
  115. ^ "2: Codesets and Codeset Conversion". DIGITAL UNIX Technical Reference for Using Japanese Features. Digital Equipment Corporation, Compaq.[데드링크]
  116. ^ a b Lunde (2008), 페이지 236–238, 제4장 ('인코딩 방법'), 섹션 "ISO-2022-JP 인코딩의 전신—J"IS 부호화"
  117. ^ RFC 1554 (1993)
  118. ^ RFC 2237 (1997)
  119. ^ "PQ02042: New Function to Provide C/370 iconv() Support for Japanese ISO-2022-JP". IBM. 2021-01-19. Archived from the original on 2022-01-04. Retrieved 2022-01-04.
  120. ^ a b "CCSID 9148". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2014-11-29.
  121. ^ "CCSID 956". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2014-12-02.
  122. ^ "CCSID 957". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2014-11-30.
  123. ^ "CCSID 958". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2014-12-01.
  124. ^ "CCSID 959". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2014-12-02.
  125. ^ "CCSID 5052". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2014-11-29.
  126. ^ "CCSID 5053". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2014-11-29.
  127. ^ "CCSID 5054". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2014-11-29.
  128. ^ "CCSID 5055". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2014-11-29.
  129. ^ a b RFC 1557 (1993)
  130. ^ "KS X 1001:1992" (PDF). Archived (PDF) from the original on 2007-09-26. Retrieved 2007-07-12.
  131. ^ ISO-IR-149(1988)
  132. ^ a b c d RFC 1922 (1996)
  133. ^ ECMA-43(1991), 페이지 9-10, 8장("레벨")
  134. ^ ECMA-43(1985), 페이지 7-11, 7.3장("G0 세트")
  135. ^ ECMA-43 (1991), 페이지 6-8, 7.4장("G0 설정")
  136. ^ ECMA-43(1991), 페이지 11, 10.3장("버전의 식별")
  137. ^ a b ECMA-43(1991), 페이지 23, 부속서 E("이 ECMA 표준의 제2판(1985년)과 현재 (제3판)의 주요 차이점")
  138. ^ IPTC (1995). The IPTC Recommended Message Format (PDF) (5th ed.). IPTC TEC 7901. Archived (PDF) from the original on 2022-01-25. Retrieved 2020-01-14.
  139. ^ ECMA-43(1991), 페이지 10, 9.2장("문자의 고유 코딩")
  140. ^ van Wingen, Johan W (1999). "8. Code Extension, ISO 2022 and 2375, ISO 4873 and 10367". Character sets. Letters, tokens and codes. Terena. Archived from the original on 2020-08-01. Retrieved 2019-10-02.
  141. ^ ECMA-43(1991), 페이지 10-11, 10장("버전과 수준의 식별")
  142. ^ IBM. "Character Data Representation Architecture (CDRA)". IBM. pp. 157–162. Archived from the original on 2019-06-23. Retrieved 2020-06-18.
  143. ^ "DICOM PS3.2 2016d - Conformance; D.6.2 Character Sets; D.6 Support of Character Sets". Archived from the original on 2020-02-16. Retrieved 2020-05-21.
  144. ^ "DICOM ISO 2022 variation". Archived from the original on 2013-04-30. Retrieved 2009-07-25.
  145. ^ a b Sivonen, Henri (2018-12-17). "(UNSUBMITTED DRAFT) No U+FFFD Generation for Zero-Length ASCII-State Content between ISO-2022-JP Escape Sequences" (PDF). Archived (PDF) from the original on 2019-02-21. Retrieved 2019-02-21.
  146. ^ "935453 - Gather telemetry about HZ and other encodings we might try to remove". Archived from the original on 2017-05-19. Retrieved 2018-06-18.
  147. ^ Davis, Mark; Suignard, Michel (2014-09-19). "3.6.2 Some Output For All Input". Unicode Technical Report #36: Unicode Security Considerations (revision 15). Unicode Consortium. Archived from the original on 2019-02-22. Retrieved 2019-02-21.

인용된 표준 및 레지스트리 인덱스

등록된 코드 세트 인용

인터넷 댓글 요청 인용

기타 인용된 출판물

추가 정보

외부 링크