De meeste uploadformulieren melden elke mislukking met dezelfde zin. Achter dat ene berichtje gaan minstens vier verschillende controles schuil, en voor elk daarvan is de oplossing anders.
Controle één: de bytelimiet
De meest voorkomende limiet, en de enige waar mensen meestal aan denken. Hij wordt in bytes gemeten en niet in megapixels, dus een afbeelding die er klein uitziet maar rechtstreeks uit een moderne telefoon komt, gaat er zonder moeite overheen.
Los het op door te comprimeren naar een getal ónder de genoemde limiet, en niet precies erop. Sommige systemen meten het gecodeerde verzoek in plaats van het bestand, en een upload die onderweg base64-gecodeerd wordt, is ongeveer een derde groter dan het bestand op schijf. Een paar procent onder de limiet mikken kost je vrijwel niets en haalt die hele vraag weg.
Controle twee: de afmetingslimiet
Los van de bestandsgrootte, en vaak nergens vermeld. Een formulier kan eisen dat een foto niet breder is dan 1200 pixels, hoe klein het bestand ook is. Harder comprimeren zal daar nooit aan voldoen — je moet schalen. Noemt het formulier een weergaveformaat, dan handhaaft het meestal ook een maximum in de buurt daarvan.
Controle drie: het MIME-type
Servers die het zorgvuldig doen, vertrouwen de bestandsextensie niet; ze lezen de eerste bytes en
herkennen het formaat aan de signatuur. Hernoem je een PNG naar .jpg, dan ziet een strenge server
nog steeds een PNG, want dat is wat de bytes zeggen.
Daarom helpt omzetten wel en hernoemen niet. Het verklaart ook waarom een bestand dat een ontwerpprogramma als “JPEG” exporteert, alsnog kan falen: sommige exporteurs schrijven een variant die de bibliotheek van de server weigert.
Controle vier: kleurruimte en codeervariant
Zeldzamer, maar het bestaat. CMYK-JPEG’s, 16-bits PNG’s en progressieve JPEG’s zijn allemaal geldige bestanden die sommige oudere serverbibliotheken botweg weigeren.
Hercoderen lost op wat het bereiken kan. ToolZool decodeert naar gewone 8-bits pixels en schrijft standaard baseline-JPEG, dus een 16-bits PNG komt als 8-bits terug en een progressieve JPEG als baseline — precies de varianten die een kieskeurige server het eerst accepteert. Een CMYK-JPEG is het lastige geval: dat is een bestand uit een drukwerkproces en niet uit een webproces, en de betrouwbare oplossing is om het opnieuw als RGB te exporteren uit wat het gemaakt heeft.
Hoe je ze uit elkaar houdt
Probeer een bewust piepkleine testafbeelding: een paar kilobyte, een paar honderd pixels, gewone baseline-JPEG. Gaat die er wel doorheen, dan zit het probleem in jouw bestand en weet je nu op welke as je moet bijsturen — begin bij de compressor, en is de limiet krap, dan behandelt een limiet van 50 KB halen de volgorde waarin je dingen aanpakt. Faalt de testafbeelding ook, dan ligt het aan het formulier, de sessie of de browser, en helpt geen enkele hoeveelheid hercoderen.
