Base64 디코딩이 실패할 때 원인 네 가지와 입력을 고치는 순서

API 응답에서 받은 Base64 문자열을 디코더에 붙여넣었는데 오류가 납니다. 보기에는 정상적인 문자열이고 길이도 충분히 긴데 결과가 나오지 않습니다.

값이 손상된 것은 아닐 가능성이 높습니다. 결론부터 말하면 디코딩 실패의 대부분은 네 가지 원인 중 하나이고, 어느 것인지는 문자열을 보면 30초 안에 판별됩니다.

실패를 만드는 네 가지

첫째, 패딩이 잘렸습니다. Base64 결과의 길이는 항상 4의 배수입니다. 모자라는 자리는 끝에 등호로 채웁니다. 그런데 이 등호가 지저분해 보여 지우거나, 주소에 넣는 과정에서 사라지는 일이 흔합니다. 길이가 4의 배수가 아니라면 여기를 의심해야 합니다.

둘째, URL 안전 변형입니다. 표준 Base64는 더하기와 슬래시를 씁니다. 그런데 이 두 글자는 웹 주소에서 다른 의미를 가져서, 주소에 실을 때는 하이픈과 밑줄로 바꿔 쓰는 방식이 널리 쓰입니다. 문자열에 하이픈이나 밑줄이 보이면 이 경우입니다.

셋째, data URI 접두사가 함께 붙었습니다. 이미지 태그에서 값을 복사하면 data:image/png;base64, 같은 앞부분이 딸려옵니다. 이것은 Base64 데이터가 아니라 그 데이터가 무엇인지 설명하는 머리말이라, 텍스트 디코더에 그대로 넣으면 실패합니다.

넷째, 문자열이 잘렸습니다. 화면에서 긴 문자열을 드래그해 복사하면 끝이나 중간이 누락되는 경우가 있습니다. 로그에 출력된 값은 아예 일정 길이에서 잘려 있기도 합니다.

어느 경우인지 판별하는 표

공백과 줄바꿈은 대체로 괜찮습니다. Base64 디코더는 일반적인 공백과 줄바꿈을 정리한 뒤 처리합니다.

순서대로 확인하는 방법

1. 길이를 봅니다. 4의 배수가 아니면 그 자체로 답이 나옵니다.
2. 앞부분을 봅니다. data: 로 시작하면 쉼표 뒤부터만 잘라 씁니다.
3. 하이픈과 밑줄을 찾습니다. 있으면 표준 문자로 바꿉니다.
4. 점의 개수를 셉니다. 두 개면 토큰 형식이므로 각 부분을 따로 디코딩합니다.
5. 원본이 파일인지 확인합니다. 이미지나 문서라면 텍스트가 아니라 파일 디코더를 씁니다.
6. 그래도 안 되면 원본을 다시 받습니다. 잘림은 눈으로 확인하기 어렵습니다.

디코딩은 됐는데 결과가 이상할 때

성공했는데 내용이 이상한 경우는 실패와 다르게 다뤄야 합니다.

네 번째 줄이 의외로 자주 나옵니다. 시스템 사이를 거치면서 중복으로 감싸진 경우인데, 결과가 다시 Base64처럼 보이면 한 번 더 돌려보면 됩니다.

디코딩 실패를 오래 끄는 습관

오류 메시지만 반복해서 봅니다. 대부분의 디코더는 어디가 문제인지 알려주지 않습니다. 메시지보다 입력 문자열을 보는 편이 빠릅니다.

여러 디코더를 옮겨 다닙니다. 도구를 바꿔도 표준을 따르는 이상 결과는 같습니다. 입력을 고쳐야 합니다.

패딩을 임의로 붙입니다. 등호를 몇 개 붙이면 통과하는 경우가 있지만, 문자열이 잘린 상황이라면 복원된 내용도 잘려 있습니다. 통과했다고 정상은 아닙니다.

바이너리를 텍스트로 디코딩합니다. 이미지를 텍스트 디코더에 넣으면 깨진 문자가 나오는데, 이것을 실패로 오해하기 쉽습니다.

원본 확보를 마지막으로 미룹니다. 잘림이 의심되면 원본을 다시 받는 것이 가장 빠른 해결입니다.

오류 메시지보다 입력을 보세요

디코딩은 규칙이 단순해서 실패 원인도 몇 가지로 좁혀집니다. 길이, 앞부분, 하이픈과 밑줄, 점의 개수. 이 네 가지만 확인하면 대부분 판별됩니다.

그리고 결과가 나왔는데 이상하다면 그것은 실패가 아니라 다른 문제입니다. 문자 인코딩이나 파일 형식 쪽을 봐야 합니다.