Base64로 복원한 파일이 열리지 않을 때, 확장자보다 먼저 볼 것

메일이나 API로 받은 Base64 문자열을 파일로 복원했습니다. 오류 없이 저장됐는데 막상 열어보니 손상됐다는 메시지가 뜹니다.

디코딩이 실패한 것은 아닙니다. 결론부터 말하면 문자열을 바이트로 되돌리는 일과 그 바이트가 온전한 파일인 것은 다른 문제이고, 원인은 대개 입력 문자열 쪽에 있습니다.

저장은 됐는데 열리지 않는 이유

디코더가 하는 일은 정해져 있습니다. 받은 문자열을 규칙에 따라 바이트로 바꾸고, 그 바이트를 파일로 내보냅니다.

그 바이트가 올바른 파일 구조인지는 확인하지 않습니다. 문자열이 절반만 있으면 절반짜리 바이트가 나오고, 그것도 파일로 저장됩니다. 저장 자체는 성공하지만 뷰어가 열려고 하면 필요한 부분이 없어 거부합니다.

파일 형식은 대부분 앞부분에 자기가 무엇인지 알리는 표식을 갖고 있습니다. PNG인지 PDF인지 ZIP인지가 첫 몇 바이트로 구분됩니다. 이 표식이 어긋나면 뷰어는 바로 거부합니다.

그래서 확인할 것은 두 가지로 좁혀집니다. 앞부분이 제대로 시작하는가, 끝까지 다 왔는가.

원인별 판별표

세 번째 줄이 가장 흔합니다. 긴 문자열을 화면에서 드래그해 복사하면 끝부분이 빠지는 일이 잦습니다.

확인하는 순서

1. 문자열 앞부분을 봅니다. data:로 시작하면 쉼표 뒤부터만 잘라 씁니다. 이 앞부분은 데이터가 아니라 설명입니다.
2. 길이를 확인합니다. 표준 Base64는 길이가 4의 배수입니다. 아니라면 잘렸거나 끝의 등호가 사라진 것입니다.
3. 파일 디코더로 복원합니다. 형식을 감지해 적절한 확장자로 저장해 줍니다.
4. 크기를 비교합니다. 복원된 파일이 문자열 길이의 약 4분의 3이면 정상입니다. 크게 모자라면 잘린 것입니다.
5. 원본을 다시 받습니다. 잘림이 의심되면 화면 복사 대신 파일이나 다운로드로 받는 편이 확실합니다.

4번이 판별의 핵심입니다. 눈으로는 잘림을 알 수 없지만 크기 비교로는 바로 드러납니다.

확장자를 바꾸는 것으로 해결되는 경우와 아닌 경우

확장자는 이름표일 뿐 내용을 바꾸지 않습니다. 다만 내용은 온전한데 이름만 틀린 경우에는 바꾸면 열립니다.

구분하는 방법이 있습니다. 파일을 텍스트 편집기로 열어 첫 줄을 보면 형식을 짐작할 수 있습니다. PDF는 앞부분에 형식 이름이 그대로 보이고, PNG나 ZIP은 알아볼 수 없는 문자 사이에 형식을 나타내는 짧은 글자가 섞여 있습니다.

첫 부분이 아예 읽을 수 없는 잡음이라면 이름 문제가 아니라 내용이 깨진 것입니다. 이때는 확장자를 어떻게 바꿔도 열리지 않습니다.

압축 파일에서는 판단이 조금 더 쉽습니다. 압축 프로그램이 목록을 보여주면 앞부분은 온전한 것이고, 목록은 보이는데 풀다가 실패하면 뒷부분이 잘린 것입니다. 어디까지 왔는지 알려주는 셈이라 원본을 다시 받아야 할지 판단하는 데 도움이 됩니다.

복원 파일을 다룰 때 헛수고가 되는 시도

확장자를 여러 개 바꿔 봅니다. 내용이 깨졌다면 어떤 이름으로도 열리지 않습니다. 크기부터 확인하세요.

디코더를 바꿔가며 시도합니다. 표준을 따르는 이상 결과는 같습니다. 입력을 고쳐야 합니다.

data URI 접두사를 그대로 넣습니다. 이미지 태그에서 값을 복사하면 앞부분이 딸려옵니다. 쉼표 뒤부터가 실제 데이터입니다.

긴 문자열을 화면에서 드래그해 옮깁니다. 끝이 잘리기 쉽습니다. 파일로 저장해 옮기는 편이 안전합니다.

큰 파일을 Base64로 주고받습니다. 용량이 33% 늘고 처리 부담도 커집니다. 파일 전송이 가능하면 그쪽이 낫습니다.

크기를 비교하면 대부분 판별됩니다

복원 파일이 열리지 않을 때 확인할 것은 두 가지입니다. 앞부분에 군더더기가 붙었는지, 끝까지 다 왔는지.

data:로 시작하면 잘라내고, 복원 파일 크기가 문자열의 4분의 3쯤 되는지 보세요. 크게 모자라면 확장자를 바꿔볼 것이 아니라 원본을 다시 받아야 합니다.