Codificar es el proceso de transformar un conjunto de caracteres Unicode en una secuencia de bytes. Por contraste, decodificar es el proceso de transformar una secuencia de bytes codificados en un conjunto de caracteres Unicode. Para obtener información sobre los formatos de transformación Unicode (UTF) y otras codificaciones admitidas por Encoding, vea Introducción a las codificaciones. Vea también Utilizar codificación Unicode.
Observe que Encoding se ha diseñado para operar sobre caracteres Unicode, no sobre datos binarios arbitrarios tales como las matrices de bytes. Si la aplicación debe codificar datos binarios arbitrarios en el texto, utilice un protocolo, como UUencode, que métodos tales como ConvertToBase64CharArray()()() lo implementan.
.NET Framework proporciona las implementaciones siguientes de la clase Encoding para que exista compatibilidad con las codificaciones Unicode actuales y de otro tipo:
ASCIIEncoding codifica caracteres Unicode como caracteres ASCII sencillos de 7 bits. Esta codificación sólo admite valores de caracteres entre U+0000 y U+007F. Página de códigos 20127. También disponible mediante la propiedad ASCII.
La clase UTF7Encoding codifica los caracteres Unicode mediante la codificación UTF-7. Esta codificación acepta todos los valores de caracteres Unicode. Página de códigos 65000. También disponible mediante la propiedad UTF7.
La clase UTF8Encoding codifica los caracteres Unicode mediante la codificación UTF-8. Esta codificación acepta todos los valores de caracteres Unicode. Página de códigos 65001. También disponible mediante la propiedad UTF8.
La clase UnicodeEncoding codifica los caracteres Unicode mediante la codificación UTF-16. Se admiten tanto el orden de bytes little-endian (página de códigos 1200) como el big-endian (página de códigos 1201). También disponible mediante las propiedades Unicode y BigEndianUnicode.
La clase UTF32Encoding codifica los caracteres Unicode mediante la codificación UTF-32. Se admiten tanto el orden de bytes little-endian (página de códigos 12000) como el big-endian (página de códigos 12001). También disponible mediante la propiedad UTF32.
La clase Encoding está pensada principalmente para convertir entre diferentes codificaciones y Unicode. A menudo, la opción correcta para una aplicación es una de las clases de Unicode derivadas.
Las aplicaciones utilizan el método GetEncoding para obtener otras codificaciones. Utilizarían el método GetEncodings para obtener una lista de todas las codificaciones.
En la tabla siguiente se ofrece una lista de las codificaciones compatibles y sus páginas de códigos asociadas. Un asterisco en la última columna indica que .NET Framework admite de forma nativa la página de códigos, con independencia de la plataforma subyacente.
Página de códigos
|
Name
|
Nombre mostrado
|
|
|---|
37
|
IBM037
|
IBM EBCDIC (EE.UU.-Canadá)
|
|
437
|
IBM437
|
Estados Unidos OEM
|
|
500
|
IBM500
|
IBM EBCDIC (Internacional)
|
|
708
|
ASMO-708
|
Árabe (ASMO 708)
|
|
720
|
DOS-720
|
Árabe (DOS)
|
|
737
|
ibm737
|
Griego (DOS)
|
|
775
|
ibm775
|
Báltico (DOS)
|
|
850
|
ibm850
|
Europa occidental (DOS)
|
|
852
|
ibm852
|
Centroeuropeo (DOS)
|
|
855
|
IBM855
|
Cirílico OEM
|
|
857
|
ibm857
|
Turco (DOS)
|
|
858
|
IBM00858
|
Latín multilingüe OEM I
|
|
860
|
IBM860
|
Portugués (DOS)
|
|
861
|
ibm861
|
Islandés (DOS)
|
|
862
|
DOS-862
|
Hebreo (DOS)
|
|
863
|
IBM863
|
Francés canadiense (DOS)
|
|
864
|
IBM864
|
Árabe (864)
|
|
865
|
IBM865
|
Nórdico (DOS)
|
|
866
|
cp866
|
Cirílico (DOS)
|
|
869
|
ibm869
|
Griego moderno (DOS)
|
|
870
|
IBM870
|
IBM EBCDIC (Latín multilingüe-2)
|
|
874
|
windows-874
|
Tailandés (Windows)
|
|
875
|
cp875
|
IBM EBCDIC (Griego moderno)
|
|
932
|
shift_jis
|
Japonés (Shift-JIS)
|
|
936
|
gb2312
|
Chino simplificado (GB2312)
|
*
|
949
|
ks_c_5601-1987
|
Coreano
|
|
950
|
big5
|
Chino tradicional (Big5)
|
|
1026
|
IBM1026
|
IBM EBCDIC (Turco Latín-5)
|
|
1047
|
IBM01047
|
IBM Latín-1
|
|
1140
|
IBM01140
|
IBM EBCDIC (EE.UU.-Canadá-Euro)
|
|
1141
|
IBM01141
|
IBM EBCDIC (Alemania-Euro)
|
|
1142
|
IBM01142
|
IBM EBCDIC (Dinamarca-Noruega-Euro)
|
|
1143
|
IBM01143
|
IBM EBCDIC (Finlandia-Suecia-Euro)
|
|
1144
|
IBM01144
|
IBM EBCDIC (Italia-Euro)
|
|
1145
|
IBM01145
|
IBM EBCDIC (España-Euro)
|
|
1146
|
IBM01146
|
IBM EBCDIC (Reino Unido-Euro)
|
|
1147
|
IBM01147
|
IBM EBCDIC (Francia-Euro)
|
|
1148
|
IBM01148
|
IBM EBCDIC (Internacional-Euro)
|
|
1149
|
IBM01149
|
IBM EBCDIC (Islandés-Euro)
|
|
1200
|
utf-16
|
Unicode
|
*
|
1201
|
unicodeFFFE
|
Unicode (big-endian)
|
*
|
1250
|
windows-1250
|
Centroeuropeo (Windows)
|
|
1251
|
windows-1251
|
Cirílico (Windows)
|
|
1252
|
Windows -1252
|
Europeo occidental (Windows)
|
*
|
1253
|
windows-1253
|
Griego (Windows)
|
|
1254
|
windows-1254
|
Turco (Windows)
|
|
1255
|
windows-1255
|
Hebreo (Windows)
|
|
1256
|
windows-1256
|
Árabe (Windows)
|
|
1257
|
windows-1257
|
Báltico (Windows)
|
|
1258
|
windows-1258
|
Vietnamita (Windows)
|
|
1361
|
Johab
|
Coreano (Johab)
|
|
10000
|
macintosh
|
Europa occidental (Mac)
|
|
10001
|
x-mac-japanese
|
Japonés (Mac)
|
|
10002
|
x-mac-chinesetrad
|
Chino tradicional (Mac)
|
|
10003
|
x-mac-korean
|
Coreano (Mac)
|
*
|
10004
|
x-mac-arabic
|
Árabe (Mac)
|
|
10005
|
x-mac-hebrew
|
Hebreo (Mac)
|
|
10006
|
x-mac-greek
|
Griego (Mac)
|
|
10007
|
x-mac-cyrillic
|
Cirílico (Mac)
|
|
10008
|
x-mac-chinesesimp
|
Chino simplificado (Mac)
|
*
|
10010
|
x-mac-romanian
|
Rumano (Mac)
|
|
10017
|
x-mac-ukrainian
|
Ucraniano (Mac)
|
|
10021
|
x-mac-thai
|
Tailandés (Mac)
|
|
10029
|
x-mac-ce
|
Centroeuropeo (Mac)
|
|
10079
|
x-mac-icelandic
|
Islandés (Mac)
|
|
10081
|
x-mac-turkish
|
Turco (Mac)
|
|
10082
|
x-mac-croatian
|
Croata (Mac)
|
|
12000
|
utf-32
|
Unicode (UTF-32)
|
*
|
12001
|
utf-32BE
|
Unicode (UTF-32 big-endian)
|
*
|
20000
|
x-Chinese-CNS
|
Chino tradicional (CNS)
|
|
20001
|
x-cp20001
|
TCA Taiwán
|
|
20002
|
x-Chinese-Eten
|
Chino tradicional (Eten)
|
|
20003
|
x-cp20003
|
IBM5550 Taiwán
|
|
20004
|
x-cp20004
|
TeleText Taiwán
|
|
20005
|
x-cp20005
|
Wang Taiwán
|
|
20105
|
x-IA5
|
Europa occidental (IA5)
|
|
20106
|
x-IA5-German
|
Alemán (IA5)
|
|
20107
|
x-IA5-Swedish
|
Sueco (IA5)
|
|
20108
|
x-IA5-Norwegian
|
Noruego (IA5)
|
|
20127
|
us-ascii
|
EE.UU.-ASCII
|
*
|
20261
|
x-cp20261
|
T.61
|
|
20269
|
x-cp20269
|
ISO -6937
|
|
20273
|
IBM273
|
IBM EBCDIC (Alemania)
|
|
20277
|
IBM277
|
IBM EBCDIC (Dinamarca-Noruega)
|
|
20278
|
IBM278
|
IBM EBCDIC (Finlandia-Suecia)
|
|
20280
|
IBM280
|
IBM EBCDIC (Italia)
|
|
20284
|
IBM284
|
IBM EBCDIC (España)
|
|
20285
|
IBM285
|
IBM EBCDIC (Reino Unido)
|
|
20290
|
IBM290
|
IBM EBCDIC (Katakana japonés)
|
|
20297
|
IBM297
|
IBM EBCDIC (Francia)
|
|
20420
|
IBM420
|
IBM EBCDIC (Árabe)
|
|
20423
|
IBM423
|
IBM EBCDIC (Griego)
|
|
20424
|
IBM424
|
IBM EBCDIC (Hebreo)
|
|
20833
|
x-EBCDIC-KoreanExtended
|
IBM EBCDIC (Coreano extendido)
|
|
20838
|
IBM-Thai
|
IBM EBCDIC (Tai)
|
|
20866
|
koi8-r
|
Cirílico (KOI8-R)
|
|
20871
|
IBM871
|
IBM EBCDIC (Islandés)
|
|
20880
|
IBM880
|
IBM EBCDIC (Ruso cirílico)
|
|
20905
|
IBM905
|
IBM EBCDIC (Turco)
|
|
20924
|
IBM00924
|
IBM Latín-1
|
|
20932
|
EUC-JP
|
Japonés (JIS 0208-1990 y 0212-1990)
|
|
20936
|
x-cp20936
|
Chino simplificado (GB2312-80)
|
*
|
20949
|
x-cp20949
|
Coreano Wansung
|
*
|
21025
|
cp1025
|
IBM EBCDIC (Cirílico serbio-búlgaro)
|
|
21866
|
koi8-u
|
Cirílico (KOI8-U)
|
|
28591
|
iso-8859-1
|
Europa occidental (ISO)
|
*
|
28592
|
iso-8859-2
|
Centroeuropeo (ISO)
|
|
28593
|
iso-8859-3
|
Latín 3 (ISO)
|
|
28594
|
iso-8859-4
|
Báltico (ISO)
|
|
28595
|
iso-8859-5
|
Cirílico (ISO)
|
|
28596
|
iso-8859-6
|
Árabe (ISO)
|
|
28597
|
iso-8859-7
|
Griego (ISO)
|
|
28598
|
iso-8859-8
|
Hebreo (ISO-Visual)
|
*
|
28599
|
iso-8859-9
|
Turco (ISO)
|
|
28603
|
iso-8859-13
|
Estonio (ISO)
|
|
28605
|
iso-8859-15
|
Latín 9 (ISO)
|
|
29001
|
x-Europa
|
Europa
|
|
38598
|
iso-8859-8-i
|
Hebreo (ISO-Lógico)
|
*
|
50220
|
iso-2022-jp
|
Japonés (JIS)
|
*
|
50221
|
csISO2022JP
|
Japonés (JIS-Permitir 1 byte Kana)
|
*
|
50222
|
iso-2022-jp
|
Japonés (JIS-Permitir 1 byte Kana - SO/SI)
|
*
|
50225
|
iso-2022-kr
|
Coreano (ISO)
|
*
|
50227
|
x-cp50227
|
Chino simplificado (ISO-2022)
|
*
|
51932
|
euc-jp
|
Japonés (EUC)
|
*
|
51936
|
EUC-CN
|
Chino simplificado (EUC)
|
*
|
51949
|
euc-kr
|
Coreano (EUC)
|
*
|
52936
|
hz-gb-2312
|
Chino simplificado (HZ)
|
*
|
54936
|
GB18030
|
Chino simplificado (GB18030)
|
*
|
57002
|
x-iscii-de
|
ISCII Devanagari
|
*
|
57003
|
x-iscii-be
|
ISCII Bengalí
|
*
|
57004
|
x-iscii-ta
|
ISCII Tamil
|
*
|
57005
|
x-iscii-te
|
ISCII Telugu
|
*
|
57006
|
x-iscii-as
|
ISCII Asamés
|
*
|
57007
|
x-iscii-or
|
ISCII Oriya
|
*
|
57008
|
x-iscii-ka
|
ISCII Kannada
|
*
|
57009
|
x-iscii-ma
|
ISCII Malayalam
|
*
|
57010
|
x-iscii-gu
|
ISCII Gujarati
|
*
|
57011
|
x-iscii-pa
|
ISCII Punjabí
|
*
|
65000
|
utf-7
|
Unicode (UTF-7)
|
*
|
65001
|
utf-8
|
Unicode (UTF-8)
|
*
|
El método GetByteCount()()() determina cuántos bytes se obtienen al codificar un conjunto de caracteres Unicode y el método GetBytes()()() realiza la codificación real. El método GetBytes()()() espera conversiones discretas, a diferencia del método GetBytes()()(), que administra varias conversiones en una secuencia de entrada única.
Se admiten varias versiones de GetByteCount()()() y GetBytes()()(). Las siguientes son algunas consideraciones de programación para el uso de estos métodos:
Puede ser necesario que la aplicación codifique muchos caracteres de entrada en una página de códigos y procese los caracteres mediante varias llamadas. En este caso, la aplicación probablemente necesite mantener el estado entre las llamadas, teniendo en cuenta el estado que persiste por el objeto Encoder que se está usando.
Si la aplicación administra las entradas de cadena, se recomienda usar la versión de cadena de GetBytes()()().
La versión del búfer de caracteres Unicode de GetBytes()()() permite algunas técnicas rápidas, especialmente cuando varias llamadas usan el objeto Encoder o insertan datos en los búferes existentes. Sin embargo, tenga presente que esta versión de método no es segura a veces, ya que se requieren punteros.
Si la aplicación debe convertir gran cantidad de datos, debería reutilizar el búfer de salida. En este caso, la mejor opción es la versión de GetBytes()()() que admite matrices de bytes.
Considere el uso del método Encoder..::.Convert en lugar de GetByteCount()()(). El método de conversión convierte tanto datos como sea posible y produce una excepción si el búfer de salida es demasiado pequeño. Para la codificación continua de una secuencia, este método suele ser la mejor opción.
El método GetCharCount()()() determina el número de caracteres resultante de la descodificación de una secuencia de bytes, y el método GetChars()()() realiza la descodificación real. El método GetChars()()() espera conversiones discretas, a diferencia del método GetChars()()(), que administra varios pasos en una secuencia de entrada única.
Se admiten varias versiones de GetCharCount()()() y GetChar()()(). Las siguientes son algunas consideraciones de programación para el uso de estos métodos:
Es posible que la aplicación necesite descodificar varios bytes de entrada de una página de códigos y procesar los bytes mediante varias llamadas. En este caso, la aplicación probablemente necesite mantener el estado entre las llamadas.
Si la aplicación administra los resultados de cadena, se recomendaba usar el método GetString()()(). Como este método debe comprobar la longitud de cadena y asignar un búfer, es ligeramente más lento, pero se prefiere usar el tipo String resultante.
La versión de bytes de GetChar()()() permite a algunas técnicas rápidas, especialmente con varias llamadas a búferes grandes. Sin embargo, tenga presente que esta versión de método no es segura a veces, ya que se requieren punteros.
Si la aplicación debe convertir gran cantidad de datos, debería reutilizar el búfer de salida. En este caso, la versión de GetChar()()() que admite búferes de caracteres de salida es la mejor opción.
Considere el uso del método Decoder..::.Convert en lugar de GetCharCount()()(). El método de conversión convierte tanto datos como sea posible y produce una excepción si el búfer de salida es demasiado pequeño. Para la descodificación continua de una secuencia, este método suele ser la mejor opción.
Si los datos que se van a convertir sólo están disponibles en bloques secuenciales (como los datos leídos de una secuencia) o si la cantidad de datos es tan grande que es necesario dividirlos en bloques más pequeños, use las clases Decoder o Encoder proporcionadas por el método GetDecoder o GetEncoder, respectivamente, de una clase derivada.
Los codificadores UTF-16 y UTF-32 pueden utilizar el orden de bytes big endian (primero el byte más significativo) o el orden de bytes little endian (primero el byte menos significativo). Por ejemplo, la letra mayúscula latina A (U+0041) se serializa del siguiente modo (en hexadecimal):
El orden de bytes big endian de UTF-16: 00 41
El orden de bytes little endian de UTF-16: 41 00
El orden de bytes big endian de UTF-32: 00 00 00 41
El orden de bytes little endian de UTF-32: 41 00 00 00
Generalmente es más eficaz almacenar caracteres Unicode utilizando el orden de bytes nativo. Por ejemplo, es mejor usar el orden de bytes little-endian en plataformas little-endian, como los equipos Intel.
El método GetPreamble recupera una matriz de bytes que contiene la marca de orden de bytes (BOM). Si esta matriz se antepone a una secuencia codificada, ayuda al descodificador a identificar el formato de codificación utilizado.
Para obtener más información sobre el orden de bytes y la marca de orden de bytes, vea The Unicode Standard en Unicode home page
Observe que las clases de codificación permiten errores que:
Cambian a un carácter "?" sin notificación.
Usan un carácter de "ajuste perfecto".
Cambian a un comportamiento específico de la aplicación a través del uso de las clases EncoderFallback y DecoderFallback con el carácter de reemplazo Unicode U+FFFD.
Se recomienda que se produzcan excepciones en todos los errores de la secuencia de datos en las aplicaciones. Una aplicación usa un marcador "throwonerror" cuando corresponda o usa las clases EncoderExceptionFallback y DecoderExceptionFallback. A menudo no se recomienda el retroceso de ajuste perfecto porque puede producir pérdida de datos o confusión y es más lento que los simples reemplazos de caracteres. Para las codificaciones ANSI, el mejor comportamiento de ajuste perfecto es el predeterminado.