맨위로가기

문자 인코딩

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

1. 개요

문자 인코딩은 문자를 컴퓨터에서 표현하기 위해 문자를 숫자 또는 이진 코드로 변환하는 기술이다. 1870년대 보도 코드에서 시작하여 ASCII, EBCDIC, 유니코드에 이르기까지 다양한 문자 인코딩 방식이 개발되었다. 문자 인코딩은 1바이트, 2바이트, 유니코드로 분류되며, 대표적으로 ASCII, ISO/IEC 8859, KS X 1001, JIS X 0208, UTF-8, UTF-16, UTF-32 등이 있다. 유니코드는 전 세계 모든 문자를 일관되게 표현하기 위한 표준으로, UTF-8이 웹에서 가장 널리 사용된다. 문자 인코딩은 문자 집합, 부호화된 문자 집합, 문자 인코딩 형식, 문자 인코딩 구조의 4단계 모델을 가지며, 서로 다른 인코딩 간의 데이터 교환 시 문자 깨짐 현상이 발생할 수 있어 트랜스코딩이 필요하다.

더 읽어볼만한 페이지

  • 문자 인코딩 - 유니코드
    유니코드는 세계의 모든 문자를 하나의 컴퓨터 인코딩 표준으로 통합하기 위해 설계되었으며, 유니코드 컨소시엄에 의해 관리되고 UTF-8, UTF-16, UTF-32 등의 부호화 형식을 제공하지만, 일부 문자 표현 문제, 버전 간 비호환성, 레거시 인코딩과의 호환성 문제 등의 과제를 안고 있다.
  • 문자 인코딩 - UTF-8
    UTF-8은 유니코드 문자를 표현하는 가변 길이 문자 인코딩 방식으로, ASCII 코드와 호환성을 유지하며 다양한 언어의 문자를 표현할 수 있도록 설계되었지만, 보안 문제점과 공간 효율성 측면에서 단점을 가진다.
문자 인코딩

2. 역사

문자 코드의 역사는 한때 획기적이었던 전기적 수단을 사용하여 기계 매개 문자 기반의 기호 정보를 원거리에서 전송해야 할 필요성이 진화해 온 과정을 보여준다. 가장 초기의 코드는 베이컨 암호, 브라유 점자, 국제 해상 신호기, 중국 전신 코드와 같은 수동 및 손으로 쓴 암호화 및 부호화 시스템을 기반으로 했다. 전기 및 전자 기계 기술이 채택되면서 이러한 초기 코드들은 초기 기계의 새로운 기능과 제한 사항에 맞춰 조정되었다. 1840년대에 소개된 최초의 잘 알려진 전기 전송 문자 코드인 모스 부호는 가변 길이 코드를 생성하기 위해 4개의 "기호"(짧은 신호, 긴 신호, 짧은 간격, 긴 간격) 시스템을 사용했다. 모스 부호는 전신기에서 손으로 생성되고 귀로 해독할 수 있는 수동 코드로 사용되었으며, 아마추어 무선 및 항공 분야에서 사용되고 있다.

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

EBCDIC 문자 집합이 있는 헐리리드 80열 펀치 카드


1870년 에밀 보도에 의해 만들어진 5비트 인코딩인 보도 코드는 1874년에 특허를 받았고, 1901년 도널드 머레이에 의해 수정되었으며, 1930년 CCITT에 의해 국제 전신 알파벳 No. 2(ITA2)로 표준화되었다. 허먼 홀러리드는 19세기 후반 인구 조사 데이터를 분석하기 위해 펀치 카드 데이터 인코딩을 발명했다. 처음에는 각 구멍 위치가 다른 데이터 요소를 나타냈지만, 나중에는 하단 행에 0에서 9까지 번호를 매기고 열에 구멍을 뚫어 해당 행 번호를 나타내는 방식으로 숫자 정보가 인코딩되었다. 나중에 알파벳 데이터는 열당 둘 이상의 펀치를 허용하여 인코딩되었다.

IBM은 IBM 603 전자 곱셈기를 시작으로 전자 처리를 시작했을 때, 펀치 카드 코드와 관련된 다양한 바이너리 인코딩 방식을 사용했다. IBM은 702[5] 및 704 컴퓨터, 이후의 7000 시리즈 및 1400 시리즈, 그리고 관련 주변 장치에서 1953년 초부터 2진화 십진법(BCD) 6비트 문자 인코딩 방식을 여러 개 사용했다. IBM의 BCD 인코딩은 확장 2진화 십진법 교환 코드(EBCDIC)의 전신이었으며, 이는 IBM System/360용으로 1963년에 개발된 8비트 인코딩 방식이다.

1959년 미국 군대는 6 또는 7비트 코드인 Fieldata 코드를 정의했으며, 이는 미국 육군 신호 군단에 의해 도입되었다. 1963년에는 ASCII 위원회에서 최초의 ASCII 코드(X3.4-1963)가 발표되었으며, 이는 7비트 코드를 사용하여 Fieldata의 대부분의 단점을 해결했다. 1967년 ASCII 코드(소문자를 추가하고 일부 "제어 코드" 문제를 해결함)의 후속 문제로 인해 ASCII67이 상당히 널리 채택되었다. ASCII67의 미국 중심적인 특성은 유럽 ECMA-6 표준에서 어느 정도 해결되었다.[7]

ISO/IEC 8859와 같은 8비트 확장 ASCII 인코딩은 ASCII 문자와 추가 비 ASCII 문자를 지원했다. MS 윈도 문자 집합에는 Windows-1250, Windows-1251, Windows-1252 등이 있다.

맥 오에스 로만 (Mac OS Roman), KOI8-R, MIK, ISCII, TSCII, VISCII, JIS X 0208 기반의 Shift JIS, EUC-JP, 중국어 간체자 GB에는 GB 2312, GBK 등이 있다. 대만 Big5, 홍콩 HKSCS, 한국어의 경우 KS X 1001, EUC-KR 등이 있다.

2. 1. 초기 전신 기술과 문자 코드

1870년대에 프랑스의 전신 기술자인 에밀 보도는 5 비트와 문자와 기호를 대응시키는 코드를 발명하여, 1876년에 해당 코드를 사용하는 전신 장치의 특허를 프랑스에서 취득했다. 이 장치에 사용된 5비트 코드는 '''보도 코드'''(Baudot Code)로 알려지게 되었다.[14]

2. 2. ASCII와 EBCDIC

1963년, 미국 표준 협회(ASA)는 정보 통신용 문자 코드로서 7비트 ASCII(아스키)를 제정했다.[7] 1964년, IBM은 System/360과 함께 8비트 EBCDIC 문자 코드를 발표했다. EBCDIC는 4비트 BCD를 8비트로 확장한 것이다.

2. 3. 다양한 문자 인코딩의 등장

ISO/IEC 8859는 서유럽, 동유럽, 키릴 문자, 아랍 문자, 그리스 문자, 히브리 문자 등 다양한 지역의 언어를 지원하기 위해 여러 부분으로 구성된 표준이다. 예를 들어, ISO/IEC 8859-1은 서유럽 언어를, ISO/IEC 8859-5는 키릴 문자를 지원한다.

마이크로소프트는 자체적인 MS 윈도 문자 집합을 개발했는데, Windows-1250은 폴란드어, 체코어 등 중앙 유럽 언어를, Windows-1251은 키릴 문자를, Windows-1252는 서양어를 지원한다.

한국어의 경우, KS X 1001(KS C 5601)은 2바이트 한국어 문자 인코딩 표준이다. 이와 함께 EUC-KR 인코딩도 사용되었다. 일본어는 JIS X 0208 표준을 기반으로 Shift JIS, EUC-JP 등의 인코딩이 개발되었다. 중국어 간체자는 GB 표준에 따라 GB 2312, GBK, GB 18030 등의 인코딩이 사용되었다.

2. 4. 유니코드의 등장과 발전

유니코드는 전 세계 모든 문자를 통합하여 표현하기 위한 표준으로 등장했다. 초기에는 UTF-16, UTF-32 등의 인코딩 방식이 사용되었으나, 현재는 UTF-8이 가장 널리 사용된다.[8] 1980년대, 보편적으로 상호 교환 가능한 문자 인코딩을 개발하려는 연구자들은 한편으로는 추가 문자를 수용하기 위해 더 많은 비트를 추가해야 할 필요성이 있었지만, 다른 한편으로는 비교적 작은 라틴 알파벳 문자 집합의 사용자(여전히 컴퓨터 사용자의 대다수를 차지함)에게 그러한 추가 비트는 당시 부족하고 비싼 컴퓨팅 리소스의 엄청난 낭비였다는 딜레마에 직면했다.[8]

결국 발견된 타협적인 해결책은 (전신 코드에서 비롯된) 각 문자가 항상 특정 비트 시퀀스에 직접 대응해야 한다는 가정을 깨는 것이었다. 대신, 문자는 먼저 코드 포인트라는 추상적인 숫자의 형태로 보편적인 중간 표현에 매핑된다. 그런 다음 코드 포인트는 컨텍스트에 따라 다양한 방법과 문자당 다양한 기본 비트 수(코드 유닛)로 표현된다. 8비트 단위의 경우 256 이상과 같이 코드 유닛의 길이보다 높은 코드 포인트를 인코딩하기 위한 해결책은 가변 길이 인코딩을 구현하는 것이었으며, 여기서 이스케이프 시퀀스는 후속 비트가 더 높은 코드 포인트로 구문 분석되어야 함을 알린다.

3. 문자 인코딩의 종류

문자 인코딩은 크게 1바이트 계열, 2바이트 계열, 그리고 유니코드로 분류할 수 있다.

3. 1. 1바이트 계열 문자 인코딩

1바이트 계열 문자 인코딩은 주로 영문 알파벳과 숫자, 일부 특수 문자를 표현하는 데 사용된다. 1바이트 계열 문자 인코딩에는 ASCII, ISO/IEC 8859, Windows-1252 등이 있다.

ASCII는 7비트, ISO/IEC 8859와 그 하위 인코딩, EBCDIC, GB 18030, UTF-8은 8비트를 코드 단위로 사용한다.

1바이트계 문자 인코딩은 "반각 문자"라고도 불린다.

1바이트 계열 문자 인코딩의 종류는 다음과 같다.

3. 1. 1. ASCII (ANSI INCITS 4)

미국 정보 교환 표준 코드(ASCII)는 1963년에 처음 발표된 7비트 문자 인코딩이다. ASCII는 영문 알파벳, 숫자, 기호 등 128개의 문자를 표현하며, Fieldata 코드의 단점을 해결하기 위해 개발되었다.[7] 1967년에는 소문자와 일부 제어 문자를 추가한 ASCII 코드(ASCII67)가 발표되어 널리 채택되었다.[7] ASCII는 ISO 646의 US 버전이며, ANSI INCITS 4로도 알려져 있다.

ASCII의 코드 단위는 7비트로 구성된다.

3. 1. 2. ISO/IEC 8859

ISO/IEC 8859영어는 ASCII를 확장하여 다양한 유럽 언어를 지원하는 8비트 문자 인코딩이다. ISO/IEC 8859영어는 여러 파생 규격이 존재하는데, 대표적으로 다음과 같다.[7]

규격설명
ISO 8859-1서유럽
ISO 8859-2서유럽 및 중부 유럽
ISO 8859-3서유럽 및 남유럽 (터키어tr, 몰타어몰타어 및 에스페란토eo)
ISO 8859-4서유럽 및 발트해 연안 국가(리투아니아lt, 에스토니아et, 라트비아lv 및 랩란드smi)
ISO 8859-5키릴 문자
ISO 8859-6아랍어ar
ISO 8859-7그리스 문자
ISO 8859-8히브리어he
ISO 8859-9개정된 터키어tr 문자 집합을 포함한 서유럽
ISO 8859-10아이슬란드어is 전체 집합을 포함한 북유럽 언어에 대한 합리화된 문자 집합을 포함한 서유럽
ISO 8859-11태국어th
ISO 8859-13발트해 연안 언어 및 폴란드어pl
ISO 8859-14아일랜드 게일어ga, 스코틀랜드어gd, 웨일스어cy
ISO 8859-15유로 기호 및 기타 합리화를 ISO 8859-1영어에 추가
ISO 8859-16중부, 동부 및 남부 유럽 언어 (알바니아어sq, 보스니아어bs, 크로아티아어hr, 헝가리어hu, 폴란드어pl, 루마니아어ro, 세르비아어sr 및 슬로베니아어sl, 프랑스어프랑스어, 독일어de, 이탈리아어it 및 아일랜드 게일어ga 포함)


3. 1. 3. Windows 코드 페이지

마이크로소프트는 Windows 운영체제에서 다양한 언어를 지원하기 위해 자체적인 코드 페이지를 개발했다.[2] 대표적인 코드 페이지로는 Windows-1252(서유럽 언어), Windows-1250(중부 유럽 언어), Windows-1251(키릴 문자) 등이 있다.

MS-Windows 문자 집합은 다음과 같다.

코드 페이지설명
Windows-1250라틴 문자를 사용하는 중부 유럽 언어 (폴란드어, 체코어, 슬로바키아어, 헝가리어, 슬로베니아어, 세르비아어, 크로아티아어, 보스니아어, 루마니아어 및 알바니아어)
Windows-1251키릴 문자
Windows-1252서유럽 언어
Windows-1253그리스어
Windows-1254터키어
Windows-1255히브리어
Windows-1256아랍어
Windows-1257발트해 연안 언어
Windows-1258베트남어


3. 2. 2바이트 계열 문자 인코딩

2바이트 계열 문자 인코딩은 한글, 한자, 일본어 가나 등 더 많은 문자를 표현하기 위해 사용된다. 대표적인 예로는 KS X 1001, JIS X 0208, GB 2312, Big5 등이 있다.[13][14] 2바이트 문자 코드는 "전각 문자"라고도 불린다.

3. 2. 1. KS X 1001 (KS C 5601)

KS X 1001은 대한민국에서 사용되는 한글 등을 포함하는 문자 집합으로, KS C 5601이라고도 불린다.[13] 이 문자 집합은 한글, 한자, 영문, 숫자, 기호 등 다양한 문자를 포함하고 있다.

KS X 1001을 기반으로 하는 문자 인코딩 방식은 다음과 같다.

  • EUC-KR: KS X 1001을 기반으로 한 8비트 문자 인코딩 방식이다.
  • ISO-2022-KR: KS X 1001을 기반으로 한 7비트 문자 인코딩 방식이다.

3. 2. 2. JIS X 0208

JIS X 0208는 일본에서 사용되는 문자 집합으로, 제1·제2 수준 한자 등을 포함한다.[13]

3. 2. 3. GB 2312, GB 18030

GB 2312는 중국의 중국어 간체를 표현하기 위한 국가 표준 문자 인코딩이다.[13] GB 18030은 GB 2312를 확장하여 더 많은 한자를 포함하는, 중국에서 사용되는 문자 인코딩이다.[13] GB 18030에서 코드 포인트는 하나, 둘 또는 네 개의 코드 유닛에 매핑된다.[13]

3. 2. 4. Big5

는 중국어 번체를 사용하는 대만에서 주로 사용되는 문자 인코딩 방식이다.[14]

3. 3. 유니코드 (Unicode)

유니코드와 이와 병행하는 표준인 ISO/IEC 10646 범용 문자 집합은 문자 인코딩에 대한 통합된 표준이다. 유니코드는 문자를 직접 바이트에 매핑하는 대신, 문자를 고유한 자연수(코드 포인트)에 매핑하는 부호화된 문자 집합, 해당 코드 포인트가 일련의 고정 크기 자연수(코드 유닛)에 매핑되는 방식, 마지막으로 해당 유닛이 옥텟(바이트) 스트림으로 인코딩되는 방식을 개별적으로 정의한다. 이러한 분해의 목적은 다양한 방식으로 인코딩될 수 있는 범용적인 문자 집합을 확립하는 것이다.[14]

유니코드 모델은 문자 집합, 문자 인코딩 형식, 문자 인코딩 체계 단계를 포함하여 문자의 시퀀스를 바이트의 시퀀스에 직접 할당하는 다른 시스템에 대해 "문자 맵"이라는 용어를 사용한다.[14]

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

다음 표는 코드 포인트 값의 예시를 보여준다.

문자유니코드 코드 포인트글리프
라틴 문자 AU+0041A
라틴어 sharp SU+00DFß
한자 '동'U+6771東
앰퍼샌드U+0026&
거꾸로 된 느낌표U+00A1¡
단락 기호U+00A7§



UTF-8, UTF-16, UTF-32는 대표적인 유니코드 인코딩 방식이다.

3. 3. 1. UTF-8

UTF-8은 가변 길이 문자 인코딩 방식으로, ASCII 문자는 1바이트, 그 외 문자는 2~4바이트로 표현한다.[2] 2024년 5월 기준으로 조사된 웹 사이트의 98.2%에서 사용될 정도로 웹에서 가장 많이 사용되는 문자 인코딩 방식이다.[2] 응용 소프트웨어 및 운영 체제 작업에서 UTF-8과 UTF-16이 모두 인기 있는 옵션이다.[3][18]

𐐀은 하나의 32비트 값(UTF-32), 두 개의 16비트 값(UTF-16) 또는 네 개의 8비트 값(UTF-8)으로 표현되는 문자이다.

3. 3. 2. UTF-16

UTF-16은 대부분의 문자를 2바이트(16비트)로 표현하는 가변 길이 문자 인코딩 방식이다. 기본 다국어 평면(BMP)에 속하는 문자는 2바이트로, 그 외 문자는 4바이트(16비트 2개)로 표현한다.[18]

"ab̲c𐐀" 문자열을 예로 들면, UTF-16에서는 다음과 같이 표현된다.

  • a:
  • b:
  • ̲:
  • c:
  • 𐐀: , (4바이트)


위에서 볼 수 있듯이, 𐐀 문자는 4바이트, 즉 2개의 16비트 값으로 표현된다.

웹에서 UTF-8이 가장 많이 사용되지만, 응용 소프트웨어 및 운영 체제에서는 UTF-16도 널리 사용된다.[3][18]

3. 3. 3. UTF-32

UTF-32는 모든 유니코드 문자를 4바이트(32비트)로 표현하는 고정 길이 인코딩 방식이다.

"ab̲c𐐀" 문자열을 예로 들면, 이 문자열은 5개의 유니코드 코드 포인트를 가진다.

  • U+0061, U+0062, U+0332, U+0063, U+10400


UTF-32는 각 코드 포인트를 4바이트로 표현하므로, 위 문자열은 다음과 같이 표현된다.

  • 0x00000061, 0x00000062, 0x00000332, 0x00000063, 0x00010400


여기서 𐐀은 하나의 32비트 값(UTF-32)으로 표현된다.

4. 문자 인코딩 기술적 구성

문자 인코딩은 문자 집합, 부호화된 문자 집합, 문자 인코딩 형식, 문자 인코딩 구조 등의 요소로 구성된다.

문자 정보는 정보를 표현하기 위한 글자들의 집합을 정의한 것이다. 한 문자 집합을 여러 문자 인코딩에서 쓸 수도 있다. 집합 안의 문자들에 음수가 아닌 정수를 배정한 것을 부호화된 문자 집합(coded character set, CCS)이라 한다.

'''문자 인코딩 형태'''(character encoding form, CEF)는 특정한 문자 집합 안의 문자들을 컴퓨터 시스템에서 사용할 목적으로 일정한 범위 안의 정수(코드값)들로 변환하는 방법이다.[1] 여기에는 유니코드 코드 포인트를 8비트 숫자의 집합으로 나타내는 UTF-8이나, 16비트 숫자의 집합으로 나타내는 UTF-16, 그리고 대부분의 일반적인 문자 인코딩들이 포함된다.

'''문자 인코딩 구조'''(character encoding scheme, CES)는 문자 인코딩 형태로 변환된 코드값을 옥텟 기반의 시스템에서 사용하기 위하여 옥텟들로 변환하는 방법이다. 대부분의 경우 이 과정은 단순하지만, UTF-16과 같이 8비트 이상의 숫자를 사용하는 문자 인코딩 형태의 경우 엔디안을 지정해 주어야 한다.[5] ISO 2022와 같은 복합 인코딩이나, SCSU와 같은 압축 방법 등도 문자 인코딩 구조에 속한다.

4. 1. 문자 집합 (Character Set)

문자 집합은 표현하고자 하는 문자의 모음이다.[9][10] 예를 들어, 라틴 문자와 그리스 문자는 모두 문자 집합에 해당한다.

일반적으로 문자 집합과 문자 인코딩은 어떤 문자를 사용할 수 있으며 어떤 식으로 표현되는지를 나타낸다는 점에서 동의어로 취급되기도 한다.

  • '''문자'''는 의미적 가치를 갖는 텍스트의 최소 단위이다.[9][10]
  • '''문자 집합'''은 텍스트를 표현하는 데 사용되는 요소들의 모음이다.[9][10]
  • '''부호화된 문자 집합'''(CCS)은 고유한 숫자 집합에 매핑된 문자 집합이다.[10] 역사적인 이유로 이는 종종 코드 페이지라고도 한다.[9]
  • '''문자 레퍼토리'''는 특정 부호화된 문자 집합으로 표현할 수 있는 문자 집합이다.[10][11] 레퍼토리는 닫혀 있거나(예: ASCII 및 대부분의 ISO-8859 시리즈), 열려 있을 수 있다(예: 유니코드).[11]
  • '''코드 포인트'''는 부호화된 문자 집합에서 문자의 값 또는 위치이다.[10]
  • '''코드 공간'''은 부호화된 문자 집합이 포함하는 숫자 값의 범위이다.[10][14]
  • '''코드 유닛'''은 문자 인코딩에서 문자를 나타낼 수 있는 최소 비트 조합이다.[10][14]


문자 정보는 정보를 표현하기 위한 글자들의 집합을 정의한 것으로, 직접적으로 사용되지 않을 수도 있고 한 문자 집합을 여러 문자 인코딩에서 쓸 수도 있다. 특히 집합 안의 문자들에 음수가 아닌 정수들을 배정한 것을 부호화된 문자 집합(CCS)이라 한다. 문자 집합은 ASCII와 같이 더 이상의 문자가 추가될 수 없기도 하고, 유니코드와 같이 문자가 계속 추가될 수 있기도 하다.

4. 2. 부호화된 문자 집합 (Coded Character Set, CCS)

부호화된 문자 집합(Coded Character Set, CCS)은 각 문자에 고유한 숫자(코드 포인트)를 할당한 것이다.[10] 예를 들어, 유니코드에서 'A'는 U+0041, '가'는 U+AC00으로 표현된다.

문자 집합은 ASCII와 같이 더 이상 문자가 추가될 수 없기도 하고, 유니코드와 같이 문자가 계속 추가될 수 있기도 하다.[5]

일반적으로 문자 집합과 문자 인코딩은 어떤 문자를 사용할 수 있으며 어떤 식으로 표현되는지를 나타낸다는 점에서 동의어로 취급되기도 한다. 역사적인 이유로 MIME이나 그에 기반한 시스템은 문자 집합("charset")을 문자 인코딩을 나타내는 데 사용한다.[5]

다음 표는 코드 포인트 값의 예시를 보여준다.

문자유니코드 코드 포인트글리프
라틴 문자 AU+0041A
라틴어 sharp SU+00DFß
한자 '동'U+6771東
앰퍼샌드U+0026&
거꾸로 된 느낌표U+00A1¡
단락 기호U+00A7§


4. 3. 문자 인코딩 형식 (Character Encoding Form, CEF)

'''문자 인코딩 형태'''(character encoding form, CEF)는 특정한 문자 집합 안의 문자들을 컴퓨터 시스템에서 사용할 목적으로 일정한 범위 안의 정수(코드값)들로 변환하는 방법이다.[1] 여기에는 유니코드 코드 포인트를 8비트 숫자의 집합으로 나타내는 UTF-8이나, 16비트 숫자의 집합으로 나타내는 UTF-16, 그리고 대부분의 일반적인 문자 인코딩들이 포함된다.[1]

문자 인코딩 형식은 코드 포인트를 컴퓨터가 이해할 수 있는 형태로 바꾸는 규칙이다. 예를 들어, '가'라는 글자를 컴퓨터가 이해하려면 '가'에 해당하는 코드 포인트(U+AC00)를 0과 1로 이루어진 형태로 바꿔야 하는데, 이때 사용되는 규칙이 UTF-8, UTF-16 같은 문자 인코딩 형식이다.

4. 4. 문자 인코딩 구조 (Character Encoding Scheme, CES)

문자 인코딩 구조(CES)는 문자 인코딩 형태(CEF)로 변환된 코드값을 옥텟 기반의 시스템에서 사용하기 위하여 실제 바이트 단위로 표현하는 방법이다. 대부분의 문자 인코딩 형태는 이 과정에서 별다른 변환이 필요 없지만, 8비트 이상의 숫자를 사용하는 UTF-16과 같은 문자 인코딩 형태의 경우 엔디안을 지정해 주어야 한다. 예를 들어, UTF-16은 빅 엔디안(UTF-16BE)과 리틀 엔디안(UTF-16LE)으로 표현될 수 있다.[5] 여기에는 ISO 2022와 같은 복합 인코딩이나, SCSU와 같은 압축 방법 등이 속한다.

5. 유니코드 인코딩 모델

유니코드는 문자 인코딩을 다음 4단계로 정의한다.[19]

# '''추상 문자 집합'''(ACR, Abstract Character Repertoire): 부호화의 대상이 되는 순서 없는 문자의 집합.

# '''부호화된 문자 집합'''(CCS, Coded Character Set): 추상 문자 집합을 0 이상의 정수(코드 포인트)에 대응시킨 것.

# '''문자 부호화 형식'''(CEF, Character Encoding Form): 코드 포인트를 컴퓨터 시스템에서 사용하기 위한 코드 유닛(Code Unit)으로 변환하는 방법.

# '''문자 부호화 방식'''(CES, Character Encoding Scheme): 코드 유닛을 바이트열로 직렬화하는 방법.

유니코드는 문자를 직접 바이트에 매핑하지 않고, 코드 포인트를 거쳐 다양한 방식으로 인코딩될 수 있는 범용적인 문자 집합을 확립하는 것을 목표로 한다.[14]

이후 바이트열을 gzip 등으로 압축하거나, Base64 등 7비트 전송로를 위한 변환을 할 수 있지만, 이는 문자 코드의 범위를 벗어난다.

5. 1. 추상 문자 집합 (Abstract Character Repertoire, ACR)

시스템이 지원하는 모든 추상 문자의 집합이다. 유니코드는 시간이 지남에 따라 새로운 문자가 레퍼토리에 추가되는 열린 레퍼토리를 가지고 있다.[14]

5. 2. 부호화된 문자 집합 (Coded Character Set, CCS)

부호화된 문자 집합(Coded Character Set, CCS)은 추상 문자를 코드 포인트(Code Point)에 매핑하는 함수이다.[14] 각 코드 포인트는 하나의 문자를 나타낸다. 예를 들어, 유니코드에서 라틴 알파벳 대문자 "A"는 코드 포인트 65에, "B"는 66에 매핑될 수 있다.[14]

문자 집합은 ASCII와 같이 더 이상 문자가 추가될 수 없는 닫힌 형태일 수도 있고, 유니코드처럼 문자가 계속 추가될 수 있는 열린 형태일 수도 있다.

일반적으로 문자 집합과 문자 인코딩은 어떤 문자를 사용할 수 있고 어떻게 표현되는지를 나타내기 때문에 동의어로 취급되기도 한다. 그러나 역사적인 이유로 MIME과 같은 시스템에서는 문자 집합("charset")을 문자 인코딩을 나타내는 데 사용한다.[14]

유니코드와 ISO/IEC 10646 범용 문자 집합은 문자 인코딩에 대한 통합된 표준을 구성한다. 유니코드는 문자를 직접 바이트에 매핑하는 대신, 문자를 고유한 숫자(코드 포인트)에 매핑하는 부호화된 문자 집합, 코드 포인트를 코드 유닛에 매핑하는 방식, 그리고 코드 유닛을 옥텟(바이트) 스트림으로 인코딩하는 방식을 개별적으로 정의한다. 이러한 분해의 목적은 다양한 방식으로 인코딩될 수 있는 범용적인 문자 집합을 확립하는 것이다.[14]

유니코드 모델에서는 다음과 같은 용어를 사용하여 문자 인코딩 과정을 설명한다.[14]

  • 문자 레퍼토리: 특정 부호화된 문자 집합으로 표현할 수 있는 문자 집합.[10][11]
  • 코드 포인트: 부호화된 문자 집합에서 문자의 값 또는 위치.[10]
  • 코드 공간: 부호화된 문자 집합이 포함하는 숫자 값의 범위.[10][14]


여러 부호화된 문자 집합이 동일한 문자 레퍼토리를 공유할 수 있다. 예를 들어 ISO/IEC 8859-1과 IBM 코드 페이지 037 및 500은 모두 동일한 레퍼토리를 다루지만 이를 다른 코드 포인트에 매핑한다.

5. 3. 문자 부호화 형식 (Character Encoding Form, CEF)

'''문자 인코딩 형식'''(character encoding form, CEF)은 특정한 문자 집합 안의 문자들을 컴퓨터 시스템에서 사용할 목적으로 일정한 범위 안의 정수(코드값)들로 변환하는 방법이다. 이는 코드 포인트를 코드 유닛(Code Unit)에 매핑하는 것이다. 코드 유닛은 컴퓨터 시스템에서 문자를 저장하기 위한 고정 길이 비트 시퀀스이다.[14] 여기에는 유니코드 코드 포인트를 8비트 숫자의 집합으로 나타내는 UTF-8이나, 16비트 숫자의 집합으로 나타내는 UTF-16, 그리고 대부분의 일반적인 문자 인코딩들이 포함된다.

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

다음 표는 코드 포인트 값의 예시를 보여준다.

문자유니코드 코드 포인트글리프
라틴 문자 AU+0041A
라틴어 sharp SU+00DFß
한자 '동'U+6771東
앰퍼샌드U+0026&
거꾸로 된 느낌표U+00A1¡
단락 기호U+00A7§



유니코드 모델에서는 문자 코드를 다음과 같은 4단계로 나눈다.[19]


  • 문자 부호화 형식 (CEF): 부호화 문자 집합의 0 이상의 정수를 부호 단위열로 변환하는 방법. 문자 부호화 형식에 따라서는 하나의 부호화 문자가 복수의 부호 단위가 되는 경우가 있다 (서로게이트 쌍). 이를 포함하여, 문자에 따라 길이가 다른 부호 단위열이 되는 문자 부호화 형식을 가변폭, 어떤 문자를 변환해도 같은 길이의 부호 단위열이 되는 것을 고정폭이라고 한다. 문자 부호화 형식은 컴퓨터 내에서 실제로 데이터로서 문자를 표현하는 것을 가능하게 한다.

5. 4. 문자 부호화 방식 (Character Encoding Scheme, CES)

코드 유닛을 옥텟(바이트) 시퀀스로 매핑하는 것이다. 이는 파일 시스템에 저장하거나 네트워크를 통해 전송하기 위해 필요하다.[19]

간단한 문자 인코딩 체계에는 UTF-8, UTF-16BE, UTF-32BE, UTF-16LE, UTF-32LE가 포함된다. UTF-16, UTF-32 및 ISO/IEC 2022와 같은 복합 문자 인코딩 체계는 바이트 순서 표시 또는 이스케이프 시퀀스를 사용하여 여러 간단한 체계 간을 전환한다. 압축 체계는 코드 유닛당 사용되는 바이트 수를 최소화하려고 시도한다(예: SCSU 및 BOCU).[14]

UTF-32BE와 UTF-32LE는 더 간단한 CES이지만, 유니코드를 사용하는 대부분의 시스템은 고정 길이 ASCII와 하위 호환되며 유니코드 코드 포인트를 가변 길이 옥텟 시퀀스에 매핑하는 UTF-8 또는 고정 길이 UCS-2BE와 하위 호환되며 유니코드 코드 포인트를 가변 길이 16비트 단어 시퀀스에 매핑하는 UTF-16BE를 사용한다.[14]

6. 한국어 환경과 문자 인코딩

한국어 환경에서는 KS X 1001, EUC-KR, 유니코드(UTF-8 포함) 등의 문자 인코딩이 사용된다. KS X 1001은 2바이트 한국어 문자 인코딩 표준이며, EUC-KR은 KS X 1001을 기반으로 한 8비트 문자 인코딩이다.

6. 1. KS X 1001과 EUC-KR

KS X 1001영어은 한글, 한자, 영문, 숫자, 기호 등을 포함하는 2바이트 문자 집합이다. EUC-KR영어은 KS X 1001영어을 기반으로 한 8비트 문자 인코딩으로, 한글 완성형 인코딩이라고도 불린다. EUC-KR영어은 한글 표현에 있어 몇 가지 문제점을 가지고 있어, 유니코드로의 전환이 권장된다.

6. 2. 유니코드와 UTF-8

유니코드는 잘 정의되고 확장 가능한 인코딩 시스템으로, 이전의 대부분의 문자 인코딩을 대체했지만, 현재에 이르기까지 코드 개발 과정은 비교적 잘 알려져 있다.

1980년대에 보편적으로 상호 교환 가능한 문자 인코딩을 개발하려는 연구자들은 딜레마에 직면했다. 추가 문자를 수용하기 위해 더 많은 비트를 추가해야 할 필요성이 있었지만, 비교적 작은 라틴 알파벳 문자 집합 사용자(여전히 컴퓨터 사용자의 대다수를 차지함)에게 그러한 추가 비트는 당시 부족하고 비싼 컴퓨팅 리소스의 엄청난 낭비였다(이러한 사용자에게는 항상 0으로 채워질 것이기 때문). 1985년, 평균적인 개인용 컴퓨터 사용자의 하드 디스크 드라이브는 약 10메가바이트만 저장할 수 있었고, 도매 시장에서 약 250USD였다.[8] 따라서 당시 모든 비트를 계산하는 것이 매우 중요했다.

결국 발견된 타협적인 해결책은 각 문자가 항상 특정 비트 시퀀스에 직접 대응해야 한다는 가정을 깨는 것이었다. 대신, 문자는 먼저 코드 포인트라는 추상적인 숫자의 형태로 보편적인 중간 표현에 매핑되었다. 그런 다음 코드 포인트는 컨텍스트에 따라 다양한 방법과 문자당 다양한 기본 비트 수(코드 유닛)로 표현된다. 8비트 단위의 경우 256 이상과 같이 코드 유닛의 길이보다 높은 코드 포인트를 인코딩하기 위한 해결책은 가변 길이 인코딩을 구현하는 것이었으며, 여기서 이스케이프 시퀀스는 후속 비트가 더 높은 코드 포인트로 구문 분석되어야 함을 알린다.

6. 3. 문자 깨짐 현상과 해결 방안

utf-8이나 euc-kr과 같이 서로 다른 문자 인코딩 방식을 사용하면 텍스트나 문자가 깨지는 현상이 발생할 수 있다. 이러한 현상은 서로 다른 시스템 간에 데이터를 교환할 때 주로 발생한다.[5]

이 문제를 해결하기 위한 방법은 다음과 같다:

  • 모든 시스템에서 동일한 문자 인코딩 사용: 주로 UTF-8이 사용된다.
  • 트랜스코딩(Transcoding) 도구 사용: 서로 다른 인코딩 간에 변환을 수행하여 문자 깨짐을 방지한다.

7. 기타 용어

코드 세트 독립(CodeSet Independent, CSI)은 소프트웨어 구현에서 임의의 문자 코드를 처리할 수 있도록 구현하는 것을 가리키며, Ruby 1.9의 String 객체 등에서 사용된다.[24]

MIME에서 '''문자 집합'''(charset 또는 character set영어)은 "옥텟의 배열을 문자의 배열로 변환하는 방식"으로 정의되며,[25] 실제로는 문자 코드에 가깝다. 이는 전자 메일 메시지 등 MIME으로 구현되는 처리를 주안점으로 둔 개념이다. IANA는 인터넷상에서 사용할 수 있는 "문자 집합"을 등록하고 공개한다.

유니코드 문자 부호화 모델에서 '''문자 맵'''(; CM)은 문자열을 바이트 열로 변환하는 4단계의 조작을 통칭한다.[26]

XML에서는 문자 코드 선언에 encoding이라는 용어를 사용한다.

7. 1. 코드 페이지 (Code Page)

코드 페이지는 특정 문자 집합과 그에 해당하는 코드 값을 정의한 표이다. IBM이나 마이크로소프트는 독자적으로 문자 코드에 번호(코드 페이지)를 부여하여 관리하고 있다.[9]

7. 2. 외자 (外字)

외자(外字)는 표외자(規格表外字, 규격표 밖의 문자)의 약자로, 사용자가 직접 디자인하여 사용하는 사용자 정의 문자나, 제조사 등이 정의한 환경 의존 문자(소위 기종 의존 문자) 또는 '''벤더 확장 한자'''를 가리킨다.

외자는 사용자가 독자적으로 문자를 등록할 수 있는 영역이 있는 문자 코드를 말한다. 유니코드에는 6,400+131,072 문자의 "PUA (Private Use Area=사설 영역)"가 있으며, Windows-31J(Microsoft Windows Codepage 932)에도 1,880 문자의 외자 영역이 있다. 사용자가 독자적으로 글꼴을 등록한 문자(사용자 정의 문자)는 문서 교환 시에 다른 환경에서 읽을 수 없어 호환성 문제가 발생할 수 있다. 벤더 확장 문자는 사용자가 표외자가 아니라고 인식하고 사용할 수 있어 더 큰 문제를 일으킨다. (예: Windows 환경(CP932)의 로마 숫자가 Mac 환경에서 깨져 보임).

JIS 규격에서 JIS X 0208 문자 집합에 대해 EUC-JP 또는 Shift_JIS 부호화를 할 때, 1~94구에 대응하지 않는 영역(EUC-JP나 Shift_JIS는 94구에 94점을 곱한 8,836을 초과하는 문자 정의 가능)이나 1~94구 내에서 문자가 정의되지 않은 곳(JIS X 0208에는 빈 영역 다수 존재)에 외자를 넣는 구현이 있었다. 1997년 개정(JIS X 0208:1997)에서 Shift_JIS 및 EUC-JP 부호화를 규격으로 정하여 빈 영역을 외자로 사용을 원칙적으로 금지했다. JIS X 0213:2000에서는 주요 벤더 외자 문자를 규격에 넣어 94구까지의 빈 영역을 없애고 94구 내 외자 처리 부분을 제거했다. 2면을 사용한 구현 수준 4를 선택하면 Shift_JIS-2004 부호화의 경우 94구 외 영역도 채워져 외자 영역이 없어진다.

8. 트랜스코딩 (Transcoding)

트랜스코딩은 서로 다른 문자 인코딩 간에 데이터를 변환하는 과정이다. 다양한 문자 인코딩 방식이 사용되고 있으며, 보관된 데이터와의 하위 호환성을 유지해야 할 필요성이 있기 때문에, 문자 인코딩 체계 간에 데이터를 변환하는 여러 컴퓨터 프로그램이 개발되었다. 이러한 과정을 트랜스코딩이라고 한다.[15]

웹 브라우저와 같은 크로스 플랫폼에서 트랜스코딩을 지원한다. 대부분의 최신 웹 브라우저는 자동 문자 인코딩 감지 기능을 갖추고 있다. 예를 들어, Firefox 3에서는 보기/문자 인코딩 하위 메뉴를 통해 확인할 수 있다. 또한, 인코딩 변환 프로그램 및 표준화된 API인 iconv와 C 및 Java 라이브러리 세트인 국제화 구성 요소 유니코드(International Components for Unicode)를 통해 문자 집합 변환을 수행할 수 있다. ICU4C에서는 uconv를 사용할 수 있다.

윈도우에서는 Encoding.Convert(.NET API)를 사용하여 트랜스코딩을 할 수 있다. 또한 MultiByteToWideChar/WideCharToMultiByte를 통해 ANSI에서 유니코드로, 유니코드에서 ANSI로 변환할 수 있다.[16][17]

9. 벤더별 문자 코드

여러 벤더(회사)들이 독자적인 문자 코드를 개발하여 사용해왔다. 마이크로소프트, IBM, 후지쯔, NEC, 히타치 등이 대표적이다.

벤더문자 인코딩특징
마이크로소프트cp932마이크로소프트판 Shift JIS.
마이크로소프트cp10001마이크로소프트판 MacJapanese.
마이크로소프트cp20290마이크로소프트판 IBM CCSID 00290.
마이크로소프트cp20932마이크로소프트판 일본어 EUC.
마이크로소프트cp21027마이크로소프트판 IBM CCSID 01027.
마이크로소프트cp50220마이크로소프트판 ISO-2022-JP 중 하나.
마이크로소프트cp50221마이크로소프트판 ISO-2022-JP 중 하나.
마이크로소프트cp50222마이크로소프트판 ISO-2022-JP 중 하나.
마이크로소프트cp51932Windows-31J를 EUC-JP로 나타낸 것.
선 마이크로시스템즈(Sun Microsystems)cp942Ccp942의 확장.
선 마이크로시스템즈(Sun Microsystems)cp943Ccp943의 확장.
애플(Apple Inc.)MacJapanese애플판 Shift JIS.
후지쯔(Fujitsu)JEF메인프레임 (M 시리즈, GS 시리즈)에서 사용된다. JIS C 6226-1978을 GR (Graphic Right)에 전개하고, 그 상단 영역에 "JEF 확장 한자"라는 벤더 선정 확장 한자를 배치.
후지쯔(Fujitsu)EUC-U90DS/90계 UNIX 서버에서 사용된다. JIS X 0208-1990을 GR에 전개하고, "JEF 확장 한자"를 싱글 시프트의 GR 전개로 표현.
NECJIPS(J)ACOS-6계 메인프레임에서 사용된다. JIS C 6226-1978의 9구~13구에 특수 문자를 등록하고, GR 영역에 "G1 집합"이라는 벤더 선정 확장 한자를 등록한 코드.
NECJIPS(E)ACOS-2, ACOS-4계 메인프레임에서 사용된다. JIPS (J)의 상하 1바이트를 각각 EBCDIC으로 변환하여 얻는 코드.
NECNEC 내부 코드(E)ITOS, A-VX계 오피스 컴퓨터에서 사용된다. JIPS (J)의 상위 1바이트를 시프트한 것에 대해 상하 1바이트를 각각 EBCDIC으로 변환하여 얻는 코드.
히타치 제작소(Hitachi)KEIS(78)[메인프레임]] (M 시리즈, AP 시리즈)에서 사용된다. JIS C 6226-1978을 GR에 전개하고, 그 상단 영역에 "확장 문자 세트 3"이라는 벤더 선정 확장 한자를 배치.
히타치 제작소(Hitachi)KEIS(83)[메인프레임]] (M 시리즈, AP 시리즈)에서 사용된다. JIS X 0208-1983을 GR에 전개하고, 그 상단 영역에 "확장 문자 세트 3"이라는 벤더 선정 확장 한자를 배치.
IBMIBM 한자 (DBCS-Host)메인프레임 (시스템/360계), AS/400계 오피스 컴퓨터 (현행 제품에서는 IBM i 탑재 PowerSystem)에서 사용된다. JIS C 6226-1978 이전에 제정되었기 때문에, 완전히 독자적인 한자표를 사용. 한자 부분에 관해서는, Windows-31J의 제1·제2 수쥰 한자 및 IBM 확장 문자와 일대일 대응이 있다.
한국IBM|style="white-space:nowrap"|cp930메인프레임에서 사용된다.
한국IBMcp932IBM OS/2에서 사용된다. 마이크로소프트의 cp932와의 동일성은 미확인.
한국IBMcp939메인프레임에서 사용된다.
한국IBMcp942IBM OS/2에서 사용된다.
한국IBMcp943IBM OS/2에서 사용된다.
일본 유니시스LETS-J유니백계 메인프레임에서 사용된다. JIS X 0208-1983을 GR에 전개하고, 그 상단 및 좌측 영역에 벤더 선정 확장 한자를 배치.
일본 유니시스JBIS배로우스계 컴퓨터에서 사용된다.
미쓰비시 전기(Mitsubishi Electric)JSII
・MELCOM 한자		미쓰비시 전기의 메인프레임에서 사용된다. JIS X 0208-1983을 GR에 전개하고, 그 상단 영역에 벤더 선정 확장 한자를 배치.
DECDEC 한자미니컴의 VAX용 OS인 VMS에서 사용된다. JIS X 0208-1983을 GR에 전개하고, 그 좌측 영역에 벤더 선정 확장 한자를 배치.
DECSuper DEC 한자미니컴의 VAX용 OS인 VMS에서 사용된다. JIS X 0208-1983을 GR에 전개하고, 그 좌측 영역에 벤더 선정 확장 한자를 배치. 그리고, 싱글 시프트의 GR 전개로 JIS X 0212를 표현.
어도비(Adobe)90ms-RKSJ-H어도비판 cp932 가로쓰기용.
어도비(Adobe)90ms-RKSJ-V어도비판 cp932 세로쓰기용.
어도비(Adobe)90msp-RKSJ-H어도비판 cp932 반각 영자 프로포셔널판 가로쓰기용.
어도비(Adobe)90msp-RKSJ-V어도비판 cp932 반각 영자 프로포셔널판 세로쓰기용.
어도비(Adobe)83pv-RKSJ-H어도비판 한자Talk6 확장판 Shift_JIS 가로쓰기용.
어도비(Adobe)90pv-RKSJ-H어도비판 MacJapanese 가로쓰기용.
어도비(Adobe)Add-RKSJ-H어도비판 후지쯔(Fujitsu) FMR 확장판 Shift_JIS 가로쓰기용.
어도비(Adobe)Add-RKSJ-V어도비판 후지쯔(Fujitsu) FMR 확장판 Shift_JIS 세로쓰기용.
어도비(Adobe)Ext-RKSJ-H어도비판 NEC 확장판 Shift_JIS 가로쓰기용.
어도비(Adobe)Ext-RKSJ-V어도비판 NEC 확장판 Shift_JIS 세로쓰기용.



이러한 벤더별 문자 코드는 호환성 문제를 야기할 수 있어, 가능한 유니코드 사용을 권장한다.

참조

[1] 웹사이트 Character Encoding Definition http://techterms.com[...] 2010-09-24
[2] 웹사이트 Usage Survey of Character Encodings broken down by Ranking https://w3techs.com/[...] 2024-04-29
[3] 웹사이트 Charset https://developer.an[...] 2021-01-02
[4] 웹사이트 Ancient Computer Character Code Tables – and Why They're Still Relevant http://blog.smartbea[...] Smartbear 2014-04-17
[5] 웹사이트 IBM Electronic Data-Processing Machines Type 702 Preliminary Manual of Information http://www.bitsavers[...] 1954
[6] 웹사이트 UNIVAC System http://www.bitsavers[...]
[7] 웹사이트 An annotated history of some character codes https://www.sr-ix.co[...] 2018-11-01
[8] 뉴스 IBM Drives Hard Disks to New Standards https://books.google[...] Popular Computing Inc. 1985-04-15
[9] 웹사이트 What's the difference between an Encoding, Code Page, Character Set and Unicode? https://docs.microso[...] 2005-03-15
[10] 웹사이트 Glossary of Unicode Terms https://unicode.org/[...] Unicode Consortium
[11] 서적 The Unicode Standard Version 15.0 – Core Specification https://www.unicode.[...] Unicode Consortium 2022-09
[12] 웹사이트 VT510 Video Terminal Programmer Information http://www.vt100.net[...] Digital Equipment Corporation 2017-02-15
[13] 웹사이트 Terminology (The Java Tutorials) https://docs.oracle.[...] Oracle 2018-03-25
[14] 웹사이트 UTR#17: Unicode Character Encoding Model https://www.unicode.[...] Unicode Consortium 2022-11-11
[15] 웹사이트 Encoding.Convert Method https://docs.microso[...]
[16] 웹사이트 MultiByteToWideChar function (stringapiset.h) https://learn.micros[...] 2021-10-13
[17] 웹사이트 WideCharToMultiByte function (stringapiset.h) https://learn.micros[...] 2022-08-09
[18] 웹사이트 Character encoding for iOS developers. Or UTF-8 what now? https://www.galloway[...] 2021-01-02
[19] 웹사이트 UTR#17: Unicode Character Encoding Model https://www.unicode.[...] The Unicode Consortium 2019-05-21
[20] 웹사이트 The Unicode Standard Version 12.0 https://www.unicode.[...] The Unicode Consortium 2019-05-23
[21] 웹사이트 The Unicode Standard Version 12.0 https://www.unicode.[...] The Unicode Consortium 2019-05-21
[22] 웹사이트 The Unicode Standard Version 12.0 https://www.unicode.[...] The Unicode Consortium 2019-05-21
[23] 웹사이트 The Unicode Standard Version 12.0 https://www.unicode.[...] The Unicode Consortium 2019-05-21
[24] 문서 http://docs.oracle.com/cd/E19455-01/806-5582/6jej6u9sp/index.html
[25] 문서 Freed and Postel. 参考文献, ‘1.3. Charset’, p.1.
[26] 웹사이트 UTR#17: Unicode Character Encoding Model https://www.unicode.[...] The Unicode Consortium 2019-07-20
[27] 문서 文学作品に現れたJIS X 0208にない文字 青空文庫 1999-02
[28] 문서 【事例編】JTB、基幹系プラットフォームを刷新 - 進化するITプラットフォーム Part8 IT Leaders 편집부, インプレス (企業) 2009-06
[29] 문서 (마이크로소프트-파일을 열거나 저장할 때 텍스트 인코딩 선택) https://support.micr[...]
[30] 서적 Electric Circuits https://www.docsity.[...] Pearson 2011
[31] 서적 HTML CSS 길벗출판사 2013-08-26


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

문의하기 : help@durumis.com