문서 작업 가이드
원본 파일 바이트에서 깨진 텍스트 복구하기
손대지 않은 원본 바이트에서 문자 깨짐을 진단하고 알려진 텍스트로 decoder 후보를 검증해 파괴적인 재저장 없이 복구합니다.
작성 및 검수 SimpleWebUtils게시일: 검토일:
이 작업 흐름을 검증한 방법
바이트 증거로 텍스트 파일 인코딩 감지에서 다음 가이드 픽스처로 검증을 시작했습니다: “Windows-1252로 잘못 표시된 UTF-8 고객 이름 복구”. “깨진 preview 재저장 중지”부터 “증거와 출처로 후보 선택”까지 실행해 생성 결과를 기대값과 대조했습니다. 별도 한계 검토에는 “깨진 화면을 다시 인코딩”, “Unicode 정규화를 복구로 사용” 항목을 사용했습니다.
원본 4A C3 BC 바이트를 UTF-8로 해석하자 Jürgen이 복원됐고, 이미 깨진 Jürgen 화면 문자열을 다시 인코딩한 결과는 바이트 비교에서 실패했습니다.
문제 상황
문자 깨짐은 한 인코딩의 바이트를 다른 문자표로 해석할 때 생깁니다. ü의 UTF-8 바이트를 Windows-1252로 읽으면 ü처럼 보이고, 같은 실수로 한글이 여러 라틴 문자 조각으로 변할 수 있습니다. 이 깨진 화면을 저장하면 프로그램이 잘못된 문자를 다시 인코딩해 두 번째 변환을 만들며, replacement character를 거치면 정보가 영구히 사라지기도 합니다. BOM 문제는 별개입니다. 나머지 텍스트가 올바르게 디코딩돼도 첫 CSV field에 숨은 U+FEFF가 붙어 header 비교만 실패할 수 있습니다. Unicode 정규화도 별개입니다. 올바르게 디코딩된 뒤 NFC와 NFD가 비교에서 달라질 수 있지만 정규화는 잘못된 바이트 해석을 고치지 못합니다. 복구는 가장 이른 손대지 않은 바이트에서 시작해 생성 정보와 바이트 증거로 decoder 후보를 고르고, 알려진 이름과 header를 확인하며, 되돌릴 수 있는 문자 깨짐과 이미 유실된 데이터를 구분해야 합니다.
공식 출처와 표준
다음 공식 문서는 이 작업 흐름에서 다루는 형식과 보안 경계의 기준입니다. 도구별 실행 검증은 위에 별도로 기록합니다.
- Encoding Standard
WHATWG
이럴 때 사용하세요
- 원본 시스템에서는 정상이던 텍스트가 내보내기나 가져오기 뒤 ü, ’, 낯선 조각, 네모, replacement character로 바뀔 때 사용합니다.
- 다국어 CSV의 delimiter는 맞지만 이름, 도시, 설명, header가 깨졌을 때 적용합니다.
- 첫 column만 다르게 동작해 BOM이 이름 일부로 들어갔는지 확인해야 할 때 필요합니다.
- 복사된 깨진 문자열만 보이지만 손대지 않은 파일에 복구 가능한 원본 바이트가 남았는지 판단할 때 사용합니다.
- 고객 또는 운영 데이터 전체를 바꾸기 전에 복구 script를 문서화하고 표본 검증해야 할 때 적합합니다.
단계
- 1단계
깨진 preview 재저장 중지
편집기나 스프레드시트를 저장하지 않고 닫습니다. 운영상 중요한 장애라면 원본 export를 보관하고 hash를 계산합니다. 모든 decoder 비교는 같은 바이트 복사본에서 시작합니다.
- 2단계
처음 잘못된 경계 찾기
바이트가 문자로 바뀐 지점을 찾습니다. export, HTTP response, file reader, spreadsheet import, database client, terminal 중 어디에서 어떤 charset을 선언하거나 가정했는지 기록합니다.
- 3단계
원본 바이트 증거 검사
원본 파일을 문자셋 감지기로 검사합니다. BOM, 엄격한 UTF-8, NUL pattern, 제어 바이트 경고, 선두 hex와 결과가 확정·강한 증거·추정·호환·미확정 중 무엇인지 기록합니다.
- 4단계
증거와 출처로 후보 선택
정확한 BOM이나 유효한 비ASCII UTF-8을 우선합니다. 미확정 레거시 텍스트는 생성 프로그램, locale, 운영체제, protocol header, 공급자 문서로 짧은 후보 목록을 만듭니다.
- 5단계
알려진 텍스트 preview 비교
각 후보로 복사본을 디코딩해 예상 header, 이름, punctuation, CJK, emoji, delimiter를 비교합니다. 예상하지 않은 replacement character나 제어 문자가 있으면 해당 후보를 버립니다.
- 6단계
BOM과 정규화를 별도 처리
목적지가 BOM을 거부하거나 데이터로 해석할 때만 제거합니다. NFC 같은 정규화는 올바른 디코딩 뒤 목적지 계약이 요구할 때만 적용합니다.
- 7단계
한 번 변환하고 목적지 검증
목적지가 지원한다면 보통 UTF-8 같은 명시적 목표 인코딩으로 새 파일을 씁니다. 결과 바이트를 재검사하고 소량 가져오기, count와 핵심 값 비교를 끝낸 뒤 원본을 rollback용으로 보관합니다.
예시
Windows-1252로 잘못 표시된 UTF-8 고객 이름 복구
입력
깨진 화면: Jürgen
이름 주변 원본 바이트: 4A C3 BC 72 67 65 6E
감지 결과: 엄격한 UTF-8, BOM 없음, 강한 증거출력
원본 바이트를 UTF-8로 디코딩 -> Jürgen
화면의 Jürgen을 새 원본처럼 다시 인코딩하지 않음
수정된 이름과 주변 CSV delimiter를 소량 가져오기에서 검증흔한 실수
깨진 화면을 다시 인코딩
보이는 문자 깨짐은 이미 잘못된 디코딩으로 만들어진 텍스트입니다. 변환 경로를 추적하지 않고 다시 인코딩하면 손상이 한 겹 더 생깁니다.
Unicode 정규화를 복구로 사용
정규화는 올바른 디코딩 뒤 동등한 Unicode sequence를 맞춥니다. 원본 바이트를 다른 문자셋으로 재해석하지 않습니다.
모든 BOM 제거
목적지에 따라 BOM은 필수, 선택, 금지일 수 있으며 모든 깨진 문자의 원인은 아닙니다.
UTF-8 실패만으로 Windows-1252 추측
여러 레거시 인코딩이 UTF-8 검증에 실패합니다. 하나를 고르기 전에 생성 정보와 알려진 텍스트를 사용하세요.
되돌릴 수 없는 replacement 무시
이전 시스템이 알 수 없는 바이트를 U+FFFD나 물음표로 바꾸고 원본을 버렸다면 사라진 정보는 복구하지 못할 수 있습니다.
자주 묻는 질문
감지기가 문자 깨짐을 자동으로 고치나요?
아니요. 원본 바이트 증거를 분류합니다. 올바른 decoder를 선택하고 검증한 뒤 명시적 목표 인코딩으로 새 파일을 써야 합니다.
Jürgen은 왜 UTF-8을 Windows-1252로 읽은 단서인가요?
ü의 UTF-8 바이트 C3 BC가 Windows-1252에서 두 문자로 해석되며 이런 패턴이 생깁니다. 유용한 단서지만 원본 바이트와 생성 맥락으로 확인해야 합니다.
U+FFFD가 나타난 뒤에도 복구할 수 있나요?
원본 바이트나 다른 무손실 복사본이 남아 있을 때만 가능합니다. U+FFFD는 decoder가 잘못된 sequence를 대체했다는 표시이며 버린 바이트 값을 보존하지 않습니다.
언제 NFC로 정규화해야 하나요?
올바른 디코딩 뒤 목적지의 비교, 검색, 저장 계약이 NFC를 요구할 때만 적용하세요. 문자셋 복구와 분리해야 합니다.
복구 파일은 항상 BOM 없는 UTF-8이어야 하나요?
아니요. UTF-8은 흔한 목표지만 BOM 허용 여부와 다른 인코딩 필요성은 수신 protocol이 정합니다.
대량 복구를 안전하게 검증하려면 어떻게 하나요?
알려진 다국어 값이 있는 고정 표본을 사용하고 row·field 수, replacement character를 비교하세요. 원본 hash를 남기고 덮어쓰기 대신 새 출력 파일을 만드세요.