내보낸 일기 파일에서 깨진 이모지를 진단하는 방법

‘깨짐’이 어떻게 나타나는지 확인하기

영향을 받은 항목 하나를 자세히 살펴보세요. 😀가 있어야 할 자리에 `😀`와 같은 예기치 않은 문자열이 있다면 UTF-8 바이트가 다른 인코딩을 사용하여 해석되었음을 나타낼 수 있습니다. 이를 흔히 모지바케(mojibake)라고 부릅니다. 바이트가 잘못된 가정 하에 디코딩되었기 때문에 표시되는 문자가 잘못된 것입니다. 이는 단서일 뿐, 어떤 인코딩으로 파일이 생성되었는지에 대한 결정적 증거는 아닙니다.

눈에 보이는 ``는 다릅니다. 이는 해석할 수 없는 문자를 대신해 사용되는 유니코드 대체 문자 U+FFFD입니다. 유니코드 [용어집](https://www.unicode.org/glossary/#replacement_character)에서는 이를 대체 글리프(glyph)와 구분합니다. 글꼴이나 렌더러가 문자를 그릴 수 없을 때 네모 상자를 표시할 수 있지만, 기본 문자는 여전히 손상되지 않고 남아 있을 수 있습니다. 일부 이모지만 상자로 표시된다면 파일의 인코딩을 변경하기 전에 다른 최신 앱이나 글꼴에서 먼저 확인해 보세요.

문제 해결 전에 기준선 보존하기

내보낸 파일의 사본을 만들고 원본은 변경하지 않은 상태로 유지하세요. 파일 확장자, 내보낸 앱, 영향을 받은 문구 하나에서 보이는 모습을 기록해 둡니다. 가능하다면 일기 속 알고 있는 이모지를 원본 앱이나 이전 내보내기 파일의 동일한 항목과 비교해 보세요. 하나뿐인 사본을 반복해서 열고 저장하는 것은 피해야 합니다. 텍스트 편집기가 새로 디코딩된 텍스트를 바이트로 다시 기록하여, 되돌릴 수 있었던 화면 표시 테스트를 영구적인 변경으로 만들 수 있습니다.

인코딩을 선택할 수 있는 편집기에서 사본을 일반 텍스트로 엽니다. 먼저 일기 앱에 명시된 인코딩을 시도해 보세요. 알 수 없고 파일이 일반적인 최신 텍스트 내보내기 파일이라면, UTF-8은 원본에 덮어써서 저장할 가정이 아니라 점검해 볼 만한 합리적인 후보입니다. 각 후보 설정에서 영향을 받은 텍스트와 주변의 일반 문자를 비교하세요. 파일 전반에 걸쳐 일관된 결과가 나오는 것이 우연히 올바르게 보이는 이모지 하나보다 훨씬 강력한 증거입니다.

다시 쓰지 않고 디코딩 테스트하기

편집기의 인코딩 보기를 변경했을 때 이상한 문자열이 원래 의도한 이모지로 바뀌고 주변 텍스트도 읽을 수 있게 된다면, 내보낸 파일에 온전한 바이트가 포함되어 있으나 잘못 해석되었을 가능성이 큽니다. 사본을 저장하지 않고 닫은 후 유력한 설정으로 다시 열어 이를 확인하세요. 그런 다음 일기 앱의 가져오기 또는 열기 워크플로에서 공식 인코딩 선택 옵션을 제공하는지 확인하고, 실제 다시 가져오기 작업에는 해당 워크플로를 우선 사용하세요.

[유니코드 UTF FAQ](https://www.unicode.org/faq/utf_bom.html)에 따르면 잘못된 형식의 UTF-8 바이트 시퀀스는 오류를 발생시키거나 U+FFFD와 같은 마커로 처리될 수 있습니다. 이는 디코더가 표시하거나 가져오는 과정에서 이미 유효하지 않은 입력을 대체했을 수 있음을 의미합니다. 해당 단계 이후에 인코딩을 전환하더라도 원본 바이트가 반드시 복구되는 것은 아닙니다. 유일한 사본에서 디코딩할 수 없는 문자를 조용히 대체해 버리는 ‘복구’ 또는 변환 옵션을 사용하지 마세요.

인코딩 문제와 글리프 누락 구분하기

다른 뷰어에서 이모지가 올바르게 표시된다면, 파일을 변경하기 전에 해당 비교 결과를 증거로 보관하세요. 단순히 겉모습을 바꾸기 위해 내보낸 파일을 다시 저장하지 마세요.

여러 뷰어에서 동일한 위치에 U+FFFD나 물음표 기호 자체가 표시된다면 원본 일기나 이전 내보내기 파일과 비교해 보세요. 파일 내에 대체 문자로 저장된 경우 글꼴을 변경해도 복원할 수 없습니다. 복구 여부는 해당 문자를 유지하고 있는 다른 사본이 있는지에 달려 있습니다.

CSV와 JSON을 서로 다른 가져오기 경로로 다루기

`.csv` 확장자만으로는 어떤 문자 인코딩이 사용되었는지 알 수 없으며, 스프레드시트 프로그램이 자체 가져오기 설정을 적용할 수 있습니다. 데스크톱용 Excel의 경우, Microsoft는 [텍스트 및 CSV 가져오기/내보내기 가이드](https://support.microsoft.com/en-us/excel/get-started/import-or-export-text-txt-or-csv-files)에서 **데이터 > 텍스트/CSV에서** 메뉴 및 텍스트 마법사를 통한 텍스트 가져오기 방법을 설명합니다. 로드하기 전에 미리보기를 활용하세요. 이모지, 행과 열의 경계, 인접한 텍스트를 확인합니다. 올바른 미리보기는 선택한 가져오기 경로가 파일을 의도대로 읽고 있다는 증거일 뿐, 원본을 덮어써도 된다는 이유는 아닙니다.

JSON의 경우 파일을 그대로 보존하고, CSV로 취급하는 대신 JSON을 인식하는 가져오기 도구를 사용하세요. [RFC 8259 JSON 사양](https://www.rfc-editor.org/rfc/rfc8259#section-8.1)은 폐쇄된 생태계 외부의 시스템 간에 교환되는 JSON에 UTF-8을 요구합니다. 또한 JSON 문자열이 문자를 직접 표현하거나 이스케이프로 표현할 수 있다고 설명합니다. `\u263A`와 같은 이스케이프가 보인다고 해서 무조건 손상된 것은 아닙니다. JSON 파서는 유효한 이스케이프를 올바르게 해석해야 합니다. JSON이 유효하지 않거나 가져오기 도구에서 파싱 오류를 보고하는 경우, 짐작으로 구두점이나 바이트를 편집하지 말고 작업을 멈춘 뒤 정확한 파일을 그대로 유지하세요.

재시도, 재내보내기 또는 중단 여부 결정하기

다음 순서를 따르세요: (1) 원본 일기와 내보낸 파일을 비교합니다. (2) 필요한 경우 예상 인코딩 및 UTF-8 보기를 사용하여 복제본을 검사합니다. (3) 다른 뷰어에서 글리프 누락 현상인지 확인합니다. (4) 올바른 CSV 또는 JSON 가져오기 도구를 통해 파일을 미리 봅니다. (5) 원본에서 여전히 이모지가 올바르게 표시된다면 문서화된 텍스트 인코딩으로 내보내기를 다시 시도합니다. 한 번에 한 가지 변수만 변경하고 각 결과를 따로 보관하세요.

어떤 뷰어나 가져오기 도구에서도 원래 문자가 나타나지 않고 파일에 대체 문자나 다른 대체 데이터만 들어 있다면, 재인코딩을 통한 복구를 장담하지 마세요. 디코딩 설정을 변경한다고 해서 어떤 이모지가 버려졌는지 알아낼 수는 없습니다. 다른 내보내기 파일, 백업 또는 온전한 일기 항목을 찾은 다음 새 파일로 다시 내보내고, 이를 사용하기 전에 미리보기를 확인하세요.

이 주제 더 살펴보기