대부분의 업로드 양식은 어떤 실패든 같은 문장으로 알립니다. 그 한 문장이 적어도 네 가지 서로 다른 검사를 감추고 있고, 해결 방법도 저마다 다릅니다.
검사 하나: 바이트 제한
가장 흔한 제한이자, 사람들이 대개 유일하게 떠올리는 제한입니다. 메가픽셀이 아니라 바이트로 재기 때문에, 요즘 휴대폰에서 막 꺼낸 작아 보이는 이미지도 쉽게 걸립니다.
명시된 제한보다 아래의 숫자로 압축해서 해결하세요. 딱 그 숫자에 맞추지는 마세요. 어떤 시스템은 파일이 아니라 인코딩된 요청의 크기를 재는데, 전송 과정에서 base64로 인코딩되는 업로드는 디스크에 있는 파일보다 3분의 1가량 큽니다. 제한보다 몇 퍼센트 아래를 노리면 잃는 것은 거의 없으면서 이 문제 자체가 사라집니다.
검사 둘: 치수 제한
파일 용량과는 별개이며, 문서에 적혀 있지 않은 경우가 잦습니다. 파일이 아무리 작아도 가로 1200픽셀을 넘지 말라고 요구하는 양식이 있습니다. 더 세게 압축해도 이 조건은 절대 만족되지 않습니다. 크기를 줄여야 합니다. 양식이 표시 크기를 명시한다면, 대개 그 근처의 최대치도 함께 강제합니다.
검사 셋: MIME 타입
꼼꼼한 서버는 확장자를 믿지 않습니다. 앞부분 몇 바이트를 읽어 그 서명으로 형식을 판별합니다.
PNG의 이름을 .jpg로 바꿔도 엄격한 서버는 여전히 PNG로 봅니다. 바이트가 그렇게 말하고 있으니까요.
변환이 의미가 있고 이름 바꾸기가 의미가 없는 이유가 이것입니다. 디자인 도구에서 “JPEG“으로 내보낸 파일이 거부당하는 이유이기도 합니다. 어떤 내보내기 도구는 서버 쪽 라이브러리가 받아 주지 않는 변형을 씁니다.
검사 넷: 색 공간과 인코딩 변형
더 드물지만 실제로 있습니다. CMYK JPEG과 16비트 PNG, 프로그레시브 JPEG은 모두 유효한 파일인데, 오래된 서버 쪽 라이브러리 중에는 이들을 아예 거부하는 것이 있습니다.
다시 인코딩하면 손이 닿는 것들은 해결됩니다. ToolZool은 평범한 8비트 픽셀로 디코딩하고 기본값으로 베이스라인 JPEG을 씁니다. 그래서 16비트 PNG는 8비트로 돌아오고 프로그레시브 JPEG은 베이스라인으로 돌아옵니다. 둘 다 까다로운 서버가 받아 줄 가능성이 가장 높은 변형입니다. 곤란한 쪽은 CMYK JPEG입니다. 웹용이 아니라 인쇄 작업용 파일이라, 확실한 해결책은 그것을 만들어 낸 프로그램에서 RGB로 다시 내보내는 것입니다.
어느 검사에 걸렸는지 가려내는 법
일부러 아주 작은 시험용 이미지를 하나 올려 보세요. 몇 KB에 몇백 픽셀, 평범한 베이스라인 JPEG이면 됩니다. 그것이 올라간다면 문제는 여러분의 파일에 있고, 이제 어느 축을 바꿔야 할지 아시게 된 것입니다. 압축 도구에서 시작하시고, 제한이 빡빡하다면 50 KB 제한 맞추기에서 무엇을 어떤 순서로 바꿔야 하는지 다룹니다. 시험용 이미지도 실패한다면 문제는 양식이나 세션, 아니면 브라우저에 있고, 아무리 다시 인코딩해도 소용이 없습니다.
