엑셀 CSV 한글 깨짐 — UTF-8 BOM 3바이트가 원인

엑셀에서 CSV 파일을 열었더니 한글이 전부 수출 같은 낯선 라틴 문자로 바뀌어 있는 분을 위한 글입니다. 결론부터 말하면 파일이 손상된 게 아니라, 엑셀이 그 파일을 UTF-8로 읽지 않았을 뿐입니다.

CSV에는 "나는 UTF-8이다"라고 적어 둘 자리가 없습니다. 그래서 파일 맨 앞에 BOM 3바이트를 붙여 신호를 보내고, 엑셀은 그 3바이트가 있을 때 UTF-8로 읽습니다.

요약 ① 깨진 글자는 UTF-8 바이트를 다른 문자표로 읽은 결과입니다. 바이트 자체는 그대로라 되돌릴 수 있습니다. ② UTF-8 BOM은 파일 맨 앞의 EF BB BF 세 바이트이며, 제대로 읽는 프로그램에서는 화면에 보이지 않습니다. ③ 파일을 고치지 않고도, 엑셀에서 더블클릭 대신 데이터 탭의 텍스트/CSV 가져오기로 인코딩을 직접 지정해 열 수 있습니다.

왜 하필 수출 같은 글자가 나올까

한글 '수출'을 UTF-8로 저장하면 EC 88 98 EC B6 9C 여섯 바이트가 됩니다. 한글 한 글자가 보통 3바이트를 차지하기 때문입니다.

엑셀이 이 파일을 UTF-8로 인식하지 못하면, 이 여섯 바이트를 한 바이트에 한 글자씩 대응하는 옛 문자표에 그대로 대입해 읽습니다. 서유럽 문자표(Windows-1252)에서 EC는 ì, 88은 ˆ, 98은 ˜입니다.

그래서 여섯 바이트가 여섯 글자 수출로 표시됩니다. 글자가 사라진 게 아니라 같은 바이트를 다른 표로 읽은 것뿐이라, 같은 파일을 UTF-8로 읽는 편집기에서 열면 멀쩡한 한글이 보입니다.

깨진 모양은 어떤 표로 읽혔는지에 따라 달라집니다. 한국어 코드 페이지(CP949)로 읽히면 두 바이트씩 묶이기 때문에, 주문번호가 二쇰Ц踰덊샇처럼 뜻이 통하지 않는 한자·한글로 나오기도 합니다.

CSV에는 인코딩을 적을 자리가 없습니다

CSV 형식을 정리한 RFC 4180은 문자 집합을 파일 안에 표시하는 방법을 두지 않았습니다. "일반적으로 US-ASCII를 쓰지만, 다른 문자 집합은 charset 파라미터와 함께 쓸 수 있다"고만 적혀 있습니다.

여기서 말하는 charset은 파일을 주고받을 때 붙는 전송 헤더의 값입니다. 즉 인코딩 정보는 파일 밖에 있습니다.

파일을 내려받아 저장하는 순간 그 헤더는 사라집니다. 남은 건 바이트 덩어리뿐이라, 여는 프로그램은 추측을 할 수밖에 없습니다.

BOM 3바이트가 하는 일

BOM은 Byte Order Mark의 약자로, 유니코드 문자 U+FEFF를 파일 맨 앞에 넣은 것입니다. 이 문자를 UTF-8로 인코딩하면 EF BB BF 세 바이트가 됩니다.

원래는 UTF-16처럼 바이트 순서가 두 가지인 인코딩에서 어느 쪽인지 알리는 용도였습니다. UTF-8은 바이트 순서가 하나뿐이라 알릴 것이 없고, 여기서는 "이 파일은 UTF-8이다"라는 서명 역할만 합니다.

이 3바이트는 본문이 아닙니다. 웹 표준(WHATWG Encoding Standard)의 UTF-8 디코딩 절차는 앞 세 바이트가 EF BB BF면 그 3바이트를 읽어 버린 뒤 나머지를 본문으로 처리하도록 정하고 있습니다.

마이크로소프트의 엑셀 지원 문서도 같은 이야기를 합니다. UTF-8로 인코딩된 CSV 파일은 BOM과 함께 저장되었다면 그냥 열어도 정상이고, 그렇지 않으면 데이터 탭의 가져오기를 쓰라고 안내합니다.

도구 없이 고치는 방법

세 가지가 있습니다. 파일을 손대도 되는지, 안 되는지에 따라 고르면 됩니다.

1. 더블클릭 대신 엑셀에서 가져오기

파일을 전혀 건드리지 않는 방법입니다. 엑셀의 데이터 탭에서 데이터 가져오기 → 파일에서 → 텍스트/CSV에서를 고르고 해당 파일을 선택합니다.

그러면 미리보기 창이 열리고 맨 위에 파일 원본 목록이 있습니다. 여기서 65001: 유니코드(UTF-8)를 고르면 아래 미리보기의 한글이 즉시 정상으로 바뀝니다.

받는 사람이 여럿이면 각자 이 과정을 반복해야 한다는 점이 단점입니다.

2. 메모장에서 BOM을 붙여 다시 저장

윈도우 메모장으로 파일을 열고 파일 → 다른 이름으로 저장을 누르면, 저장 창 아래에 인코딩 목록이 있습니다. 여기서 UTF-8(BOM)을 고르면 됩니다.

목록에 UTF-8과 UTF-8(BOM)이 따로 있는 이유가 바로 이것입니다. 요즘 메모장의 기본값은 BOM이 없는 쪽이라, 그대로 저장하면 문제가 그대로 남습니다.

3. 엑셀에서 내보낼 때부터 형식을 고르기

반대로 엑셀에서 만든 표를 CSV로 넘길 때는, 다른 이름으로 저장에서 파일 형식을 CSV UTF-8(쉼표로 분리)로 고릅니다. 이 형식은 BOM을 붙여 저장합니다.

문제는 이미 받아 둔 파일이 여러 개일 때입니다. 메모장은 큰 파일에서 버겁고, 가져오기는 열 때마다 반복해야 하며, 형식 선택은 이미 만들어진 파일에는 소급되지 않습니다.

저희 도구로 확인하기. 파일을 올리면 앞 5줄 미리보기로 한글이 제대로 읽히는지 먼저 보여 주고, 버튼 한 번으로 맨 앞에 BOM이 붙은 새 CSV를 내려받습니다.

직접 해보기 →

자주 막히는 지점

BOM을 붙였는데도 여전히 깨진다면, 그 파일은 애초에 UTF-8이 아니었을 가능성이 큽니다. BOM은 "UTF-8이라고 알리는 표시"일 뿐이지 다른 인코딩을 UTF-8로 바꿔 주지 않습니다.

그래서 도구가 앞 5줄 미리보기를 먼저 보여 줍니다. 이 미리보기는 파일을 UTF-8로 읽어 표시한 것이라, 판별 기준이 됩니다.

미리보기가 깨져 보이는데 그대로 내려받으면, 읽지 못한 글자가 대체 문자로 굳어져 원래 글자를 되살릴 수 없습니다. 이때는 파일을 만든 쪽에서 UTF-8로 다시 내보내는 것이 유일한 해법입니다.

반대로 BOM 때문에 생기는 부작용도 있습니다. 프로그램에서 CSV를 읽을 때 첫 열 이름이 \ufeff주문번호처럼 보이는 경우인데, 이는 읽는 쪽이 BOM을 걷어내지 않은 것입니다.

정리

• 깨진 글자는 UTF-8 바이트를 한 바이트짜리 옛 문자표로 읽은 결과입니다. 수출의 EC 88 98 EC B6 9C가 수출로 보이는 식입니다.
• CSV는 파일 안에 인코딩을 적지 않습니다. RFC 4180은 charset을 전송 단계의 정보로만 다룹니다.
• UTF-8 BOM은 파일 맨 앞의 EF BB BF 세 바이트이고, 유니코드 U+FEFF를 인코딩한 값입니다.
• 파일을 손대지 않으려면 엑셀의 데이터 탭 → 텍스트/CSV에서 → 파일 원본을 65001: 유니코드(UTF-8)로 지정합니다.
• 파일을 고치려면 메모장의 UTF-8(BOM) 저장, 엑셀의 CSV UTF-8(쉼표로 분리) 형식, 또는 아래 도구를 씁니다.
• BOM을 붙여도 안 되면 원본이 UTF-8이 아닌 것입니다. 미리보기에서 먼저 확인하세요.

자주 묻는 질문

BOM을 붙이면 파일 내용이 바뀌나요?

본문 글자는 그대로이고, 맨 앞에 EF BB BF 세 바이트가 추가됩니다. 파일 크기는 3바이트 늘어납니다.

표준을 따르는 프로그램은 이 3바이트를 읽어 버린 뒤 나머지를 본문으로 처리하므로, 화면에 보이는 내용은 달라지지 않습니다. 이미 BOM이 붙은 파일을 다시 올려도 두 번 붙지 않습니다. 브라우저가 파일을 읽을 때 쓰는 UTF-8 디코딩 절차가 앞의 3바이트를 먼저 걷어내기 때문입니다.

메모장에서는 멀쩡한데 엑셀에서만 깨집니다. 왜 그런가요?

두 프로그램이 인코딩을 정하는 방식이 다르기 때문입니다. 메모장은 UTF-8을 우선 시도하는 반면, 엑셀은 CSV를 바로 열 때 BOM이 없으면 UTF-8로 보지 않습니다. 같은 파일인데 결과가 다른 것은 파일이 아니라 읽는 쪽의 판단이 다르기 때문입니다.

BOM을 붙였는데도 여전히 깨집니다.

원본이 UTF-8이 아닐 때 그렇습니다. BOM은 "이 파일은 UTF-8"이라는 표시일 뿐, 다른 인코딩의 바이트를 변환해 주지 않습니다. 도구의 5줄 미리보기에서 한글이 이미 깨져 보인다면 그 경우이므로, 파일을 만든 시스템에서 UTF-8로 다시 내보내야 합니다.

업로드한 CSV 파일이 서버로 전송되나요?

아니요. 파일 읽기, 미리보기, BOM을 붙인 새 파일 만들기가 전부 브라우저 안에서 처리되며 파일은 서버로 올라가지 않습니다. 사내 주문 내역이나 거래처 목록이 담긴 CSV도 외부로 나가지 않습니다.