아마도 누구나 한번쯤 들어봤을 만한 친숙한 코드이다. 아스키 코드는 0x00 ~ 0x7F 까지 각각의 할당된 문자표로서 언어를 표현한다.
7 bit 인코딩으로 33 개의 출력 불가능한 제어 문자들과 공백을 비롯한 95 개의 출력 가능한 문자들로 이루어 진다. 출력 가능한 문자들은 52 개의 영문 알파벳 대소문자와 10 개의 숫자, 32 개의 특수 문자, 그리고 하나의 공백 문자로 이루어진다.
하지만 한글과 같은 1 byte 가 넘어가는 문자를 표현할 수 없다. 아래의 코드를 통해 간단히 알아볼 수 있다.

char test = 'a';
printf("%d", test);

영어를 사용하는 국가의 경우에는 기존의 아스키 코드를 사용하여 문자를 표현할 수 있었지만, 영어를 사용하지 않는 다른 국가 특히, 한 문자가 1 byte 이상 필요한 언어의 경우는 각각 독자적인 형태의 언어 코드를 만들어 냈다.
각 나라마다 서로 각기 다른 언어 코드를 사용하면서 서로 변환하는 데, 번거로움이 초래되었다. 이러한 불편함을 없애고자 유니코드라고 하는 표준 문자 코드를 만들게 되었다.

현재 2008년 4월에 발표된 유니코드 5.1 이 가장 최신버전이다.

유니코드는 0x0000 ~ 0x10FFFF 의 범위를 갖는다. 이 중에서 한글이 포함된 범위는 0x1100 ~ 0x11FF 이다.
이 외에도 한글에서 사용되는 코드의 범위는 아래의 표와 같다.

유니코드를 위한 가변 길이 문자 인코딩 방식 중 하나로서, 유니코드 한 문자를 나타내기 위해 1 바이트에서 4 바이트까지 사용한다. 예를 들어서, U+0000 부터 U+007F 범위에 있는 아스키 문자들은 UTF-8 에서 1 바이트만으로 표시된다.
4 바이트로 표현되는 문자는 모두 기본 다국어 평면(BMP) 바깥의 유니코드 문자이며, 거의 사용되지 않는다. UTF-16 과 UTF-8 중 어느 인코딩이 더 적은 바이트를 사용하는 지는 문자열에서 사용된 코드 포인트에 따라 달라지며, 실제로 압축 알고리즘을 사용할 경우 이 차이는 무시할 수 있을 정도이다.

UTF-8 은 여러 표준 문서에서 다른 방법으로 정의되어 있지만, 일반적인 구조는 모두 동일하다.
유니코드 코드 포인트를 나타내는 비트들은 여러 부분으로 나뉘어서, UTF-8 로 표현된 바이트의 하위 비트들에 들어간다. U+007F 까지의 문자는 7 비트 아스키 문자와 동일한 방법으로 표시되며, 그 이후의 문자는 다음과 같은 4 바이트까지의 비트 패턴으로 표시된다. 7 비트 아스키 문자와 혼동되지 않게 하기 위하여 모든 바이트들의 최상위 비트는 1 이다.

예를 들어서, 문자 “위”(U+C704)는 다음과 같은 방법으로 UTF-8 로 인코딩 된다.

이 문자는 U+0800 부터 U+FFFF 사이의 영역에 있으므로, 표에 따라 1110xxxx 10xxxxxx 10xxxxxx 형식으로 인코딩된다.
16 진수 C704 는 2 진수 1100-0111-0000-0100 와 같다.
이 비트들은 순서대로 x 로 표시된 비트에 들어간다 : 1110'1100' 10'011100' 10'000100'
결과적으로 이 문자는 3 바이트로 인코딩되며, 16 진수로 표시하면 EC 9C 84 가 된다.

따라서 첫 128 문자는 1 바이트로 표시되고, 그 다음 1920 문자 - 발음 구별 기호가 붙은 라틴문자, 그리스 문자, 키릴 문자, 콥트 문자, 아르메니아 문자, 히브리 문자, 아랍문자 - 는 2 바이트로 표시되며, 나머지 문자들 중 BMP 안에 들어 있는 것은 3 바이트, 아닌 것은 4 바이트로 표시된다.
위의 패턴을 사용하면 더 큰 코드 포인트를 표시할 수도 있다. 원래 UTF-8 은 6 바이트를 사용해서 U+7FFFFFFF 까지의 코드포인트를 표현할 수 있게 하였으나, 2003 년 11월에 발표된 RFC_3629 에서는 유니코드에서 실제로 정의하는 U+10FFFF 까지의 문자만을 표시할 수 있도록 제한하였다. 따라서 이전까지는 UTF-8 에서 나타날 수 없는 바이트가 0xFE 와 0xFF 뿐이었지만, RFC 3629 에 따라서 0xC0, 0xC1 그리고 0xF5 부터 0xFF 까지의 13개의 바이트가 나타날 수 없게 되었다.

그 구조로부터, UTF-8 이 다음과 같은 성질을 가지고 있다는 것을 알 수 있다.

1. 1 바이트로 표시된 문자의 최상위 비트는 항상 10 이다.
2. 2 바이트 이상으로 표시된 문자의 경우, 첫 바이트의 상위 비트들이 그 문자를 표시하는 데 필요한 바이트 수를 결정한다. 예를 들어서 2 바이트는 110 으로 시작하고, 3 바이트는 1110 으로 시작한다.
3. 첫 바이트가 아닌 나머지 바이트들은 상위 2 비트가 항상 10 이다.

UTF-8 이 이런 성질을 가지도록 설계한 까닭은 어떤 경우에도 한 문자에 대한 바이트 표현이 다른 문자에 대한 바이트 표현의 일부가 되는 경우가 없도록 하기 위함이다. 따라서 텍스트 안에 들어 있는 다른 텍스트를 찾는데 쓰이는 바이트 단위의 부문자열 매칭이 UTF-8 문자열에서도 쓰일 수 있다.
통합 완성형, Shift_JIS, Big5 와 같이 ISO 2022 체계에 부합하지 않는 이전의 가변길이 인코딩은 그런 성질을 지니지 않았고(기존 인코딩 가운데 EUC-KR 이나 EUC-JP 등은 이 점에서는 UTF-8 과 비슷한 성질을 지닌다)
더 복잡한 알고리즘을 써야 했다. 왜냐하면, 이들 인코딩은 아스키 영역의 글자를 나타내는 바이트를 2 바이트로 나타내는 다른 글자의 두번째 바이트로 사용하기 때문이다.
또한 UTF-8 에서 하나 이상의 바이트들이 손실되었을 때도, 다음의 정상 문자를 찾아서 동기화할 수 있기 때문에 피해를 줄일 수 있다.
그 설계 때문에 어떤 바이트들이 올바른 UTF-8 로 확인되면, 그 문자열이 실제로 UTF-8 로 인코딩되었을 가능성이 매우 높다. 임의의 바이트들이 순수한 아스키 인코딩이 아닌 UTF-8 문자열일 가능성은 2 바이트 문자의 경우 1/32, 3 바이트 문자의 경우 5/256 으로 매우 낮다. 또한 ISO-8859-1 과 같은 기존의 인코딩으로 표현된 자연어 문자열이나 문서를 UTF-8 로 표현된 것으로 오인할 가능성도 매우 낮다.

잘못된 입력이 들어 왔을 때 UTF-8 디코더가 해야 할 동작은 표준들에 일정하게 정의되어 있지 않다. 일반적으로 이러한 경우에 디코더가 취할 수 있는 동작은 다음과 같을 수 있다.

1. U+003F(?, 물음표)나 U+FFFD(�, 유니코드 대치 문자) 같은 다른 문자를 집어 넣는다.
2. 해당 바이트들을 무시한다.
3. 해당 바이트들을 다른 인코딩으로 해석한다.
4. 오류로 처리하지 않고 UTF-8과 비슷한 형식으로 취급하여 디코딩한다. (이러한 동작은 디코더의 버그일 수도 있다)
5. 오류를 보고한다.

또한 디코더들은 다른 잘못된 입력에 대해서 다른 동작을 보일 수 있다.

RFC 3629에서는 UTF-8 디코더들이 '너무 긴 형식', 즉 해당 문자를 표현하는 데 필요한 최소의 바이트보다 더 많은 바이트를 사용해서 표현한 바이트들을 잘못된 입력으로 처리해야 한다고 요구하고 있다. 유니코드 표준에서는 유니코드를 따르는 디코더가 '잘못된 형식으로 표현된 모든 단위 문자열을 오류로 처리하고, 따라서 잘못된 형식으로 표현된 단위 문자열을 해석하거나 생성해 내서는 안 된다' 라고 요구하고 있다.

모든 가능한 해석은 장단점을 가지고 있으며, 만약 UTF-8을 해석하기 전에 검증이 이루어질 경우 보안 관련해서 주의가 요구된다.

너무 긴 형식은 처리하기 곤란한 경우 중 하나이다. 현재의 RFC에는 이러한 형식이 디코드되어서는 안 된다고 규정하고 있지만, 옛 UTF-8 표준에는 경고만 하였으며 대부분의 간단한 디코더들은 이러한 데이터를 정상적으로 해석한다. 이 형식은 실제로는 같은 코드 포인트를 서로 다른 두 개의 UTF-8 문자열로 나타내어 마이크로소프트의 IIS 웹 서버와 같은 제품의 보안 검증을 우회하는데 사용되었다.

잘못된 입력이 들어 왔을 때 보안을 지키기 위해서는 두 가지 선택이 있다. 한 가지는 입력을 검증하기 전에 항상 UTF-8로부터 디코드하는 것이며, 다른 한 가지는 잘못된 입력을 언제나 오류로 처리하는 엄격한 디코더를 사용하는 것이다.

1. ASCII 인코딩은 UTF-8의 부분 집합이다. 일반적인 ASCII 문자열은 올바른 UTF-8 문자열이며, 따라서 하위 호환성이 보장된다.
2. UTF-8 문자열은 바이트 단위로 정렬을 수행하는 알고리즘으로도 코드 포인트 단위로 올바르게 정렬할 수 있다. (일반적인 목적으로는 재정렬이 필요하다)
3. UTF-8과 UTF-16은 XML 문서의 표준 인코딩으로, 다른 인코딩들을 사용하려면 외부에서, 또는 문서 안에서 명시적으로 인코딩을 정해야 한다.
4. 다른 인코딩과의 왕복 변환이 간단하다.
5. 바이트 단위 문자열 검색 알고리즘들을 그대로 사용할 수 있다.
6. 간단한 알고리즘을 통하여 UTF-8 문자열임을 확인할 수 있다. 즉, 다른 인코딩에서 나타나는 바이트들이 올바른 UTF-8 문자열일 가능성은 낮다.
7. U+0000을 표현할 때를 제외하면, 널 문자는 UTF-8 문자열 안에 나타나지 않는다. 따라서 널 문자로 끝나는 문자열을 사용하는 C 언어의 문자열 함수(strncpy() 같은)를 그대로 사용할 수 있다.

1. 나쁘게 만들어진(그리고 현재 표준을 따르지 않는) UTF-8 파서는 서로 다른 가짜 UTF-8 표현(예를 들어서 너무 긴 형식)을 같은 유니코드 문자열로 해석할 수 있다.

1. UTF-8은 한 문자를 표현하는 데 UTF-7보다 더 적은 바이트들을 사용한다.
2. UTF-8은 “+“를 그대로 인코딩하지만 UTF-7은 ”+-“로 인코딩한다.

1. UTF-8은 8비트 안전한 전송 체계가 필요하다. 전자 우편에서 quoted-printable이나 base64 인코딩을 사용한다면 전송량이 더 많아진다. 예를 들어서 base64 인코딩의 경우 인코딩된 결과는 원본보다 약 33% 더 커진다. 하지만 최근에는 대부분의 SMTP 서버가 8BITMIME 을 지원하기 때문에 이런 단점은 크게 부각되지 않는다.

1. U+0000부터 U+007F까지의 공백과 문장 부호를 포함한 ASCII 문자들은 1바이트로 표현할 수 있기 때문에, 한중일 문자와 표의 문자를 사용하지 않는 대부분의 문자열을 UTF-16보다 더 작은 크기로 표현할 수 있다.
2. 유닉스 의 파일 시스템과 여러 도구들은 옥텟 (컴퓨팅), 옥텟 을 기본 단위로 하며, 널 문자와 경로 식별자(<code>/</code>, 0x2F)에 특별한 의미를 부여하는 경우가 많다. 0x00이나 0x2f 옥텟이 U+0000과 U+002F가 아닌 다른 문자에서도 나타날 수 있는 UTF-16 등의 인코딩과는 달리, UTF-8은 ASCII와 호환되기 때문에 0x00이나 0x2f 옥텟이 항상 U+0000과 U+002F에 대응되므로 기존 API를 약간 수정해서 쓸 수 있다.
3. UTF-16은 바이트 순서를 나타내기 위하여 바이트 순서 표식, 바이트 순서 문자(BOM, U+FEFF)가 필요하지만, UTF-8은 바이트 순서가 정해져 있기 때문에 BOM이 필요하지 않다.

1. UTF-8은 가변 길이 인코딩이며, 다른 문자는 다른 바이트 수로 표현될 수 있다. 사실 이 문제는 별로 심각한 것이 아니며, UTF-8 문자열을 다루기 위한 추상적인 인터페이스를 만드는 것으로 해결될 수 있다. 실제로 기술적으로는 UTF-16도 BMP 바깥 문자를 4바이트로 표현하기 때문에 가변 길이 인코딩이다.
2. BMP에 들어 있는 한중일 문자들은 UTF-8에서 3바이트로 표현되지만, UTF-16에서는 2바이트로 표현된다. 따라서 UTF-8에서는 이러한 문자를 표현하기 위하여 더 많은 바이트가 필요하며 UTF-16과 비교할 때 최대 50%까지 크기가 늘 수 있다. 하지만 반대로 U+0000부터 U+007F 사이의 글자들은 UTF-16에서 크기가 두 배로 늘기 때문에 실질적으로는 큰 문제가 없을 수도 있다.

UTF-16(16 bit Unicode Transformation Format)은 유니코드 문자 인코딩 방식의 하나이다. 주로 사용되는 기본 다국어 평면에 속하는 문자들은 그대로 16 비트 값으로 인코딩이 되고 그 이상의 문자는 특별히 정해진 방식으로 32 비트로 인코딩이 된다.
UTF-16 은 유니코드 컨소시움과 ISO/IEC 10646 에 의해 정의되어 있다. 유니코드는 거기에 추가적인 내용을 정하고 있다. 정확한 차이점은 유니코드 4.0 표준의 부록편 부분에 자세히 기술되어 있다. ISO 표준은 UCS-2 인코딩도 정의하며 여기선 BMP 의 16 비트 표현만을 다룬다.
기본 다국어 평면은 U+0000 에서 U+FFFF 에 놓인 문자를 담고 있다. 이 영역에는 우리가 쉽게 생각할 수 있는 문자들이 포함되며, 한글, 한자 등은 모두 여기에 포함되어 있다. 이 영역에는 서로 게이트(surrogate) 문자들이 준비되어 있어 16 비트 이상의 문자를 표현할 때를 대비해 놓았다.
기본 다국어 평면의 문자들은 곧바로 16 비트 값으로 대응되어 인코딩되며, 이 경우에는 인코딩된 바이트 스트링의 엔디언만 조심하면 된다.

그림

기본 다국어 평면에 포함되지 않는 문자들, 즉 16 비트로 값을 표현할 수 없는 문자들은 서로게이트(Surrogate) 문자 영역에 해당하는 두 개의 16 비트 문자로 변환되어 이 한 쌍(즉 32 비트)이 그 문자를 나타내게 된다.
그 자세한 방식은 다음 그림을 통해 설명한다.

유니코드 문자 영역에서 상위 서로 게이트는 U+D800 에서 U+DBFF 까지의 값을 갖는다. 즉 최상위비트 6 개의 값이 그림에서 보듯이 110110 으로 일정하다. 마찬가지로 하위 서로게이트는 U+DC00 에서 U+DFFF 까지의 값을 가지며 최상위 비트 6 개의 값은 110111 이 된다. 각 서로게이트 문자는 하위 10 비트 씩의 자유도를 갖는다. 따라서 주어진 문자를 10 비트 씩 두조각을 내서 상위 서로게이트와 하위 서로게이트에 배정한 것이다.
여기서 다음을 만족한다.

이 방법으로 UTF-16 인코딩이 가능한 유니코드 문자의 범위가 나온다.
zzzzz=00000 이라면, 문자는 16 비트 이하로 표현이 가능하다. 즉, U+00xxxx 그대로 대응되는 값을 써주면 된다. 그렇지 않다면 ZZZZ=0000..1111

Extended Unix Code 의 약자로서 한국어, 중국어 등에 주로 사용되는 8 비트 문자 인코딩 방식이다. 한글을 표현하는 데 가장 많이 사용되는 EUC-KR 은 이 인코딩 방식을 사용한 것이다.

한글을 그 구조와 관계없이 코드를 배당하여 표현하는 문자 인코딩을 총칭하는 말이며, 흔히 한글 조합형 인코딩과 비교된다.

최상위 비트를 사용할 수 없는 영문 프로그램들에서 사용하기 위하여 만들어졌으며, 로마자 소문자 뒤에 대문자가 오거나 $ 등의 특수문자 뒤에 로마자가 오는 등 일반적으로 사용되지 않는 조합에 자주 사용되는 한글을 배열한 것이다. 표현할 수 있는 글자 수가 1300 여자로 제한되고, 영문이 한글로 표시되는 문제가 종종 발생했다.

현재 KS X 1001 과 EUC-KR 로 표준화되어 사용되고 있는 문자 집합 및 인코딩이다. 2350 자만의 한글을 완성된 형태로 지원하게 되어서 많은 논란을 낳았다.

한글을 그 낱자에 따라 기계적으로 조합하여 표현하는 문자 인코딩들을 총칭하는 말이다.

최상위 비트를 사용하지 않고 한글을 전송하므로 하위 호환성을 유지할 수 있음. 한글이 나오는 부분을 SI 와 SO 로 둘러싸서 구분하고, 그 안에서 홀낱자를 순서대로 배열하여 한글을 표현한다. 예를 들어 '원더걸스'는 다음과 같이 표현한다.

<SI>ㅇㅜㄴㄷㅓㄱㅓㄹㅅㅡ<SO>

n 바이트 조합형이라는 이름은 한글 한 글자가 2 바이트에서 최고 5 바이트가 될 수 있기 때문에 붙었다. 단점은 다른 인코딩에 비해 결과물이 다소 길고 가변 길이라서 처리가 불편하다.

한 글자의 길이가 가변적인 n 바이트 조합형의 단점을 보완하기 위해, 한글 한 글자를 초성, 중성, 종성으로 나누고 각각을 인코딩하여 항상 3 바이트로 표현하는 방법이다.
ㅄ과 같은 겹낱자도 1 바이트로 표현하고, 종성(받침)이 없는 경우 채움 문자를 넣어서 쓴다. 한글 한 글자의 길이가 일정하게 유지되기 대문에 처리가 편리하지만 2 바이트 조합형에 비해서는 결과물이 길다.
3 바이트 조합형은 나중에 KS X 1001 에서 한글 영역에 들어있지 않은 현대 한글을 표현할 때 사용되었다. 실제로는 3 바이트는 아니다. 이 경우 한글 채움 문자를 앞에 넣어서 표시를 해 줘야 하기 때문에 실질적으로 4 개의 글자를 사용하게 된다.

최상위 비트를 사용할 수 있는 환경에서 2 바이트로 한글을 표현하기 위해 사용하는 방법이며, 그냥 조합형이라고 하면 이 종류의 인코딩을 나타내는 경우가 많다.
이 방법에서는 2 바이트(16 비트)를 최상위 1비트, 초성 5 비트, 중성 5 비트, 종성 5 비트로 다음과 같이 나누고, 아스키와 겹치지 않도록 한글은 최상위 비트를 설정하여 표현하였다.

1xxxxxyy yyyzzzzz

이 방법은 3 바이트 조합형과 같은 원리를 사용하면서 결과물이 더 짧기 때문에, 7 비트 환경을 제외하고 널리 사용되었다. 또한 미완성 한글을 2 바이트로 표현할 수 있다는 장점도 있다. 그러나 둘째 바이트의 최상위 비트가 0 일 수도 있기 때문에 문자열 검색 등에서 문제가 생길 수 있다.
초성, 중성, 종성에 실제로 어떤 코드를 배당하고, 한자와 특수문자를 어떻게 표현할 지는 인코딩마다 서로 다르며, 상용 조합성, 삼성 조합형, 금성 조합형, 도깨비 조합형 등이 공존했다. 윈도우 95 가 발표되면서 부터 점차 사용되지 않기 시작했다.

1974년에 처음으로 제정되었고, 2004년에 개정된 KS X 1001:2004 가 최신 규격이다.
이 규격은 2 바이트 부호계로서, 0x2121 ~ 0x7EHE 까지 영역에서 8836 문자의 표현을 규정하는데, 문자는 제어 문자와 도형 문자로 분류하며, 도형 문자는 특수 문자, 괘선 조각, 숫자, 한글 낱자, 한글 글자 마디, 한자, 기본 로마 문자, 확장 로마 문자, 그리스 문자, 가나 문자, 키릴 문자로 구성되어 있다.
KS X 1001 은 유니코드를 제외하고 한국에서 사용되는 거의 유일한 문자 집합이다. KS X 1001 기반의 문자 인코딩으로는 EUC-KR(완성형)과 ISO-2022-KR 이 있다.
MS 윈도에서 사용하는 CP949 는 EUC-KR 의 확장으로 2 바이트로 표현할 수 없는 한글 글자 마디 8821 자를 추가한 것이다.

KS X 1001 과 KS X 1003 을 사용하는 8 비트 문자 인코딩으로, EUC 의 일종이며 대표적인 한글 완성형 인코딩이기 때문에 보통 완성형이라고 불린다.
EUC-KR 인코딩은 다음과 같이 구성된다.

1. 128 보다 작은 바이트에 KS X 1003 을 배당한다.
2. 128 보다 크거나 같은 바이트에 KS X 1001 을 배당한다. 각 글자는 행과 열에 128 을 더한 코드값을 사용하여 2 바이트로 표현된다.

따라서 KS X 1001 의 40-27 에 배당된 “위” 라는 글자는 EUC-KR 에서 C0 A7 라는 바이트 열로 표현된다.
KS X 1001 에는 한글 채움 문자를 사용하여 규격의 문자 집합에 포함되지 않은 한글을 표현하는 확장 방법이 있지만, 대부분의 경우 이 방법은 EUC-KR 에서 사용되지 않고 대신 CP949 와 같은 다른 방법을 사용하여 KS X 1001 바깥의 현대 한글을 표현한다.

코드페이지 949(CP949)는 마이크로 소프트 한글 윈도우에서 사용되는 코드페이지이다. 본래는 KS C 5601 의 완성형 한글을 표현한 코드페이지였으나, 윈도 95 부터는 확장 완성형 혹은 통합형 한글 코드 라는 명칭으로 확장되어 모든 현대 한글을 수용하게 되었다.
마이크로소프트에서는 이 인코딩을 기반 문자 집합 이름인 “ks_c_5601-1987” 로 사용하고 있다.
CP949 인코딩은 EUC-KR 의 확장이며, 하위 호환성이 있다.

1. 128 보다 작은 바이트에 KS X 1003 을 배당한다.
2. 128 보다 크거나 같은 두 바이트에 KS X 1001 을 배당한다. 각 글자는 행과 열에 128 을 더한 코드값을 사용하여 2 바이트로 표현된다. 행과 열 번호가 32 부터 시작하기 때문에 실제로 이 문자 집합은 첫째/둘째 바이트가 161 부터 254 범위에 있다.
3. 나머지 공간에 KS X 1001 에 없는 8822 자의 현대 한글을 가나다 순서대로 배당한다. 이 경우 첫째 바이트가 129 부터 197 까지 이며, 둘째 바이트는 65 부터 90 까지(로마자 대문자), 97 부터 122 까지(로마자 소문자), 129 부터 254 까지의 범위이다. 단 첫째 바이트가 161 이상일 경우 KS X 1001 과 충돌을 막기 위해 둘째 바이트는 161 이상이 될 수 없다.
4. 한글 채움 문자의 부호값은 A4D4 이다.

따라서 KS X 1001 의 40-27 에 배당된 “위” 라는 글자는 CP949 에서도 C0 4A 라는 바이트 열로 표현된다.
한편 KS X 1001 에 없는 ”&#44056;” 이라는 글자는 KS X 1001 에 없는 현대 한글 중 10 번째이고 따라서 CP949 에서 81 4A 가 된다.