9 문자와 텍스트 — 표준 속의 흉터

9.1 문자는 번호다

기계에 “A”를 저장하는 방법은 하나뿐이다 — “A는 65번으로 한다”는 약속을 만들고, 65라는 수를 저장하는 것이다. 이런 약속의 표, 즉 글자와 번호의 대응표를 문자 집합(character set) 또는 문자 코드라 부른다.

문제는 이 표가 여러 개였다는 것이다. 회사마다, 나라마다 자기 표를 만들었다. 같은 번호가 표마다 다른 글자를 가리켰고, 표가 다른 두 기계가 텍스트를 주고받으면 글자가 엉켰다. 이 장의 나머지는 그 엉킴의 역사이고, 역사의 각 굽이가 오늘의 C와 컴퓨팅에 흔적을 남겼다.

9.2 ASCII와 EBCDIC — 두 개의 표

1960년대에 두 갈래의 표가 자리 잡았다. IBM의 대형 컴퓨터 세계는 EBCDIC이라는 표를 썼다 — 천공카드 시절의 코드에서 자라난 표라서 알파벳이 연속 번호가 아닌 등 지금 눈에는 기묘한 배치였지만, IBM의 세계에서는 그것이 법이었다.

다른 한쪽에서 통신 업계를 중심으로 만들어진 표가 ASCII다. 7비트, 즉 128칸짜리 작은 표에 영어 대소문자·숫자·문장부호, 그리고 화면에 안 보이는 제어 문자들을 담았다. 제어 문자는 “종이를 한 줄 올려라”, “경고음을 울려라”처럼 글자가 아니라 장치에 내리는 지시다 — 이들의 사연은 다음 장(스트림)에서 만난다. 그리고 이 표의 0번 자리에 앉은 것이 6장에서 얼굴을 익힌 NUL 문자다. “아무 글자도 아님”을 뜻하는 문자로, 나중에 C가 문자열(string)의 끝 표시로 채용한다(42장).

9.2.1 「알파벳이 연속이 아니다」가 코드에 하는 일

방금 「기묘한 배치」라고 지나간 대목을 그냥 넘기면 안 된다. 그것이 C 코드 한 줄의 운명을 가르기 때문이다. 누구나 한 번은 이렇게 적는다.

if (c >= 'A' && c <= 'Z') { … }        /* 대문자인가? */

ASCII 에서는 잘 돈다. A 가 0x41 이고 Z 가 0x5A 라 그 사이 26칸이 정확히 알파벳이기 때문이다. 그런데 이 코드가 참인 것은 언어의 규칙이 아니라 표의 사정이다.

EBCDIC 은 다르다. 이 책이 실제 표(코드 페이지 037)를 재 보았다.

알파벳이 세 토막인 것은 천공카드 코드에서 자라난 흔적이다. 그래서 'A' 에서 'Z' 까지의 범위에는 41칸이 들어 있는데 그중 글자는 26개뿐이다. 나머지 15칸에 무엇이 앉아 있는지 세어 보았다.

★ 즉 저 한 줄은 EBCDIC 에서 닫는 중괄호와 백슬래시를 「대문자」라고 대답한다. 컴파일 오류도, 경고도, 이상한 값도 없다. 그냥 조용히 틀린다.

9.2.2 그래서 라이브러리가 있다 — 추상이 하는 일

여기서 이 책이 되풀이할 논지 하나가 처음 모습을 드러낸다. 표의 사정을 코드에 적어 넣지 말고, 물어보라.

if (isupper((unsigned char)c)) { … }   /* 표가 무엇이든 옳다 */

<ctype.h> 의 판정 함수들이 하는 일이 정확히 그것이다. 이 함수들은 「0x41 이상 0x5A 이하」를 검사하지 않는다 — 그 구현이 도는 문자 집합에서 무엇이 대문자인지를 안다. EBCDIC 기계의 C 구현은 세 토막을 아는 판정을 담고 오고, ASCII 기계의 구현은 간단한 범위 검사로 만들어도 된다. 어느 쪽이든 부르는 쪽의 코드는 한 글자도 바뀌지 않는다.

이것이 추상이 파는 물건이다 — 기능이 아니라 변하는 것을 한 자리에 가두는 일.

★ 그리고 이 이야기는 문자 판정에서 끝나지 않는다. 같은 논리가 이 책 곳곳에서 되풀이된다 — 문자열의 길이를 세는 일(42장), 정렬 순서를 정하는 일(69장의 strcoll), 글자 수를 세는 일(72장). 전부 「내가 아는 표가 세상의 전부」라는 가정을 코드에서 걷어 내는 일이다.

ASCII가 이긴 표가 되었다 — 오늘날 거의 모든 문자 코드가 ASCII를 안쪽에 품고 있다. 그러나 128칸은 영어만으로도 빠듯했고, 세계의 글자를 담기에는 어림도 없었다. 여기서 흉터의 역사가 시작된다.

9.3 ISO 646 — 국가 변형과 C의 삼중자

첫 번째 미봉책은 ASCII의 국제판인 ISO 646이었다. 아이디어는 이랬다: “표는 하나로 쓰되, 나라마다 덜 중요한 몇 칸을 자기 글자로 바꿔 쓰게 허용한다.” 그렇게 바꿔 쓰도록 지정된 칸에 하필 [ ] { } \ | # 같은 기호들이 있었다.

결과는 프로그래머에게 재앙이었다. 덴마크의 단말기에서 C 코드를 열면 중괄호 자리에 덴마크 글자가 보였다. 같은 번호인데 표가 달라 다른 글자가 찍힌 것이다.

C는 이 혼란의 한복판에서 표준화됐다(12장). 중괄호가 안 보이는 나라에서도 C를 쓸 수 있어야 했으므로, C89는 기괴한 우회로를 마련했다 — 삼중자(trigraph)다. ??<라고 적으면 {로, ??/라고 적으면 \로 읽어 주는 문자 세 개짜리 암호였다. 언어 문법에 새겨진, 문자 코드 전쟁의 흉터다.

9.4 8비트의 백가쟁명, 그리고 한글

바이트가 8비트로 자리 잡자(4장) 표를 256칸으로 늘린 ISO 8859 계열이 나왔다 — 앞 128칸은 ASCII 그대로, 뒤 128칸에 각 언어권 글자를 담는 방식이다(서유럽용 Latin-1 등). 그러나 뒤 128칸을 언어권마다 다르게 쓰는 구조라, 표를 잘못 짚으면 글자가 엉키는 문제는 그대로였다.

그리고 256칸으로는 어림도 없는 글자들이 있었다. 한글, 한자, 가나 — 동아시아의 글자는 수천, 수만이다. 해법은 한 글자에 바이트 여러 개를 쓰는 멀티바이트 인코딩이었다(한국의 EUC-KR 등). 글자마다 길이가 다른 데다 나라마다 방식이 달라, 표를 잘못 짚은 한글 문서가 뜻 모를 기호의 행렬로 깨지는 일 — 이른바 “글자 깨짐” — 은 이 시대 한국 컴퓨터 사용자의 일상이었다.

9.5 유니코드와 UTF-8 — 하나의 표, 영리한 담기

근본 해법은 결국 하나뿐이었다. 세상 모든 글자를 하나의 표에 넣자. 그것이 1990년대의 유니코드다. 글자마다 고유 번호(코드 포인트)를 주고 U+AC00(가)처럼 적는다. 표의 크기는 백만 칸이 넘는다.

남은 문제는 그 큰 번호를 바이트에 어떻게 담느냐였다. 모든 글자를 4바이트씩 쓰면 낭비가 크고, 무엇보다 산더미 같은 기존 ASCII 텍스트와 호환되지 않는다. 답이 된 것이 UTF-8이라는 가변 길이 인코딩이다 — ASCII 범위의 글자는 1바이트 그대로, 그 밖의 글자는 2–4바이트로 담는다. 기존 ASCII 파일은 그 자체로 올바른 UTF-8이라는 절묘한 설계 덕에, UTF-8은 오늘날 웹과 소스 코드의 사실상 유일한 표준이 됐다. 이 책의 예제와 C23의 u8"" 문자열이 쓰는 것도 UTF-8이다(42장).

9.6 C가 가르는 두 문자 집합 — 소스와 실행

여기까지가 세상의 문자 집합 이야기였다. 이제 C가 그것을 어떻게 다루는가를 본다. 핵심은 한 문장이다 — C는 소스 코드의 문자 집합과 프로그램이 실행될 때의 문자 집합을 서로 다른 것으로 취급한다.

표준이 붙인 이름부터 정확히 적어 둔다(§5.2.1).

표준은 이 둘이 같은 인코딩이어야 한다고 말하지 않는다. 오히려 §5.2.2 가 명시적으로 갈라 둔다 — 실행 문자 집합도 멀티바이트 문자를 담을 수 있고, 그 인코딩이 소스 문자 집합의 것과 같을 것을 요구하지 않는다고. 그리고 §5.2.1 은 못을 하나 더 박는다: 실행 문자 집합 구성원의 값은 구현 정의(implementation-defined)다.

9.6.1 언제 옮겨 실리는가 — 번역 단계 1과 5

두 집합이 만나는 자리는 번역 단계(translation phase, 57장)에 정확히 못박혀 있다.

5단계의 뒷문장이 특히 중요하다 — 대응하는 구성원이 없으면, 구현이 정한 방식으로 널이 아닌 어떤 구성원으로 바꾼다. 즉 조용히 다른 글자가 된다. 오류가 아니다.

9.6.2 C23 이 붙인 더 정확한 이름 — 리터럴 인코딩

C23 은 §6.2.9 「Encodings」를 새로 두어 이름을 하나 더 정리했다.

「실행 문자 집합」이 어떤 글자들이 있는가라면, 「리터럴 인코딩」은 그 글자를 어떤 바이트 값으로 적는가다. 표준은 둘 다 기본 실행 문자 집합 전체를 대응시킬 것만 요구하고, 나머지는 구현에 맡긴다.

9.6.3 인코딩을 못박는 접두어

실행 문자 집합이 무엇이든 상관없이 인코딩을 고정하는 방법이 있다 — 리터럴 접두어다(§6.4.5).

바이트가 흔들리면 곤란한 자리 — 프로토콜, 파일 형식, 시험의 기대값 — 에는 u8"…"를 쓴다. 「구현이 정한다」를 「표준이 정한다」로 바꾸는 낱말 두 글자다. 와이드 문자(wide character) 쪽의 자세한 사정은 70장과 71장에서 다시 본다.

9.7 같은 글자, 여러 표현 — 텍스트에 잠복한 보안 지형

유니코드가 표를 통일했다고 문제가 끝난 것은 아니다. 오히려 표가 커지고 표현이 여러 겹이 되면서 새로운 함정이 생겼다. 텍스트를 다루는 프로그램 이라면 언젠가 만나게 되는 지형이라, 길잡이 삼아 훑어 둔다. 뿌리는 하나다 — 같은 것을 두 가지 이상으로 적을 수 있으면, 검사하는 쪽과 해석하는 쪽이 어긋날 수 있다.

① 정규화(normalization) — 한글의 NFC와 NFD. “각”이라는 글자는 유니코드에서 두 가지로 적을 수 있다. 완성된 음절 하나로 적는 방식(NFC, U+AC01 한 코드 포인트)과, 자모를 이어 적는 방식(NFD, ᄀ+ᅡ+ᆨ 세 코드 포인트)이다. 눈에는 똑같이 보이지만 바이트 열은 완전히 다르다 — 그래서 단순 바이트 비교는 “각 ≠ 각”이라 답한다. 한국 사용자에게 이것은 교과서 이야기가 아니다: macOS가 파일 이름을 NFD 계열로 저장해 온 탓에, 한글 파일 이름이 다른 OS로 건너가며 자모가 풀려 보이거나 압축 파일에서 이름이 어긋나는 일이 흔했다. 해법은 경계에서 한 형태로 정규화하는 것 — 그리고 보안 문맥에서는 이 정규화의 순서가 결정적이다(아래 ④).

② 오버롱 인코딩 — UTF-8이 한때 열어 둔 뒷문. 이 장 수학 박스의 UTF-8 규칙대로면 /(U+002F)는 1바이트 2F다. 그런데 초기 구현들은 같은 문자를 2바이트(C0 AF)나 3바이트로 “길게” 적은 것도 관대하게 받아 주었다 — 오버롱(overlong) 표현이다. 여기서 고전적 공격이 나왔다: 보안 검사는 2F만 찾아 경로 조작(../)을 걸러 내는데, 파일 시스템은 오버롱 C0 AF도 /로 해석한 것이다. 검사와 해석의 어긋남 — 2001년 IIS 서버를 휩쓴 디렉터리 탈출 취약점의 정체가 이것이었다. 그래서 오늘의 표준은 오버롱을 불법으로 못박고 디코더가 거부하도록 정했다.

③ 사라진 인코딩의 유령 — UTF-7. 7비트 통로(초기 전자우편)로 유니코드를 보내려고 만든 UTF-7은, 평범해 보이는 ASCII 글자들로 다른 문자를 표현 한다(+ADw-가 <가 되는 식이다). 브라우저들이 인코딩을 자동 추측하던 시절, 공격자는 이 성질로 필터를 통과시켰다 — 검사할 때는 무해한 글자 열이었다가, 브라우저가 UTF-7로 해석하는 순간 태그로 부활하는 것이다. UTF-7은 이 사고들 때문에 사실상 퇴출됐고, 오늘의 규범은 인코딩을 추측하지 말고 명시하라로 굳었다.

④ 유니코드 자체의 함정 — 동형 문자와 방향 제어. 표가 크다는 것은 똑같이 생긴 다른 글자가 있다는 뜻이기도 하다. 라틴 a와 키릴 а는 화면에서 구별되지 않는다 — 이를 이용해 진짜와 똑같아 보이는 가짜 도메인을 만드는 것이 호모그래프 공격이다(그래서 브라우저는 의심스러운 혼용 도메인을 원래 표기로 되돌려 보여 준다). 더 교묘한 것은 방향 제어 문자다: 유니코드에는 글자의 표시 순서를 뒤집는 보이지 않는 문자 들이 있어서, 소스 코드에서 사람이 읽는 순서와 컴파일러가 읽는 순서를 다르게 만들 수 있다 — 2021년 공개된 “Trojan Source”가 이 기법으로, 리뷰어에게는 멀쩡해 보이는 코드가 실제로는 다른 논리로 컴파일되게 만들 수 있음을 보였다. 이후 컴파일러들이 이런 문자에 경고를 내기 시작했다.

⑤ 층이 겹칠 때 — 이스케이프와 다중 해석. 웹에서 <를 글자로 보이게 하려면 <로 적는다(HTML 이스케이프). 이 층이 여럿 겹치면 사고가 난다 — 한 번 이스케이프한 것을 다른 층이 다시 해독하면 원래 기호가 부활하고, 반대로 검사만 하고 이스케이프를 잊으면 입력이 코드가 된다. 22장에서 볼 서식 문자열 취약점, 데이터베이스의 SQL 주입, 웹의 XSS가 전부 같은 무늬다 — 데이터를 틀(코드)로 오해하게 만드는 것. C의 삼중자도 이 무늬의 조상 격 사례였다: 문자열 안에 우연히 ??/가 들어 있으면 전처리기가 그것을 백슬래시로 바꿔 버려, 프로그래머가 적은 적 없는 이스케이프가 생겨났다(C23의 삼중자 제거가 반가운 이유의 하나다).

9.8 글자들의 열 — 문자열을 담는 방식들

글자 하나를 담는 법을 알았으니, 마지막 질문이 남는다. 글자들의 열 — 문자열(string) — 을 사물함에 담을 때, “어디부터 어디까지가 이 문자열인가”를 어떻게 아는가. 5장의 후렴구가 다시 나온다: 메모리는 덩어리의 경계를 모르고, 아는 것은 읽는 쪽의 약속이다. 그 약속의 방식이 여럿이라, 주요 갈래를 구경해 둔다.

방식 1 — 길이를 앞에 적는다(길이-버퍼). 문자열 앞에 “이 뒤로 몇 글자”라는 수를 붙여 두는 방식이다. 파스칼 계열 언어가 써서 파스칼 문자열이라고도 부른다. 길이를 묻는 데 셈이 필요 없고(적힌 수를 읽으면 끝), 어떤 바이트든 — 0번 문자조차 — 내용물로 담을 수 있다. 대가는 길이 칸의 크기를 미리 정해야 한다는 것 — 옛 파스칼은 길이를 1바이트에 담아서 문자열이 255자를 넘을 수 없었다(4장의 그릇 이야기가 여기서도).

방식 2 — 끝에 표지를 세운다(NUL 종단). 길이를 적지 않는 대신, 열의 끝에 특별한 문자 — 6장에서 얼굴을 익힌 값 0의 NUL 문자 — 를 세워 두는 방식이다. C가 택한 방식이 이것이다. 미덕은 극단적 단순함이다 — 시작 지점만 알면 되고, 열의 중간 어디를 가리켜도 “거기부터 NUL까지”가 곧 문자열이다. 대가는 셋: 길이를 알려면 NUL까지 일일이 세어야 하고, 내용물에 NUL을 담을 수 없으며, 무엇보다 — 표지 세우기를 잊으면 읽는 쪽이 남의 땅까지 폭주한다. 이 마지막 대가가 C 역사상 가장 많은 사고를 낸 지형이고, 42장이 그 현장이다.

방식 3 — 길이와 용량을 함께 관리한다. 현대 언어들의 동적 문자열은 대개 [내용물의 위치, 지금 길이, 그릇의 용량] 세 값을 한 묶음으로 관리한다 — 길이 조회는 즉시, 덧붙이기는 용량 안에서 자유, 모자라면 더 큰 그릇으로 이사한다. C++의 std::string, Rust의 String이 이 구조이고, 뒤에서 만날 proven의 문자열 처리도 길이를 명시적으로 다루는 이 계열의 사고방식이다(제12부).

이 밖에도 지형은 넓다 — 큰 문서를 조각의 나무로 관리하는 편집기용 표현(로프), 원본을 복사하지 않고 [시작, 길이]만 가리키는 뷰(view) 방식 등, 쓰임마다 알맞은 표현이 따로 있다. 기억할 것은 하나다: 문자열이 메모리에 놓이는 모양은 하나가 아니고, 언어와 라이브러리의 선택이며, 그 선택이 성능과 안전의 성격을 정한다. C의 선택(NUL 종단)이 어떤 성격이고 어떻게 다뤄야 하는지는 42장에서 정면으로 만난다.

다음 장은 표현의 사다리 마지막 단이다. 글자를 담을 줄 알게 됐으니, 이제 글자가 흐르는 이야기다 — 컴퓨터의 입출력이 왜 “문자가 한 줄씩 흘러가는 것”으로 생겼는지, 그 답이 종이 카드와 타자기의 시대에 있다.