핵심 요약
컴퓨터는 문자를 숫자(바이트)로 저장한다. "어떤 숫자가 어떤 글자냐"를 정한 규칙이 문자 인코딩이다. 글자가 í•œêµì–´처럼 깨지는(모지바케) 이유는 단 하나 — 저장할 때 쓴 인코딩과 읽을 때 쓴 인코딩이 다르기 때문이다. 오늘날 정답은 거의 항상 UTF-8이다.
1. 문자셋 vs 인코딩
- 유니코드(문자셋) — 세상 모든 글자에 고유 번호(코드포인트)를 부여. 예: '한' = U+D55C
- UTF-8(인코딩) — 그 번호를 실제 바이트로 바꾸는 방식. 유니코드를 저장·전송하는 표준
2. 왜 UTF-8인가
| 인코딩 | 특징 |
|---|---|
| ASCII | 영문·숫자만(1바이트). 한글 표현 불가 |
| EUC-KR / CP949 | 과거 한국 표준. 한글 2바이트. 유니코드 아님 → 이모지·타 언어 불가 |
| UTF-8 | 영문 1바이트, 한글 3바이트. 전 세계 문자·이모지 모두 표현. 웹 표준 |
3. 깨짐의 전형적 원인
- EUC-KR로 저장한 파일을 UTF-8로 읽음(또는 반대) → 한글이 깨진다
- DB 커넥션/테이블 charset 불일치 — 저장은 UTF-8인데 커넥션이 latin1이면
???또는 깨짐 - HTTP 응답에 charset 미지정 → 브라우저가 다른 인코딩으로 추측
4. 실무 체크리스트
- 파일: UTF-8(BOM 없이)로 저장. BOM은 일부 도구에서 문제를 일으킨다
- HTML:
<meta charset="utf-8">, HTTP:Content-Type: text/html; charset=utf-8 - DB(MySQL): 테이블·컬럼·커넥션 모두
utf8mb4(진짜 UTF-8, 이모지 포함).utf8은 3바이트 제한이라 이모지 깨짐 - PostgreSQL: DB 인코딩
UTF8
자주 묻는 질문
utf8과 utf8mb4는 뭐가 다른가요?
MySQL의 utf8은 최대 3바이트만 지원하는 반쪽짜리라 이모지(4바이트)를 저장하면 깨집니다. utf8mb4가 진짜 UTF-8입니다. 새 프로젝트는 무조건 utf8mb4를 쓰세요.
BOM이 뭔가요? 붙여야 하나요?
BOM(Byte Order Mark)은 파일 앞에 붙는 특수 표식입니다. UTF-8에선 불필요하고, 오히려 셸 스크립트·JSON·일부 파서에서 오류를 일으킵니다. "UTF-8(BOM 없음)"으로 저장하세요.
글자가 ???로 나오면?
보통 DB나 커넥션이 해당 문자를 표현 못 하는 인코딩(latin1 등)일 때입니다. 저장 경로 전체(앱→커넥션→DB→테이블→컬럼)의 charset을 utf8mb4/UTF8로 통일하세요.
댓글 0