Base64 to 이미지 변환기 - Data URI를 디코딩해 파일로 저장

아닙니다. 접두사를 붙여도, 붙이지 않아도 모두 동작합니다. 접두사는 data URI 문법의 일부일 뿐 인코딩된 이미지의 일부가 아니며, 뒤따르는 페이로드를 어떻게 해석할지 브라우저에 알려 주는 역할을 합니다. 접두사가 있으면 도구가 읽어서 무엇을 주장했는지 보여 주고, 없어도 잃는 것은 없습니다. 어느 쪽이든 형식은 디코딩된 바이트에서 알아내기 때문입니다.

접두사는 데이터가 아니라 텍스트이기 때문입니다. 누구든 PNG 바이트 앞에 `data:image/jpeg;base64,`를 적을 수 있고, 실제로 많은 생성기가 실수로 그렇게 합니다. 템플릿을 그대로 복사했거나, MIME 타입을 하드코딩했거나, 이미지를 다시 내보낸 뒤 예전 문자열을 재사용한 경우입니다. 그 말을 믿으면 어떤 JPEG 디코더도 열지 못하는 .jpg 파일이 저장됩니다. 이 도구는 대신 앞쪽 바이트를 읽고, 둘이 어긋나면 그 사실을 알린 뒤 바이트를 기준으로 파일 이름을 정합니다.

거의 항상 복사가 덜 된 경우입니다. 긴 data URI는 수만 자에 이르는데, 화면 끝에서 끊긴 선택 영역, 줄을 접으면서 역슬래시를 끼워 넣은 터미널, 모든 줄 앞에 +를 붙인 diff 화면은 모두 디코딩되지 않는 문자열을 만듭니다. 그 밖에 흔한 원인으로는 &가 & 같은 HTML 엔티티로 남아 있는 경우, 그리고 +와 / 대신 -와 _를 쓰는 URL 안전 변형이 있습니다. 후자는 디코딩 전에 변환해야 합니다.

아닙니다. 포매터와 미니파이어 출력은 긴 data URI를 여러 줄로 감싸는 일이 흔하고, 이메일 클라이언트는 76자에서 강제로 줄을 바꿉니다. 공백은 Base64의 일부가 아니므로 디코딩 전에 제거됩니다. 주변 문법을 그대로 붙여넣어도 됩니다. `background-image: url("data:…");` 선언 전체, `img src="…"` 태그, 따옴표로 감싼 JSON 문자열 어느 쪽이든 그 안에서 페이로드를 뽑아냅니다.

전혀 아닙니다. Base64는 되돌릴 수 있는 인코딩일 뿐 압축도, 재인코딩도 아닙니다. 디코딩된 바이트는 원래 인코딩된 파일과 EXIF 메타데이터, ICC 컬러 프로필, 내장 썸네일까지 동일합니다. 결과가 기대보다 나빠 보인다면 손실은 인코딩 이전에 일어난 것입니다. 예를 들어 이미지가 저품질 JPEG로 저장되었거나 먼저 축소되었을 수 있습니다.

네. SVG는 XML이라 바이너리 시그니처가 없으므로 마크업으로 식별합니다. 디코딩된 텍스트가 태그로 시작하고, XML 선언이나 주석을 지나 앞부분에 `svg` 요소가 있어야 합니다. .svg로 다운로드되며 텍스트 편집기에서 열 수 있습니다. 반대 방향도 알아 둘 만합니다. SVG는 이미 텍스트이므로 Base64로 인코딩하면 아무 이득 없이 용량만 3분의 1가량 늘어납니다.

PNG, JPEG, GIF, WebP, AVIF, BMP, ICO, SVG를 각각 파일 앞부분의 고유 시그니처로 인식합니다. Base64는 깔끔하게 디코딩됐는데 어느 것과도 맞지 않으면 다운로드 대신 분명한 안내 메시지가 표시됩니다. 대개 페이로드가 PDF나 폰트, zip이거나 우연히 Base64로 인코딩된 일반 텍스트라는 뜻입니다.

아닙니다. 디코딩은 이 페이지에서 실행되는 몇 줄짜리 JavaScript입니다. 문자열은 탭의 메모리에 머물고, 미리보기 이미지는 로컬에서 만든 blob URL이며, 다운로드 파일도 사용자 기기에서 생성됩니다. 서버 측 구성 요소도, 페이로드를 실어 나르는 요청도 없으며, 네트워크를 끊어도 페이지는 계속 동작합니다. 붙여넣는 data URI가 사적인 스크린샷이나 스캔, 문서인 경우가 많다는 점에서 이는 중요한 부분입니다.