위키백과

문자 인코딩

사용자가 입력한 문자나 기호들을 컴퓨터가 이용할 수 있는 신호로 만드는 것
(문자 집합에서 넘어옴)

문자 인코딩(文字 - , 영어: character encoding) 또는 텍스트 인코딩(text encoding)[1] 또는 줄여서 인코딩은 문자를 숫자 값으로 표현하는 쓰기 스크립트의 규칙이다. 문자 집합에는 자연어 기호뿐만 아니라 제어 문자나 공백 문자와 같이 언어 외부에서 의미나 기능을 가지는 코드도 포함될 수 있다. 인공어를 위한 문자 인코딩도 정의되었다. 인코딩된 문자 데이터는 컴퓨터에 의해 저장, 전송 및 변환될 수 있다.[2] 문자 인코딩을 구성하는 숫자 값은 코드 포인트로 알려져 있으며, 이들을 통틀어 코드 공간 또는 코드 페이지라고 한다.

ASCII로 "Wikipedia"라는 단어가 인코딩된 천공 테이프. 구멍의 존재와 부재는 각각 1과 0을 나타낸다. 예를 들어, W는 1010111로 인코딩된다.
두벌식 한글 자판.

광학 또는 전기 전보와 초기 컴퓨터에서 시작된 초기 문자 인코딩은 언어에서 사용되는 문자 중 일부만을 나타낼 수 있었으며, 때로는 대문자, 숫자 및 제한된 문장 부호로 제한되었다. 시간이 지남에 따라 ASCII, ISO/IEC 8859 및 UTF-8 및 UTF-16과 같은 유니코드 인코딩과 같이 더 많은 문자를 나타낼 수 있는 인코딩이 생성되었다.

2024년 5월 현재, 월드 와이드 웹에서 가장 인기 있는 문자 인코딩은 UTF-8로, 조사된 웹사이트의 98.2%에서 사용된다.[3] 응용 프로그램 및 운영체제 작업에서는 UTF-8과 UTF-16 모두 인기 있는 옵션이다.[4]

역사

편집

문자 코드의 역사는 한때 새로운 전기적 수단을 사용하여 기계로 중재된 문자 기반의 상징적 정보를 원거리로 전달해야 하는 진화하는 필요성을 보여준다. 초기 코드는 베이컨 암호, 점자, 국제 신호기 및 중국 전신 부호를 위한 중국어 문자의 4자리 인코딩(한스 스켈레루프, 1869)과 같은 수동 및 손으로 쓴 인코딩 및 암호화 시스템을 기반으로 했다. 전기 및 전기-기계적 기술이 채택되면서 이러한 초기 코드는 초기 기계의 새로운 기능과 한계에 맞게 조정되었다. 1840년대에 도입된 최초의 잘 알려진 전기 전송 문자 코드인 모스 부호는 4가지 "기호" (짧은 신호, 긴 신호, 짧은 공백, 긴 공백) 시스템을 사용하여 가변 길이 코드를 생성했다. 모스 부호의 일부 상업적 사용은 기계를 통해 이루어졌지만, 종종 전건으로 손으로 생성하고 귀로 해독할 수 있는 수동 코드로 사용되었으며, 아마추어 무선 및 항공 사용에서 여전히 사용된다. 대부분의 코드는 문자당 길이가 고정되어 있거나 고정 길이 코드의 가변 길이 시퀀스이다(예: 유니코드).[5]

문자 인코딩 시스템의 일반적인 예로는 모스 부호, 보도 코드, 미국 정보 교환 표준 부호(ASCII) 및 유니코드가 있다. 잘 정의되고 확장 가능한 인코딩 시스템인 유니코드는 대부분의 초기 문자 인코딩을 대체했지만, 현재까지의 코드 개발 경로는 상당히 잘 알려져 있다.

비트 5개로 인코딩된 보도 코드는 1870년 에밀 보도가 만들고 1874년에 특허를 받았으며, 1901년 도널드 머레이가 수정하고 1930년 CCITT가 국제 전신 알파벳 No. 2(ITA2)로 표준화했다. 보도라는 이름은 ITA2 및 그 변형에 잘못 적용되었다. ITA2는 많은 단점이 있었고, 많은 장비 제조업체에 의해 종종 개선되어 때로는 호환성 문제를 일으켰다.

 
EBCDIC 문자 집합이 있는 홀러리스 80열 천공 카드

허먼 홀러리스는 19세기 후반에 인구 조사 데이터를 분석하기 위해 천공 카드 데이터 인코딩을 발명했다. 처음에는 각 구멍 위치가 다른 데이터 요소를 나타냈지만, 나중에는 아래쪽 행에 0부터 9까지 번호를 매겨 숫자 정보를 인코딩했으며, 열의 구멍은 해당 행 번호를 나타냈다. 나중에는 열당 두 개 이상의 구멍을 허용하여 알파벳 데이터를 인코딩했다. 전기 기계식 제표기는 기계를 통해 카드의 움직임에 대한 펄스 타이밍으로 날짜를 내부적으로 표현했다.

IBM은 IBM 603 전자 곱셈기를 시작으로 전자 처리로 전환하면서 천공 카드 코드와 연결된 다양한 이진 인코딩 방식을 사용했다. IBM은 1953년부터 702[6] 및 704 컴퓨터, 그리고 이후의 IBM 700/7000 시리즈 및 IBM 1400 시리즈뿐만 아니라 관련 주변 기기에서도 여러 이진화 십진법(BCD) 6비트 문자 인코딩 방식을 사용했다. 당시 사용되던 천공 카드 코드는 숫자, 대문자 영어 글자 및 몇 가지 특수 문자로 제한되었기 때문에 6비트로 충분했다. 이러한 BCD 인코딩은 기존의 간단한 4비트 숫자 인코딩을 확장하여 알파벳 및 특수 문자를 포함했으며, 이미 널리 사용되던 천공 카드 인코딩에 쉽게 매핑되었다. IBM의 코드는 주로 IBM 장비와 함께 사용되었다. 당시 다른 컴퓨터 공급업체들도 유니박 I에서 사용된 인코딩과 같이 자체 문자 코드를 가지고 있었으며, 종종 6비트였다.[7] 그들은 일반적으로 IBM 장비에서 생성된 테이프를 읽을 수 있었다. IBM의 BCD 인코딩은 1963년 IBM 시스템/360을 위해 개발된 8비트 인코딩 방식인 확장 이진화 십진법 교환 부호(일반적으로 EBCDIC로 약칭됨)의 전신이었으며, 소문자를 포함한 더 큰 문자 집합을 특징으로 했다.

1959년 미국군은 필드데이터 코드를 정의했는데, 이는 미국 육군 통신대가 도입한 6비트 또는 7비트 코드였다. 필드데이터는 당시의 많은 현대적 문제(예: 기계 정렬을 위해 배열된 문자 및 숫자 코드)를 해결했지만, 목표에 미치지 못하고 단명했다. 1963년 ASCII 위원회(필드데이터 위원회의 일원인 W. F. 류버트를 포함)에서 첫 번째 ASCII 코드(X3.4-1963)가 발표되었는데, 이는 필드데이터의 대부분의 단점을 해결하고 더 간단한 7비트 코드를 사용했다. 많은 변경 사항은 특정 숫자 범위 내에서 정렬 가능한 문자 집합과 같이 미묘했다. ASCII63은 성공적이었고, 산업계에서 널리 채택되었으며, 1967년 ASCII 코드의 후속 발행(소문자를 추가하고 일부 "제어 코드" 문제를 수정)으로 ASCII67은 상당히 널리 채택되었다. ASCII67의 미국 중심적인 특성은 유럽 ECMA-6 표준에서 어느 정도 해결되었다.[8] 다양한 공급업체 확장 및 ISO/IEC 8859 시리즈와 같은 8비트 확장 ASCII 인코딩은 모든 ASCII 문자와 추가 비 ASCII 문자를 지원했다.

1980년대에 보편적으로 호환 가능한 문자 인코딩을 개발하려고 노력하면서 연구원들은 한편으로는 추가 문자를 수용하기 위해 더 많은 비트를 추가해야 하는 것처럼 보였지만, 다른 한편으로는 라틴 알파벳의 비교적 작은 문자 집합 사용자(여전히 컴퓨터 사용자 대부분을 구성)에게는 이러한 추가 비트가 당시 부족하고 비쌌던 컴퓨팅 자원의 막대한 낭비였다는 딜레마에 직면했다(이러한 사용자에게는 항상 0으로 채워졌기 때문). 1985년 일반 개인 컴퓨터 사용자의 하드 디스크 드라이브는 약 10메가바이트만 저장할 수 있었고, 도매 시장에서는 약 250달러(소매로 별도 구매 시 훨씬 더 높음)에 달했다.[9] 따라서 당시에는 모든 비트를 중요하게 만드는 것이 매우 중요했다.

결과적으로 발견되어 유니코드로 개발된[10] 절충안은 각 문자가 항상 특정 비트 시퀀스와 직접적으로 일치해야 한다는 가정(전신 코드 시대부터 이어져 온)을 깨는 것이었다. 대신 문자는 먼저 코드 포인트라고 불리는 추상적인 숫자 형태의 보편적인 중간 표현으로 매핑되었다. 그런 다음 코드 포인트는 문맥에 따라 다양한 방식으로, 다양한 기본 비트 수(코드 단위)로 표현되었다. 8비트 단위의 256개 이상과 같이 코드 단위 길이보다 높은 코드 포인트를 인코딩하려면, 이스케이프 시퀀스가 후속 비트가 더 높은 코드 포인트로 구문 분석되어야 함을 알리는 가변 길이 인코딩을 구현하는 것이 해결책이었다.

용어

편집

문자 인코딩과 관련된 다양한 용어는 종종 일관되지 않거나 잘못 사용된다.[10] 역사적으로, 동일한 표준은 문자의 레퍼토리와 그것들이 코드 단위 스트림으로 인코딩되는 방식(일반적으로 코드 단위당 하나의 문자)을 지정했다. 그러나 더 정교한 문자 인코딩의 출현으로 용어 간의 구분이 중요해졌다.

문자

편집

문자는 의미 값을 가지는 텍스트의 가장 작은 단위이다.[10][11]

문자가 무엇을 구성하는지는 문자 인코딩마다 다르다. 예를 들어, 발음 구별 기호가 있는 글자의 경우, 이를 인코딩하는 데 두 가지 다른 접근 방식을 취할 수 있다. 단일 통합 문자(선조합 문자라고도 함)로 인코딩하거나, 단일 자체로 결합되는 별도의 문자로 인코딩할 수 있다. 전자는 텍스트 처리 시스템을 단순화하지만, 후자는 모든 문자/발음 구별 기호 조합을 텍스트에서 사용할 수 있도록 한다. 합자도 비슷한 문제를 제기한다. 아랍어와 히브리어와 같은 일부 문자 체계는 다른 문맥에서 다른 방식으로 연결되지만 동일한 의미 문자를 나타내는 자소와 같은 것을 수용해야 한다.

문자 집합

편집

문자 집합은 텍스트를 나타내는 데 사용되는 문자 모음이다.[10][11] 예를 들어, 라틴 음소문자와 그리스 문자는 문자 집합이다.

부호화 문자 집합

편집

부호화 문자 집합은 각 항목이 고유하게 숫자 값으로 매핑된 문자 집합이다.[11]

일반적으로 구식으로 간주되지만, 이것은 코드 페이지라고도 알려져 있다.[10] 원래 코드 페이지는 특정 문자 인코딩을 정의한 IBM 설명서의 페이지 번호를 의미했다.[12] 마이크로소프트, SAP, 오라클을 포함한 다른 공급업체들도 윈도우 코드 페이지 및 코드 페이지 437을 포함한 자체 코드 페이지를 발행했다. 더 이상 설명서의 특정 페이지를 지칭하지 않음에도 불구하고, 많은 문자 인코딩은 여전히 동일한 번호로 식별된다. 마찬가지로, 코드 페이지라는 용어는 여전히 문자 인코딩을 지칭하는 데 사용된다.

유닉스 및 유닉스 계열 시스템에서는 일반적으로 로케일의 더 큰 문맥에서 charmap이라는 용어가 사용된다.

IBM의 문자 데이터 표현 아키텍처(CDRA)는 각 엔티티에 부호화 문자 집합 식별자(CCSID)를 지정하는데, 이는 charset, character set, code page 또는 CHARMAP으로 다양하게 불린다.[13]

문자 레퍼토리

편집

문자 레퍼토리는 특정 부호화 문자 집합으로 나타낼 수 있는 문자 집합이다.[11][14] 레퍼토리는 닫혀 있을 수 있다. 즉, 새 표준을 생성하지 않고는 추가가 허용되지 않는다(ASCII 및 대부분의 ISO-8859 시리즈의 경우와 같음). 또는 열려 있을 수 있다. 즉, 추가가 허용된다(유니코드 및 제한된 범위 내에서 윈도우 코드 페이지의 경우와 같음).[14]

코드 포인트

편집

코드 포인트는 부호화 문자 집합에서 문자의 값 또는 위치이다.[11] 코드 포인트는 코드 단위의 시퀀스로 표현된다. 매핑은 인코딩에 의해 정의된다. 따라서 코드 포인트를 나타내는 데 필요한 코드 단위의 수는 인코딩에 따라 달라진다.

  • UTF-8: 코드 포인트는 하나, 둘, 셋 또는 네 개의 코드 단위 시퀀스로 매핑된다.
  • UTF-16: 코드 단위는 8비트 코드 단위보다 두 배 길다. 따라서 스칼라 값이 U+10000 미만인 코드 포인트는 단일 코드 단위로 인코딩된다. U+10000 이상의 값을 가진 코드 포인트는 각각 두 개의 코드 단위가 필요하다. 이러한 코드 단위 쌍은 UTF-16에서 "유니코드 서로게이트 쌍"이라는 고유한 용어를 가지고 있다.
  • UTF-32: 32비트 코드 단위는 모든 코드 포인트가 단일 코드 단위로 표현될 수 있을 만큼 충분히 크다.
  • GB 18030: 코드 단위가 작기 때문에 코드 포인트당 여러 코드 단위가 일반적이다. 코드 포인트는 하나, 둘 또는 네 개의 코드 단위로 매핑된다.[15]

코드 공간

편집

코드 공간은 부호화 문자 집합에 의해 포괄되는 숫자 값의 범위이다.[11][13]

코드 단위

편집

코드 단위는 문자 인코딩에서 문자를 나타낼 수 있는 최소 비트 조합이다(컴퓨터 과학 용어로는 문자 인코딩의 워드 크기이다).[11][13] 일반적인 코드 단위는 7비트, 8비트, 16비트, 32비트를 포함한다. 일부 인코딩에서는 일부 문자가 여러 코드 단위로 인코딩된다.

예를 들어:

유니코드 인코딩

편집

유니코드와 그 병렬 표준인 ISO/IEC 10646 국제 문자 세트는 함께 문자 인코딩을 위한 통합 표준을 구성한다. 유니코드는 문자를 바이트에 직접 매핑하는 대신, 문자를 고유한 자연수(코드 포인트)에 매핑하는 부호화 문자 집합, 해당 코드 포인트를 고정 크기 자연수(코드 단위) 시리즈에 매핑하는 방법, 마지막으로 해당 단위를 옥텟(바이트) 스트림으로 인코딩하는 방법을 별도로 정의한다. 이 분해의 목적은 다양한 방식으로 인코딩될 수 있는 보편적인 문자 집합을 확립하는 것이다. 모델을 정확하게 설명하기 위해 유니코드는 기존 용어를 사용하고 새로운 용어를 정의한다.[13]

추상 문자 레퍼토리

편집

추상 문자 레퍼토리(ACR)는 시스템이 지원하는 추상 문자의 전체 집합이다. 유니코드는 개방형 레퍼토리를 가지고 있다. 즉, 시간이 지남에 따라 새로운 문자가 레퍼토리에 추가될 것이다.

부호화 문자 집합

편집

부호화 문자 집합(CCS)은 문자를 코드 포인트에 매핑하는 함수이다(각 코드 포인트는 하나의 문자를 나타낸다). 예를 들어, 주어진 레퍼토리에서 라틴 알파벳의 대문자 "A"는 코드 포인트 65로, 문자 "B"는 66 등으로 표현될 수 있다. 여러 부호화 문자 집합이 동일한 문자 레퍼토리를 공유할 수 있다. 예를 들어 ISO/IEC 8859-1과 IBM 코드 페이지 037 및 500은 모두 동일한 레퍼토리를 다루지만 다른 코드 포인트에 매핑한다.

문자 인코딩 형식

편집

문자 인코딩 형식(CEF)은 숫자를 고정 길이의 비트 시퀀스로 표현하는 시스템(즉, 거의 모든 컴퓨터 시스템)에 저장을 용이하게 하기 위해 코드 포인트를 코드 단위로 매핑하는 것이다. 예를 들어, 16비트 단위로 숫자 정보를 저장하는 시스템은 각 단위에서 코드 포인트 0에서 65,535까지만 직접 표현할 수 있지만, 더 큰 코드 포인트(예: 65,536에서 1.4백만)는 여러 16비트 단위를 사용하여 표현할 수 있다. 이러한 대응은 CEF에 의해 정의된다.

문자 인코딩 스킴

편집

문자 인코딩 스킴(CES)은 옥텟 기반 파일 시스템에 저장을 용이하게 하거나 옥텟 기반 네트워크를 통해 전송을 용이하게 하기 위해 코드 단위를 옥텟 시퀀스로 매핑하는 것이다. 간단한 문자 인코딩 스킴에는 UTF-8, UTF-16BE, UTF-32BE, UTF-16LE 및 UTF-32LE가 포함된다. UTF-16, UTF-32 및 ISO/IEC 2022와 같은 복합 문자 인코딩 스킴은 바이트 순서 표식 또는 이스케이프 시퀀스를 사용하여 여러 간단한 스킴 간을 전환한다. 압축 스킴은 코드 단위당 사용되는 바이트 수를 최소화하려고 한다(SCSU 및 BOCU와 같은).

UTF-32BE와 UTF-32LE는 더 간단한 CES이지만, 유니코드를 사용하는 대부분의 시스템은 하위 호환성이 있고 유니코드 코드 포인트를 가변 길이 옥텟 시퀀스로 매핑하는 UTF-8 또는 고정 길이 UCS-2BE와 하위 호환성이 있고 유니코드 코드 포인트를 가변 길이 16비트 워드 시퀀스로 매핑하는 UTF-16BE를 사용한다. 자세한 내용은 유니코드 인코딩 비교를 참조하라.

상위 수준 프로토콜

편집

유니코드 문자, 특히 유니코드에서 동일한 문자로 '통일'된 지역 변형이 있는 경우 특정 변형을 선택하기 위한 추가 정보를 제공하는 상위 수준 프로토콜이 있을 수 있다. XML 속성 xml:lang이 그 예이다.

유니코드 모델은 CCS, CEF 및 CES 레이어를 모두 포괄하는 문자 시퀀스를 바이트 시퀀스에 직접 할당하는 다른 시스템에 대해 "문자 맵"이라는 용어를 사용한다.[13]

코드 포인트 문서화

편집

문자는 일반적으로 'U+' 뒤에 십육진법 코드 포인트 값이 붙어 문서화된다. 유니코드 표준에 대한 유효한 코드 포인트 범위(코드 공간)는 U+0000부터 U+10FFFF까지이며, 0부터 16까지의 번호로 식별되는 17개의 평면으로 나뉜다. U+0000부터 U+FFFF까지의 문자는 기본 다국어 평면(BMP)이라고 불리는 평면 0에 있다. 이 평면에는 가장 일반적으로 사용되는 문자가 포함되어 있다. 다른 평면의 U+10000부터 U+10FFFF까지의 문자는 보충 문자라고 불린다.

다음 표에는 코드 포인트의 예가 포함되어 있다.

문자 코드 포인트 자체
라틴 A U+0041 Α
라틴 샤프 S U+00DF ß
동한 U+6771 東
앰퍼샌드 U+0026 &
역전된 느낌표 U+00A1 ¡
섹션 기호 U+00A7 §

예시

편집

"ab̲c𐐀"를 생각해 보라. 이 문자열은 유니코드 조합 문자(U+0332 ̲ )와 보충 문자(U+10400 𐐀 )를 포함한다. 이 문자열은 논리적으로 동등하지만, 다양한 상황이나 요구 사항에 적합한 여러 유니코드 표현을 가지고 있다.

  • 네 개의 합성 문자:
    a, b̲, c, 𐐀
  • 다섯 개의 자소:
    a, b, _, c, 𐐀
  • 다섯 개의 유니코드 코드 포인트:
    U+0061, U+0062, U+0332, U+0063, U+10400
  • 다섯 개의 UTF-32 코드 단위(32비트 정수 값):
    0x00000061, 0x00000062, 0x00000332, 0x00000063, 0x00010400
  • 여섯 개의 UTF-16 코드 단위(16비트 정수):
    0x0061, 0x0062, 0x0332, 0x0063, 0xD801, 0xDC00
  • 아홉 개의 UTF-8 코드 단위(8비트 값 또는 바이트):
    0x61, 0x62, 0xCC, 0xB2, 0x63, 0xF0, 0x90, 0x90, 0x80

특히 𐐀는 32비트 값 하나(UTF-32), 16비트 값 두 개(UTF-16), 또는 8비트 값 네 개(UTF-8)로 표현된다. 각 형식이 자체를 나타내는 데 동일한 총 비트 수(32)를 사용하지만, 실제 숫자 바이트 값들이 어떻게 관련되어 있는지는 명확하지 않다.

트랜스코딩

편집

여러 문자 인코딩을 사용하는 환경을 지원하기 위해 문자 인코딩 스킴 간에 텍스트를 변환하는 소프트웨어가 개발되었다. 이 과정은 트랜스코딩으로 알려져 있다. 주목할 만한 소프트웨어는 다음과 같다.

일반적인 문자 인코딩

편집
  이 부분의 본문은 텍스트 인코딩의 인기도입니다.

2024년 5월 현재, 웹에서 가장 많이 사용되는 문자 인코딩은 UTF-8이며, 조사된 웹사이트의 98.2%에서 사용된다.[3] 응용 프로그램 및 운영체제 작업에서는 UTF-8과 UTF-16 모두 인기 있는 옵션이다.[4][19]

같이 보기

편집

각주

편집
  1. ↑ (마이크로소프트-파일을 열거나 저장할 때 텍스트 인코딩 선택)https://support.microsoft.com/ko-kr/office/%ED%8C%8C%EC%9D%BC%EC%9D%84-%EC%97%B4%EA%B1%B0%EB%82%98-%EC%A0%80%EC%9E%A5%ED%95%A0-%EB%95%8C-%ED%85%8D%EC%8A%A4%ED%8A%B8-%EC%9D%B8%EC%BD%94%EB%94%A9-%EC%84%A0%ED%83%9D-60d59c21-88b5-4006-831c-d536d42fd861#bm1
  2. ↑ “Character Encoding Definition”. 《The Tech Terms Dictionary》. 2010년 9월 24일. 
  3. ↑ 가 나 “Usage Survey of Character Encodings broken down by Ranking”. 《W3Techs》. 2024년 4월 29일에 확인함. 
  4. ↑ 가 나 “Charset”. 《Android Developers》. 2021년 1월 2일에 확인함. Android note: The Android platform default is always UTF-8. 
  5. ↑ Tom Henderson (2014년 4월 17일). “Ancient Computer Character Code Tables – and Why They're Still Relevant”. Smartbear. 2014년 4월 30일에 원본 문서에서 보존된 문서. 2014년 4월 29일에 확인함. 
  6. ↑ “IBM Electronic Data-Processing Machines Type 702 Preliminary Manual of Information” (PDF). 1954. 80쪽. 22-6173-1. 2022년 10월 9일에 원본 문서 (PDF)에서 보존된 문서 – bitsavers.org 경유. 
  7. ↑ “UNIVAC System” (PDF) (reference card). 
  8. ↑ Tom Jennings (2016년 4월 20일). “An annotated history of some character codes”. 《Sensitive Research》. 2018년 11월 1일에 확인함. 
  9. ↑ Strelho, Kevin (1985년 4월 15일). “IBM Drives Hard Disks to New Standards”. 《InfoWorld》 (Popular Computing Inc.). 29–33면. 2020년 11월 10일에 확인함. 
  10. ↑ 가 나 다 라 마 Shawn Steele (2005년 3월 15일). “What's the difference between an Encoding, Code Page, Character Set and Unicode?”. 《Microsoft Docs》. 
  11. ↑ 가 나 다 라 마 바 사 “Glossary of Unicode Terms”. Unicode Consortium. 
  12. ↑ “VT510 Video Terminal Programmer Information”. 디지털 이큅먼트 코퍼레이션 (DEC). 7.1. Character Sets - Overview. 2016년 1월 26일에 원본 문서에서 보존된 문서. 2017년 2월 15일에 확인함. In addition to traditional DEC and ISO character sets, which conform to the structure and rules of ISO 2022, the VT510 supports a number of IBM PC code pages (page numbers in IBM's standard character set manual) in PCTerm mode to emulate the console terminal of industry-standard PCs. 
  13. ↑ 가 나 다 라 마 Whistler, Ken; Freytag, Asmus (2022년 11월 11일). “UTR#17: Unicode Character Encoding Model”. Unicode Consortium. 2023년 8월 12일에 확인함. 
  14. ↑ 가 나 〈Chapter 3: Conformance〉. 《The Unicode Standard Version 15.0 – Core Specification》 (PDF). Unicode Consortium. September 2022. ISBN 978-1-936213-32-0. 
  15. ↑ “Terminology (The Java Tutorials)”. Oracle. 2018년 3월 25일에 확인함. 
  16. ↑ “Encoding.Convert Method”. 《Microsoft .NET Framework Class Library》. 
  17. ↑ “MultiByteToWideChar function (stringapiset.h)”. 《Microsoft Docs》. 2021년 10월 13일. 
  18. ↑ “WideCharToMultiByte function (stringapiset.h)”. 《Microsoft Docs》. 2022년 8월 9일. 
  19. ↑ Galloway, Matt (2012년 10월 9일). “Character encoding for iOS developers. Or UTF-8 what now?”. 《Matt Galloway》 (영어). 2021년 1월 2일에 확인함. in reality, you usually just assume UTF-8 since that is by far the most common encoding. 

외부 링크

편집
원본 주소 "https://ko.wikipedia.org/w/index.php?title=문자_인코딩&oldid=40303479#문자_인코딩의_구성"