hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
보도 코드 역사
문자 시프트 코드(LS)는 또한 천공된 테이프에서 텍스트를 읽은 후 취소/삭제하는 방법으로도 사용될 수 있어, 천공된 밴드를 버리기 전에 메시지를 안전하게 파괴할 수 있다. 기능적으로는 ASCII(또는 천공 카드용 EBCDIC를 포함한 다른 7비트 및 8비트 인코딩)의 삭제 코드와 동일한 필러 역할을 할 수 있다. 텍스트 조각의 코드가 임의의 수의 LS 코드로 대체된 후에도 이어지는 내용은 여전히 유지되고 디코딩할 수 있다. 또한 첫 번째 코드의 디코딩이 숫자 페이지의 숫자나 다른 기호를 제공하지 않도록 하는 시작자로도 사용될 수 있다(널 코드는 펀치 밴드의 끝이나 시작 근처에 임의로 삽입될 수 있으며 무시되어야 하는 반면, 공백 코드는 텍스트에서 중요하다).
확장용으로 예약된 셀(첫 번째 LS 코드 직후에 두 번째로 LS 코드를 다시 사용하여 숫자 페이지에서 문자 시프트 페이지로 전환)은 새 모드로 전환하도록 정의되었다. 이 새 모드에서는 문자 페이지에 소문자만 포함되지만, 대문자를 위한 세 번째 코드 페이지에 대한 액세스를 유지한다. 이는 단일 문자를 인코딩(해당 문자 앞에 LS를 보냄)하거나, 무제한의 대문자 또는 숫자를 잠금(FS+LS 사용)한 다음 잠금 해제(단일 LS 사용)하여 소문자 모드로 돌아가는 방식으로 이루어진다. "예약됨"으로 표시된 셀도 사용 가능하며(숫자 시프트 페이지에서 FS 코드를 사용하여) 숫자 페이지(일반적으로 숫자 및 국가별 소문자 또는 기호 포함)를 네 번째 페이지로 전환할 수 있다(국가별 문자가 대문자이고 다른 기호가 인코딩될 수 있는 곳).
ITA2는 여전히 청각 장애인을 위한 통신 기기 (TDD), 가입전신, 그리고 아마추어 무선 응용 프로그램인 무선 전신타자기 ("RTTY") 등에서 사용된다. ITA2는 또한 21세기 초 도이치 뵈르제가 지정한 금융 프로토콜인 Enhanced Broadcast Solution에서도 문자 인코딩 공간을 줄이기 위해 사용된다.
보도 코드 명명법
거의 모든 20세기 전신타자기 장비는 웨스턴 유니온의 코드, ITA2 또는 그 변형을 사용했다. 무선 아마추어들은 ITA2와 그 변형을 잘못해서 "보도"라고 부른다. 미국아마추어무선연맹의 아마추어 무선 핸드북도 그렇게 하지만, 최근 판에서는 코드표가 이를 ITA2로 정확하게 식별한다.
보도 코드 문자 집합
각 셀에 표시된 값은 비교를 위해 제공된 유니코드 코드 포인트이다.
기상학자들은 ITA2의 변형을 사용했는데, 10진수, BEL 및 몇몇 다른 문자를 제외한 숫자-대문자 기호가 날씨 기호로 대체되었다.
보도 코드 상세 설명
참고: 이 표는 보도와 머레이가 "1"이라고 부른 공간이 가장 오른쪽에 있고 최하위 비트임을 전제로 한다. 전송된 비트가 더 큰 코드로 압축되는 방식은 제조업체마다 달랐다. 가장 일반적인 해결책은 최하위 비트에서 최상위 비트 방향으로 비트를 할당하는 것이다(바이트의 세 최상위 비트는 사용되지 않음).
ITA2에서 문자는 5비트를 사용하여 표현된다. ITA2는 "문자 시프트"(LTRS)와 "숫자 시프트"(FIGS)의 두 가지 코드 하위 집합을 사용한다. FIGS 문자(11011)는 LTRS(11111) 문자로 재설정될 때까지 다음 문자가 FIGS 집합으로 해석되어야 함을 나타낸다. 사용 시, LTRS 또는 FIGS 시프트 키를 누르고 놓으면 해당 시프트 문자가 다른 기기로 전송된다. 그런 다음 원하는 문자 또는 숫자 문자를 입력한다. 타자기나 현대 컴퓨터 키보드와 달리, 해당 문자를 입력하는 동안 시프트 키를 계속 누르고 있지 않는다. "ENQuiry"는 다른 기기의 응답을 유발한다. 이는 "누구입니까?"를 의미한다.
보도 코드 상세 설명
CR은 캐리지 리턴, LF는 줄 바꿈, BEL은 작은 종을 울리는 경고음 문자이다(종종 작업자에게 수신 메시지를 알리는 데 사용됨). SP는 공백이며, NUL은 널 문자(빈 테이프)이다.
참고: 코드 포인트의 이진 변환은 종이 테이프를 어느 쪽에서 보느냐에 따라 종종 역순으로 표시된다. 또한, "제어" 문자는 대칭이거나 유용한 쌍으로 선택되어 테이프를 "거꾸로" 삽입해도 장비에 문제가 발생하지 않고 결과 인쇄물을 해독할 수 있도록 했다. 따라서 FIGS(11011), LTRS(11111), 공백(00100)은 불변인 반면, CR(00010)과 LF(01000)는 일반적으로 쌍으로 사용되며, 페이지 프린터에 의해 순서에 관계없이 동일하게 처리된다. LTRS는 또한 종이 테이프에서 삭제할 문자를 오버펀칭하는 데 사용될 수 있었다(ASCII 7비트의 DEL과 매우 유사하다).
보도 코드 상세 설명
RYRYRY... 시퀀스는 종종 테스트 메시지와 모든 전송의 시작 부분에 사용된다. R은 01010이고 Y는 10101이므로, 이 시퀀스는 전신타자기의 기계적 구성 요소의 대부분을 최대 스트레스로 작동시킨다. 또한 한때 수신기의 미세 조정은 두 가지 색상의 불빛(각 톤마다 하나씩)을 사용하여 이루어졌다. 'RYRYRY...'는 0101010101...을 생성하여 조정이 정확할 때 불빛이 동일한 밝기로 빛나게 했다. 이 조정 시퀀스는 ITA2가 일반적으로 무선 전신타자기 (RTTY) 사용에서 볼 수 있는 두 톤 FSK 변조와 함께 사용될 때만 유용하다.
보도 코드의 미국 구현은 FIGS 레이어의 #, &와 같은 몇 가지 문자를 추가하여 다를 수 있다.
보도 코드의 러시아어 버전(MTK-2)은 세 가지 시프트 모드를 사용했다. 키릴 문자 모드는 문자(00000)로 활성화되었다. 키릴 문자가 더 많기 때문에 !, &, £ 문자는 생략되고 키릴 문자로 대체되었으며, BEL은 키릴 문자 Ю와 같은 코드를 가진다. 키릴 문자 Ъ와 Ё는 생략되었고, Ч는 숫자 4와 합쳐졌다.
KOI-8
KOI-8(КОИ-8)은 GOST 19768-74로 표준화된 8비트 문자 집합이다. 라틴 음소문자와 러시아어 문자를 대소문자 모두 사용할 수 있도록 KOI-7을 확장한 것이다. 그러나 문자 Ёё와 대문자 Ъ는 빠져 있는데, 후자는 지움 문자와의 충돌을 피하기 위함이다(대부분의 확장에서는 둘 다 추가된다. KOI8-B 참조). 처음 127개의 코드 포인트는 달러 기호$ (코드 포인트 2416진수)가 만국 통화 기호 ¤로 대체된 것을 제외하고는 ASCII와 동일하다. x8_ 및 x9_ 행(코드 포인트 128-159)은 확장 이진화 십진법 교환 부호의 추가 제어 문자 (코드 포인트 32-63)로 채워질 수 있다.
KOI-8
이 표준은 이후 인터넷 표준인 KOI8-RU의 기반이 되었다.
현대 응용 프로그램, 특히 인터넷에서는 KOI-8 및 그 변형이나 다른 키릴 문자 인코딩보다 유니코드가 선호되며, 이로 인해 UTF-8은 웹 페이지에서 지배적인 인코딩이 되었다. (옛 키릴 문자를 포함하여 436개의 키릴 문자/코드 포인트를 포괄하는 유니코드의 완전한 범위와, Windows-1251 및 KOI8 변형과 같은 단일 바이트 문자 인코딩이 이를 제공할 수 없는 방법에 대한 자세한 내용은 유니코드 키릴 문자를 참조한다.)
KOI-8 문자 집합
다음 표는 KOI-8 인코딩을 보여준다. 각 문자는 해당 유니코드 코드 포인트와 함께 표시된다.
KOI8-R
KOI8-R(RFC 1489)은 프로그래머 안드레이 체르노프가 1993년에 KOI-8 인코딩에서 파생시킨 8비트 문자 인코딩으로, 키릴 문자의 러시아어 하위 집합을 사용하는 러시아어를 지원하도록 설계되었다. KOI-8은 차례로 MTK-2 텔레타이프 코드에서 러시아어와 라틴어 문자의 음성 일치를 계승한 KOI-7 인코딩의 8비트 확장이다. 그 결과, KOI8-R의 러시아어 키릴 문자는 ISO 8859-5와 같은 일반적인 키릴 문자의 알파벳 순서가 아닌 유사 라틴어 알파벳 순서로 되어 있다. 이것은 부자연스럽게 보일 수 있지만, 8번째 비트가 제거되어도 텍스트가 ASCII 기반 인코딩(KOI8-R 자체 포함)에서 대소문자가 반전된 전자된 형태로 부분적으로 읽을 수 있는 유용한 효과가 있다. 예를 들어, "Код для обмена и обработки информации" (KOI 약어의 러시아어 의미)는 kOD DLQ OBMENA I OBRABOTKI INFORMACII가 된다.
KOI8-R
KOI-8은 "정보 교환을 위한 8비트 코드"를 의미하는 8-bitnyy kod dlya obmena i obrabotki informatsii(러시아어: 8-비트니 코드 델리아 오베마 이 오브라보트키 인포르마치)를 나타낸다. 마이크로소프트 윈도우에서 KOI8-R은 코드 페이지 번호 20866이 할당되어 있다. IBM에서 KOI8-R은 코드 페이지 878이 할당되어 있다. KOI8-R은 또한 불가리아어도 포함한다.
이러한 언어에 대한 적절한 인용 부호가 없는데, «...»와 불가리아어 „...“ 모두 해당한다. Windows-1251은 이들을 지원하며 더 많은 문자를 지원하므로 더 인기가 많아졌다. KOI8-R은 웹사이트의 0.004% 미만에서 사용되며, 주로 러시아와 불가리아 웹사이트에서 사용된다. 유니코드와 UTF-8은 현대 애플리케이션에서 단일 바이트 키릴 인코딩보다 선호되며, 유니코드에는 옛 키릴 문자를 포함하여 436개의 키릴 문자가 포함되어 있다.
KOI8-R 문자 집합
다음 표는 KOI8-R 인코딩을 보여준다. 각 문자는 해당 유니코드 코드 포인트와 함께 표시된다.
KOI8-R 추가 자료
Flohr, Guido; Kiss, Gabor; Chernov, Andrey A. (2016) [2006]. “Locale::RecodeData::KOI8_R - Conversion routines for KOI8-R”. 《CPAN libintl-perl》. 1.0. 2017년 1월 15일에 원본 문서에서 보존된 문서. 2017년 1월 15일에 확인함.
Kornai, Andras; Birnbaum, David J.; da Cruz, Frank; Davis, Bur; Fowler, George; Paine, Richard B.; Paperno, Slava; Simonsen, Keld J.; Thobe, Glenn E.; Vulis, Dimitri; van Wingen, Johan W. (1993년 3월 13일). “CYRILLIC ENCODING FAQ Version 1.3”. 1.3. 2020년 6월 24일에 확인함.
KOI8-U
KOI8-U(RFC 2319)는 키릴 문자를 사용하는 우크라이나어를 다루도록 설계된 8비트 문자 인코딩이다. 러시아어와 불가리아어를 다루는 KOI8-R을 기반으로 하지만, 8개의 상자 그리기 문자를 대문자와 소문자 Ґ, Є, І, Ї 네 개의 우크라이나 문자로 대체한다.
KOI8-RU는 밀접하게 관련되어 있지만 벨라루스어를 위해 Ў를 추가한다. 둘 다 문자 할당은 KOI8-E의 문자 할당과 일치하며, KOI8-F에 추가된 Ґ는 예외이다.
마이크로소프트 윈도우에서 KOI8-U는 코드 페이지 번호 21866으로 할당된다. IBM에서 KOI8-U는 코드 페이지/CCSID 1168로 할당된다.
KOI8은 실제로 유행하지 못했던 ISO 8859-5보다 훨씬 더 일반적으로 사용된다. 또 다른 일반적인 키릴 문자 인코딩은 Windows-1251이다. 미래에는 둘 다 결국 유니코드에 자리를 내줄 수도 있다.
KOI8-U
KOI8은 "정보 교환을 위한 코드, 8비트"를 의미하는 러시아어인 Kod Obmena Informatsiey, 8 bit (러시아어: Код Обмена Информацией, 8 бит)의 약자이다.
KOI8 문자 집합은 키릴 문자가 ISO 8859-5와 같이 키릴 알파벳 순서가 아니라 유사 라틴 알파벳 순서로 배열되어 있다는 특징을 가지고 있다. 이는 8번째 비트가 제거되고 텍스트가 KOI8 자체를 포함하여 ASCII 기반의 모든 문자 집합으로 표시될 경우에도 텍스트가 대소문자가 뒤바뀐 전사로 여전히 합리적으로 읽을 수 있다는 유용한 효과를 제공한다. 예를 들어, "KOI" 약어 "Код Обмена Информацией"는 kOD oBMENA iNFORMACIEJ가 된다.
KOI8-U 문자 집합
다음 표는 KOI8-U 인코딩을 보여준다. 각 문자는 해당 유니코드 코드 포인트와 함께 표시된다.
RFC 2319는 문자 0x95가 U+2219 (∙)여야 한다고 명시하고 있지만, Windows-1251의 글머리표 문자와 일치하도록 U+2022 (•)일 수도 있다.
일부 참고 자료에는 오타가 있어 문자 0xB4가 올바른 U+0404가 아닌 U+0403이라고 잘못 기재되어 있다. 이 오타는 RFC 2319의 부록 A에 있다 (그러나 RFC 본문의 표에는 올바른 매핑이 나와 있다).
KOI8-U 더 읽어보기
Leishner, Mark (2008) [1999-12-20]. “KOI8-U Belorussian/Ukrainian Cyrillic to Unicode 2.1 mapping table - Based on RFC 2319”. Department of Mathematical Sciences, New Mexico State University. 2017년 2월 19일에 원본 문서에서 보존된 문서. 2017년 2월 19일에 확인함.
Kornai, Andras; Birnbaum, David J.; da Cruz, Frank; Davis, Bur; Fowler, George; Paine, Richard B.; Paperno, Slava; Simonsen, Keld J.; Thobe, Glenn E.; Vulis, Dimitri; van Wingen, Johan W. (1993년 3월 13일). “CYRILLIC ENCODING FAQ Version 1.3”. 1.3. 2017년 2월 18일에 원본 문서에서 보존된 문서. 2020년 6월 24일에 확인함.
보체성분 5
보체성분 5(補體成分五, 영어: complement component 5, C5)는 사람의 경우 C5 유전자에 의해 암호화되는 단백질이다.
C5는 보체계에 관여한다. C5는 다음과 같이 C5a와 C5b로 분열된다.
라이네르병은 C5의 결핍으로 인해 발생하는 것으로 생각된다.
보체성분 5 기능
C5는 보체의 다섯 번째 성분으로, 염증과 세포사멸 과정에서 중요한 역할을 한다. C5는 이황화물 다리로 연결된 α와 β 폴리펩타이드 사슬로 구성된다. 활성화 펩타이드로 아나필라톡신인 C5a는 강력한 경련성 및 화학주성 활성을 가지고 있으며, C5-전환효소에 의한 절단을 통해 α 폴리펩타이드로부터 유래된다. C5b 거대분자 절단 생성물은 C6(보체성분 6)과 복합체를 형성할 수 있으며, 이 복합체는 추가적인 보체성분을 포함하는 막공격 복합체 형성의 기초가 된다.
보체성분 5 임상적 중요성
이 유전자의 돌연변이는 C5 결핍증을 유발하는데, 이 질병을 앓는 환자는 심각한 재발성 감염의 경향이 있다. 이 유전자의 결함은 간경변증과 류머티스 관절염에 걸리기 쉬운 것과도 관련이 있다.
보체성분 5 치료적 활용
에쿨리주맙(상품명 솔라리스)은 C5가 C5a와 C5b로 분리되는 것을 방지한다.
확장 ASCII
확장 ASCII(Extended ASCII)는 원래 ASCII 문자 집합 96개(대부분)와 최대 128개의 추가 문자를 포함하는 문자 인코딩의 레퍼토리이다. "확장 ASCII"에 대한 공식적인 정의는 없으며, 이 용어의 사용 자체도 비판받기도 하는데, 이는 미국 국가표준 협회 (ANSI)가 ANSI X3.4-1986 표준을 업데이트하여 더 많은 문자를 포함했다거나, 이 용어가 단일하고 명확한 인코딩을 식별한다는 오해를 불러일으킬 수 있기 때문이다. 이 두 가지 모두 사실이 아니다.
ISO 8859 표준은 ASCII 문자 집합의 (제한된) 확장을 공식화한 최초의 국제 표준이었다. 이 표준이 인코딩한 많은 언어 변형 중 ISO 8859-1("ISO Latin 1") – 대부분의 서유럽 언어를 지원한다 – 은 서구에서 가장 잘 알려져 있다. 그 외에도 많은 확장 ASCII 인코딩(220개 이상의 도스 및 윈도우 코드 페이지)이 존재한다. 확장 이진화 십진법 교환 부호("다른" 주요 문자 코드) 또한 수십 년에 걸쳐 많은 확장 변형(186개 이상의 확장 이진화 십진법 교환 부호 코드 페이지)을 개발했다.
확장 ASCII
모든 현대 운영체제는 수천 개의 문자를 지원하는 유니코드를 사용한다. 그러나 확장 ASCII는 컴퓨팅 역사에서 여전히 중요하며, 여러 확장 ASCII 문자 집합을 지원하기 위해서는 나중에 UTF-8 인코딩 방식을 더 쉽게 지원할 수 있도록 소프트웨어를 작성해야 했다.
확장 ASCII 역사
ASCII는 1960년대 전신타자기와 전보, 그리고 일부 컴퓨팅을 위해 설계되었다. 초기 전신타자기는 전자기식이었고, 마이크로프로세서가 없었으며, 작동에 필요한 최소한의 전자기식 메모리만 가지고 있었다. 이들은 한 번에 한 문자를 완전히 처리하고 즉시 유휴 상태로 돌아갔다. 이는 모든 제어 시퀀스가 한 문자 길이여야 함을 의미했으며, 따라서 많은 수의 코드를 그러한 제어용으로 예약해야 했다. 이들은 타자기에 기반한 타격식 프린터였으며, 금속 활자 요소에 주조된 고정된 글리프 집합만 인쇄할 수 있었다. 이는 또한 최소한의 글리프 집합을 권장했다.
확장 ASCII 역사
7비트 ASCII는 이전의 5비트 및 6비트 코드보다 개선되었다. 27=128개의 코드 중 33개는 제어용으로 사용되었고, 95개의 신중하게 선택된 인쇄 가능 문자(94개의 자체와 하나의 공백)가 포함되었는데, 여기에는 영어 알파벳(대소문자), 숫자, 그리고 31개의 문장 부호와 기호가 포함되었다. 이는 표준 미국 타자기에 있는 모든 기호와 프로그래밍 작업에 선택된 몇 가지 기호를 포함한다. 일부 인기 있는 주변 장치는 64개의 인쇄 문자 하위 집합만 구현했다. 텔레타이프 모델 33은 "a"부터 "z"까지 또는 덜 일반적인 다섯 가지 기호(`, {, |, }, 및 ~)를 전송할 수 없었으며, 그러한 문자를 받으면 대신 "A"부터 "Z"까지(강제 올 캡스)와 다른 다섯 가지 유사한 기호(@, [, \, ], 및 ^)를 인쇄했다.
확장 ASCII 역사
ASCII 문자 집합은 미국 영어를 사용하기에는 겨우 충분하며, 조판에 흔한 많은 자체(글리프)가 부족하고, 보편적으로 사용하기에는 너무 작다. 영어 외의 알파벳 문자, 더 많은 종류의 문장 부호와 간격, 더 많은 수학 연산자와 기호(× ÷ ⋅ ≠ ≥ ≈ π 등), 일부 프로그래밍 언어에서 사용하는 고유한 기호, 표의문자, 표어문자, 상자 그리기 문자 등 훨씬 더 많은 문자와 기호가 바람직하거나 유용하거나 필요하다.
확장 ASCII 역사
전 세계 컴퓨터 사용자에게 가장 큰 문제는 각 지역 알파벳의 필요성이었다. ASCII의 영어 알파벳은 발음 구별 기호 없이 악센트가 붙은 문자를 쓰거나 ß 대신 ss와 같은 두 문자 근사치를 사용한다면 유럽 언어를 거의 수용할 수 있다. 7비트 ASCII의 수정된 지역 변형이 즉시 나타나, 덜 사용되는 일부 기호를 매우 원하는 기호나 문자로 교환했는데, 예를 들어 영국 전신타자기에서 #를 £로, 일본에서 \를 ¥로 또는 한국에서 ₩로 대체하는 식이었다. 최소 29가지 변형 집합이 생겨났다. 최소 한 가지 국가 집합에 의해 12개의 코드 포인트가 수정되어 82개의 "불변" 코드만 남았다. 그러나 프로그래밍 언어는 대체된 문자 중 상당수에 의미를 할당했기 때문에 C 언어의 세 문자 시퀀스 ??< 및 ??>를 사용하여 { 및 }를 나타내는 것과 같은 해결 방법이 고안되었다. 기본 알파벳이 다른 언어는 전사(transliteration)를 사용할 수 있었는데, 예를 들어 모든 라틴 문자를 가장 가까운 키릴 문자로 대체하는 방식이었다(영어가 키릴 문자로 인쇄되거나 그 반대의 경우 이상하지만 어느 정도 읽을 수 있는 텍스트가 생성됨). 또한 두 문자를 겹쳐 인쇄(종종 백스페이스 제어 문자를 사용하여)하여 악센트가 붙은 문자를 생성하는 방법도 고안되었다. 사용자들은 이러한 타협안에 만족하지 못했고, 지원도 제대로 이루어지지 않는 경우가 많았다.
1970년대에 컴퓨터와 주변기기가 8비트 바이트를 표준으로 사용하면서, 컴퓨터와 소프트웨어가 256자 집합을 사용하는 텍스트를 거의 추가적인 프로그래밍 비용 없이 처리할 수 있으며, 저장 비용도 추가되지 않는다는 점이 명백해졌다(각 바이트의 사용되지 않는 8번째 비트가 오류 검사, 부울 필드 또는 8문자를 7바이트로 압축하는 등의 방식으로 재사용되지 않는다고 가정할 경우). 이는 ASCII를 변경 없이 사용할 수 있게 하고 128개의 문자를 더 제공할 수 있게 할 것이다. 많은 제조업체들은 ASCII와 최대 128개의 사용되지 않는 코드로 구성된 8비트 문자 집합을 고안했다. 따라서 모든 주요 서유럽(및 라틴 아메리카) 언어 등을 포함하는 인코딩을 만들 수 있었다.
128개의 추가 문자는 모든 목적, 모든 언어, 심지어 모든 유럽 언어를 포괄하기에는 여전히 충분하지 않으므로, 많은 독점 및 국가별 ASCII 파생 8비트 문자 집합의 등장은 불가피했다. 이러한 집합 간의 변환(트랜스코드)은 복잡하며(특히 한 문자가 두 집합 모두에 없는 경우), 종종 수행되지 않아 문자 깨짐(부분적으로 읽을 수 있는 결과 텍스트로, 사용자가 수동으로 디코딩하는 방법을 배우는 경우가 많았음)이 발생했다. 1990년대 후반에 국가 및 국제 표준 기관의 협력 또는 조정 시도가 있었지만, 국제 표준이 특정 문화에 인기 있거나 특유한 문자를 제외했기 때문에 제조업체 독점 집합이 훨씬 더 인기를 유지했다.
확장 ASCII 독점 확장
메인프레임 및 미니컴퓨터 –  특히 대학에서 수학, 과학 및 언어 교육을 지원해야 하는 필요성을 충족하기 위해 다양한 독점적인 ASCII 수정 및 확장이 등장했다.
휴렛 팩커드는 1978/1979년경 워크스테이션, 터미널 및 프린터에 사용할 목적으로 확장된 7비트/8비트 ASCII 문자 세트인 HP Roman Extension에 유럽 문자를 추가하기 시작했다. 이는 나중에 널리 사용되는 일반 8비트 문자 세트인 HP Roman-8 및 HP Roman-9(및 여러 변형)로 발전했다.
아타리와 코모도어 가정용 컴퓨터는 비표준 ASCII(각각 1963년의 원본 ASCII 표준에 기반한 ATASCII 및 PETSCII)에 많은 그래픽 기호를 추가했다.
TRS-80 가정용 컴퓨터를 위한 TRS-80 문자 집합은 저해상도 블록 그래픽을 구현하는 64개의 반 그래픽 문자(0x80부터 0xBF까지)를 추가했다. (각 블록 그래픽 문자는 2x3 픽셀 그리드로 표시되었으며, 각 블록 픽셀은 하위 6비트 중 하나에 의해 효과적으로 제어되었다.)
확장 ASCII 독점 확장
IBM은 최초의 IBM PC에 8비트 확장 ASCII 코드를 도입했으며, 나중에 다양한 언어와 문화를 위한 변형을 만들었다. IBM은 이러한 문자 집합을 코드 페이지라고 부르고 참조 번호 – 를 할당했다. 이는 IBM 자체가 고안한 것뿐만 아니라 다른 제조업체가 고안하고 사용한 많은 것들을 포함한다. 따라서 문자 집합은 IBM 코드 페이지 번호로 표시되는 경우가 매우 많다. ASCII 호환 코드 페이지에서 하위 128개 문자는 표준 ASCII 값을 유지했으며, 상위 128개 문자에서는 다른 페이지(또는 문자 집합)를 사용할 수 있었다. 예를 들어, 북미 시장용으로 제작된 도스 컴퓨터는 코드 페이지 437을 사용했는데, 여기에는 프랑스어나 독일어와 같은 몇몇 유럽 언어에 필요한 악센트 문자뿐만 아니라 일부 그래픽 선 그리기 문자도 포함되었다. 더 큰 문자 집합 덕분에 영어와 프랑스어를 조합한 문서(프랑스 컴퓨터는 보통 코드 페이지 850을 사용하지만)를 만들 수 있었지만, 예를 들어 영어와 그리스어를 조합한 문서(이는 코드 페이지 737이 필요함)는 만들 수 없었다.
확장 ASCII 독점 확장
애플 컴퓨터는 Mac OS 로마와 같이 맥 OS에 자체적인 8비트 확장 ASCII 코드를 도입했다. 애플 레이저프린터는 또한 포스트스크립트 문자 집합을 도입했다.
디지털 이큅먼트 코퍼레이션(DEC)은 더 적은 문자 수를 가졌지만 더 많은 글자와 발음 구별 기호 조합을 가진 다국적 문자 집합을 개발했다. 이는 VT220 및 이후의 DEC 단말기에서 지원되었다. 이는 나중에 로터스 국제 문자 집합(LICS), ECMA-94 및 ISO 8859-1과 같은 다른 문자 집합의 기반이 되었다.
확장 ASCII ISO 8859
1987년, 국제 표준화 기구(ISO)는 8비트 ASCII 확장을 위한 표준 집합인 ISO 8859를 발행했다. 이 중 가장 인기 있는 것은 ISO 8859-1("ISO Latin 1"이라고도 함)으로, 가장 일반적인 서유럽 언어에 충분한 문자를 포함하고 있다. 8859 그룹의 다른 표준으로는 라틴 문자를 사용하는 동유럽 언어를 위한 ISO 8859-2와 키릴 문자를 사용하는 언어를 위한 ISO 8859-5 등이 있었다.
ISO 표준이 일부 벤더별 확장 ASCII 문자 세트와 다른 주목할 만한 점 중 하나는 확장 블록의 처음 32개 코드 포인트가 ISO 표준에서 제어용으로 예약되어 인쇄 가능한 문자에는 사용할 수 없다는 것이다. 이 정책은 ASCII의 처음 32개 코드 포인트를 차지하는 C0 제어 코드 블록을 모방했다. 이 표준의 이러한 측면은 다른 확장 ASCII 세트에서는 거의 보편적으로 무시되었다.
확장 ASCII Windows-1252
마이크로소프트는 Windows에서 ISO 8859 표준을 사용할 예정이었으나, 곧 C1 제어 코드를 추가 문자로 대체하여 독점적인 Windows-1252 문자 집합을 만들었다. 추가된 문자에는 "곱슬" 따옴표, 엠 대시, 유로 기호, 그리고 ISO-8859-15의 프랑스어 및 핀란드어 문자가 포함되었다. 이는 세계에서 가장 많이 사용되는 확장 ASCII가 되었으며, 종종 웹에서 8859-1이 지정되어 있더라도 사용된다.
확장 ASCII 문자 집합 혼동
확장 코드를 포함하는 텍스트 데이터(문자 시퀀스)를 올바르게 해석하고 표시하려면 텍스트를 읽거나 수신하는 소프트웨어는 해당 텍스트가 작성된 특정 인코딩을 사용해야 한다. 잘못된 인코딩을 선택하면 종종 심하게 잘못된 문자가 표시되는데, 이를 일본 용어로 문자 깨짐이라고 한다. 모든 "확장 ASCII" 인코딩에서 ASCII가 공통이므로, 잘못된 인코딩을 사용해도 읽을 수 있는 영어(또는 A-Z만 사용하는 모든 언어)뿐만 아니라 숫자 및 대부분의 구두점은 유지된다.
많은 통신 프로토콜, 특히 SMTP와 HTTP는 소프트웨어가 여러 인코딩을 올바르게 해석하도록 하기 위해 콘텐츠의 문자 인코딩을 IANA가 할당한 문자 집합 식별자로 태그 지정하도록 요구한다. 그러나 대다수의 소프트웨어는 사용자가 선호하는 인코딩을 나타내는 시스템 설정에 의존하거나 가정된 설정을 컴파일한다.
확장 ASCII 문자 집합 혼동
현대에 유니코드는 거의 모든 비ASCII 인코딩 사용을 대체했다. 많은 인터넷 표준이 ISO 8859-1을 사용하고, 마이크로소프트 윈도우(서유럽 및 아메리카에서 사용되는 대부분의 언어의 경우)가 ISO 8859-1의 상위 집합인 CP1252를 사용하기 때문에, 일반적으로 유효한 UTF-8이 아닌 바이트 스트림은 CP1252 또는 시스템 설정에 있다고 가정하는 것이 안전하다.
CCCII
정보 교환용 중국어 문자 코드(Chinese Character Code for Information Interchange, 중국어: 中文資訊交換碼) 또는 CCCII는 타이완의 중국어 문자 분석 그룹에서 개발한 문자 집합이다. 1980년에 처음 발행되었고, 1982년과 1987년에 크게 확장되었다.
주로 도서관 시스템에서 사용된다. 이는 Big5가 1984년에, CNS 11643이 1986년에 설립되기 전부터 가장 초기에 확립되고 가장 정교한 번체 중국어 인코딩 중 하나였다. 이 인코딩은 간체 버전 및 주요 한자 문자 세트의 다른 이체를 인코딩하는 독특한 시스템으로 구별된다.
CCCII의 초기 버전 변형은 미국 의회도서관에서 동아시아 문자 코드(EACC, ANSI/NISO Z39.64)라는 이름으로 MARC-8의 일부로 사용되고 있다. 여기서 EACC는 MARC 21의 JACKPHY 지원의 일부를 구성한다. 그러나 EACC는 최신 버전의 CCCII보다 문자가 적다. EACC를 유지하는 데 사용되었던 리서치 라이브러리 그룹의 CJK 시소러스를 기반으로 한 애플 컴퓨터에서의 작업은 유니코드의 유니한 세트의 직접적인 전신 중 하나였다.
CCCII 설계
CCCII는 ISO/IEC 2022에서 정의한 94n 세트로 설계되었다. 각 한자 문자는 0x21부터 0x7E까지의 7비트 바이트 3개로 표현된다. 따라서 CCCII에서 표현할 수 있는 한자의 최대 개수는 94×94×94 = 830584이다. 실제로 CCCII로 인코딩할 수 있는 문자 수는 이보다 적다. 변형 문자는 CCCII의 관련 ISO 2022 평면에 인코딩되므로 대부분의 코드 포인트는 변형 문자를 위해 예약되어야 한다.
CCCII 설계
그러나 실제로는 이러한 범위를 벗어나는 바이트가 때때로 사용된다. 코드 0x212320은 일부 구현에서 표의 문자 공간으로 사용된다. 홍콩의 도서관에서 사용하는 CCCII 사양은 0x2120으로 시작하는 코드를 구두점과 기호에 사용한다. 첫 번째 바이트 0x7F는 일부 변형에서 사용할 수 없는 Unified Repertoire and Ordering 또는 CJK Unified Ideographs Extension A 한자(예: U+3449의 경우 0x7F3449 또는 U+796E의 경우 0x7F796E; 계속 바이트가 UCS-2BE 코드와 일치하는 방식에 유의)에 대한 코드를 인코딩하는 데 사용되며, 여기에는 0x21–0x7E 또는 심지어 0x20–0x7F 범위를 벗어나는 바이트도 포함될 수 있다(예: U+551C의 경우 0x7F551C, U+5AA4의 경우 0x7F5AA4 또는 U+8EDA의 경우 0x7F8EDA).
CCCII 설계
CCCII/EACC는 탈출 시퀀스와 함께 사용될 부호화 문자 세트 국제 등록부에 등록되지 않았다. 따라서 ISO 2022와 함께 사용할 수 있는 표준 지정 탈출 시퀀스가 없다. MARC-8은 EACC에 ANSI X3.41 (ISO 2022) 구현에서 비공개 사용 F-바이트 0x31 (1)을 할당한다.
94개의 ISO 2022 평면은 각각 6개의 평면으로 구성된 16개 레이어로 그룹화된다(레이어 16은 평면 91-94 4개로 구성됨). 레이어 1에는 한자 외 문자와 한자 문자가 모두 포함되어 있으며, 한자 외 문자와 가장 자주 사용되는 한자는 평면 1에 배치되고 나머지 5개 평면은 덜 일반적인 한자로 구성된다. 레이어 2에는 간체 중국어 문자가 포함되어 있으며, 이들의 행 및 셀 번호는 레이어 1의 번체 중국어와 동일하다. 레이어 3에서 12까지는 처음 두 레이어와 동등한 행 및 셀 번호에 추가 이체 형태를 포함한다.
마지막 네 개 레이어는 다른 목적으로 사용된다. 구체적으로, 레이어 13은 일본어 지원(가나 및 일본어 고쿠지)을 위한 추가 문자를 포함하고, 레이어 14는 한국어 지원(한글)을 위한 추가 문자를 포함한다. 레이어 15는 사용되지 않으며(예약됨), 레이어 16은 다른 문자에 사용된다.
이 독특한 설계는 하나조노 대학 선불교 국제 연구소의 크리스티안 비테른에 의해 비판받았는데, 그는 문자 변형의 관계가 "매우 복잡하며 고정된, 1차원적인, 고정된 코드 테이블로 표현할 수 없다"고 주장했다. 켄 런디는 이를 "대만에서 가장 잘 고안된 문자 세트 표준 중 하나"라고 묘사하며, 그 구조를 "정말로 존경할 만하다"고 설명했지만, OpenType 변형 대체가 동일한 수준의 기능을 제공할 수 있다고 결론지었다.
CCCII는 1987년 판 기준으로 약 53940개의 코드 포인트를 정의하지만, 1989년의 더 최근 초안은 이를 75684개의 코드 포인트(44167개의 고유 문자 및 31517개의 변형으로 구성)로 확장했다. 미국 의회도서관에서 사용하는 EACC 변형은 15686개의 더 작은 문자 세트만 포함한다.
CCCII 채택
1995년 현재, CCCII 또는 EACC는 주로 미국, 홍콩, 대만의 도서관에서 사용되었다. CCCII는 범-한중일 지원을 약속했지만, 그 지원은 특수 하드웨어로 제한되었다. 확고하게 확립된 참조 글리프의 부족으로 인해 루트 대 변형 문자를 언제 사용해야 하는지 확인하기 어려웠고, 이는 채택을 더욱 제한하여 도서관 외부에서는 유니코드가 당시 널리 채택되지 않았기 때문에 Big5가 해당 지역에서 중국어에 더 일반적으로 사용되었다.
CCCII 채택
2009년 기준, EACC는 여전히 전문 서지 목적으로 광범위하게 사용되고 있다. 또한 유니코드의 중요한 전신이었다. EACC를 유지하는 데 사용되었던 Research Libraries Group의 CJK 시소러스를 기반으로 한 CJK 문자 상호 참조 데이터베이스에 대한 애플 컴퓨터의 작업은 유니코드의 유니한 세트 개발에 직접 통합되었다. 유니코드 한자 문자는 유니한 데이터베이스의 kCCCII 및 kEACC 키에서 해당 CCCII 및 EACC 코드로 참조된다. 그러나 유니코드의 문자 통합 기준(일본 JIS X 0208 및 중국에서 Common Chinese Code 협회에서 개발한 기준에 기반함)은 CCCII에서 사용된 기준과 다르므로 모든 변형 문자가 개별적으로 매핑되지 않는다. EACC와 유니코드 간의 한자, 한글, 가나 및 구두점 매핑 테이블은 미국 의회도서관에서 구할 수 있다.
CCCII 구두점, 기호, 가나 및 자모 차트
다음은 구두점, 기호, 가나 및 한글 자모 차트로, 문자를 보여주고 가능한 유니코드 매핑을 제공한다. 가능한 경우, 이러한 것들은 공개된 매핑 데이터를 참조한다.
한글 음절에 대한 유니코드 매핑은 간결성을 위해 아래에서 생략되었지만, 미국 의회도서관에서 문서화되어 있다. CCCII 한자는 수만 개에 달하며 아래에는 표시되지 않지만(부수 또는 숫자로 한자 외 범위에 포함된 경우 제외), 유니코드 매핑은 유니한 데이터베이스 및 다른 곳에서 구할 수 있다.
CCCII는 일반적으로 94n 세트이므로, 일반적으로 0x2120으로 시작하는 코드를 사용하지 않지만, 다음 레이아웃은 홍콩의 도서관에서 사용하는 변형에서 사용된다.
평면 1 행 1에는 문자가 할당되지 않았으며, 제어 코드용으로 예약되어 있다.
이 행에는 수학 연산자가 포함되어 있다. EACC는 이 행을 비워둔다. 다음 표는 대만 출처를 참조한다.
다음 표는 홍콩의 도서관 그룹인 홍콩 이노베이티브 사용자 그룹(Hong Kong Innovative Users Group)에서 제공하고 홍콩 대학에서 호스팅하는 CCCII 데이터를 참조한다. 이 행에서는 완전히 다른 레이아웃을 사용한다.
CCCII 구두점, 기호, 가나 및 자모 차트
이 행에는 구두점, 아라비아 숫자 및 로마자 문자가 포함되어 있다. 완성 코드의 행 3 및 GB 2312의 행 3과 비교한다.
다양한 변형은 표의 문자 공간(U+3000)를 0x212320(MARC 사양에서 인정), 0x212321(ANSI 표준에 나열되어 있으며 MARC에서도 인정), 또는 0x21635F에 인코딩한다. EACC는 이 세트에 하이픈 마이너스, 괄호 및 표의 문자 공간만 포함한다.
EACC에서 이 행에는 RLIN 입력 방식에서 문자 구성 요소를 내부적으로 나타내는 데 사용되는 여러 Private Use Area 매핑 문자가 포함되어 있으며, 이는 미국 의회도서관에서 비로마자 카탈로그 작성에 사용된다. 이러한 구성 요소 문자는 IME에서만 내부적으로 사용해야 하며, 다른 곳에서 발견될 경우 게타 기호(U+3013)로 대체될 수 있으며, 이 행에는 0x212A46에도 포함되어 있다. 이 행은 CCCII에는 할당되지 않았지만, 게타 기호는 CCCII의 일부 매핑에서 해당 위치에도 나열되어 있다.
CCCII 구두점, 기호, 가나 및 자모 차트
이 행에는 중국어에서 사용되는 다양한 구두점과 다른 기호가 포함되어 있다. CCCII는 이 행에 35개의 구두점을 포함한다. EACC는 이 행에 13개의 문자만 포함한다(아래 상자로 표시).
이 행에는 중국 부수, 로마 숫자, 십간, 십이지 문자가 포함되어 있다.
이 행에는 중국 숫자와 주음부호 문자가 포함된다. EACC는 표의 문자 0(〇)만 포함한다.
이 행에는 참조 기호(코메 지루시)가 포함된다.
홍콩의 도서관에서 사용하는 변형은 평면 1 행 15에 주음부호 문자를 포함하지 않지만, 평면 7에 다른 레이아웃으로 포함한다.
이 행은 레이어 13의 첫 번째 평면인 평면 73에 있으며, 일본어 지원을 위해 포함된 문자를 포함한다. 구두점을 포함한다. 이 행이 포함하는 문자의 레이아웃을 따르는 JIS X 0208의 행 1과 비교한다.
이 행에는 히라가나가 포함된다. JIS X 0208의 행 4와 비교한다.
이 행에는 가타카나가 포함된다. JIS X 0208의 행 5와 비교한다. 이 행은 별도의 탁점 및 반탁점 추가 외에는 JIS X 0208의 행 5에 해당한다.
이 행에는 한국어 자모가 포함된다.
이 행에는 더 이상 정기적으로 사용되지 않는 여러 역사적인 한글 문자가 포함되어 있다. 이들 중 일부는 Private Use Area에 매핑되어 있다.
이 행에는 외국어 음소를 표기하는 데 사용되는 추가 가타카나가 포함된다.
CNS 11643
CNS 11643 문자 집합(중화민국 국가 표준 11643)은 공식적으로 중국 표준 교환 코드 또는 CSIC (중국어 정체자: 中文標準交換碼)로 알려져 있으며, 타이완의 공식 표준 문자 집합이다. CNS 11643의 발행 및 초안 버전은 타이완에서 사용하기 위해 제출된 한중일 통합 한자에 대한 유니코드 참조 글리프의 원본 표준으로 남아 있으며, CNS 11643의 문자 레퍼토리는 계속 업데이트되고 타이완의 행정 목적으로 사용되고 있다.
EUC-TW는 확장 유닉스 코드(EUC) 형식의 CNS 11643 및 ASCII의 인코딩된 표현이다. 실제로, CNS 11643의 첫 두 평면과 밀접하게 관련된 Big5 문자 집합의 변형들은 유니코드가 도입되기 전까지 정체자에 대한 사실상의 표준 인코딩으로 사용되었다. 특정 CSIC 평면을 표현할 수 있는 다른 인코딩으로는 ISO-2022-CN (평면 1, 2) 및 ISO-2022-CN-EXT (평면 1–7)가 있다.
CNS 11643 구조
CNS 11643은 ISO 2022를 따르도록 설계되었지만, 처음 일곱 개의 94×94 문자 평면만 ISO-IR 등록되어 있다. 평면의 총 수는 표준의 연속적인 개정판에 따라 다양했으며, 가장 최근의 보류 중인 초안은 19개의 평면을 가지고 있다. 따라서 모든 평면에서 인코딩 가능한 최대 문자 수는 19×94×94 = 167884이다. 평면 1부터 7까지는 표준에 의해 정의되어 있으며, 2007년부터는 평면 10부터 15까지도 표준에 의해 정의되었다.:115–122 이전에는 평면 12부터 15까지(35344 코드 포인트) 사용자 정의 문자를 위해 특별히 지정되었다. CCCII와 달리 CNS 11643에서의 변형 문자 인코딩은 관련이 없다.
CNS 11643 역사
표준의 첫 번째 판은 1986년에 발행되었으며, 평면 1과 2를 포함했다. 이 평면들은 Big5의 레벨 1과 2에서 파생되었으며, 획수 수정으로 인한 일부 재배열, 두 개의 중복 문자 생략, 그리고 평면 1에 213개의 고전 부수 추가(214개의 강희자전 부수 중 210개는 기존 Big5 문자와, 나머지 3개는 HKSCS 문자의 사실상 중복)가 있었다. (강희자전 부수 (유니코드 블록) 참조). 표준의 확장은 이어서 1988년(6319자, 평면 14 사용)과 1990년(7169자, 평면 15 사용)에 발행되었다.:115–122
CNS 11643 역사
유니코드 1.0.0은 아직 한자를 포함하지 않았지만, CNS 11643과의 호환성을 위한 문자를 포함했다. 한중일 호환용 꼴 블록은 유니코드 1.0.0에서 "CNS 11643 호환성"이라는 이름으로 명명되었다. 유니코드 1.0.1을 위해 유니코드 한중일 통합 한자 집합이 컴파일될 때, 각국 기관들은 포함을 위해 한중일 공동 연구 그룹에 문자 집합을 제출했다. 제출된 CNS 11643 버전은 평면 14 확장 외에도 평면 14에 추가로 원하는 문자(표준 버전 확장에서 마지막으로 사용된 코드 포인트인 68–21 이후)를 추가했다.:179–180
1992년에 발행된 표준의 두 번째 판에서는 7개의 평면에 걸쳐 훨씬 더 많은 한자 모음이 정의되었다. 1988년 평면 14 확장 중 대다수(01-01부터 66–38까지의 6148개 코드 포인트로 구성)는 평면 3으로 채택되었으며(나머지 171개 문자, 즉 66-39부터 68–21까지의 코드 포인트는 대신 평면 4에 분산되었다). 평면 15 확장은 포함되지 않았지만, 그 중 338개 문자가 평면 4부터 7까지에 포함되었다.:115–122
2007년에 발행된 표준의 세 번째 판에서는 유로 기호, 표의 문자 0, 가나 (문자) 및 기존 주음부호와 로마자 지원에 대한 확장이 평면 1에 추가되었다. 이 판은 추가 한자를 포함하는 평면 10부터 14까지를 도입했으며, 기존 평면 15 확장을 표준 자체에 통합했다(평면 4부터 7까지에 이미 존재하는 문자는 공백으로 남겨두었다). 또한 유니코드에 포함하기 위해 제출된 1988년 평면 14 버전의 추가 사항을 기반으로, 코드 포인트 68–40부터 시작하여 평면 3에 128개의 추가 한자를 추가했다.:115–122
CNS 11643 현재 목적 및 유니코드와의 관계
CNS 11643 레퍼토리는 교육에 사용되는 문자 외에도 타이완에서 호적 등록 및 주민등록증과 같은 행정 목적으로 사용되는 문자를 포함한다. 특히 평면 1과 2의 문자는 교육에 사용된다. CNS 11643에서는 교육에 사용되는 문자만 글리프 형식 정규화 대상이 된다. 이 코드는 계속 확장되어, 19개 평면까지 추가적인 평면이 초안으로 작성되었지만, 아직 CNS 11643 버전의 일부로 발행되지는 않았다. 2007년 판에 대한 2022년 개정안은 평면 2의 끝에 U+7934 礴 를 추가했으며, 평면 1과 2의 여러 글리프 형식을 수정했다.
1992년 및 2007년 CNS 11643 버전과 최근 작업 초안은 타이완에서 사용하기 위해 제출된 한중일 통합 한자에 대한 참조 글리프의 Unihan 소스 역할을 하지만, 2017년 기준 기준으로 유니코드에 해당하는 문자가 없거나 유니코드를 통해 왕복 변환되지 않는 수천 개의 CNS 11643 문자가 여전히 존재하며, 대부분 평면 10부터 14에 있다. 이들은 유니코드 보충용 개인용 영역으로 매핑된다.
CNS 11643 현재 목적 및 유니코드와의 관계
어떤 경우에는 두 개 이상의 CNS 11643 문자가 단일 유니코드 한중일 통합 한자에 해당한다. 이러한 경우(현재 한중일 호환용 한자 보충 블록에 포함된 경우를 제외하고) 유니코드 보충용 개인용 영역 코드 포인트로 매핑되지만, Ideographic Research Group에 참여하고 있는 타이베이 컴퓨터 협회는 미래에 이들을 표의 문자 변형 시퀀스로 등록할 가능성을 평가하고 있다.
CNS 11643 Big5와의 관계
Big5 인코딩의 레벨 1과 2는 각각 CNS 11643 평면 1과 2에 주로 해당하지만, 가끔 순서가 다르거나 Big5에만 있고 CNS 11643에는 없는 두 개의 중복 한자가 존재한다. 이는 범위 목록을 사용하여 매핑할 수 있다. 그러나 CNS 11643 평면 1의 213개 고전 부수는 Big5에서 사용할 수 있는 문자에 추가된 것이며(Big5 또는 HKSCS의 해당 한자 문자에 손실적으로 매핑될 수 있지만), 2007년에는 CNS 11643 평면 1에 추가 문자가 더해졌다.:115–122 Big5의 Big5-2003 변형은 CNS 11643의 부분 인코딩으로 정의된다.
CNS 11643 Big5와의 관계
Big5 한자 레퍼토리 내에서, 단 하나의 평면 1 문자가 CNS 11643의 첫 두 평면에 해당하는 문자로부터 유니코드에 다르게 매핑된다: U+5F5D (彝)로 매핑되는 반면, 그 CNS 평면 1 대응 문자는 U+5F5E (彞)의 관련 변형에 매핑된다; U+5F5D는 CNS 11643 평면 3에 별도로 포함되어 있다. 그러나 IBM에서 정의한 일부 Big5의 변형 매핑은 U+5F5D 대신 U+5F5E를 포함한다. 마찬가지로 Big5 레벨 2의 단일 문자(IBM 변형 포함)는 CNS 11643 평면 2 대응 문자(U+7B9A (箚)로 매핑되는 반면, Unihan 데이터베이스는 현재 CNS 11643 문자를 U+7B9A로 매핑한다)와 다른 유니코드 코드 포인트(U+5284 (劄)로 매핑)에 매핑된다. U+5284는 CNS 11643 평면 14에 나타난다.
GB 18030
GB 18030은 중국 정부 표준으로, 정보 기술 – 중국어 코드 문자 집합으로 설명되며 중국 내 소프트웨어에 필요한 언어 및 문자 지원을 정의한다. GB18030은 GB2312를 대체하는 중화인민공화국(PRC)의 공식 문자 집합에 대한 등록된 인터넷 이름이다. 유니코드 변환 형식 (즉, 모든 유니코드 코드 포인트의 인코딩)으로서, GB18030은 간체자와 정체자를 모두 지원한다. 또한 GB/T 2312, CP936, 및 GBK 1.0을 포함한 레거시 인코딩과도 호환된다.
유니코드 컨소시엄은 이 중국 표준의 최신 버전인 GB 18030-2022가 이전 버전인 GB 18030-2005에서 "33개의 다른 문자와 55개의 코드 위치를 포함하는" "파괴적인 변경"을 도입했다고 구현자들에게 경고했다. GB 18030-2022는 2023년 8월 1일부터 시행되었다. 이는 ICU 73.2 및 자바 21에 구현되었고, 이전 자바 8, 11, 17 (LTS 릴리스) 및 20.0.2로 백포트되었다.
GB 18030
인코딩 방식 외에도 이 표준은 어떤 추가 스크립트와 언어가 표현되어야 하는지, 그리고 이 표준이 누구에게 적용되는지에 대한 요구 사항을 포함한다. 그러나 이 표준은 중국어 한자에 대한 공식 문자 형태를 정의하지 않는다. 이는 통용규범한자표에 표준화되어 있다.
GB 18030 역사
GB18030 문자 집합은 공식적으로 "중국 국가 표준 GB 18030-2005: 정보 기술—중국어 코드화 문자 집합"이라고 불린다. GB는 Guójiā Biāozhǔn (国家标准)의 약어로, 중국어로 국가 표준을 의미한다. 이 표준은 2005년 11월 8일 베이징의 중국 표준 출판사에서 발행되었다. 표준의 일부만 의무 사항이다. 2006년 5월 1일부터 PRC에서 판매되는 모든 소프트웨어 제품에 대해 의무 하위 집합 지원이 공식적으로 요구된다.
GB 18030 역사
"중국 국가 표준 GB 18030-2000: 정보 기술—정보 교환을 위한 중국어 이데오그램 코드화 문자 집합—기본 세트 확장"으로 알려진 이 표준의 이전 버전은 2000년 3월 17일에 발행되었다. 인코딩 방식은 새 버전에서도 동일하며, GB-유니코드 매핑의 유일한 차이점은 GB 18030-2000이 문자 A8 BC (ḿ)를 개인 사용 코드 포인트 U+E7C7에 매핑하고, 문자 81 35 F4 37 (글리프 지정 없이)를 U+1E3F (ḿ)에 매핑한 반면, GB 18030-2005는 이 두 매핑 할당을 교환한다는 것이다.:534 한중일 통합 한자 확장 B의 출현과 같이 유니코드의 업데이트로 인해 더 많은 코드 포인트가 문자와 연결되었다. 중국의 소수민족이 사용하는 일부 문자, 예를 들어 몽골 문자 및 티베트 문자 (GB 16959-1997 및 GB/T 20542-2006)도 추가되었으며, 이는 표준 이름 변경의 이유가 되었다.
선행 표준들과 비교하여, GB 18030의 유니코드 매핑은 GBK 1.0에서 임시로 유니코드 Private Use Area 코드 포인트 (U+E000–F8FF)로 할당되었고 나중에 유니코드에 인코딩된 81개 문자에 대해 수정되었다. 이는 GB 18030의 부록 E에 명시되어 있다.:534:499 GB 18030-2005에는 여전히 유니코드 PUA에 매핑되는 24개의 문자가 있다.
GB 18030-2022 업데이트에서는 PUA에 매핑되어야 하는 문자 요구 사항이 완전히 해제되었으며 모든 문자는 표준 유니코드 코드 포인트에 매핑되어야 한다. 이 중 18개의 매핑은 GBK와 GB 18030 사이에서 발생한 것과 유사하게 위치 교환을 통해 업데이트되었다. 나머지 6개는 두 바이트 PUA 매핑을 유지했으므로 비 PUA 선호도를 따르기 위해 4바이트 시퀀스 변경이 필요하다.
GB 18030 국가 표준으로서
GB 18030의 첫 번째 버전인 GB 18030-2000 정보 기술 - 정보 교환용 중국어 코드 문자 집합 - 기본 집합 확장은 1바이트 및 2바이트 인코딩과 함께 한중일 통합 한자 확장 A(유니코드 3.0에 있는 문자들과 일치)에 대한 4바이트 인코딩으로 구성된다. 잠정적인 개인 할당을 포함한 이 부분집합의 해당 유니코드 코드 포인트는 전적으로 BMP에 있다. 이 부분들은 GB 18030-2000에서 완전히 필수적이다.:2 대부분의 주요 컴퓨터 회사들은 이미 유니코드의 특정 버전을 바이너리 형식 및 OS 호출에 사용되는 기본 형식으로 표준화했다. 그러나 그들은 주로 유니코드 1.0에서 원래 정의된 BMP의 코드 포인트만 지원했으며, 이는 65,536개의 코드 포인트만 지원하고 종종 UCS-2로 16비트로 인코딩되었다. 이 표준은 기본적으로 GBK를 기반으로 하는 확장으로, 한중일 통합 한자 확장 A에 추가 문자가 포함되어 있다.