Exportar (0) Imprimir
Expandir todo

Introducción a las codificaciones

Internamente, .NET Framework almacena el texto como Unicode UTF-16. Un codificador transforma estos datos de texto en una secuencia de bytes. Un descodificador transforma una secuencia de bytes en este formato interno. Una codificación describe las reglas según las cuales funciona un codificador o un descodificador. Por ejemplo, la clase UTF8Encoding describe las reglas para codificar y descodificar una secuencia de bytes que representa texto como Unicode UTF-8. La codificación y descodificación también pueden incluir algunos pasos de validación. Por ejemplo, la clase UnicodeEncoding comprueba todos los suplentes para asegurarse de que constituyen pares suplentes válidos. Ambas clases se heredan de la clase Encoding.

Elegir una codificación

La clase Encoding es muy general. Las clases admitidas heredadas de Encoding permiten a las aplicaciones de .NET trabajar con las codificaciones comunes que pueden encontrarse en las aplicaciones antiguas, y los programadores de .NET pueden implementar codificaciones adicionales. Sin embargo, si tiene la oportunidad de elegir, sería muy recomendable que utilizase una codificación Unicode, normalmente UTF8Encoding o UnicodeEncoding (también se admite UTF32Encoding). Concretamente, por lo general se prefiere UTF8Encoding antes que ASCIIEncoding. Si el contenido es ASCII, las dos codificaciones serán idénticas, pero UTF8Encoding puede representar todos los caracteres Unicode, mientras que ASCIIEncoding sólo admite los valores de caracteres Unicode entre U+0000 y U+007F. Dado que ASCIIEncoding no proporciona detección de errores, UTF8Encoding también es mejor en cuanto a seguridad.

UTF8Encoding se ha mejorado en materia de velocidad y debería ser más rápida que cualquier otra codificación. Incluso cuando todo el contenido es ASCII, las operaciones realizadas con UTF8Encoding serán más rápidas que las operaciones realizadas con ASCIIEncoding. Los desarrolladores deberían pensar en utilizar ASCIIEncoding sólo para ciertas aplicaciones antiguas. Sin embargo, incluso en este caso, UTF8Encoding puede ser una mejor opción. Dando por hecho que la configuración es la predeterminada, pueden darse los escenarios siguientes:

  • Si tiene contenido interno que no es estrictamente ASCII y lo codifica con ASCIIEncoding, cada carácter no ASCII se codificará como un signo de interrogación ("?"). Si descodifica estos datos después, perderá la información.

  • Si tiene contenido interno que no es estrictamente ASCII y lo codifica con UTF8Encoding, el resultado parecerá ininteligible si se interpreta como ASCII. Sin embargo, si descodifica estos datos después, el resultado será correcto.

Elegir una estrategia de reinterpretación

Cuando una aplicación intenta codificar o descodificar un carácter pero no existe ninguna asignación, debe implementar una estrategia de reinterpretación. Una estrategia de reinterpretación es un mecanismo de control de errores. Hay dos tipos de estrategias de reinterpretación:

  1. Reinterpretación con ajuste perfecto

    Cuando los caracteres no tienen una coincidencia exacta en la codificación/descodificación de destino, la aplicación puede decidir si debe intentar asignarlos a un carácter similar.

  2. Reinterpretación con cadenas de reemplazo

    Si no hay ningún carácter similar adecuado, la aplicación puede especificar qué debe insertarse en la cadena para identificar la omisión.

Por ejemplo, una aplicación puede llamar a GetEncoding(1252, 0, 0) (vea GetEncoding); así se especifica la página de códigos 1252 (la página de códigos de Windows para los idiomas de Europa occidental) con encoderFallback y decoderFallback establecidos en cero. El comportamiento predeterminado será una asignación de ajuste perfecto para algunos caracteres Unicode. Por ejemplo, CIRCLED LATIN CAPITAL LETTER S (U+24C8) se cambiará a LATIN CAPITAL LETTER S (U+0053) antes de codificarse; SUPERSCRIPT FIVE (U+2075) se cambiará a DIGIT FIVE (U+0035). Después, si descodifica la página de códigos 1252 a Unicode de nuevo, se perderá el círculo que rodea la letra y 25 pasará a ser 25. Otras conversiones pueden ser aún más drásticas: es posible que el símbolo INFINITY de Unicode (U+221E) se asigne a DIGIT EIGHT (U+0038).

Las estrategias de ajuste perfecto varían en función de la página de códigos, y no se encuentran documentadas de manera detallada. Por ejemplo, para algunas páginas de códigos, los caracteres latinos de ancho completo se asignarán a caracteres latinos de ancho medio, que son más comunes; para otras, no sucederá lo mismo.

Incluso con una estrategia de ajuste perfecto agresiva, algunos caracteres no tienen un ajuste imaginable en algunas codificaciones. Por ejemplo, un ideograma chino no tiene ninguna asignación razonable para la página de códigos 1252. En ese caso, se utilizaría una cadena de reemplazo. De forma predeterminada, esta cadena es simplemente un carácter QUESTION MARK (U+003F).

La asignación de ajuste perfecto es el comportamiento predeterminado para Encoding, que codifica los datos Unicode en datos de página de códigos, y hay aplicaciones antiguas que se basan en este comportamiento. Sin embargo, la mayoría de las aplicaciones nuevas deberían evitarlo por razones de seguridad. (Por ejemplo, las aplicaciones no deberían asignar nombres de dominio mediante una codificación de ajuste perfecto). Dispone de las siguientes alternativas a la asignación de ajuste perfecto:

  • Para evitar problemas de reinterpretación de caracteres, utilice sólo las codificaciones Unicode (UTF8Encoding, UnicodeEncoding y UTF32Encoding).

    Caution notePrecaución

    Aunque UTF7Encoding es, técnicamente, una codificación Unicode, es menos sólida y segura que otras codificaciones. En algunos casos, cambiar un bit puede modificar radicalmente la interpretación de una cadena UTF-7 completa. En otros casos, es posible que cadenas UTF-7 sustancialmente diferentes codifiquen el mismo texto. Por consiguiente, si puede elegir, no debería utilizar UTF-7. Se prefiere UTF-8.

  • Utilice EncoderExceptionFallback y DecoderExceptionFallback, que inician la excepción (EncoderFallbackException y DecoderFallbackException, respectivamente) si un carácter no se asigna con exactitud.

  • Utilice EncoderReplacementFallback y DecoderReplacementFallback para sustituir siempre una cadena de reemplazo si un carácter no tiene una asignación exacta. (Éste es el comportamiento predeterminado para ASCIIEncoding). De forma predeterminada, esta cadena será simplemente un signo de interrogación, pero existen métodos que permiten que una aplicación elija una cadena diferente. Aunque suele ser un carácter individual, no es obligatorio. Para DecoderReplacementFallback, que se utiliza al transformar texto en Unicode, un carácter que suele utilizarse es REPLACEMENT CHARACTER (U+FFFD).

  • Escriba su propio EncoderFallback o DecoderFallback, para implementar la estrategia que prefiera. Vea Ejemplo Fallback Encoding Application.

Dos comentarios adicionales acerca de las estrategias de reinterpretación de codificación (o descodificación) con ajuste perfecto:

  • El ajuste perfecto es básicamente una cuestión de codificación, más que de descodificación. Hay muy pocas páginas de códigos que contengan caracteres que no se puedan asignar correctamente a Unicode. Dichos caracteres no se utilizan con frecuencia, motivo por el cual se omitieron de Unicode.

  • No hay objetos con nombre compatibles que se correspondan con las reinterpretaciones con ajuste perfecto, y la reinterpretación con ajuste perfecto de cada página de códigos es diferente. Si desea poder alternar entre el ajuste perfecto y alguna otra reinterpretación de un objeto Encoding, realice una copia del objeto con ajuste perfecto en una variable antes de asignar cualquier otro objeto de reinterpretación. Después, podrá recuperar la reinterpretación con ajuste perfecto si vuelve a asignar ese valor a System.Text.Encoding.EncoderFallback (o System.Text.Encoding.DecoderFallback).

Vea también

Adiciones de comunidad

AGREGAR
Mostrar:
© 2014 Microsoft