De fleste uploadformularer melder hver eneste fejl med den samme sætning. Den ene besked dækker over mindst fire forskellige tjek, og løsningen er forskellig for hvert af dem.
Tjek ét: bytegrænsen
Den mest almindelige grænse, og den eneste, folk normalt tænker på. Den måles i bytes, ikke i megapixels, så et billede, der ser lille ud, og som kommer direkte fra en moderne telefon, kan sagtens falde igennem.
Løsningen er at komprimere til et tal under den oplyste grænse — ikke lige præcis til den. Nogle systemer måler den kodede forespørgsel frem for selve filen, og en upload, der bliver base64-kodet på vejen ud, fylder cirka en tredjedel mere end filen på disken. At sigte et par procent under grænsen koster dig næsten ingenting og fjerner hele spørgsmålet.
Tjek to: dimensionsgrænsen
Uafhængig af filstørrelsen og ofte udokumenteret. En formular kan kræve et foto, der ikke er bredere end 1200 pixels, uanset hvor lille filen er. Hårdere komprimering kommer aldrig til at gøre den tilfreds — du bliver nødt til at ændre målene. Oplyser formularen en visningsstørrelse, håndhæver den som regel også en maksimumsgrænse tæt på den.
Tjek tre: MIME-typen
Servere, der er omhyggelige, stoler ikke på filendelsen; de læser de første bytes og genkender
formatet på dets signatur. Omdøb en PNG til .jpg, og en striks server ser stadig en PNG, for det
er det, bytesene siger.
Det er derfor, det gør en forskel at konvertere, og ingen forskel at omdøbe. Det er også derfor, en fil, der er eksporteret fra et designprogram som “JPEG”, kan blive afvist: nogle eksportfunktioner skriver en variant, som serverens bibliotek nægter at tage imod.
Tjek fire: farverum og kodningsvariant
Sjældnere, men reelt nok. CMYK-JPEG’er, 16-bit-PNG’er og progressive JPEG’er er alle gyldige filer, som nogle ældre serverbiblioteker afviser uden videre.
Genkodning løser dem, den kan nå. ToolZool afkoder til almindelige 8-bit-pixels og skriver baseline JPEG som standard, så en 16-bit-PNG kommer tilbage som 8-bit, og en progressiv JPEG kommer tilbage som baseline — og det er netop de varianter, en kræsen server er mest tilbøjelig til at acceptere. CMYK-JPEG er det besværlige tilfælde: det er en fil fra et trykkeriforløb frem for fra nettet, og den sikre løsning er at eksportere den igen som RGB fra det program, der lavede den.
Sådan skelner du dem fra hinanden
Prøv med et bevidst bittelille testbillede: et par kilobytes, et par hundrede pixels, almindelig baseline JPEG. Går det igennem, ligger problemet i din fil, og nu ved du, hvilken akse du skal ændre på — start med komprimeringen, og er grænsen stram, gennemgår sådan rammer du en grænse på 50 KB den rækkefølge, du skal ændre tingene i. Bliver testbilledet også afvist, ligger problemet i formularen, i sessionen eller i browseren, og så hjælper ingen mængde genkodning.
