Calcolatore dimensione data URI

Incorporare un font, un'icona o un foglio di stile come data URI evita una richiesta HTTP aggiuntiva, ma la codifica Base64 gonfia il payload di circa un terzo e il prefisso data: aggiunge ancora altri caratteri. Restituisce la lunghezza esatta del payload Base64, il conteggio totale dei caratteri del data URI, il sovraccarico del payload vicino al trentatré per cento, il sovraccarico totale compreso il prefisso e una raccomandazione di incorporare o mantenere un collegamento separato. Le chiamate API riuscite costano $0.002; un input non valido non viene fatturato.

Come si ottiene la dimensione di un data URI Base64 dai byte originali

Un data URI che trasporta contenuto binario segue la forma RFC 2397: data, poi un tipo di media facoltativo, poi il token punto e virgola-base64, una virgola e il payload. Il payload è Base64 standard RFC 4648: ogni tre byte originali diventano quattro caratteri ASCII, quindi la lunghezza codificata è esattamente quattro volte il soffitto della lunghezza originale divisa per tre. Quando la lunghezza originale non è un multiplo di tre, i segni di uguale di riempimento completano l'ultimo quartetto così il payload ha sempre una lunghezza multipla di quattro. Il sovraccarico del solo payload è dunque circa il trentatré per cento — esattamente un terzo quando la dimensione originale è multipla di tre, un po' di più se serve il riempimento.

Contratto di ingresso, forma della risposta e comportamento in errore

Tali fallimenti non vengono fatturati. Diecimila byte con il tipo octet-stream predefinito producono un URI di 13373 caratteri e una raccomandazione link. Invii tramite POST un corpo JSON con un campo obbligatorio bytes: un intero positivo (o una stringa numerica) per la dimensione originale della risorsa prima della codifica. Il campo facoltativo media_type (alias mime, type, content_type, mime_type) è il tipo MIME scritto nel prefisso; se omesso vale application/octet-stream. Il campo facoltativo budget (alias max, limit, max_bytes, max_size) è la maggiore lunghezza di data URI ancora considerata conveniente da incorporare e vale 2048 per impostazione predefinita, una regola comune in HTTP/1. Valori mancanti, vuoti, non interi, zero o negativi falliscono con invalid_input indicando il campo; un tipo di media che non sia type/subtype, o che contenga spazi o una virgola, viene rifiutato allo stesso modo. In caso di successo il corpo ripete bytes, media_type e budget; restituisce prefix e prefix_chars; restituisce base64_chars e padding_chars; restituisce data_uri_chars e overhead_chars; restituisce overhead_percent dell'URI completo rispetto al file originale e payload_overhead_percent del solo payload Base64 (la cifra di circa trentatré per cento); restituisce expansion_ratio come lunghezza dell'URI sui byte originali; e restituisce within_budget più recommendation uguale a inline o link. Esempio: 1024 byte come image/png producono un prefisso di 22 caratteri, 1368 caratteri Base64 con due riempimenti, un data URI di 1390 caratteri, un sovraccarico di payload di circa 33.59 per cento e una raccomandazione inline rispetto al budget 2048. Abbini i numeri al proprio codificatore se Le serve la stringa; questo endpoint non emette mai il payload codificato.

Quando conviene incorporare un data URI nonostante il sovraccarico del trentatré per cento

Base64 peggiora quel compromesso di circa un terzo, e il multiplexing di HTTP/2 o HTTP/3 rende una richiesta separata più economica di quanto fosse su HTTP/1, quindi la soglia di pareggio è più bassa di quanto molti articoli del 2012 sostengano ancora. I bundler che usavano un limite url-loader di otto kilobyte ottimizzavano gli sprite HTTP/1; sovrascriva budget a 8192 se riproduce quella regola ereditata, oppure lo abbassi sui siti HTTP/2. Lo usi come soglia in un controllo di pull-request: se data_uri_chars supera il budget, tenga la risorsa come URL.