EUC-KR UTF-8 변환

CP949(확장 완성형·통합 완성형)는 EUC-KR 에 한글 8,822자를 더한 것입니다. EUC-KR 만으로는 "펲"이나 "똠" 같은 글자를 적을 수 없어서, 윈도우 한국어판은 오래전부터 CP949 를 써 왔습니다. 그래서 "EUC-KR 파일"이라고 부르는 것은 대부분 실제로는 CP949 이고, 이 도구도 CP949 전체(17,048자)를 다룹니다. 화면에서 EUC-KR 이라고 적은 것은 전부 CP949 를 뜻합니다.

한국어 윈도우의 엑셀은 UTF-8 CSV 를 열 때 앞에 BOM 이 없으면 EUC-KR 로 읽습니다. 그래서 UTF-8 로 저장한 파일이 통째로 깨져 보입니다. 해결책은 둘입니다. UTF-8 로 저장하면서 BOM 을 켜거나(이 도구가 CSV·TSV 파일은 기본으로 켜 둡니다), 아예 EUC-KR 로 저장하는 것입니다. BOM 을 켜면 엑셀·메모장·구글 시트에서 모두 제대로 열립니다.

아닙니다. BOM 은 파일 맨 앞에 보이지 않는 세 바이트를 넣는 것이라, 그것을 모르는 프로그램은 첫 글자가 이상하다고 여깁니다. 설정 파일, 셸 스크립트, 소스 코드, JSON 에서는 BOM 이 오류를 냅니다. 그래서 CSV·TSV 처럼 엑셀로 열 파일에만 기본으로 켜고 나머지는 꺼 둡니다.

있습니다. EUC-KR 에 아예 없는 글자는 물음표(?)가 되고, 이 도구는 그런 글자가 무엇이 몇 개인지 화면에 적어 줍니다. 대표적인 것이 이모지, 중국 간체자, 그리고 워드에서 붙여넣은 —(em dash)와 –(en dash)입니다. 반대로 둥근 따옴표(" ")와 줄임표(…), 유로 기호(€)는 EUC-KR 에도 있어서 그대로 넘어갑니다. 원화 기호는 ￦(전각) 쪽만 있고 ₩(U+20A9)는 없습니다.

어림짐작입니다. 다만 한쪽으로는 꽤 강합니다. EUC-KR 로 쓴 한글은 UTF-8 문법에 맞지 않아 "UTF-8 로 읽으면 오류"라는 뚜렷한 신호가 나오기 때문입니다. 반대로 UTF-8 로 쓴 한글은 EUC-KR 로도 읽히는 자리가 많아서, 읽은 결과가 한자·기호 뒤범벅인지까지 함께 봅니다. 그래도 확실하지 않으므로 후보마다 미리보기를 나란히 놓고 직접 고르게 했습니다. 영문·숫자뿐인 파일은 어느 쪽으로 읽어도 같아서 그렇다고 알려 줍니다.

그 자리는 되살릴 수 없습니다. �는 읽는 쪽이 "이 바이트가 뭔지 모르겠다"고 판단해 한 글자로 뭉개 버린 흔적이라, 원래 바이트가 무엇이었는지 알 방법이 남아 있지 않습니다. 이런 경우 나머지 글자는 되돌리더라도 그 자리만 빈칸으로 남습니다. 원본 파일이 있다면 파일 변환 쪽을 쓰세요 — 파일에는 바이트가 그대로 남아 있습니다.

아닙니다. 파일은 브라우저 안에서만 읽고 변환합니다. 이 페이지는 어떤 내용도 서버로 보내지 않습니다.