Introducción a la conversión de contenido

 

Se aplica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Última modificación del tema: 2009-09-09

Conversión de contenido es el proceso de formatear correctamente un mensaje para cada destinatario. La decisión de llevar a cabo la conversión de contenido de un mensaje depende del destinatario y del formato del mensaje que se procesa. No necesita realizar conversión de contenido en los mensajes que se mandan a destinatarios dentro de la organización Microsoft Exchange Server. Solamente se tiene que realizar conversión de contenido para los mensajes que se manden a destinatarios externos.

En una organización de Exchange Server 2007, el responsable de realizar la conversión de contenido es el categorizador de un servidor que tenga instalada la función del servidor Transporte de concentradores. La categorización se produce en los mensajes cuando se coloca un mensaje recién llegado en la cola de envío. Además de la resolución de destinatario y de enrutamiento, la conversión de contenido se realiza en el mensaje antes de que se ponga en la cola de envío. Si un único mensaje contiene varios destinatarios, la conversión de contenido determina la codificación adecuada para cada destinatario del mensaje. En un servidor de transporte perimetral tiene lugar una categorización abreviada. Esto no conlleva una conversión de contenido.

Introducción a la estructura de los mensajes de correo electrónico

Para entender mejor la conversión de contenido, debe entender la estructura de los mensajes de correo electrónico. El Protocolo simple de transferencia de correo (SMTP) está basado en un ASCII-US plano de 7 bytes para componer y enviar mensajes de correo electrónico. Un mensaje SMTP estándar consiste en los siguientes elementos:

  • El sobre del mensaje   El sobre del mensaje está definido en RFC 2821. El sobre del mensaje contiene información necesaria para transmitir y enviar el mensaje. Los destinatarios nunca ven el sobre del mensaje porque lo genera el proceso de transmisión del mensaje y no forma parte del contenido de este.

  • El contenido del mensaje   El contenido del mensaje está definido en RFC 2822. El contenido del mensaje está compuesto por los siguientes elementos:

    • El encabezado del mensaje   El encabezado del mensaje es una colección de campos de encabezado. Los campos de encabezado consisten en el nombre del campo, seguido de dos puntos ( : ), después el cuerpo del campo y por último una combinación de caracteres de avance de línea y retorno de carro (CRLF).

      Un nombre de campo tiene que estar compuesto por caracteres de texto US-ASCII imprimibles excepto el carácter de los dos puntos ( : ). En concreto, se permiten los caracteres ASCII que tienen valores entre 33 y 57 inclusive y entre 59 y 126 inclusive.

      Un cuerpo de campo puede estar compuesto por cualquier carácter US-ASCII, excepto los caracteres de retorno de carro (CR) y de avance de línea (LF). Sin embargo, un cuerpo de campo puede contener una combinación de caracteres CRLF cuando se usa en un doblado de encabezado. El doblado de encabezado es la separación de un único cuerpo de campo de encabezado en varias líneas, tal y como se describe en la sección 2.2.3 de RFC 2822. En las secciones 3 y 4 de RFC 2822 se describen otros requisitos de sintaxis de cuerpo de campo.

    • El cuerpo del mensaje   El cuerpo del mensaje es una colección de líneas de caracteres de texto US-ASCII que aparece después del encabezado del mensaje. El encabezado del mensaje y el cuerpo del mensaje están separados por una línea en blanco que termina con la combinación de caracteres CRLF. El cuerpo de mensaje es opcional. Cualquier línea de texto en el cuerpo del mensaje tiene que tener menos de 998 caracteres. Los caracteres de retorno de carro y de avance de línea solamente aparecen juntos para indicar el final de una línea.

Cuando los mensajes SMTP contienen elementos que no son texto sin formato US-ASCII, el mensaje tiene que ir codificado para preservar esos elementos. El estándar MIME define un método de codificación de contenido de mensajes que no es de texto. MIME permite texto con otros conjuntos de caracteres, datos adjuntos de no texto, cuerpos de mensajes multiparte y cuerpos de encabezado en otros conjuntos de caracteres. MIME está definido en RFC 2045, RFC 2046, RFC 2047, RFC 2048 y RFC 2077. MIME define una colección de campos de encabezado que especifican atributos de mensaje adicionales. En la tabla siguiente se describen algunos campos de encabezado MIME importantes.

Campos de encabezado MIME importantes

Nombre de campo de encabezado Valor predeterminado Descripción

Versión de MIME:

1.0

Este campo de encabezado es el primer campo de encabezado MIME que aparece en un mensaje con formato MIME. Este campo de encabezado aparece después de los otros campos de encabezado estándar RFC 2822, pero antes que cualquier campo de encabezado MIME. Los clientes de correo electrónico para MIME usan este campo de encabezado para identificar un mensaje codificado con MIME. Cuando no existe este campo de encabezado, los clientes de correo electrónico con MIME identifican el mensaje como texto sin formato.

Tipo de contenido:

texto/sin formato

Este campo de encabezado identifica el tipo de medio del contenido del mensaje tal y como se describe en RFC 2046. Un tipo de medio consiste en un tipo, un subtipo y uno o más parámetros opcionales, como el parámetro charset=, que define la codificación de caracteres MIME. Los tipos que comienzan con "x-" no son estándar. Los subtipos que comienzan con "vnd." son específicos del proveedor. Internet Assigned Names Authority (IANA) tiene una lista de los tipos de medio registrados. Si desea obtener más información, consulte Tipos de medios MIME.

Nota

UNRESOLVED_TOKEN_VAL(exNote3rdPartyURL)

El tipo de medio multiparte permite varias partes de mensaje dentro del mismo mensaje mediante secciones definidas por diferentes tipos de medio. Algunos tipos de contenido: valores de campo incluyen texto/sin formato, texto/html, multiparte/mixto y multiparte/alternativo.

Codificación de la transferencia de contenido:

7 bytes

Este campo de encabezado puede describir la siguiente información de un mensaje:

  • El algoritmo de codificación que se usó para transformar cualquier texto no US-ASCII o datos binarios que existan en el cuerpo del mensaje.

  • Un indicador que describe la condición actual del cuerpo del mensaje.

Puede haber varios valores de la codificación de transferencia de contenido: campo de encabezado en un mensaje MIME. Cuando la codificación de la transferencia de contenido: campo de encabezado aparece en el encabezado del mensaje, se aplica a todo el cuerpo del mensaje. Cuando la codificación de la transferencia de contenido: campo de encabezado aparece en una de las partes de un mensaje multiparte, se aplica sólo a esa parte del mensaje.

Cuando se aplica un algoritmo de codificación a los datos del cuerpo de un mensaje, estos se transforman en texto US-ASCII sin formato. La transformación permite al mensaje explorar servidores de mensajería SMTP antiguos que sólo admiten mensajes en texto US-ASCII. Los valores de la codificación de la transferencia de contenido: el campo de encabezado que indica que se usó un algoritmo de codificación en el cuerpo del mensaje, tal y como sigue:

  • Entrecomillado imprimible   Este algoritmo de codificación usa caracteres US-ASCII imprimibles para codificar los datos del cuerpo del mensaje. Si el texto del mensaje original está en su mayor parte en US-ASCII, la codificación de entrecomillado imprimible produce resultados compactos y más o menos legibles. Todos los caracteres de texto US-ASCII imprimibles, excepto el signo de igual ( = ) se pueden representar sin codificarse.

  • Base64   Este algoritmo de codificación está basado sobre todo en el estándar Correo de privacidad mejorada (PEM) definido en RFC 1421. La codificación Base64 usa el algoritmo de codificación del alfabeto de 64 caracteres y caracteres de relleno de salida que están definidos en PEM para codificar los datos del cuerpo del mensaje. Un mensaje codificado con Base64 suele ser un 33% mayor que el mensaje original. La codificación con Base64 crea un incremento predecible en el tamaño del mensaje y es óptimo para los datos binarios y texto que no sea US-ASCII.

Por lo general, no se ven los diferentes algoritmos de codificación usados en el mismo mensaje.

Cuando no se ha usado ningún algoritmo de codificación en el cuerpo del mensaje, la codificación de transferencia de contenido: campo de encabezado que describe la condición actual del cuerpo del mensaje. Los siguientes valores de la codificación de la transferencia de contenido: campo de encabezado indica que no se han usado algoritmos de codificación en el cuerpo del mensaje:

  • 7 bytes    Este valor indica que los datos del cuerpo del mensaje ya están en el formato RFC 2822. En concreto, significa que las siguientes condiciones deben ser verdaderas:

    • Todas las líneas de texto han de contener menos de 998 caracteres.

    • Todos los caracteres tienen que estar en formato US-ASCII y tener valores de carácter entre 1 y 127, ambos inclusive.

    • Los caracteres de retorno de carro y de avance de línea solamente aparecen juntos para indicar el final de una línea.

    El cuerpo entero del mensaje puede que sea de 7 bytes, o parte del cuerpo de un mensaje multiparte puede ser de 7bytes. Si el mensaje multiparte contiene otras partes que tienen datos binarios o texto no US-ASCII, esa parte del mensaje tiene que ser codificada con los algoritmos de codificación de entrecomillado imprimible o Base64.

    Los mensajes que tengan cuerpos de 7bytes pueden explorar servidores de mensajería SMTP mediante el comando estándar DATA.

  • 8 bytes   Este valor indica que los datos del cuerpo del mensaje contienen caracteres que no son US-ASCII. En concreto, significa que las siguientes condiciones deben ser verdaderas:

    • Todas las líneas de texto han de contener menos de 998 caracteres.

    • Uno o más de los caracteres en el cuerpo de mensaje tiene valores superiores a 127.

    • Los caracteres de retorno de carro y de avance de línea solamente aparecen juntos para indicar el final de una línea.

    El cuerpo entero del mensaje puede que sea de 8 bytes, o parte del cuerpo de un mensaje multiparte puede ser de 8 bytes Si el mensaje multiparte contiene otras partes que tienen datos binarios, esa parte del mensaje tiene que ser codificada con los algoritmos de codificación de entrecomillado imprimible o Base64.

    Los mensajes con cuerpos de 8 bytes solamente pueden navegar entre servidores de mensajería SMTP que sean compatibles con la extensión 8BITMIME SMTP, tal y como se describe en RFC 1652, como en Exchange 2000 Server o versiones posteriores. En concreto, significa que las siguientes condiciones deben ser verdaderas:

    • La palabra clave 8BITMIME tiene que anunciarse en la respuesta del servidor EHLO.

    • Se siguen transmitiendo los mensajes mediante el comando estándar DATA de SMTP. Sin embargo, se tiene que agregar el parámetro BODY=8BITMIME al final del comando MAIL FROM.

  • Binario   Este valor indica que el cuerpo del mensaje contiene datos binarios o caracteres que no son US-ASCII. En concreto, significa que las siguientes condiciones son verdaderas:

    • Se permite cualquier secuencia de caracteres.

    • No hay límite de longitud de línea.

    • Los elementos de mensaje binarios no necesitan codificación.

    Los mensajes con cuerpos binarios solamente pueden navegar entre servidores de mensajería SMTP que son compatibles con la extensión BINARYMIME SMTP, tal y como se describe en RFC 3030, como en Exchange 2000 o versiones posteriores. En concreto, significa que las siguientes condiciones deben ser verdaderas:

    • La palabra clave BINARYMIME tiene que anunciarse en la respuesta del servidor EHLO.

    • La extensión BINARYMIME SMTP solamente se puede usar con la extensión CHUNKING SMTP. Fragmentación permite que se manden los cuerpos de mensaje grandes en varios y pequeños fragmentos. La fragmentación también se define en RFC 3030. La clave CHUNKING también tiene que anunciarse en la respuesta del servidor EHLO.

    • Los mensajes se transfieren mediante el comando BDAT, en vez del comando estándar DATA.

    • El parámetro BODY=BINARYMIME se tiene que agregar al final del comando MAIL FROM cuando el mensaje tiene cuerpo de mensaje.

Los valores 7 bytes, 8 bytes y binario nunca pueden existir al mismo tiempo en el mismo mensaje multiparte. Los valores son mutuamente excluyentes. Los valores de entrecomillado imprimible o Base64 pueden aparecer en un cuerpo de mensaje multiparte de 7 bytes u 8 bytes, pero nunca en un cuerpo de mensaje binario. Si el cuerpo de un mensaje multiparte contiene diferentes partes compuestas por contenido de 7 bytes y 8 bytes, el mensaje entero se clasifica como de 8 bytes. Si el cuerpo de un mensaje multiparte contiene diferentes partes compuestas por contenido de 7 bytes, 8 bytes y binario, el mensaje entero se clasifica como binario.

Disposición del contenido:

Datos adjuntos

Este campo de encabezado indica al cliente de correo electrónico con MIME cómo debería visualizar unos datos adjuntos, tal y como se describe en RFC 2183. Los valores de este campo pueden en línea o datos adjuntos. Cuando el valor de este campo es en línea, los datos adjuntos se visualizan en el cuerpo del mensaje. Cuando el valor de este campo son datos adjuntos, aparecen como datos adjuntos normales, separado del cuerpo del mensaje. Hay otros parámetros disponibles cuando el valor es datos adjuntos, como nombre de archivo, fecha de creación y tamaño.

Exchange 2007 y formatos de mensaje de Outlook

En la siguiente lista se describen los formatos básicos de mensaje disponibles en Exchange 2007 y Microsoft Outlook:

  • Texto sin formato   Un mensaje de texto sin formato usa solamente texto US-ASCII tal y como se describe en RFC 2822. El mensaje no puede contener diferentes fuentes o formato de texto. Los dos siguientes formatos se pueden usar para un mensaje de texto sin formato:

    • Los encabezados de mensaje y el cuerpo del mensaje están compuestos por texto US-ASCII.

    • El mensaje está realmente codificado con MIME con un valor Tipo de contenido de texto/sin formato, y un valor de codificación de la transferencia de contenido de 7 bytes para las partes de texto de un mensaje multiparte. Cualquier dato adjunto del mensaje se codifica con el método de entrecomillado imprimible o Base64. De manera predeterminada, cuando escribe y envía un mensaje de texto sin formato en Outlook, el mensaje está realmente codificado en MIME con un valor de tipo de contenido de texto/sin formato.

  • HTML   Un mensaje HTML es compatible con el formato del texto, imágenes de fondo, tablas, viñetas y otros elementos gráficos. Por definición, un mensaje con formato de HTML tiene que estar codificado en MIME para conservar estos elementos de formato.

  • Formato de texto enriquecido (RTF)    RTF es compatible con formato de texto y otros elementos gráficos. RTF es sinónimo de formato de codificación neutro de transporte (TNEF). TNEF y RTF se pueden usar de manera intercambiable.

    Sólo Outlook y algunos clientes de correo MAPI comprenden los mensajes RTF. MAPI es una arquitectura de mensajería desarrollada de Microsoft que permite la interacción de varias aplicaciones con diversos sistemas de mensajería a través de distintas plataformas hardware. MAPI está construido con la arquitectura Modelo de objetos componentes (COM). Outlook usa MAPI para comunicarse con los buzones de un equipo en el que se ejecute Exchange 2007 y que tenga instalada la función del servidor Buzón de correo.

    El formato de mensaje de texto enriquecido es totalmente diferente al formato de documento de texto enriquecido disponible en Microsoft Word.

  • TNEF   TNEF es un formato específico de Microsoft para encapsular las propiedades de un mensaje MAPI. Un mensaje codificado mediante TNEF contiene una versión del mensaje en texto sin formato y datos adjuntos que empaquetan la versión original del mensaje con formato. Normalmente, estos datos adjuntos se denominan Winmail.dat e incluyen la siguiente información:

    • La versión del mensaje original con formato, incluido, por ejemplo, las fuentes, tamaños y colores del texto.

    • Los objetos OLE, como, por ejemplo, imágenes incrustadas o documentos incrustados de Microsoft Office.

    • Características avanzadas de Outlook, como formularios personalizados, botones de voto o convocatorias de reunión.

    • Datos adjuntos normales de mensaje que estaban en el mensaje original

    El mensaje de texto sin formato resultante se puede representar en los siguientes formatos:

    • Un mensaje conforme a RFC 2822 compuesto únicamente de texto US-ASCII

    • Un mensaje multiparte codificado en MIME que tiene un archivo Winmail.dat como datos adjuntos

    Un cliente de correo electrónico compatible con MAPI que entiende perfectamente TNEF, como Outlook, procesa los datos adjuntos Winmail.dat y visualiza el contenido del mensaje original sin visualizar nunca los datos adjuntos Winmail.dat. Un cliente de correo electrónico que no entiende TNEF puede presentar un mensaje codificado en TNEF de varias maneras:

    • La versión sin formato del mensaje se visualiza, y el mensaje contiene unos datos adjuntos llamados Winmail.dat, o algún otro nombre genérico como Attnnnnn.dat o Attnnnnn.eml, en los que el marcador de posición nnnnn representa un número aleatorio.

    • La versión de texto sin formato del mensaje se visualiza. Los datos adjuntos en TNEF se ignoran o se quitan. El resultado es un mensaje de texto sin formato.

    • Los servidores de mensajería que entienden el formato TNEF se pueden configurar para quitar los datos adjuntos TNEF de los mensajes entrantes. El resultado es un mensaje de texto sin formato. Incluso hay algunos clientes de correo electrónico, como Microsoft Outlook Express, que puede que no entiendan TNEF, pero sí reconocen e ignoran los adjuntos TNEF. El resultado es un mensaje de texto sin formato.

    Hay utilidades de terceros que pueden ayudar a convertir los datos adjuntos Winmail.dat.

    Exchange Server 5.0 y versiones posteriores entienden el formato TNEF. Los mensajes TNEF se transfieren entre los servidores de mensajería SMTP con el verbo de comando estándar DATA. Exchange usa el formato TNEF automáticamente en las siguientes situaciones:

    • Exchange 2000 Server   Se usa el formato TNEF para los mensajes que se transfieren entre servidores de Exchange que están en grupos de enrutamiento diferentes.

    • Exchange Server 2003   Si la organización Exchange está en un modo mixto, el formato TNEF se usa para los mensajes que se transfieren entre servidores de Exchange que están en diferentes grupos de enrutamiento.

  • Formato de codificación neutro de transporte de resumen (STNEF)   STNEF es equivalente a TNEF. Sin embargo, los mensajes STNEF están codificados de manera diferente a los mensajes TNEF. En concreto, los mensajes STNEF siempre están codificados en MIME y siempre tienen un valor de codificación de la transferencia de contenido de binario. Por ello, no hay ninguna representación del texto sin formato en el mensaje, y no hay datos adjuntos Winmail.dat distinto en el cuerpo del mensaje. El mensaje entero se representa sólo mediante datos binarios. Los mensajes que contienen valor binario de codificación de la transferencia de contenido solamente se pueden transferir entre servidores de mensajería SMTP que son compatibles y que anuncian las extensiones BINARYMIME y CHUNKING SMTP, tal y como se define en RFC 3030. Los mensajes siempre se transfieren entre los servidores de mensajería SMTP mediante el comando BDAT, en vez del comando estándar DATA.

    Exchange 2000 y versiones posteriores entienden el formato STNEF. Exchange usa de manera automática el formato STNEF si se dan las siguientes condiciones:

    • Exchange 2000   Se usa el formato STNEF para los mensajes que se transfieren entre servidores de Exchange que están en grupos de enrutamiento diferentes. Una revisión no compatible también permite que Exchange 2000 use STNEF para mensajes que se transfieren entre servidores de Exchange en distintos grupos de enrutamiento.

    • Exchange 2003   Si la organización Exchange está en modo nativo, el formato STNEF se usa para los mensajes que se transfieren entre servidores de Exchange en la organización.

    • Exchange 2007   El formato STNEF se usa para todos los mensajes que se transfieren entre los servidores Exchange en la organización.

    Exchange nunca manda mensajes con formato STNEF a destinatarios externos. Solamente se pueden enviar mensajes TNEF a destinatarios fuera de la organización Exchange.

Elementos de conversión del contenido

Conversión de contenido es el proceso de formatear correctamente un mensaje para cada destinatario externo. La conversión la realiza el categorizador en un servidor de transporte de concentradores.

Las opciones de conversión de contenido que puede establecer en una organización Exchange se pueden describir en las siguientes categorías:

  • Opciones de conversión TNEF   Estas opciones de conversión especifican si se ha de quitar o conservar el formato TNEF en los mensajes que salen de la organización Exchange.

  • Opciones de codificación de mensaje   Estas opciones especifican las opciones de codificación de mensaje, como los conjuntos de caracteres MIME y no MIME, codificación de mensaje y formatos de datos adjuntos.

Estas opciones de conversión y codificación son independientes las unas de las otras. Por ejemplo, que los mensajes TNEF puedan salir de la organización Exchange no tiene nada que ver con las opciones de configuración de la codificación MIME o la configuración de codificación de texto sin formato de esos mensajes.

Puede especificar la conversión del contenido a diferentes niveles de la organización Exchange tal y como se describe en la siguiente lista:

  • Configuración de dominio remoto   Los dominios remotos definen la configuración de las transferencias de mensajes salientes entre la organización Exchange 2007 y los dominios fuera del bosque de servicio de directorio Active Directory. Incluso si no crea entradas de dominio remoto para dominios específicos, hay un dominio remoto predeterminado llamado Predeterminado que se aplica a todos los espacios de direcciones remotos ( * ).

  • Configuración de usuario de correo y de contacto de correo   Los usuarios de correo se parecen a los contactos de correo: ambos tienen direcciones de correo electrónico externas y contienen información acerca de personas fuera de la organización Exchange. La diferencia principal es que los usuarios de correo tienen contextos de seguridad que pueden usarse para iniciar sesión en el dominio de Active Directory y tener acceso a los recursos para los que se les ha concedido permiso.

  • Configuración de Outlook   Outlook permite fijar las opciones de mensaje, de formato y de codificación descritas en la siguiente lista:

    • Formato de mensaje   Puede fijar el formato de mensaje predeterminado para todos los mensajes. Y puede invalidar el formato de mensaje predeterminado mientras escribe un mensaje específico.

    • Formato de mensaje interno   Puede controlar si los mensajes TNEF se envían a destinatarios remotos o si primero se convierten a un formato más compatible. También puede especificar diferentes opciones de codificación de mensaje para mensajes que se envían a destinatarios remotos. La configuración no se aplica a mensajes enviados a destinatarios en la organización Exchange.

    • Formato de mensaje de destinatario de Internet   Puede controlar si los mensajes TNEF se envían a destinatarios específicos o si primero se convierten a un formato más compatible. Puede fijar las opciones de conversión para contactos específicos en su carpeta de contactos, y puede invalidar las opciones de conversión para un destinatario específico en el Para: y CC: o CCO: cuando compone un mensaje. Estas opciones de conversión no están disponibles para destinatarios de la organización Exchange.

    • Opciones de codificación de mensaje de destinatario de Internet   Puede controlar las opciones de codificación de MIME o de texto sin formato para contactos específicos de su carpeta de contactos, y puede invalidar las opciones de conversión para un destinatario específico en los campos Para:, CC: o CCO: mientras compone un mensaje. Estas opciones de conversión no están disponibles para destinatarios de la organización Exchange.

    • Opciones internacionales   Puede controlar los conjuntos de caracteres que se usan en los mensajes.

Opciones de conversión TNEF

Puede establecer las opciones de conversión de TNEF en los siguientes niveles:

  • Configuración del dominio remoto

  • Configuración del usuario de correo y el contacto de correo

  • Outlook configuración

    • Formato del mensaje

    • Formato de los mensajes de Internet

    • Formato de los mensajes de destinatario de Internet

Para obtener información, consulte Opciones de conversación TNEF.

Opciones de la codificación de mensajes

Puede establecer las opciones de mensaje en los siguientes niveles:

  • Configuración del dominio remoto

  • Configuración del usuario de correo y el contacto de correo

  • Configuración de Outlook

    • Formato del mensaje

    • Mensaje de Internet

    • Formato de los mensajes de destinatario de Internet

    • Opciones de codificación del conjunto de caracteres del mensaje

Para obtener información, consulte Opciones de la codificación de mensajes.

Conversión de contenido efectuada por el controlador de almacenamiento

El controlador de almacenamiento efectúa también un tipo de conversión de contenido. El controlador de almacenamiento existe en los servidores de transporte de concentradores para transportar mensajes entre los buzones de los servidores de buzones y la cola de envío. En concreto, el controlador de almacenamiento transporta los mensajes desde la bandeja de salida del remitente hasta la cola de envío del servidor de transporte de concentradores y, a continuación, desde la cola de entrega MAPI del servidor de transporte de concentradores hasta la bandeja de entrada del destinatario. El controlador de almacenamiento convierte todos los mensajes salientes codificados con MAPI y convierte todos los entrantes a MAPI. El seguimiento de la conversión de contenido detecta los errores de conversión del controlador de almacenamiento.

Para obtener más información, consulte Administración del seguimiento de la conversión de contenido.