텍스트 ↔ 2진수 변환

컴퓨터가 글자를 저장하는 방식

컴퓨터에 "글자"라는 것은 없습니다. 숫자만 있고, 그 숫자를 어떤 표로 읽을지 약속해 둔 것이 인코딩입니다. 이 도구는 그 중간 과정을 통째로 펼쳐 보여 줍니다.

순서는 이렇습니다. 글자 → 유니코드 코드포인트(U+로 시작하는 번호) → UTF-8 바이트열 → 각 바이트를 고른 진법으로 표기. 글자별 상세표의 네 열이 정확히 이 단계에 대응합니다.

한글이 3바이트인 이유와 실무에서 터지는 지점

UTF-8은 가변 길이 인코딩입니다. ASCII 영역(U+0000~U+007F)은 1바이트로 두어 기존 영문 데이터와 호환되게 하고, 대신 그 뒤 문자는 2·3·4바이트로 늘려 씁니다. 한글 음절(U+AC00~U+D7A3)은 3바이트 구간에, 이모지(U+10000 이상)는 4바이트 구간에 들어갑니다.

이 차이가 코드에서는 이렇게 나타납니다.

• MySQL의 옛 utf8(utf8mb3)은 글자당 최대 3바이트만 담습니다. 한글은 되지만 이모지를 넣으면 "Incorrect string value" 오류가 납니다. utf8mb4로 바꿔야 합니다.
• 컬럼 길이 제한이 바이트 기준인지 글자 기준인지에 따라 결과가 달라집니다. 오라클의 VARCHAR2(10 BYTE)에는 한글이 3자밖에 안 들어갑니다.
• API 요청 본문 크기 제한, 쿠키 4KB 제한 같은 것은 전부 바이트 기준입니다. 한글이 섞이면 체감 글자 수의 3분의 1에서 걸립니다.

글자가 깨지는 원리

인코딩 깨짐은 데이터가 손상된 게 아니라, 같은 바이트열을 다른 표로 읽어서 생깁니다. UTF-8로 저장한 한글을 CP949(윈도우 한국어 인코딩)로 읽으면 엉뚱한 글자가 나오고, 반대로 CP949로 저장한 한글을 UTF-8로 읽으면 물음표나 네모가 뜹니다. 바이트는 그대로인데 읽는 표만 다른 것입니다.

이 도구에서 그 상황을 직접 볼 수 있습니다. 진법을 잘못 고른 채 코드를 되돌리려 하면 "UTF-8 문자로 해석할 수 없는 바이트 배열"이라는 오류가 뜹니다. 바이트가 UTF-8 규칙에 맞지 않으면 해석 자체를 거부하기 때문입니다.

구분자·진법·접두어 설정이 되돌리기를 좌우합니다

만드는 건 아무 설정으로나 되지만, 되돌리려면 바이트 경계를 알 수 있어야 합니다. 구분자를 "없음"으로 두면 자릿수로만 끊어 읽으므로 진법별 자릿수가 정확히 맞아야 합니다.

• 접두어 옵션은 구분자가 "없음"이면 무시됩니다. 0b를 계속 붙여 놓으면 경계를 되찾을 수 없어 애초에 붙이지 않습니다.
• 10진수는 접두어가 없는 진법이라 체크해도 아무 변화가 없습니다.
• "그룹" 옵션은 보기 편하라고 몇 바이트마다 줄을 바꾸는 것뿐입니다. 되돌릴 때 줄바꿈도 구분자로 취급하므로, 그룹을 켜 둔 결과를 그대로 다시 넣어도 됩니다.

자동 감지는 어떻게 판단하나

자동 감지는 입력을 일단 되돌려 보고, UTF-8로 성립하면 코드로, 실패하면 평범한 텍스트로 봅니다. 그래서 16진수 모드에서 "cafe" 같은 영단어를 넣어도 대개 텍스트로 처리됩니다. CA FE라는 바이트가 UTF-8로 해석되지 않기 때문입니다.

다만 우연히 성립하는 짧은 입력은 오판할 수 있습니다. 결과가 이상하면 "텍스트 → 코드" 또는 "코드 → 텍스트"를 직접 눌러 방향을 고정하세요.

# 같은 일을 명령줄에서
echo -n "한" | xxd -b        # 2진수 보기
echo -n "한" | xxd -p        # 16진수 보기 (ed959c)
echo -n "한" | wc -c         # UTF-8 바이트 수 (3)