문자 부호화

Character encoding
"Wikipedia"라는 단어가 ASCII로 인코딩된 천공 테이프.홀의 유무는 각각 1과 0을 나타냅니다.예를 들어 "W"는 "1010111"로 부호화됩니다.

문자 인코딩은 그래픽 문자, 특히 인간의 언어로 쓰여진 문자에 숫자를 할당하는 과정으로 디지털 [1]컴퓨터를 사용하여 숫자를 저장, 전송 및 변환할 수 있습니다.문자 인코딩을 구성하는 숫자는 "코드 포인트"라고 하며, 집합적으로 "코드 공간", "코드 페이지" 또는 "문자 맵"으로 구성됩니다.

광학 또는 전기 전신과 관련된 초기 문자 코드는 문자 언어에서 사용되는 문자의 하위 집합만 나타낼 수 있으며, 때로는 대문자, 숫자 및 일부 구두점만 나타낼 수 있습니다.현대 컴퓨터 시스템의 데이터 디지털 표현 비용이 낮기 때문에 많은 문자 언어에서 사용되는 대부분의 문자를 나타내는 보다 정교한 문자 코드(유니코드 등)를 사용할 수 있습니다.국제적으로 인정되고 있는 표준을 사용한 문자 부호화에 의해, 전 세계에서 전자 형식의 텍스트를 교환할 수 있습니다.

역사

문자 코드의 역사는 한 때 누벨이었던 전기 수단을 사용하여 먼 거리에 걸쳐 기계에서 매개한 문자 기반 기호 정보에 대한 진화하는 필요성을 보여준다.최초의 암호는 베이컨의 암호, 점자, 국제 해상 신호 플래그, 중국 전신 코드용 한자 4자리 인코딩과 같은 수동 및 손으로 쓴 부호화와 암호 체계에 기초했다.전기 및 전기 기계 기술의 채택으로 이러한 초기 코드는 초기 기계의 새로운 기능과 제한 사항에 맞게 조정되었습니다.1840년대에 도입된 가장 초기의 잘 알려진 전기 전송 문자 코드인 모르스 부호는 가변 길이의 코드를 생성하기 위해 4개의 "심볼" (단신호, 긴 신호, 짧은 공간, 긴 공간) 시스템을 사용했습니다.비록 모스 부호의 상업적 용도는 기계를 통한 것이었지만, 그것은 종종 수동 부호로 사용되었고, 전보 키로 손으로 만들어지고 귀로 읽을 수 있으며, 아마추어 무선 및 항공적 용도를 지속하고 있다.대부분의 코드는 문자당 고정 길이 또는 고정 길이 코드의 가변 길이 시퀀스(예: 유니코드)[2]입니다.

문자 부호화 시스템의 일반적인 예로는 모스 코드, Baudot 코드, American Standard Code for Information Interchange(ASCII), Unicode 등이 있습니다.잘 정의되고 확장 가능한 인코딩 시스템인 유니코드는 대부분의 초기 문자 인코딩을 대체했지만, 현재까지의 코드 개발 경로는 꽤 잘 알려져 있다.

5비트 부호화인 보도 코드는 1870년 에밀 보도에 의해 만들어졌고 1874년 특허를 받았으며 1901년 도널드 머레이에 의해 수정되었으며 1930년 CCITT에 의해 국제 전신 알파벳 번호 2(ITA2)로 표준화되었다."baudot"이라는 이름이 ITA2 및 ITA2의 많은 변형에 잘못 적용되었습니다.ITA2는 많은 단점을 안고 있으며 많은 기기 제조업체에 의해 종종 "개선"되어 호환성 문제가 발생하기도 했습니다.1959년 미군은 미 육군 신호부대가 도입한 6비트 또는 7비트 코드인 Fieldata 코드를 정의했다.Fieldata는 당시 많은 현대적 문제(예: 기계 조회를 위해 배열된 문자와 숫자 코드)를 해결했지만 Fieldata는 목표에 미치지 못했고 오래가지 못했다.1963년 ASCII 위원회(적어도 Fieldata 위원회의 멤버인 W. F. Leubbert)는 보다 단순한 코드를 사용하여 Fieldata의 대부분의 단점을 해결한 최초의 ASCII(American Standard Code for Information Interchange) 코드를 발표했다(X3.4-1963).많은 변경은 특정 수치 범위 내의 조합 가능한 문자 집합과 같이 미묘했다.ASCII63은 업계에서 널리 채택되었으며 1967년 ASCII 코드 후속호(소문자를 추가하고 일부 "제어 코드" 문제를 수정)와 함께 상당히 광범위하게 채택되었습니다.ASCII67의 미국 중심성은 유럽 ECMA-6 [3]표준에서 어느 정도 다루어졌습니다.

EBCDIC 문자 세트가 있는 Hollerith 80 컬럼 펀치 카드

Herman Hollerith는 인구조사 데이터를 분석하기 위해 19세기 말에 펀치 카드 데이터 인코딩을 발명했다.처음에는 각 홀 위치가 서로 다른 데이터 요소를 나타냈지만, 나중에는 아래쪽 행에 0 ~9의 번호를 매겨 숫자 정보를 인코딩하고 행 번호를 나타내는 컬럼에 펀치를 넣었습니다.이후 알파벳 데이터는 열당 두 개 이상의 펀치를 허용하여 인코딩되었습니다.전기기계식 표계산기는 내부적으로 기계를 통과하는 카드의 움직임에 상대적인 펄스의 타이밍으로 날짜를 나타냅니다.IBM은 IBM 603 Electronic Multiplier를 시작으로, 펀치 카드 코드에 연결된 다양한 바이너리 인코딩 방식을 사용했습니다.

IBM의 BCD(Binary Coded Decimal)는 1953년 초에 IBM이 702[4] 및 704 컴퓨터, 이후 7000 시리즈 및 1400 시리즈 및 관련 주변기기에서 사용한 6비트 인코딩 체계입니다.당시 펀치된 카드코드는 숫자, 대문자 영문 및 특수문자만 허용되었기 때문에 6비트면 충분했습니다.BCD는 기존의 간단한 4비트 숫자 인코딩을 알파벳과 특수 문자를 포함하도록 확장하여 이미 널리 사용되고 있는 펀치 카드 인코딩에 쉽게 매핑했습니다.IBM 코드는 주로 IBM 장비와 함께 사용되었습니다. 그 시대의 다른 컴퓨터 공급업체들은 그들만의 문자 코드(종종 6비트)를 가지고 있었지만, 대개 IBM 장비에서 생산된 테이프를 읽을 수 있는 능력을 가지고 있었습니다.BCD는 IBM System/360용으로 1963년에 개발된 8비트 인코딩 체계로 소문자를 포함한 더 큰 문자 집합을 특징으로 하는 IBM의 확장 이진 코드 십진수 교환 코드(일반적으로 EBCDIC)의 선구자였습니다.

이러한 세트의 제한은 곧 [to whom?]명백해졌고, 이를 확장하기 위한 많은 임시 방법이 개발되었습니다.동아시아 문자 CJK 패밀리를 포함한 다양한 언어에 대해 더 많은 문자 시스템을 지원해야 하는 필요성은 훨씬 더 많은 수의 문자를 지원해야 했고 기존의 임시 [citation needed]방식보다 문자 인코딩에 대한 체계적인 접근 방식을 요구했습니다.

1980년대 연구자들은 보편적으로 교환 가능한 문자 인코딩을 개발하려고 노력하면서 한편으로는 추가 문자를 수용하기 위해 더 많은 비트를 추가해야 하는 딜레마에 직면했지만, 다른 한편으로는 상대적으로 작은 문자 집합의 사용자들(아직도 com의 대부분을 구성)에게는 더 많은 비트를 추가해야 했다.이러한 추가 비트는 (이러한 사용자에게는 항상 0이 되기 때문에) 당시 사용되던 컴퓨팅 리소스의 엄청난 낭비였습니다.1985년 PC 사용자의 평균 하드 디스크 드라이브는 약 10메가바이트밖에 저장할 수 없었고 도매 시장에서는 약 250달러(소매점에서 [5]별도로 구입하는 경우에는 훨씬 더 비트가 필요함)의 비용이 들었습니다. 따라서 당시에는 모든 비트를 계산하는 것이 매우 중요했습니다.

결국 Unicode로 발견되어 개발된 타협적 해결책은 각 문자가 항상 특정 비트 시퀀스에 직접 대응해야 한다는 가정(전신 코드로의 날짜 변경)을 깨는 것이었습니다.대신, 문자는 먼저 코드 포인트라고 불리는 추상 숫자의 형태로 범용 중간 표현에 매핑됩니다.코드 포인트는 다양한 방법으로 표현되며 컨텍스트에 따라 문자(코드 단위)당 다양한 기본 비트 수로 표현됩니다.8비트 유닛의 경우 256을 초과하는 등 코드 유닛의 길이보다 큰 코드 포인트를 인코딩하기 위해 해결책은 이스케이프 시퀀스가 후속 비트를 더 높은 코드 포인트로 해석해야 한다는 신호를 보내는 가변 폭 인코딩을 구현하는 것이었습니다.

용어.

문자 인코딩 관련 용어
KB Dubeolsik for Old Hangul (NG3).svg
  • 문자는 의미 값이 있는 텍스트의 최소 단위입니다.
  • 문자 집합은 여러 언어로 사용될 수 있는 문자 집합입니다.예:라틴 문자 집합은 영어와 대부분의 유럽 언어에서 사용되지만 그리스 문자 집합은 그리스 언어에서만 사용됩니다.
  • 부호화된 문자 집합은 각 문자가 고유한 숫자에 대응하는 문자 집합입니다.
  • 코드화된 문자 집합의 코드 포인트는 문자 집합 또는 코드 공간에서 허용되는 값입니다.
  • 코드 공간은 값이 코드 포인트인 정수 범위입니다.
  • 코드 유닛은 7비트, 8비트, 16비트 등의 문자 부호화 방식의 "워드 크기"입니다.일부 방식에서는 여러 개의 코드 단위를 사용하여 일부 문자가 인코딩되므로 가변 길이 인코딩이 발생합니다.일부 문서에서는 [6]코드 단위를 코드 값이라고 합니다.
캐릭터 레퍼토리(추상적인 캐릭터 세트)

문자 레퍼토리는 라틴어, 키릴어, 중국어, 한국어, 일본어, 히브리어, 아람어 등 다양한 문자에서 볼 수 있는 100만 자 이상의 추상 모음이다.

악보 같은 다른 기호들도 캐릭터 레퍼토리에 포함되어 있다.Unicode 및 GB 18030 규격 모두 문자 레퍼토리가 있습니다.하나의 표준에 새로운 문자가 추가되면 다른 표준에서도 패리티를 유지하기 위해 해당 문자가 추가됩니다.

코드 유닛 사이즈는 특정 인코딩의 비트 측정과 동일합니다.

  • US-ASCII의 코드 유닛은 7비트로 구성됩니다.
  • UTF-8, EBCDIC 및 GB 18030의 코드 유닛은 8비트로 구성됩니다.
  • UTF-16의 코드 유닛은 16비트로 구성됩니다.
  • UTF-32의 코드 유닛은 32비트로 구성됩니다.

코드 유닛의 예:문자 "abc" 뒤에 U+10400 𐐨 DESERET 대문자 LONG I(1 char32_t, 2 char16_t 또는 4 char8_t로 표시됨)가 이어지는 문자열로 간주합니다.이 문자열에는 다음이 포함됩니다.

  • 4글자
  • 4개의 코드 포인트
  • 다음 중 하나:
    UTF-32의 4개의 코드 유닛(000061, 000062, 000063, 00010400)
    UTF-16의 5개의 코드 유닛(0061, 0062, 0063, d801, dc00) 또는
    UTF-8의 7개의 코드 유닛(61, 62, 63, f0, 90, 90, 80)

Unicode의 문자를 참조하는 규칙은 16진수 코드 포인트 값 뒤에 'U+'로 시작하는 것입니다.Unicode 표준의 유효한 코드 포인트의 범위는 U+0000 ~ U+10FFF이며, 숫자 0 ~ 16으로 식별되는 17개의 플레인으로 나뉩니다.U+0000 ~ U+FFFF 범위의 문자는 Basic Multilinguage Plane(BMP; 기본 다국어 플레인)이라고 불리는 플레인0 에 있습니다.이 평면에는 가장 일반적으로 사용되는 문자가 포함되어 있습니다.다른 플레인에서 U+10000 ~ U+10FFF 범위의 문자를 보조 문자라고 합니다.

다음 표에 코드 포인트 값의 예를 나타냅니다.

성격 유니코드 코드 포인트 글리프
라틴계 여자 U+0041 알파
라틴 샤프 S U+00DF ß
동양의 한 U+6771 東
앰퍼샌드 U+0026 &
반전 느낌표 U+00A1 ¡
단면 부호 U+00A7 §

코드 포인트는 일련의 코드 단위로 나타납니다.매핑은 인코딩으로 정의됩니다.따라서 코드 포인트를 나타내는 데 필요한 코드 유닛의 수는 인코딩에 따라 달라집니다.

  • UTF-8: 코드 포인트는 1개, 2개, 3개 또는 4개의 코드 단위로 구성됩니다.
  • UTF-16: 코드 단위는 8비트 코드 단위의 2배입니다.따라서 스칼라 값이 U+10000보다 작은 모든 코드포인트는 단일 코드유닛으로 부호화 됩니다값이 U+10000 이상인 코드 포인트에는 각각 2개의 코드 유닛이 필요합니다.이들 코드 유닛의 쌍은 UTF-16에서 유니코드 대리쌍이라는 고유한 용어를 가지고 있습니다.
  • UTF-32: 32비트 코드 유닛은 모든 코드 포인트가 단일 코드 유닛으로 표현될 정도로 충분히 큽니다.
  • GB 18030: 코드 단위가 작기 때문에 코드 포인트당 여러 개의 코드 단위가 일반적입니다.코드 포인트는 1개, 2개 또는 4개의 코드 [7]유닛에 매핑됩니다.

유니코드 부호화 모델

Unicode와 병렬 표준인 ISO/IEC 10646 유니버설 문자 집합은 모두 현대적인 통합 문자 인코딩을 구성합니다.문자를 옥텟(바이트)에 직접 매핑하는 것이 아니라 사용할 수 있는 문자, 대응하는 자연수(코드 포인트), 일련의 고정 사이즈 자연수(코드 단위)로 인코딩되는 방법, 마지막으로 이러한 단위를 옥텟의 스트림으로 인코딩하는 방법을 개별적으로 정의합니다.이 분해의 목적은 다양한 방법으로 [8]부호화할 수 있는 범용 문자 세트를 확립하는 것입니다.이 모델을 올바르게 기술하려면 "문자 집합" 및 "문자 인코딩"보다 더 정확한 용어가 필요합니다.현대 모델에서 사용되는 용어는 다음과 같습니다.[8]

문자 레퍼토리는 시스템이 지원하는 추상 문자의 전체 집합입니다.레퍼토리는 닫힙니다.즉, 새로운 표준(ASCII 및 ISO-8859 시리즈의 대부분의 경우)을 작성하지 않으면 추가할 수 없습니다.또, 오픈되어 있는 경우도 있습니다(Unicode의 경우와 같이, Windows 코드 페이지도 한정되어 있습니다.주어진 레퍼토리의 문자는 기본 정보 단위로 문자 시스템을 나누는 방법에 대해 내려진 결정을 반영합니다.라틴어, 그리스어, 키릴어 알파벳의 기본 변형은 문자, 숫자, 구두점 및 공백과 같은 몇 개의 특수 문자로 나눌 수 있으며, 모두 읽힌 순서대로 표시되는 단순한 선형 시퀀스로 배열할 수 있습니다.그러나 이러한 알파벳을 사용하더라도 분음 부호는 복잡한 문제가 됩니다. 즉, 문자 및 분음 부호를 포함하는 단일 문자의 일부이거나(사전 구성 문자로 알려져 있음) 개별 문자로 간주될 수 있습니다.전자는 훨씬 단순한 텍스트 처리 시스템을 허용하지만 후자는 텍스트에서 문자/분음 부호 조합을 사용할 수 있습니다.연결도 비슷한 문제를 일으킵니다.아랍어와 히브리어와 같은 다른 문자 체계는 서로 다른 상황에 따라 서로 다른 방식으로 결합된 양방향 텍스트와 문자와 같은 것들을 수용할 필요성 때문에 더 복잡한 문자 레퍼토리로 표현된다.

코드 문자 집합(CCS)은 문자를 코드 포인트에 매핑하는 함수입니다(각 코드 포인트는 하나의 문자를 나타냅니다).예를 들어, 특정 레퍼토리에서 라틴 알파벳의 대문자 "A"는 코드 포인트 65, 문자 "B" ~ 66 등으로 나타낼 수 있습니다.예를 들어 ISO/IEC 8859-1과 IBM 코드 페이지 037 및 500은 모두 동일한 레퍼토리를 다루지만 서로 다른 코드 포인트에 매핑됩니다.

문자 부호화 형식(CEF)은 숫자를 고정 길이의 비트 시퀀스로 나타내는 시스템(실제로는 모든 컴퓨터 시스템)에서 코드 포인트를 코드 유닛에 매핑하는 것입니다.예를 들어 16비트 단위로 숫자 정보를 저장하는 시스템은 각 단위로 코드 포인트0 ~ 65,535만을 직접 나타낼 수 있지만 16비트 단위를 여러 개 사용하여 더 큰 코드 포인트(65,536 ~140만)를 나타낼 수 있습니다.이 대응은 CEF에 의해 정의됩니다.

다음으로 문자 부호화 방식(CES)은 옥텟 기반 파일 시스템 또는 옥텟 기반 네트워크를 통한 전송을 용이하게 하기 위해 일련의 옥텟에 코드 단위를 매핑하는 것입니다.단순한 문자 부호화 방식에는 UTF-8, UTF-16BE, UTF-32BE, UTF-16LE 또는 UTF-32LE가 있습니다.UTF-16, UTF-32 및 ISO/IEC 2022 등의 복합 문자 부호화 방식은 바이트 순서 또는 이스케이프 번호를 사용하여 여러 개의 단순한 문자 부호화 방식을 전환합니다., 및 Punycode).

UTF-32BE는 단순한 CES이지만 Unicode를 사용하는 대부분의 시스템에서는 고정폭 ASCII와 하위호환성이 있는 UTF-8과 고정폭 UCS-2BE와 하위호환성이 있는 UTF-16BE와 Unicode 코드포인트를 16비트시퀀스에 매핑합니다.상세한 것에 대하여는, Unicode 인코딩의 비교를 참조해 주세요.

마지막으로, 유니코드 문자의 특정 변형을 선택하기 위한 추가 정보를 제공하는 더 높은 수준의 프로토콜이 있을 수 있으며, 특히 유니코드에서 동일한 문자로 '통합'된 지역 변형이 있을 수 있습니다.예를 들어 XML 속성 xml:lang이 있습니다.

Unicode 모델에서는 CCS, CEF 및 CES [8]레이어 모두를 대상으로 일련의 문자를 바이트에 직접 할당하는 이력 시스템에 문자 맵이라는 용어를 사용합니다.

문자 세트, 문자 맵 및 코드 페이지

역사적으로 "문자 인코딩", "문자 맵", "문자 집합" 및 "코드 페이지"라는 용어는 컴퓨터 과학에서 동의어였습니다. 동일한 표준이 문자의 레퍼토리와 코드 단위의 스트림으로 인코딩되는 방법을 지정하기 때문입니다.일반적으로 코드 단위당 하나의 문자로 구성됩니다.그러나 표준 기구가 많은 다른 부호화 [8]시스템에 대해 기술하고 통합할 때 정확한 용어를 사용하려는 노력 때문에 현재는 관련성이 있지만 명확한 의미를 [9]가지고 있습니다.그럼에도 불구하고, 문자 집합은 거의 어디에나 존재하며, 이 용어들은 여전히 서로 바꿔서 사용된다.

"코드 페이지"는 보통 바이트 지향 인코딩을 의미하지만 인코딩 스위트(각종 스크립트를 커버)에 관해서는 대부분의 코드 페이지 또는 모든 코드 페이지에서 많은 문자가 동일한 코드를 공유합니다.잘 알려진 코드 페이지 스위트는 "Windows" (Windows-1252 기반) 및 "IBM"/"DOS" (코드 페이지 437 기반)입니다. 자세한 내용은 Windows 코드 페이지를 참조하십시오.코드 페이지라고 불리는 부호화의 대부분은 싱글바이트 부호화입니다(단, 바이트 사이즈 옥텟 참조).

IBM의 CDRA(Character Data Representation Architecture)는 코드화된 문자 집합 식별자(CCSID)를 가진 엔티티를 지정합니다. 각 엔티티는 "charset", "charset", "code page" 또는 "CHARMAP"[8]로 다양하게 불립니다.

"code page"라는 용어는 "charmap"이 선호되는 Unix 또는 Linux에서는 발생하지 않으며, 일반적으로 로케일의 더 큰 컨텍스트에서 사용됩니다.

'코드화된 문자 집합'과는 대조적으로 '문자 부호화'는 추상적인 문자에서 코드 워드로의 맵이다.HTTP(및 MIME) 용어의 「문자 세트」는, 문자 인코딩과 같습니다(CCS 와는 다릅니다).

"레거시 인코딩"은 오래된 문자 인코딩을 특징짓기 위해 사용되는 용어이지만 의미가 모호합니다.그 사용의 대부분은 유니코드화의 맥락에서 모든 유니코드 코드 포인트를 커버하지 못하는 인코딩을 참조하거나, 보다 일반적으로는 다른 문자 레퍼토리를 사용한다: 하나의 유니코드 [10]문자를 나타내는 여러 코드 포인트 또는 그 반대이다(예를 들어 코드 페이지 437 참조).일부 소스에서는 부호화가 [11]Unicode보다 앞에 있기 때문에 부호화를 레거시라고 부르고 있습니다.모든 Windows 코드 페이지는 일반적으로 레거시라고 불리는데, 이는 유니코드보다 오래된 페이지와 가능한 2개의 유니코드 코드 포인트를 모두 나타낼21 수 없기 때문입니다.

문자 부호화 변환

많은 문자 인코딩 방법을 사용하고 있기 때문에(및 아카이브된 데이터와의 하위 호환성이 필요), 많은 컴퓨터 프로그램이 데이터 트랜스코딩의 한 형태로 인코딩 체계 간에 데이터를 변환하기 위해 개발되었습니다.이들 중 일부는 아래에 인용된다.

크로스 플랫폼:

  • 웹 브라우저 – 대부분의 최신 웹 브라우저는 자동 문자 인코딩 검출 기능을 갖추고 있습니다.예를 들어 Firefox 3에서는 [View/Character Encoding]서브메뉴를 참조해 주세요.
  • iconv – 인코딩을 변환하는 프로그램 및 표준화된 API
  • luit – 입출력 부호화를 대화형으로 실행하는 프로그램으로 변환하는 프로그램
  • convert_encoding.py : 임의의 인코딩과 행 [12]끝 사이에서 텍스트파일을 변환하는 Python 기반의 유틸리티.
  • decodeh.py : [13]문자열 인코딩을 경험적으로 추측하는 알고리즘 및 모듈.
  • Unicode의 International Components – Charset 변환을 수행하기 위한 C 및 Java 라이브러리 세트.ICU4C에서 uconv를 사용할 수 있습니다.
  • chardet – Mozilla 자동 부호화 검출 코드를 Python 컴퓨터 언어로 변환한 것입니다.
  • 새로운 버전의 Unix file 명령어는 문자 인코딩(Cygwin에서도 사용 가능)의 기본적인 검출을 시도합니다.
  • charset : C++/사용자 정의 스트림 간에 변환하기 위한 단순한 인터페이스를 갖춘 C++ 템플릿라이브러리charset은 많은 문자 집합을 정의하며 endianness를 지원하는 Unicode 형식을 사용할 수 있습니다.

Unix 유사:

  • cmv : 파일명을 [14]변환하기 위한 간단한 도구.
  • convmv : 파일명을 부호화 간에 [15]변환합니다.
  • cstocs : 체코어 및 슬로바키아어로 파일 내용을 부호화 간에 변환합니다.
  • enca : 지정된 텍스트파일의 [16]인코딩을 분석합니다.
  • recode : 파일 내용을 부호화 간에[17] 변환합니다.
  • utrac: 파일 내용을 부호화 [18]간에 변환합니다.

Windows:

  • 부호화.변환 –NET API[19]
  • MultiByteToWideChar/WideCharToMultiByte – ANSI에서 Unicode로, Unicode에서 ANSI로 변환[20]
  • cscvt – 문자 집합 변환[21] 도구
  • enca : 지정된 텍스트파일의 [22]인코딩을 분석합니다.

「 」를 참조해 주세요.

공통 문자 인코딩

레퍼런스

  1. ^ Tech Terms Dictionary
  2. ^ Tom Henderson (17 April 2014). "Ancient Computer Character Code Tables – and Why They're Still Relevant". Smartbear. Retrieved 29 April 2014.
  3. ^ Tom Jennings (1 March 2010). "An annotated history of some character codes". Retrieved 1 November 2018.
  4. ^ "IBM Electronic Data-Processing Machines Type 702 Preliminary Manual of Information" (PDF). 1954. p. 80. 22-6173-1.
  5. ^ Strelho, Kevin (15 April 1985). "IBM Drives Hard Disks to New Standards". InfoWorld. Popular Computing Inc. pp. 29–33. Retrieved 10 November 2020.
  6. ^ "Unicode glossary". Unicode consortium.
  7. ^ "Terminology (The Java Tutorials)". Oracle. Retrieved 25 March 2018.
  8. ^ a b c d e "Unicode Technical Report #17: Unicode Character Encoding Model". 11 November 2008. Retrieved 8 August 2009.
  9. ^ Shawn Steele (15 March 2005). "What's the difference between an Encoding, Code Page, Character Set and Unicode?". Microsoft Docs.
  10. ^ "Processing database information using Unicode, a case study". Archived from the original on 17 June 2006.
  11. ^ Constable, Peter (13 June 2001). "Character set encoding basics". Implementing Writing Systems: An introduction. SIL International. Archived from the original on 5 May 2013. Retrieved 19 March 2010.
  12. ^ GitHub에서 encoding.py를 변환합니다.
  13. ^ "Decodeh – heuristically decode a string or text file". Archived from the original on 8 January 2008.
  14. ^ "CharsetMove – Simple Tool for Transcoding Filenames".
  15. ^ "Convmv – converts filenames from one encoding to another".
  16. ^ "Extremely Naive Charset Analyser". Archived from the original on 4 December 2010. Retrieved 11 March 2008.
  17. ^ GitHub으로 재코딩하다
  18. ^ "Utrac Homepage".
  19. ^ "Encoding.Convert Method". Microsoft .NET Framework Class Library.
  20. ^ "MultiByteToWideChar/WideCharToMultiByte – Convert from ANSI to Unicode & Unicode to ANSI". Microsoft Support.
  21. ^ "Kalytta's Character Set Converter".
  22. ^ "Enca binary compiled for 32 bit Windows". Archived from the original on 15 March 2012. Retrieved 31 March 2011.

추가 정보

외부 링크

Wikimedia Commons에는 인코딩과 관련된 미디어가 있습니다.