Notepad++ 한글 깨짐 해결: 인코딩 변경 전 원본 지키기
Notepad++ 한글 깨짐은 복사본부터 만들고 해석 방식과 실제 인코딩 변환을 구분해서 접근해야 원본을 지킬 수 있습니다.
| 증상 | 원인 | 할 일 |
|---|---|---|
| 한글이 물음표·네모로 보임 | 현재 해석 방식이 실제 인코딩과 다름 | 상태 표시줄·인코딩 메뉴에서 현재 해석 방식 확인 |
| UTF-8로 바꿔도 깨짐 | 원본이 CP949 같은 지역 문자표로 저장됨 | 백업본에서 후보 인코딩을 하나씩 비교 |
| 대상 프로그램에서 다시 깨짐 | 목적 프로그램이 요구하는 문자표가 다름 | 가져오기 사양 확인 후 복사본에서 직접 열어 검증 |
| 저장 후 복구 불가 | 잘못 해석된 상태로 덮어씀 | 편집 전 반드시 복사본 생성 |
한글이 물음표나 네모로 보이면 원본 파일을 덮어쓰기 전에 복사본을 만듭니다. 잘못 해석한 상태로 저장하면 되돌릴 정보까지 사라질 수 있습니다.
현재 인코딩은 어디서 보나요?
창 아래 상태 표시줄과 인코딩 메뉴에서 현재 해석 방식을 확인합니다. UTF-8, ANSI 계열, 문자 집합 선택은 같은 뜻이 아닙니다. 파일을 연 직후의 상태와 바꿔 본 항목을 메모합니다.
인코딩 메뉴에는 현재 바이트를 다른 문자표로 해석하는 동작과 실제 바이트를 변환하는 동작이 따로 있습니다. 원문을 찾는 단계에서는 먼저 해석 방식만 바꿔 봅니다. 글자가 정상으로 보인 뒤 복사본을 새 이름으로 저장합니다.
UTF-8로 바꾸면 항상 해결되나요?
파일이 원래 CP949 같은 지역 문자표로 저장됐다면 UTF-8로 억지 변환하기 전에 올바른 원본 해석이 필요합니다. 깨진 화면 자체를 저장하면 잘못된 문자가 확정됩니다. 백업본에서 후보 인코딩을 하나씩 비교합니다.
브라우저, CSV 프로그램, 오래된 업무 시스템은 기대하는 문자표가 다를 수 있습니다. 목적 프로그램의 가져오기 사양을 확인합니다. 편집기에서 잘 보인다는 이유로 출력 시스템에서도 같은 결과라고 단정하지 않습니다.
새 문서의 기본값은 어떻게 정하나요?
환경 설정의 새 문서 항목에서 기본 인코딩을 확인합니다. 이 설정은 앞으로 만드는 파일에 적용되며 기존 파일의 바이트를 자동으로 바꾸지 않습니다. 팀 작업이라면 저장소나 서비스가 요구하는 형식에 맞춥니다.
BOM 유무도 일부 도구에서 영향을 줍니다. 요구 사양이 없다면 UTF-8을 우선 검토하되 기존 시스템 파일은 원래 형식을 유지합니다. 변환 뒤에는 한글뿐 아니라 특수문자와 줄바꿈도 확인합니다.
마지막으로 복사본을 대상 프로그램에서 직접 엽니다. 눈으로 몇 줄 보는 데 그치지 말고 파일 처음과 끝, 쉼표나 탭이 있는 줄을 함께 봅니다. 정상 파일을 확인한 뒤에만 원본 교체 여부를 정합니다.
자주 묻는 질문
깨진 상태로 저장했는데 복구되나요?
이미 손실된 문자는 복구가 어려울 수 있습니다. 이전 버전이나 백업 파일을 먼저 찾습니다.
ANSI는 하나의 인코딩인가요?
환경의 지역 문자표를 가리키는 표현으로 쓰여 정확한 문자 집합 확인이 필요합니다.
UTF-8 BOM은 꼭 필요한가요?
대상 프로그램 요구에 따라 다릅니다. 가져오기 사양과 샘플 파일을 기준으로 선택합니다.
팀에서 다시 깨지지 않게 하려면?
파일 형식별 인코딩과 줄바꿈 규칙을 저장소 문서에 명시합니다. 편집기 표시만 믿지 말고 배포나 가져오기 과정에서 자동 변환이 일어나는지도 작은 샘플로 확인합니다.
공식 자료와 함께 보기
이 글은 2026년 9월 13일에 공식 문서를 확인해 작성했습니다. 메뉴 이름은 설치 버전과 운영체제 언어에 따라 달라질 수 있습니다.
관련 안내
화면 캡처
