Transcodifica di file compressi in formato gzip

Questa pagina illustra la conversione dei file da e verso un file compresso con gzip stato. La pagina include una panoramica sulla transcodifica, best practice per lavorare con i metadati associati e il comportamento dei file compressi in Cloud Storage.

Transcodifica e gzip

gzip è un tipo di compressione dei dati: in genere riduce le dimensioni di un file. In questo modo il file può essere trasferito più rapidamente e archiviato utilizzando meno spazio rispetto a quando non fosse compresso. La compressione di un file può ridurre i costi e tempo di trasferimento. In Cloud Storage, la transcodifica cambia automaticamente della compressione di un file prima che venga pubblicato per il richiedente. Durante la transcodifica provoca la compressione di un file in formato gzip, questo può essere considerato compressivo, mentre quando il risultato è un file non più compresso in gzip, può essere considerati decompressivi. Cloud Storage supporta il linguaggio decompressivo tipo di transcodifica.

Cloud Storage non supporta la transcodifica decompressiva per Oggetti compressi con Brotli.

Transcodifica decompressiva

La transcodifica decompressiva ti consente di memorizzare versioni compresse dei file in Cloud Storage, che riduce i costi dell'archiviazione at-rest, il file stesso al richiedente, senza alcuna compressione. Questo è utili, ad esempio, durante la pubblicazione di file ai clienti.

Affinché si verifichi la transcodifica decompressiva, un oggetto deve soddisfare due di classificazione:

  1. Il file viene compresso in gzip quando viene archiviato in Cloud Storage.

  2. I metadati dell'oggetto includono Content-Encoding: gzip.

Quando un oggetto soddisfa questi due criteri, viene sottoposto a transcodifica decompressiva. quando viene pubblicato e la risposta contenente l'oggetto non contiene un Intestazione Content-Encoding o Content-Length.

Esistono due modi per impedire che la transcodifica decompressiva avvenga per un altrimenti idoneo:

  • Se la richiesta per l'oggetto include un'intestazione Accept-Encoding: gzip, il valore viene pubblicato così com'è nella richiesta specifica, insieme Intestazione della risposta Content-Encoding: gzip.

  • Se il campo dei metadati Cache-Control per l'oggetto è impostato a no-transform, l'oggetto viene pubblicato come oggetto compresso in per le richieste successive, indipendentemente dalle intestazioni delle richieste Accept-Encoding.

La prevenzione della transcodifica decompressiva è utile, ad esempio, se si desidera ridurre i costi o il tempo per i trasferimenti di dati in uscita o se vuoi gli oggetti scaricati hanno i checksum crc32c/md5 previsti.

Considerazioni

Quando lavori con la transcodifica decompressiva, tieni presente quanto segue:

  • La transcodifica decompressiva invalida il controllo dell'integrità. Se i richiedenti dei tuoi dati si basano sul checksum per il controllo dell'integrità, transcodifica decompressiva.

  • La transcodifica decompressiva consente di archiviare oggetti in Cloud Storage in un in uno stato compresso, risparmiando spazio e costi. Tuttavia, ti vengono addebitati dei costi per il download si basano sulla sua dimensione decompressa, che è la dimensione dell'oggetto gestito.

  • Se vi si accede dall'interno di un bucket montato su Cloud Storage FUSE, gli oggetti non vengono sottoposti a transcodifica decompressiva e vengono letti come compressi.

Content-Type e Content-Encoding

Esistono diversi comportamenti di cui dovresti essere a conoscenza riguardanti il Content-Type e Content-Encoding si riferiscono alla transcodifica. Entrambi sono metadati archiviati insieme a un oggetto. Consulta Visualizzazione e modifica dei metadati degli oggetti per istruzioni passo passo su come aggiungere metadati agli oggetti.

Content-Type deve essere incluso in tutti i caricamenti e indica il tipo di oggetto caricato. Ad esempio:

Content-Type: text/plain

indica che l'oggetto caricato è un file di testo normale. Anche se non è disponibile alcun controllo per garantire che il valore Content-Type specificato corrisponda alla vera natura di un l'oggetto caricato, specificando in modo errato il tipo, di ricevere qualcosa di diverso da quello che si aspettavano e che potrebbe comportamenti indesiderati.

Content-Encoding è facoltativo e può, se necessario, essere incluso nel caricamento di file compressi. Ad esempio:

Content-Encoding: gzip

indica che l'oggetto caricato è compresso con gzip. Come con Content-Type, non esiste alcun controllo a garanzia del valore Content-Encoding specificato viene applicato all'oggetto caricato e specificare in modo errato la codifica dell'oggetto potrebbe causare comportamenti indesiderati al successivo download richieste.

Buone prassi

  • Quando carichi un oggetto compresso con gzip, il metodo consigliato per impostare per i metadati è specificare sia Content-Type sia Content-Encoding. Per per un file compresso di testo normale:

    Content-Type: text/plain
Content-Encoding: gzip

    che offre a chiunque il maggior numero di informazioni sullo stato dell'oggetto. per accedervi. Ciò rende anche l'oggetto idoneo per essere decompressivo la transcodifica quando viene scaricata in un secondo momento, consentendo alle applicazioni client gestire correttamente la semantica di Content-Type.

  • In alternativa, puoi caricare l'oggetto con l'impostazione Content-Type impostata su indicare compressione e NESSUN Content-Encoding. Ad esempio:

    Content-Type: application/gzip

    Tuttavia, in questo caso l'unica cosa immediatamente nota dell'oggetto è che è compresso con gzip, senza informazioni relative alla tipo di oggetto. Inoltre, l'oggetto non è idoneo per l'uso o transcodifica multimediale.

Pratiche sconsigliate

  • Sebbene sia possibile farlo, un file compresso con gzip non dovrebbe essere caricato con la natura compressa del file. Ad esempio, per un di testo normale compresso con gzip, dovresti evitare di impostare solo Content-Type: text/plain. Questo rappresenta in modo ingannevole lo stato dell'oggetto. perché verrà consegnato a un richiedente.

  • Analogamente, gli oggetti non devono essere caricati con un'istruzione Content-Type omessa, anche se è incluso un Content-Encoding. Ciò potrebbe causare Content-Type viene impostato su un valore predefinito, ma potrebbe comportare la richiesta vengano rifiutati, a seconda di come vengono eseguiti.

Pratiche scorrette

  • Non devi impostare i metadati in modo da segnalare in modo ridondante la compressione. dell'oggetto:

    Content-Type: application/gzip
Content-Encoding: gzip

    Ciò implica che stai caricando un oggetto compresso con gzip che è stato compressa con gzip una seconda volta, quando solitamente non è così (se effettivamente di comprimere un file in modo doppio, consulta utilizzando gzip per gli oggetti compressi di seguito). Quando la transcodifica decompressiva avviene su un oggetto segnalato in modo errato, viene gestita l'identità dell'oggetto con codifica, ma i richiedenti pensano di hanno ricevuto un oggetto ancora associato a uno strato di compressione con essa. I tentativi di decompressione dell'oggetto non andranno a buon fine.

  • Analogamente, un file non compresso con gzip non deve essere caricato con Content-Encoding: gzip. In questo modo l'oggetto viene visualizzato per la transcodifica, ma quando vengono effettuate richieste dell'oggetto, tentativi di transcodifica non riusciti.

Utilizzo di gzip su oggetti compressi

Alcuni oggetti, come molti file video, audio e immagini, per non parlare del gzip sono già compressi. L'uso di gzip su questi oggetti offre praticamente nessun vantaggio: in quasi tutti i casi, ciò aumenta le dimensioni dell'oggetto a causa dell'overhead di gzip. Per questo motivo, l'uso di gzip sui file contenuti generalmente sconsigliati e possono causare comportamenti indesiderati.

Ad esempio, mentre Cloud Storage consente la compressione "doppiamente compressa" (ovvero compressi in formato gzip, ma che hanno anche un elemento Content-Type sottostante è compresso) di essere caricati e archiviati, non consente pubblicati in uno stato doppiamente compresso, a meno che i relativi metadati Cache-Control include no-transform. ma rimuove il livello esterno, gzip, compressione, ignora l'intestazione della risposta Content-Encoding e pubblica risultante. Questo si verifica anche per le richieste con Accept-Encoding: gzip. Il file ricevuto dal client non ha quindi lo stesso checksum i contenuti caricati e archiviati in Cloud Storage, quindi eventuali controlli di integrità non riuscito.

Utilizzo dell'intestazione Intervallo

Durante la transcodifica, se la richiesta per l'oggetto include un Range questa viene ignorata automaticamente. Ciò significa che le richieste di verifica i contenuti non sono soddisfatti e la risposta viene invece pubblicata nell'intero oggetto richiesto. Ad esempio, se hai un oggetto di 10 GB idoneo transcodifica, ma includi l'intestazione Range: bytes=0-10000 nella richiesta, ricevi comunque l'intero oggetto da 10 GB.

Questo comportamento si verifica perché non è possibile selezionare un intervallo da un file compresso senza prima decomprimere il file nel suo nella loro interezza: ogni richiesta per parte di un file viene accompagnata dalla decompressione dell'intero file, potenzialmente di grandi dimensioni, utilizzano in modo scarso le risorse. È necessario prestare attenzione a questo comportamento ed evitare utilizzando l'intestazione Range quando si utilizza la transcodifica, in quanto vengono addebitati dei costi per la trasmissione dell'intero oggetto e non solo dell'intervallo richiesto. Per ulteriori informazioni sul comportamento consentito delle risposte alle richieste con Range intestazioni, consulta la specifica.

Se sono necessarie richieste con intestazioni Range, assicurati che la transcodifica non si verifica per l'oggetto richiesto. Puoi farlo scegliendo le proprietà appropriate quando si caricano gli oggetti. Ad esempio: richieste di intervallo per oggetti con Content-Type: application/gzip e nessuna Content-Encoding vengono eseguite come richiesto.

Passaggi successivi