문자 인코딩 강좌는 14단계 인터랙티브 튜토리얼로, 개발 중에 자주 나오지만 제대로 설명해 주는 사람은 드문 질문에 답합니다. 한자는 몇 바이트나 차지할까? "😀".length는 왜 2일까? Base64 끝의 =는 무슨 일을 할까? 글자가 깨진 것은 파일이 망가진 걸까, 살릴 수 있을까? 단계마다 자유롭게 고칠 수 있는 실험용 텍스트 하나와 여러 뷰가 주어집니다. 문자마다의 비트, 바이트, Unicode 코드 포인트, UTF-8 바이트 단위 분해, Base64의 6비트 그룹, URL 퍼센트 인코딩, 그리고 「다른 인코딩으로 읽으면 어떻게 보이는가」입니다. 목표는 어떤 수를 읽어 내기, 어떤 16진수를 적기, 조건에 맞는 문자를 입력하기 등이고 판정기가 즉시 체크합니다.

강좌 순서는 인코딩의 역사 순서와 같습니다. 비트와 바이트 → ASCII의 128가지 약속 → Unicode가 문자마다 번호를 부여 → UTF-8이 그 번호를 1에서 4바이트로 바꾸는 방법 → UTF-16과 JavaScript 문자열 길이 → Base64가 바이트를 순수 텍스트로 옮기는 방법 → URL 인코딩 → 마지막 두 단계는 글자 깨짐을 다룹니다. 어떻게 생기는지, 浣犲ソ에서 你好를 어떻게 역추적하는지 말입니다.

약 40분이면 끝납니다. 프런트엔드·백엔드 개발자, 데이터를 다루는 사람, 그리고 글자 깨짐과 Base64, 이모지 길이 때문에 곤란을 겪은 적이 있는 누구에게나 맞습니다. 2진수를 셀 줄만 알면 됩니다.

1. 01목표와 실험용 텍스트 확인단계마다 위쪽에 목표가 있습니다. 실험용 텍스트 상자에는 그 단계의 예시가 미리 채워져 있고 아무 내용으로나 바꿀 수 있으며, 모든 뷰가 즉시 다시 계산됩니다.
2. 02뷰 읽기그 단계에 맞는 뷰가 펼쳐집니다. 「비트」 뷰는 문자마다 8비트 묶음을 보여 주고, 「코드 포인트」 뷰는 U+ 번호와 UTF-16 코드 단위를 나열합니다. 「UTF-8 분해」는 바이트마다 접두사 비트와 페이로드 비트를 나눠 색을 입히고, 「Base64 그룹」은 3바이트 → 4문자를 배치합니다. 「URL 인코딩」은 어떤 문자가 %XX로 바뀌는지 표시하고, 「다른 인코딩으로 읽기」는 같은 바이트열을 GBK, Latin-1, UTF-16으로 읽으면 어떻게 보이는지 보여 줍니다.
3. 03답 입력대부분의 단계는 답 칸에 숫자, 16진수, 문자열을 적습니다. 일부 단계는 실험용 텍스트 자체를 조건에 맞게 고쳐야 합니다(예: 「정확히 3바이트 문자 하나」). 한 단계는 객관식입니다.
4. 04판정결과 표시줄이 통과인지 어디가 다른지 즉시 보여 줍니다. 16진수 답은 대소문자와 공백을 가리지 않습니다.
5. 05힌트, 정답, 진행 상황「힌트」는 실마리를 주고 「정답 보기」는 참고 답을 보여 주며 채워 넣을 수 있습니다. 진행 상황은 이 브라우저에 저장되고 ?lesson=n으로 특정 단계에 바로 들어갈 수 있습니다.

6단계 「UTF-8 2바이트」는 café를 예시로 é의 두 바이트를 쓰라고 합니다.

14단계 「깨진 글자 역추적」은 GBK로 읽힌 깨진 글자 浣犲ソ를 주고 실험용 텍스트에서 원문을 찾으라고 합니다.

문자   코드 포인트   2진 코드 포인트      UTF-8 템플릿            바이트
c      U+0063    1100011             0xxxxxxx                63
a      U+0061    1100001             0xxxxxxx                61
f      U+0066    1100110             0xxxxxxx                66
é      U+00E9    000 1110 1001       110xxxxx 10xxxxxx       C3 A9
                 → 11비트 페이로드 00011 101001을 템플릿에 채움 → 11000011 10101001
답     C3 A9   ✓

실험용 텍스트   中文      UTF-8 바이트  E4 B8 AD E6 96 87    GBK로 읽으면 → 涓枃
실험용 텍스트   你好      UTF-8 바이트  E4 BD A0 E5 A5 BD    GBK로 읽으면 → 浣犲ソ   ← 문제와 일치
답               你好   ✓

1단계: 비트와 바이트

컴퓨터에는 0과 1밖에 없습니다. 비트(bit) 하나는 스위치 하나이고, 8개가 모여 바이트(byte) 하나가 되며 $2^8 = 256$가지 값을 나타냅니다. 자릿값을 더하면 2진수가 10진수가 됩니다. 01000001 = 64 + 1 = 65입니다. 모든 글자는 결국 바이트열이고, 「문자 인코딩」은 어떤 수가 어떤 문자를 뜻하는지 정한 표입니다. 표가 다르면 인코딩이 다릅니다.

2–3단계: ASCII

1963년의 ASCII는 7비트로 128개 문자를 정의했습니다. 0–31은 줄바꿈, 탭, 벨 같은 제어 문자이고, 48–57은 숫자 0–9, 65–90은 대문자, 97–122는 소문자입니다. 표는 마구 만든 것이 아닙니다. 대문자와 소문자는 32만큼 차이 나므로(2진수 6번째 비트) c | 0x20으로 대문자를 소문자로 바꿀 수 있고, 숫자 문자에서 48을 빼면 값이 됩니다. 16진수는 바이트를 읽을 때 쓰는 관용 표기이고 두 자리가 정확히 1바이트입니다. 0x48 0x69 = Hi입니다. ASCII는 7비트만 썼고 8번째 비트는 비어 있었습니다. 나중에 각 나라가 이 비트를 자기 방식으로 채웠고(Latin-1, GBK, Shift_JIS…), 서로 호환되지 않아 글자 깨짐의 역사적 뿌리가 되었습니다.

4단계: Unicode 코드 포인트

Unicode는 전 세계 문자에 번호를 통일해 붙입니다. 이 번호를 코드 포인트(code point)라고 하고 U+에 16진수를 붙여 씁니다. A는 U+0041, 中은 U+4E2D, 😀은 U+1F600입니다. 공간은 U+0000부터 U+10FFFF까지이고 17개 「평면」으로 나뉩니다. 자주 쓰는 문자는 거의 다 0번 기본 평면(U+0000–U+FFFF)에 있고, 이모지와 드문 한자는 보충 평면에 있습니다. 중요한 점은 코드 포인트는 번호일 뿐이고, 그것이 바이트가 되는 방식은 UTF-8, UTF-16, UTF-32 같은 「인코딩 형식」이 정한다는 것입니다. 「Unicode」는 하나의 인코딩이 아니고 utf-8이 인코딩입니다.

5–8단계: UTF-8의 가변 템플릿

UTF-8(RFC 3629)은 코드 포인트 하나를 1–4바이트로 표현하고, 규칙을 전부 첫 바이트의 접두사에 적어 둡니다.

코드 포인트의 2진수를 왼쪽에 0을 채워 페이로드 비트 수에 맞춘 뒤 x 자리에 차례로 넣으면 바이트가 됩니다. é = U+00E9 = 11101001을 11비트로 채우면 00011 101001이고, 2바이트 템플릿에 넣으면 11000011 10101001 = C3 A9입니다.

이 설계에는 장점이 셋 있습니다. ASCII 텍스트는 UTF-8로 인코딩해도 바이트 하나가 바뀌지 않습니다(완전한 하위 호환). 뒤따르는 바이트는 모두 10으로 시작하므로 바이트열 중간 아무 위치에서도 다음 문자의 시작을 찾을 수 있습니다(자기 동기화, 바이트 하나를 잃어도 전체가 어긋나지 않음). 길이가 다른 인코딩은 서로 겹치지 않아 00 같은 0 바이트는 언제나 U+0000만 뜻합니다(C 문자열에 안전). 대가는 한자 한 글자가 3바이트라 GBK의 2바이트보다 50% 크다는 점입니다. 그래도 영어, 구두점, 코드는 영향을 받지 않아 UTF-8이 웹페이지 98% 이상의 인코딩이 되었습니다.

7, 8단계에서는 3바이트 문자와 4바이트 문자를 직접 입력합니다. 후자는 지금도 자주 걸리는 함정을 보여 줍니다. MySQL의 utf8 문자 집합은 실제로 3바이트까지만 지원해서 이모지를 저장하면 오류가 나거나 잘리고, 반드시 utf8mb4를 써야 합니다.

9단계: UTF-16과 .length

JavaScript, Java, C#, Windows API의 문자열은 내부적으로 UTF-16을 씁니다. 코드 단위(code unit)는 16비트입니다. 기본 평면 문자는 코드 단위 하나를 차지하고, 보충 평면의 코드 포인트는 코드 단위 둘로 쪼개지며 이를 서로게이트 쌍(surrogate pair)이라고 합니다. 범위는 D800–DBFF와 DC00–DFFF입니다. 그래서 "😀".length === 2이고, "😀".split("")은 의미 없는 반쪽 두 개로 자르며, str[0]은 상위 서로게이트를 가져옵니다. 실제 문자 수로 세려면 [...str].length(코드 포인트 단위 반복)를 쓰고, 사용자가 인식하는 「한 글자」(결합 이모지, 발음 구별 부호 포함)로 세려면 Intl.Segmenter를 씁니다.

10–11단계: Base64

Base64(RFC 4648)는 암호화가 아니라 임의의 바이트를 64개 인쇄 가능 ASCII 문자(A–Z a–z 0–9 + /)로 옮기는 운반 방식입니다. 바이너리를 텍스트만 받는 곳에 밀어 넣기 위한 것입니다. 메일 첨부, JSON 필드, data: URL, JWT가 그렇습니다. 방식은 3바이트 = 24비트를 6비트 네 토막으로 나누고($2^6 = 64$) 토막마다 표에서 문자 하나를 찾는 것입니다. Man = 4D 61 6E = 01001101 01100001 01101110 → 010011 010110 000101 101110 → T W F u입니다. 그래서 크기가 원래의 4/3로 늘어납니다.

바이트 수가 3의 배수가 아니면 마지막 묶음이 차지 않습니다. 1바이트가 모자라면 = 하나, 2바이트가 모자라면 = 둘을 붙여 출력 길이가 언제나 4의 배수가 되게 합니다. A 한 바이트 8비트에 0을 채워 12비트로 만들고 010000 01(0000)으로 나누면 QQ가 되며 ==를 더합니다. URL-safe 변형은 + /를 - _로 바꾸고(URL에서 이스케이프되지 않게) 보통 =를 생략하는데, 디코딩할 때 길이를 보고 되돌립니다.

12단계: URL 퍼센트 인코딩

URL에서 그대로 나올 수 있는 ASCII 문자는 일부뿐입니다(RFC 3986 §2). 공백, &, =, ?, /처럼 문법적 의미가 있는 예약 문자와 모든 비 ASCII 문자는 %와 바이트의 16진수로 적어야 합니다. 그래서 URL 인코딩은 **먼저 UTF-8, 다음에 바이트마다 %**입니다. 中 → E4 B8 AD → %E4%B8%AD처럼 한자가 9개 문자로 늘어납니다. JavaScript에서는 encodeURIComponent가 가장 철저하게 인코딩하고(/ ? & =까지 인코딩) 파라미터 값에 넣기 좋으며, encodeURI는 구조 문자를 남겨 두어 주소 전체에 맞습니다. 폼 전송의 application/x-www-form-urlencoded는 공백을 +로 쓰는데, 이것은 HTML 폼의 역사적 약속이고 RFC 3986의 일부가 아닙니다.

13–14단계: 글자 깨짐은 어디서 오고 어떻게 살리는가

글자 깨짐은 데이터 손상이 아니라 쓸 때 인코딩 A, 읽을 때 인코딩 B를 쓴 결과입니다. UTF-8의 中은 E4 B8 AD입니다.

• Windows-1252 / Latin-1(1바이트 1문자)로 읽으면 세 바이트가 서유럽 문자 中 세 개가 됩니다. 발음 기호가 붙은 문자 더미는 「UTF-8을 서유럽 인코딩으로 읽었다」는 표시입니다.
• GBK(2바이트 1한자)로 읽으면 E4 B8이 한자 涓이 되고 남은 AD는 반쪽만 남습니다. 「이상한 한자 + 반쪽 문자」는 「UTF-8을 GBK로 읽었다」는 표시이고 浣犲ソ, 涓枃이 여기에 속합니다.
• 반대로 GBK 텍스트를 UTF-8로 읽으면 잘못된 바이트열마다 대체 문자 �(U+FFFD)가 잔뜩 나옵니다.

원래 바이트만 살아 있으면 올바른 인코딩으로 다시 읽어 글자를 온전히 되살릴 수 있습니다. 그래서 깨진 글자를 고치는 첫 원칙은 원본 파일을 보존하고 변환을 반복하지 않는 것입니다. 변환할 때마다 잘못된 바이트가 ?나 �로 바뀔 수 있고, 그때부터가 진짜 정보 손실입니다. 14단계에서는 역방향 작업을 합니다. 깨진 글자 浣犲ソ를 GBK 기준으로 바이트 E4 BD A0 E5 A5 BD로 되돌리고, 다시 UTF-8로 읽어 你好를 얻습니다. 요즘 방식은 HTTP 헤더, HTML <meta charset>, 데이터베이스 연결, 파일 저장 대화상자에서 UTF-8을 통일해 선언해 불일치가 생길 기회를 없애는 것입니다.

BOM과 바이트 순서

UTF-16에는 빅 엔디언과 리틀 엔디언 두 가지 바이트 순서가 있고, 파일 앞에 바이트 순서 표시 BOM(FE FF 또는 FF FE)을 두는 일이 많습니다. UTF-8은 바이트 순서 문제가 없지만, Windows 메모장이 UTF-8 BOM EF BB BF를 기본으로 넣던 시절이 있어 셸 스크립트 첫 줄이 오류를 내거나 CSV 첫 열 이름 앞에 보이지 않는 문자가 붙곤 했습니다. 강좌의 UTF-8 분해 뷰에서 이 세 바이트가 맨 앞에 보이면 출처를 짐작할 수 있습니다.

인코딩

ASCII, UTF-8, UTF-16, Base64, URL 인코딩을 자세히 다룹니다. GBK와 Windows-1252는 글자 깨짐 시연에만 쓰고 브라우저의 TextDecoder에 의존하며, GB18030, Big5, Shift_JIS의 내부 구조는 다루지 않습니다.

Unicode 심화

정규화(NFC/NFD), 결합 문자 시퀀스, 양방향 텍스트, 자소 클러스터 경계 알고리즘은 다루지 않습니다. 이모지의 피부색 수정자와 ZWJ 결합은 힌트에서만 언급합니다.

Base64

표준과 URL-safe 두 문자 집합만 다룹니다. Base32, Base16, MIME의 76자 줄바꿈 규칙은 다루지 않습니다.

판정 방식

16진수 답은 대소문자와 공백을 가리지 않습니다. 「문자 입력」 유형의 단계는 UTF-8 바이트 수와 문자 수로 판정하며 조건을 만족하는 문자는 무엇이든 허용합니다.

하지 않는 일

일괄 트랜스코딩 도구가 아닙니다(실제 데이터 처리는 「Base64 변환」, 「URL 도구」를 쓰세요). 파일 인코딩을 감지하거나 업로드한 파일을 고쳐 주지도 않습니다.

• 「Unicode는 인코딩이다」: Unicode는 문자 집합(번호표)이고 UTF-8 / UTF-16이 인코딩입니다. Windows 메모장의 「Unicode로 저장」은 실제로 UTF-16 LE입니다.
• 「한자는 2바이트다」: GBK에서는 2, UTF-8에서는 3, UTF-16에서는 기본 평면이 2이고 확장 B 영역의 드문 한자는 4입니다. 먼저 「어떤 인코딩인지」를 물어야 합니다.
• 「Base64는 암호화다」: 누구나 디코딩할 수 있고 표현만 바꾼 것입니다. 비밀을 지키려면 진짜 암호화를 쓰세요.
• 「글자가 깨졌으면 파일이 망가진 것」: 대부분은 읽는 방식이 틀린 것뿐이라 인코딩을 바꿔 다시 열면 됩니다. 「변환」을 반복할 때 진짜로 글자가 사라집니다.
• 「length가 곧 문자 수다」: JavaScript에서는 UTF-16 코드 단위 수라 이모지와 일부 드문 한자가 2로 셉니다. 데이터베이스 VARCHAR(n)의 n도 데이터베이스에 따라 바이트 수일 수도 문자 수일 수도 있습니다.
• 「URL에 한글을 그냥 쓰면 된다」: 브라우저 주소창이 알아서 인코딩해 보여 주지만, 요청을 조립할 때는 반드시 encodeURIComponent를 써야 합니다. 그렇지 않으면 &, #, 공백이 구조를 깨뜨립니다.

강좌는 전부 브라우저 로컬에서 돌아갑니다. 실험용 텍스트의 인코딩, 디코딩, Base64, URL 인코딩이 모두 페이지 안의 TextEncoder / TextDecoder와 순수 함수로 처리되어 어떤 서버로도 전송되지 않습니다. 학습 진행 상황은 이 기기의 localStorage에 저장됩니다.

• F. Yergeau, RFC 3629, UTF-8, a transformation format of ISO 10646(2003) — 네 가지 바이트 템플릿, 자기 동기화, 올바른 시퀀스의 정의. 강좌 5–8단계의 근거: https://www.rfc-editor.org/rfc/rfc3629(열람일: 2026-09-09)
• S. Josefsson, RFC 4648, The Base16, Base32, and Base64 Data Encodings(2006) — Base64 문자 집합, 패딩 규칙과 URL-safe 변형. §10의 테스트 벡터는 강좌 단위 테스트가 그대로 인용합니다: https://www.rfc-editor.org/rfc/rfc4648(열람일: 2026-09-09)
• T. Berners-Lee 등, RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, §2.1 Percent-Encoding과 §2.2 예약 문자: https://www.rfc-editor.org/rfc/rfc3986#section-2.1(열람일: 2026-09-09)
• The Unicode Consortium, The Unicode Standard, Core Specification, Chapter 2 General Structure(코드 포인트, 평면, 인코딩 형식, 서로게이트 쌍): https://www.unicode.org/versions/latest/(열람일: 2026-09-09)
• WHATWG, Encoding Standard — 브라우저 TextDecoder가 지원하는 인코딩과 디코딩 알고리즘, 강좌의 글자 깨짐 시연에 쓰는 GBK / windows-1252 디코더 규범: https://encoding.spec.whatwg.org/(열람일: 2026-09-09)
• Joel Spolsky, The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets(2003) — 「순수 텍스트란 없다」는 이야기의 고전 입문: https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/(열람일: 2026-09-09)