Email Body: Caracteres Especiales

Si necesita usar letras acentuadas o símbolos matemáticos en sus mensajes, o si se pregunta si hay una manera de insertar un “símbolo del euro”, u observa que el mensaje de otra persona contiene basura donde debería estar el carácter especial, este artículo lo ayudará entender los problemas involucrados.

Nota: Algunas personas están terminando en esta página cuando buscan: The message contains Unicode characters and has been sent as a binary attachment. Probablemente recibieron un mensaje de correo electrónico con este texto. Es un virus; no abras el archivo adjunto Los mensajes Unicode reales (que se explican a continuación) no necesitan archivos adjuntos binarios.

Caracteres Especiales de tu Computadora

Las computadoras son dispositivos muy potentes. Sin embargo, tienen una limitación muy importante: lo único que realmente pueden manejar son los números. Cualquier otra cosa (palabras, imágenes, sonidos, videoclips) debe convertirse en una secuencia de números para que una computadora pueda manejarlo. Ese es el trabajo de los estándares de formato de datos, para garantizar que las diferentes computadoras y programas estén de acuerdo entre sí sobre qué datos se representan con un grupo particular de números. En esta era de software de “apuntar y hacer clic”, los usuarios se han acostumbrado a poder arrastrar, soltar, cortar, pegar, cargar y descargar cualquier tipo de multimedia. Raramente se detienen a pensar en lo que sucede realmente “debajo del capó” de su computadora, excepto cuando algo sale mal y un archivo de datos sale como una masa de basura en la pantalla de la computadora;

Este artículo se refiere a cómo una computadora almacena y transmite texto. (Otros tipos de datos se discuten en la pagina de archivos adjuntos) El texto es uno de los primeros tipos de datos que las personas querían almacenar en las computadoras, por lo que los desarrolladores han estado ideando esquemas para representar el texto como números durante el último medio siglo. Después de que los fabricantes de computadoras idearon unos pocos sistemas de codificación patentados, la conveniencia de un estándar universal de codificación de caracteres para ser utilizado de forma sistemática por todos llevó a la elaboración del ASCII (Código Estándar Estadounidense para el Intercambio de Información) a principios de los años sesenta. Durante un tiempo, ASCII libró una batalla estilo “VHS vs. Beta” con otras codificaciones de personajes contendientes como EBCDIC y Baudot, pero al final ganó. (Sin embargo, al igual que los formatos de video basados ​​en Beta aún se encuentran en usos profesionales especializados, las otras codificaciones de caracteres todavía tienen sus nichos; hay mainframes de IBM que usan EBCDIC, y dispositivos de telecomunicaciones para sordos usando Baudot. Cualquiera que necesite transferir datos de estos a cualquier otra cosa, sin embargo, necesita convertirlo a ASCII.) Después de algunas revisiones en los últimos años, una forma de ASCII conocida como US-ASCII es ahora el conjunto de caracteres de “denominador común” que es entendido por prácticamente todos los sistemas informáticos ahora en uso.

En el juego de caracteres ASCII, cada letra, número y signo de puntuación en una pieza de texto está representado por un número del 0 al 127. (En el código binario utilizado por las computadoras, esto requiere 7 bits , o dígitos binarios, para almacenar. ) Por ejemplo, una letra mayúscula A está representada por el número 65. Puede ver la importancia de los estándares de conjunto de caracteres coherentes; si otra computadora usaba una codificación de caracteres que representaba la letra Z con el número 65, entonces cualquiera que intente leer un documento transferido a esta computadora desde uno que use ASCII vería una Z en todas partes, una A era la intención del autor. Aristóteles y Ayn Rand hacen un gran trato acerca de cómo “A es A”, pero si tus juegos de caracteres no coinciden, ¡A podría ser Z!

Si bien hay 128 caracteres en el conjunto ASCII, algunos de ellos son caracteres de control como pestañas y avances de línea (y cosas más exóticas como el Separador de unidades y el Control de dispositivos 2, que rara vez se usan en estos días). Los caracteres regulares incluyen el alfabeto de 26 letras en mayúscula y minúscula, los 10 dígitos y varios signos de puntuación comunes como puntos y puntos y comas. El texto normal en inglés se puede escribir muy bien en ASCII “simple” (aunque solo se deben usar comillas y apóstrofes “rectos”, no el tipo de letra cursiva, que analizaré más adelante).

Afortunadamente, ASCII fue adoptado de manera suficientemente universal como para que pueda estar casi seguro de que cualquier cosa que se escriba con los caracteres de este conjunto (que no sean los caracteres de control) aparecerá de la misma forma en que se escribió, independientemente de los sistemas y programas se envía a través. Para los usuarios de correo electrónico (sí, lo hice intención de quedar atrás en-tema para este sitio con el tiempo!), Esto significa que los caracteres ASCII son los personajes muy segura de usar. Si su mensaje consiste completamente de letras, números y signos de puntuación en el conjunto ASCII, no tendrá ningún problema con su legibilidad. (De hecho, incluso es legal según los estándares de formato de correo electrónico)para incluir los caracteres de control en un mensaje, con la condición especial de que el carro retorna y los avances de línea solo pueden ocurrir juntos para compensar un salto de línea, no por separado. Sin embargo, aparte de los saltos de línea y las pestañas, no tiene sentido incluir caracteres de control en el correo electrónico, y no hay una interpretación consistente de los programas que los reciben. El avance de página carácter, # 12, sin embargo, tiene algo de uso tradicional en grupos de noticias para marcar “spoilers” en las discusiones sobre libros, películas, y similares; algunos lectores de noticias hacen una pausa para presionar una tecla antes de continuar desde ese punto, o de lo contrario oscurecen lo que sigue al personaje hasta que esté listo para verlo. Sin embargo, esta característica es menos común en el correo actual o en los lectores de noticias).

Una cosa a tener en cuenta sobre los personajes de control es que hay alguna divergencia de plataforma en cómo se representa un salto de línea; según los estándares tradicionales, los dos caracteres CR (# 13) y LF (# 10) van juntos para terminar una línea. Los sistemas Windows lo hacen de esta manera (¡así que Microsoft sigue los estándares tradicionales aquí para variar!), Mientras que Unix, Linux y sistemas similares usan solo el carácter LF, y MacOS tradicionalmente solo usaba el carácter CR. (Sin embargo, las versiones recientes de MacOS están basadas en Unix y han cambiado al uso del carácter LF.) Esto a veces puede causar molestias cuando se transfieren archivos de texto entre sistemas, pero no he notado ningún problema con el correo electrónico; o bien todos los clientes de correo y los servidores siguen los estándares correctamente en la codificación de los saltos de línea, independientemente de la plataforma, o ‘

Las pestañas (n. ° 9) también pueden ser problemáticas, ya que los programas pueden diferir en la cantidad de espacios que hacen entre tabulaciones.

Más Allá de ASCII

El resto del mundo no todos hablan inglés, y allí es donde ASCII se vuelve problemático. No tiene que ser un fanático de la PC de izquierdas para encontrar que existe un sesgo cultural en dar a las computadoras un conjunto de caracteres “estándar” que representa muy bien el inglés, pero omite las letras con acentos, diéresis y otras marcas diacríticas, utilizadas en muchos otros idiomas También faltan otros alfabetos como el griego y el cirílico, símbolos monetarios distintos del signo de dólar y símbolos especializados necesarios para aplicaciones avanzadas, como las matemáticas superiores. Para que las computadoras se puedan usar en todo el mundo, es necesario ir más allá de ASCII.

Dado que el byte estándar (unidad de almacenamiento de datos) en las computadoras personales es de 8 bits, y ASCII usa solo 7 bits, lo más obvio era poner en uso el octavo bit, duplicando el número de caracteres que podrían representarse. Esto podría ser un problema con un software anterior que usó el octavo bit como indicador de suma de comprobación o indicador de modo, pero finalmente se convirtió en algo común para las computadoras usar los ocho bits para el almacenamiento de caracteres. Desafortunadamente, tomó un tiempo para que surgiera un estándar con respecto a quélos personajes estaban en esas otras 128 posiciones (que representan números del 128 al 255). Diferentes plataformas usaban diferentes combinaciones de letras acentuadas, símbolos, caracteres de dibujo de cajas y otras cosas. El modo de texto de IBM PC tenía un juego, el Macintosh usaba otro, y cuando apareció Windows, tenía un conjunto diferente. Las versiones de sistemas informáticos destinados a los mercados de diferentes países también variarían, de modo que se admitirían los caracteres particulares necesarios para el idioma local. Esta no era una situación muy buena para el intercambio de datos entre diferentes sistemas.

Afortunadamente, la Organización Internacional de Normalización (que es, por alguna razón, abreviada ISO en lugar de IOS; de hecho, según su sitio, en realidad no pretende representar sus iniciales reales, para no ofender a las diversas nacionalidades que abreviarían). de manera diferente en diferentes idiomas; en la actualidad, los tipos de mercadotecnia parecen gustar de iniciales y acrónimos que no representan nada, de todos modos) salió con un grupo de juegos de caracteres estándar. No podían simplemente salir con unoconjunto de caracteres unificados, porque los diferentes idiomas del mundo tenían más caracteres entre ellos de los que cabían en un solo grupo de 8 bits de caracteres. En cambio, salieron con varios juegos de caracteres (designados como la serie ISO 8859) diseñados para diferentes grupos de idiomas. El más usado es el ISO-8859-1, también conocido como “Latin-1”, que contiene caracteres útiles para los idiomas de Europa occidental. Este conjunto de caracteres (o, más propiamente, “codificación de caracteres”; los puristas señalarán que el “conjunto”, o “repertorio”, es el grupo de caracteres disponibles, pero la “codificación” especifica qué números corresponden a qué caracteres) en realidad lo mismo que la codificación patentada “Windows-1252”, con la excepción de que el grupo de caracteres en las posiciones # 128 a la # 159, donde Windows pone algunos caracteres como el signo de marca registrada (™) y las comillas “rizadas”, están reservados para caracteres de control en ISO-8859-1. Otro estándar ISO, ISO 6429, en realidad da nombres geeky y abreviaturas para estos caracteres de control, como “Reverse Line Feed” y “Reverse Line Feed”.

Los caracteres de control “XXX”, dicho sea de paso, no son utilizados por la industria del porno; simplemente no están definidos por el estándar. De todos modos, dado que ISO-8859-1 es solo una de varias codificaciones de caracteres específicas del idioma, es necesario que cualquier protocolo que envíe y reciba texto tenga alguna manera de indicar qué codificación se está utilizando. Una posibilidad es declarar por decreto que una codificación es el estándar; ISO-8859-1 (Latin-1) es el estándar de facto actualmente en la mayoría de los casos en que nada indica lo contrario; los caracteres de este conjunto son, junto a los de US-ASCII, los “más seguros” para usar en el texto, ya que la mayoría de los sistemas informáticos pueden comprenderlos. Sin embargo, esto deja fuera los otros lenguajes representados por diferentes codificaciones. Afortunadamente, la mayoría de los protocolos, incluidos los de la Web y el correo electrónico, proporcionar la indicación explícita de una codificación de caracteres. Para el correo electrónico, se hace enContent-Typeencabezado con la adición de un charsetparámetro. Por lo tanto, para indicar un mensaje de texto sin formato en la codificación ISO-8859-1, esto aparece en los encabezados:

Content-Type: text/plain; charset=iso-8859-1

Quoted Printable

Solo hay un problema más; los estándares de formato de correo (RFC 2822) no permiten el uso de caracteres fuera del rango ASCII de 7 bits. La razón de esto es que los caracteres de 8 bits pueden tener efectos impredecibles en los programas y las redes que no se utilizan. Esta es probablemente una preocupación académica más abstracta hoy en día, pero en un pasado no muy lejano se transfería mucho correo electrónico a través de redes que utilizaban el octavo bit como bandera o suma de comprobación. Para evitar causar problemas en tales situaciones, los sistemas de codificación imprimible y base64 entre comillas se diseñaron para permitir que cualquier tipo de datos se envíe puramente en caracteres ASCII seguros. Base64 está diseñado para transmitir datos binarios, y se discutirá más en los archivos adjuntosartículo. (Algunos spammers nocodifican el texto del cuerpo principal de la base 64 como una técnica de ocultación!) Citado imprimible está diseñado para los mensajes de texto sin formato que podrían contener algunos caracteres no ASCII. Las partes del mensaje que están compuestas de caracteres imprimibles ASCII normales se mantienen sin cambios, mientras que los caracteres “especiales” (incluyendo caracteres de control y cualquier elemento por encima del carácter # 127) se codifican como secuencias que constan de un signo igual (=) seguido de dos hexadecimales (base 16) dígitos (estos consisten en los dígitos 0 a 9 y las letras A a F). El uso del signo igual como carácter especial significa que también debe estar codificado (como ” =3D”). Algunas reglas más se utilizan para tratar con saltos de línea y espacios en blanco.

Si el programa de correo receptor entiende la codificación imprimible entre comillas (como casi todos lo hacen en estos días), esta codificación se deshace en el extremo receptor, por lo que los caracteres salen de la misma forma en que entraron. Si el destinatario no comprende esta codificación (o está viendo el mensaje en formato de código fuente sin procesar), el mensaje se verá principalmente como texto ordinario y legible, pero tendrá algunas rarezas como signos iguales y dígitos hexadecimales intercalados en él, y también puede tener saltos de línea impares (se puede imprimir con comillas) la codificación agrega saltos de línea para traer las longitudes de línea dentro de las especificaciones, pero esta se deshace en el extremo receptor cuando el último carácter de cada línea es un signo = para indicar que se trata de un “salto de línea suave”).

Esta línea de encabezado se agrega para indicar que la codificación imprimible entre comillas está en uso:

Content-Transfer-Encoding: quoted-printable

Adelante a Unicode

La estandarización del conjunto de codificaciones de caracteres ISO ayudó a poner orden en el caos de los conjuntos de caracteres específicos del proveedor, pero algunas personas todavía tenían el sueño de crear un juego de caracteres único y unificado que abarcara los caracteres necesarios para todos los idiomas. Esto obviamente tomaría más de 8 bits para representar; Solo chino, tiene más personajes de los que caben en un conjunto de 256 caracteres. Entonces, cuando el estándar de caracteres que se conocería como Unicodeprimero tomó forma, era una codificación de 16 bits, tomando dos bytes por carácter (el doble que las codificaciones de 8 bits), y capaz de representar 65.536 caracteres diferentes. (Como veremos más adelante, en última instancia, lo expandieron a un rango incluso más amplio). Estos caracteres tienen números (o “posiciones de código”) que van de 0 a 65.535, pero con mayor frecuencia se presentan en hexadecimal como 0000 a FFFF. ISO-8859-1 (Latin-1) es un subconjunto de Unicode, cuyas primeras 256 posiciones corresponden a este estándar anterior. Como esto a su vez incluye US-ASCII en sus primeras 128 posiciones, eso también está incluido dentro de Unicode. Las posiciones restantes, # 256 y más allá, incluyen todo, desde griego al hebreo, a chino, símbolos matemáticos, piezas de ajedrez … y también el símbolo del euro (€), importante para los europeos ahora para simbolizar su moneda unificada.

Como la mayoría del texto en línea está en inglés o en los idiomas de Europa occidental, donde la mayoría de los caracteres están en el conjunto US-ASCII, requerir dos bytes por carácter se consideró inútil, ya que duplica el tamaño de un documento de texto. Por lo tanto, se idearon algunas codificaciones más eficientes, siendo la más popular UTF-8. Esta codificación elimina el concepto de que todos los personajes toman la misma cantidad de bits y representa los caracteres como secuencias de longitud variable. En particular, los 128 caracteres US-ASCII están codificados como bytes únicos, idénticos a su representación en US-ASCII e ISO-8859-1, por lo que cualquier documento UTF-8 que consista en su totalidad de esos caracteres es indistinguible de un documento ASCII simple, que es bueno para la compatibilidad directa e inversa. Más allá de esto, varias combinaciones de bytes con su alto conjunto de bits se utilizan para representar otros caracteres Unicode. En particular, se debe tener en cuenta que los caracteres Latin-1 de # 128 a # 255 no se pueden incluir como bytes únicos “en bruto” en UTF-8, ya que estos bytes se usan como parte de secuencias de múltiples bytes; esos caracteres deben estar codificados como más de un byte, a diferencia de los caracteres US-ASCII. Esto a veces puede causar un problema cuando los caracteres Latin-1 se pegan en un documento UTF-8 y el software involucrado no realiza la conversión adecuada. Sin embargo, a medida que los creadores de software adquieren mayor conciencia global (a medida que el mercado de las computadoras se extiende a países donde los caracteres no ASCII son esenciales), cada vez es más común que el software maneje adecuadamente todo tipo de caracteres sin que los usuarios tengan que pensar demasiado al respecto. … ¡excepto en las ocasiones en que algo se arruina! se debe tener en cuenta que los caracteres latinos 1 de # 128 a # 255 no se pueden incluir como bytes únicos “crudos” en UTF-8, ya que estos bytes se usan como parte de secuencias de múltiples bytes; esos caracteres deben estar codificados como más de un byte, a diferencia de los caracteres US-ASCII. Esto a veces puede causar un problema cuando los caracteres Latin-1 se pegan en un documento UTF-8 y el software involucrado no realiza la conversión adecuada. Sin embargo, a medida que los creadores de software adquieren mayor conciencia global (a medida que el mercado de las computadoras se extiende a países donde los caracteres no ASCII son esenciales), cada vez es más común que el software maneje adecuadamente todo tipo de caracteres sin que los usuarios tengan que pensar demasiado al respecto. … ¡excepto en las ocasiones en que algo se arruina! se debe tener en cuenta que los caracteres latinos 1 de # 128 a # 255 no se pueden incluir como bytes únicos “crudos” en UTF-8, ya que estos bytes se usan como parte de secuencias de múltiples bytes; esos caracteres deben estar codificados como más de un byte, a diferencia de los caracteres US-ASCII. Esto a veces puede causar un problema cuando los caracteres Latin-1 se pegan en un documento UTF-8 y el software involucrado no realiza la conversión adecuada. Sin embargo, a medida que los creadores de software adquieren mayor conciencia global (a medida que el mercado de las computadoras se extiende a países donde los caracteres no ASCII son esenciales), cada vez es más común que el software maneje adecuadamente todo tipo de caracteres sin que los usuarios tengan que pensar demasiado al respecto. … ¡excepto en las ocasiones en que algo se arruina! ya que estos bytes se usan como parte de secuencias de múltiples bytes; esos caracteres deben estar codificados como más de un byte, a diferencia de los caracteres US-ASCII. Esto a veces puede causar un problema cuando los caracteres Latin-1 se pegan en un documento UTF-8 y el software involucrado no realiza la conversión adecuada. Sin embargo, a medida que los creadores de software adquieren mayor conciencia global (a medida que el mercado de las computadoras se extiende a países donde los caracteres no ASCII son esenciales), cada vez es más común que el software maneje adecuadamente todo tipo de caracteres sin que los usuarios tengan que pensar demasiado al respecto. … ¡excepto en las ocasiones en que algo se arruina! ya que estos bytes se usan como parte de secuencias de múltiples bytes; esos caracteres deben estar codificados como más de un byte, a diferencia de los caracteres US-ASCII. Esto a veces puede causar un problema cuando los caracteres Latin-1 se pegan en un documento UTF-8 y el software involucrado no realiza la conversión adecuada. Sin embargo, a medida que los creadores de software adquieren mayor conciencia global (a medida que el mercado de las computadoras se extiende a países donde los caracteres no ASCII son esenciales), cada vez es más común que el software maneje adecuadamente todo tipo de caracteres sin que los usuarios tengan que pensar demasiado al respecto. … ¡excepto en las ocasiones en que algo se arruina! Esto a veces puede causar un problema cuando los caracteres Latin-1 se pegan en un documento UTF-8 y el software involucrado no realiza la conversión adecuada. Sin embargo, a medida que los creadores de software adquieren mayor conciencia global (a medida que el mercado de las computadoras se extiende a países donde los caracteres no ASCII son esenciales), cada vez es más común que el software maneje adecuadamente todo tipo de caracteres sin que los usuarios tengan que pensar demasiado al respecto. … ¡excepto en las ocasiones en que algo se arruina! Esto a veces puede causar un problema cuando los caracteres Latin-1 se pegan en un documento UTF-8 y el software involucrado no realiza la conversión adecuada. Sin embargo, a medida que los creadores de software adquieren mayor conciencia global (a medida que el mercado de las computadoras se extiende a países donde los caracteres no ASCII son esenciales), cada vez es más común que el software maneje adecuadamente todo tipo de caracteres sin que los usuarios tengan que pensar demasiado al respecto. … ¡excepto en las ocasiones en que algo se arruina!

Una vez que se estableció el UTF-8 (y se usa mucho más comúnmente que la codificación sin formato de 16 bits), el propio Unicode omitió el concepto de que todos sus caracteres contenían el mismo número de bits y revisó su estándar para permitir asignar más caracteres en posiciones incluso más alto que # 65535. Estos caracteres toman hasta seis bytes para codificar en UTF-8, pero permiten la adición de caracteres demasiado oscuros para hacerlo antes. (Hasta ahora, sin embargo, los esfuerzos para que Klingon se agregue al conjunto Unicode han sido rechazados, sin embargo, han considerado apropiado agregar caracteres útiles como “Pila de Poo”, en el código hexadecimal U + 1F4A9.) El conjunto de caracteres Unicode tiene también ha sido adoptado como estándar por ISO, que lo ha designado como ISO 10646.

La codificación UTF-8 es muy eficiente para documentos que contienen principalmente caracteres ASCII con solo algunos otros. También es la mejor manera de codificar un documento que contiene texto de varios idiomas, donde la mayoría de las codificaciones no podrían representar todos los caracteres necesarios a la vez. Sin embargo, si algo está escrito completamente en un único idioma compuesto por caracteres que no son ASCII, una codificación diferente, específica para el juego de caracteres de ese idioma, es más eficiente. Por lo tanto, UTF-8 nunca desplazará a todas las demás codificaciones; sin embargo, el estándar Unicode subyacente es el “terreno común” mediante el cual los caracteres en todas las codificaciones se pueden comparar y convertir, una “lingua franca” para conjuntos de caracteres.

Un documento codificado en UTF-8 tiene esta línea de encabezado para indicar su codificación:

Content-Type: text/plain; charset=utf-8

En un mensaje de correo electrónico, se debe codificar con transferencia adicional como imprimible entre comillas , como se describió anteriormente, de modo que las secuencias de bytes que denotan caracteres no ASCII se representen en forma ASCII (dígito hexadecimal).

Curly Quotes, Em-Dashes, y signos de marca registrada

Anteriormente, mencioné que algunos caracteres del juego de caracteres de Windows, incluidas las comillas “rizadas” y el signo ™, no formaban parte de ISO-8859-1. A pesar de esto, a muchos programas (especialmente los de Microsoft) les gusta insertarlos en documentos y mensajes de correo electrónico. La característica de las denominadas “citas inteligentes”, que se encuentra en una serie de programas, hace que las comillas y los apóstrofos ASCII normales, “y”, se conviertan a la variedad “rizada”, “” ‘. Incluso si su correo electrónico programa no hace esto, aún podría introducir estos caracteres cuando pegue texto de otro lugar, como un procesador de textos o una página web. Los puristas tipográficos dicen que esto es más correcto, aunque los informáticos antiguos (y personas familiarizadas con las máquinas de escribir antes de eso) se usan para la variedad “directa” de citas. Hay varias formas en que se puede representar una “cita rizada”, y otros caracteres del grupo que están en el conjunto de Windows pero no en Latin-1, en un mensaje de correo electrónico, y van desde ser completamente incorrectos (según los estándares) hasta siendo correcto pero problemático (Incluso en las páginas web pueden ser problemáticos, si su navegador muestra signos de interrogación o código sin formato como‘ arriba, donde deberían ser las comillas tipográficas, eso significa que no admite estas entidades de caracteres).

  1. Algunos programas simplemente colocan estos caracteres en un documento o mensaje como caracteres de 8 bits, directamente de Windows. Si el encabezado del mensaje indica que está en us-ascii, iso-8859-1o utf-8, entonces esto es simplemente errónea. Dichos caracteres no están definidos en ASCII, son caracteres de control en ISO-8859-1 y forman parte de secuencias de múltiples bytes en UTF-8; no representan lo que Windows cree que hacen. Sin embargo, si el encabezado del mensaje indica que la codificación es windows-1252, entonces estos caracteres son técnicamente adecuados, aunque el uso de una codificación patentada específica de la plataforma no es una buena idea (los sistemas que no son de Windows pueden no saber qué hacer con ellos). Para el caso, algunos sistemas que no son de Windows (especialmente MacOS) a veces despliegan su“Comillas inteligentes” codificadas de forma propietaria, con caracteres que difieren de la variedad de Windows, en documentos y mensajes, de modo que un apóstrofo termina mirando al otro extremo como un número superíndice 1.
  2. A veces, estos caracteres se representan como referencias numéricas en sintaxis HTML (o SGML o XML). Esto no tiene sentido para un mensaje de texto sin formato (donde ninguna sintaxis de lenguaje de marcado tiene ningún negocio en uso), pero no siempre impide que los programas lo hagan de todos modos. En el correo electrónico HTML , tiene sentido al igual que en las páginas web. Sin embargo, las referencias numéricas utilizadas a veces son falsas como “, que corresponden a la posición del carácter deseado en la codificación de Windows. Las referencias de caracteres numéricos en HTML son siempre con respecto a las posiciones Unicode de los caracteres, y el carácter de control en el n. ° 147 en Unicode está en un rango específicamente no permitido en HTML. Los personajes en cuestión están en Unicode, sin embargo, en posiciones numeradas mucho más altas; así,“ es una referencia numérica válida para una cita rizada izquierda.
  3. Finalmente, si se utiliza la codificación UTF-8, estos caracteres se pueden incluir como secuencias de múltiples bytes bajo esta codificación. Esto cumple con los estándares y funciona tanto para texto simple como para correo electrónico HTML. Desafortunadamente, no todos los programas de correo electrónico son compatibles con UTF-8; esto es lo que podría parecer un intento de usar (tomado de una captura de pantalla real de un mensaje entrante como se muestra en un programa de correo):
    También se sabe que los caracteres UTF-8 se destruyen de manera similar cuando un mensaje que los contiene se cita, se reenvía, se copia y se pega, o se manipula; o cuando un conjunto de mensajes diferentes se juntan en un solo archivo de resumen o de archivo (que puede tener solo un encabezado “charset”; si esto es algo diferente a UTF-8, incluso los programas que normalmente comprenderían los caracteres codificados verían basura en lugar).

Debido a los problemas y problemas técnicos involucrados, es mejor apegarse a los caracteres “seguros” de US-ASCII, incluidas las “citas directas”, en lugar de tratar de ser “elegante” con las denominadas “citas inteligentes”. Si realmente necesita caracteres que no sean ASCII del repertorio Unicode, como en un mensaje multilingüe, siga adelante y use la codificación adecuada (y los usuarios con programas lectores no compatibles no tendrán suerte), pero si es solo un “frippery” “Al igual que las comillas, es mejor mantenerlo simple, estúpido. De todos modos, aparece un apóstrofo rizado codificado en UTF-8 y codificado por transferencia en imprimible entre comillas =E2=80=99, lo que lleva a la friolera de nueve bytes … un desperdicio de ancho de banda y espacio en disco, incluso si se muestra correctamente. La referencia HTML’toma siete bytes. Un apóstrofo ASCII normal (‘) toma un byte.

Las personas que intentan imitar citas rizadas a veces se han “apropiado” de otros caracteres ASCII y Latin-1, con resultados que considero más incómodos que solo usar citas directas. El acento grave (`), que está en ASCII, y el acento agudo (‘), que está en Latin-1, a veces se ponen en servicio como comillas simples o apóstrofes; sin embargo, no están destinados a ser ningún tipo de cita. Se apoyan tambiénlejos de verse bien como citas, y, además, algún software trata las claves para ellos como caracteres de combinación no espaciales utilizados para escribir letras acentuadas; el acento se combina con la letra escrita justo antes (¿o quizás después?). Por lo tanto, las personas que adquieren el hábito de usarlos como citas encuentran que a veces no funcionan bien. Los teclados de EE. UU. Tienen una clave solo para el acento grave, de todos modos, no el agudo (aunque los teclados en otros países a menudo tienen ambos). También he visto a personas usar un acento grave como un apóstrofo (¿cómo es eso?), Aunque se inclina completamente en la dirección incorrecta. Luego, existe lo que llamo “Unix Geek Quoting” (también es común en los servicios de noticias) que usa un acento grave como comilla simple inicial y una comilla simple normal para cerrarla, como “esto”. Esto fue alentado por versiones arcaicas del estándar ASCII, implementado en las fuentes de algunos sistemas informáticos antiguos, que requería el apóstrofo ASCII normal para “apoyarse”. Desde los años 80 al menos, el estándar ha exigido que el apóstrofo ASCII sea recto, y la mayoría de las fuentes actuales siguen esto, por lo que los dos lados de una cita hecha de esta manera no se acercan a la coincidencia. Las personas que usan este estilo de citas a menudo abren comillas dobles con dos acentos graves, lo que lo hace aún más “ fuera de sintonía ” al hacer coincidir la comilla doble de un solo carácter en el otro extremo. y la mayoría de las fuentes actuales siguen esto, por lo que los dos lados de una cita hecha de esta manera no se acercan a la coincidencia. Las personas que usan este estilo de citas a menudo abren comillas dobles con dos acentos graves, lo que lo hace aún más “ fuera de sintonía ” al hacer coincidir la comilla doble de un solo carácter en el otro extremo. y la mayoría de las fuentes actuales siguen esto, por lo que los dos lados de una cita hecha de esta manera no se acercan a la coincidencia. Las personas que usan este estilo de citas a menudo abren comillas dobles con dos acentos graves, lo que lo hace aún más “ fuera de sintonía ” al hacer coincidir la comilla doble de un solo carácter en el otro extremo.

Además de las comillas y el signo de la marca comercial, los personajes de Windows comúnmente utilizados y abusados ​​fuera de Latin-1 incluyen el “em dash” (-) y los puntos suspensivos (…). Los sustitutos “plain-ASCII” son dos guiones (-) y tres puntos (…) respectivamente.

ROT13

ROT13 no es realmente un conjunto de caracteres, pero es una forma de codificación que a veces puede encontrar, especialmente en grupos de noticias. No es parte de ningún estándar oficial documentado (hasta donde yo sé), y no tiene líneas de encabezado para indicar su presencia; más bien, normalmente está integrado en el medio de un mensaje de texto sin formato. De repente (con o sin una advertencia), tocas un fragmento de texto de galimatías, aunque está compuesto por letras normales (sin caracteres de control divertidos ni dígitos hexadecimales). Si está en un grupo de noticias geek o en una lista de correo, probablemente se encuentre con ROT13. Lo que es es un esquema trivial de “cifrado”, diseñado para no mantener un mensaje en secreto (ya que es fácil de decodificar una vez que sabes cómo), pero para proporcionar un menor grado de protección contra que se vea accidentalmente cuando no debería. Eso’

En la codificación ROT13, las 26 letras del alfabeto inglés estándar se desplazan 13 posiciones, con el alfabeto considerado para envolver de Z a A en un bucle sin fin. Todos los demás caracteres (números, signos de puntuación y letras acentuadas, por ejemplo) se dejan solos “tal cual”. (Esto probablemente hace que ROT13 sea inadecuado para ocultar texto en idiomas distintos del inglés que tienen una alta proporción de caracteres distintos del alfabeto ASCII.) Como 13 es exactamente la mitad de 26, la misma operación exacta sirve para codificar y decodificar un mensaje.

Tradicionalmente, los lectores de noticias basados ​​en Unix tienen una función de codificación / descodificación ROT13 incorporada que facilita la lectura de dichos mensajes codificados, o crea los suyos propios. Los programas de correo / noticias de Windows no siempre tienen esta función, pero existen sitios web que lo hacen por usted.

Enlaces

Siguiente : Es posible que haya visto emoticones o “emoticonos” en los mensajes. ¿Son buenos 🙂 o malos :-(?