Transcodifica archivos comprimidos en gzip

En esta página, se trata la conversión de archivos hacia y desde el estado comprimido en gzip. En esta página, se incluyen una descripción general de transcodificación, recomendaciones para trabajar con metadatos asociados y el comportamiento de archivos comprimidos en Cloud Storage.

Transcodificación y gzip

gzip es una forma de compresión de datos: reduce el tamaño de un archivo de forma típica. Esto permite que el archivo se pueda transferir más rápido y se pueda almacenar con menos uso de espacio que si no estuviera comprimido. Comprimir un archivo puede reducir costos y el tiempo de transferencia. La transcodificación, en Cloud Storage, es el cambio automático de la compresión de un archivo antes de que se entregue a un solicitante. Cuando la transcodificación da como resultado un archivo comprimido en gzip, se puede considerar compresiva, mientras que si el resultado es un archivo que ya no está comprimido en gzip, se lo puede considerar descompresiva. Cloud Storage es compatible con el formato descompresivo de la transcodificación.

Transcodificación descompresiva

Si los archivos se almacenan como objetos comprimidos en gzip en Cloud Storage, se pueden descomprimir automáticamente antes de que se envíen a un solicitante, lo que da como resultado un archivo con identidad codificada (es decir, no comprimido). Esto permite la reducción de costos de almacenamiento para el objeto dentro de Cloud Storage, pero le da al solicitante el archivo en sí, sin compresión. Esto es útil, por ejemplo, cuando se entregan archivos a los clientes.

A modo de ser elegible para la transcodificación descompresiva, un objeto debe cumplir con los dos criterios a continuación:

  1. El archivo está comprimido en gzip cuando se almacena en Cloud Storage.

  2. Los metadatos asociados incluyen Content-Encoding: gzip.

Cuando un objeto cumple con estos dos criterios, sufre una transcodificación descompresiva al momento de la solicitud y, en ese caso, también se entrega sin un encabezado Content-Encoding. Si quieres que un objeto que cumple con los dos criterios se entregue en su estado comprimido (por ejemplo, a fin de reducir costos de salida o tiempo), hay dos formas de evitar que ocurra una transcodificación descompresiva:

  • Si la solicitud del objeto incluye un encabezado Accept-Encoding: gzip, el objeto se entrega como está en esa solicitud específica, junto con un encabezado de respuesta Content-Encoding: gzip.

  • Si el campo de metadatos Cache-Control del objeto está configurado como no-transform, el objeto se entrega como un objeto comprimido en todas las solicitudes posteriores, sin importar ninguno de los encabezados de solicitud Accept-Encoding.

Tipo de contenido frente a codificación del contenido

Hay varios comportamientos que debes tener en cuenta con respecto a cómo Content-Type y Content-Encoding se relacionan con la transcodificación. Ambos son metadatos almacenados junto con un objeto. Consulta Visualiza y edita los metadatos de objetos para obtener instrucciones detalladas sobre cómo agregar metadatos a objetos.

Se debería incluir Content-Type en todas las cargas; esto indica el tipo de objeto que se sube. Por ejemplo:

Content-Type: text/plain

indica que el objeto subido es un archivo de texto sin formato. Aunque no hay ninguna verificación para garantizar que el Content-Type especificado coincida con la verdadera naturaleza de un objeto subido, si el tipo se especifica de forma incorrecta, provocará a lo sumo que los solicitantes reciban algo diferente a lo que esperaban, lo que podría desencadenar comportamientos no deseados.

Content-Encoding es opcional y se puede incluir, si se desea, en los archivos que están comprimidos. Por ejemplo:

Content-Encoding: gzip

indica que el objeto subido está comprimido en gzip. Como con Content-Type, no existe verificación para garantizar que el Content-Encoding especificado está en realidad aplicado al objeto subido; si se especifica de modo incorrecto la codificación de un objeto podría llevar a un comportamiento no deseado en solicitudes de descarga posteriores.

Recomendaciones

  • Cuando se sube un objeto comprimido en gzip, la forma recomendada de configurar tus metadatos es especificar el Content-Type y la Content-Encoding. Por ejemplo, para un archivo de texto sin formato comprimido, esta sería la forma recomendada:

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

    Esto brinda la mayoría de la información sobre el estado del objeto a cualquiera que acceda a él. Cuando haces esto, el objeto se convierte en elegible para transcodificación descompresiva si se lo descarga más tarde, lo que permite que las aplicaciones cliente controlen la semántica del Content-Type de forma correcta.

  • De modo alternativo, puedes subir el objeto con el Content-Type configurado para que indique la compresión y NINGUNA Content-Encoding. Por ejemplo:

    Content-Type: application/gzip
    

    De todas formas, en este caso lo único que se sabe de inmediato sobre el objeto es que está comprimido en gzip, sin información sobre el tipo de objeto subyacente. Además, el objeto no es elegible para la transcodificación descompresiva.

Prácticas no recomendadas

  • A pesar de que es posible hacerlo, no se debe subir un archivo comprimido en gzip sin indicar la naturaleza comprimida del archivo. Por ejemplo, para un archivo de texto sin formato comprimido en gzip, debes evitar configurar solo Content-Type: text/plain. Hacer eso tergiversa el estado del objeto, ya que se entregará a un solicitante.

  • De manera similar, los objetos no se deben subir con un Content-Type omitido, incluso si se incluye un Content-Encoding. Eso puede dar como resultado que el Content-Type se establezca en un valor predeterminado, pero también puede dar como resultado que se rechace la solicitud, según cómo se haga la carga.

Prácticas incorrectas

  • No debes configurar tus metadatos para que informen de forma redundante la compresión del objeto:

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

    Esto implica que lo que subes es un objeto comprimido en gzip que se volvió a comprimir en gzip una segunda vez, cuando ese no es el caso típico (si en realidad quieres comprimir un archivo dos veces, consulta la sección usa gzip en objetos comprimidos más adelante). Cuando la transcodificación descompresiva sucede sobre un objeto informado de forma incorrecta, el objeto se entrega con la identidad codificada, pero los solicitantes creen que recibieron un objeto que aún tiene una capa de compresión asociada a él. Los intentos por descomprimir el objeto fallarán.

  • De forma similar, un archivo que no esté comprimido en gzip no se debe subir con el Content-Encoding: gzip. Si haces eso, el objeto parece ser elegible para la transcodificación, pero cuando este se solicita, fallan los intentos de transcodificación.

Usa gzip en objetos comprimidos

Algunos objetos, como muchos archivos de imagen, video y audio, sin mencionar a los archivos gzip en sí, ya se encuentran comprimidos. Usar gzip en esos objetos ofrece casi ningún beneficio: en la mayoría de los casos, hacerlo agranda el objeto debido a la sobrecarga de gzip. Por este motivo, no se suele recomendar que uses gzip en contenido comprimido, ya que, además, podría causar comportamientos no deseados.

Por ejemplo, si bien Cloud Storage permite que los objetos “comprimidos dos veces” (es decir, objetos comprimidos en gzip, pero que a la vez tienen un tipo de contenido subyacente que está comprimido en sí mismo) se suban y se almacenen, no permite que los objetos se entreguen en un estado de compresión doble, a menos que sus metadatos Cache-Control incluyan no-transform. En cambio, quita el nivel de compresión de gzip externo, omite el encabezado de respuesta Content-Encoding y entrega el objeto resultante. Esto sucede incluso en las solicitudes con Accept-Encoding: gzip.

Usa el encabezado Range

Cuando sucede la transcodificación, si la solicitud del objeto incluye un encabezado Range, este se ignora de forma silenciosa. Esto significa que las solicitudes de contenido parcial no se llevan a cabo y la respuesta, en cambio, entrega el objeto solicitado completo. Este comportamiento surge porque no es posible seleccionar un rango desde un archivo comprimido sin descomprimir el archivo primero en su totalidad: cada solicitud de una parte del archivo estaría acompañada de la descompresión completa de un archivo potencialmente grande, que usaría recursos de modo deficiente. Debes tener en cuenta este comportamiento y evitar usar el encabezado Range cuando usas la transcodificación, ya que se cobra por la transmisión del objeto completo y no solo el rango solicitado. Para obtener más información sobre el comportamiento de respuesta permitido a las solicitudes con encabezados Range, consulta la especificación.

Si las solicitudes con los encabezados Range son necesarias, debes asegurarte de que la transcodificación no suceda para el objeto solicitado. Si quieres lograr esto, selecciona las propiedades adecuadas cuando subas objetos. Por ejemplo, las solicitudes de rango para objetos con Content-Type: application/gzip y sin Content-Encoding se realizan como se solicitó.

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Si necesitas ayuda, visita nuestra página de asistencia.