codificar acentos c# .net string utf-8 utf-16

codificar - encoding utf 8 acentos c#



¿Por qué.net usa la codificación UTF16 para cadena, pero usa utf8 como predeterminado para guardar archivos? (3)

Al igual que con muchas preguntas "por qué fue esto elegido", esto fue determinado por la historia. Windows se convirtió en un sistema operativo Unicode en su núcleo en 1993. En aquel entonces, Unicode aún tenía un espacio de código de 65535 puntos de código, en la actualidad llamado UCS. No fue hasta 1996 cuando Unicode adquirió los planos complementarios para extender el espacio de codificación a un millón de puntos de código. Y sustituye a los pares para que quepan en una codificación de 16 bits, estableciendo así el estándar utf-16.

Las cadenas .NET son utf-16 porque es una excelente opción con la codificación del sistema operativo, no se requiere conversión.

La historia de utf-8 es más oscura. Definitivamente pasado Windows NT, RFC-3629 data de noviembre de 1993. Me tomó un tiempo ganar un espacio, Internet fue instrumental.

De aquí

Básicamente, la cadena usa la forma de codificación de caracteres UTF-16

Pero al guardar contra StreamWriter :

Este constructor crea un StreamWriter con codificación UTF-8 sin una marca de orden por bytes (BOM),

He visto esta muestra (se eliminó el enlace roto):

Y parece que utf8 es más pequeño para algunas cadenas, mientras que utf-16 es más pequeño en algunas otras cadenas.

  • Entonces, ¿Por qué .net usa utf16 como codificación predeterminada para cadena mientras utf8 para guardar el archivo?

Gracias.

ps ya he leído el famoso artículo


UTF-8 es el predeterminado para el almacenamiento y la transferencia de texto porque es una forma relativamente compacta para la mayoría de los idiomas (algunos idiomas son más compactos en UTF-16 que en UTF-8). Cada lenguaje específico tiene una codificación más eficiente.

UTF-16 se utiliza para cadenas en memoria porque es más rápido por carácter para analizar y correlacionar directamente con la clase de caracteres Unicode y otras tablas. Todas las funciones de cadena en Windows usan UTF-16 y tienen desde hace años.


Si está contento ignorando los pares suplentes (o de manera equivalente, la posibilidad de que su aplicación necesite caracteres fuera del plano multilingüe básico), UTF-16 tiene algunas propiedades agradables, básicamente debido a que siempre requiere dos bytes por unidad de código y representa todos los caracteres BMP una sola unidad de código cada uno.

Considere el tipo primitivo de char . Si utilizamos UTF-8 como la representación en memoria y queremos hacer frente a todos los caracteres Unicode, ¿qué tan grande debería ser? Podría ser de hasta 4 bytes ... lo que significa que siempre tendremos que asignar 4 bytes. En ese momento, ¡podríamos usar UTF-32!

Por supuesto, podríamos usar UTF-32 como la representación de char , pero UTF-8 en la representación de string , convirtiendo sobre la marcha.

Las dos desventajas de UTF-16 son:

  • El número de unidades de código por carácter Unicode es variable, porque no todos los caracteres están en el BMP. Hasta que emoji se hizo popular, esto no afectó a muchas aplicaciones en el uso diario. Hoy en día, sin duda para las aplicaciones de mensajería y similares, los desarrolladores que usan UTF-16 realmente necesitan saber sobre los pares de sustitución.
  • Para ASCII simple (que es mucho texto, al menos en el oeste) ocupa el doble del espacio del texto codificado UTF-8 equivalente.

(Como nota al margen, creo que Windows usa UTF-16 para datos Unicode, y tiene sentido que .NET haga lo mismo por razones de interoperabilidad. Sin embargo, eso solo lleva la pregunta a un paso).

Dados los problemas de los pares de sustitución, sospecho que si un lenguaje / plataforma fuera diseñado desde cero sin requisitos de interoperabilidad (pero basando su manejo de texto en Unicode), UTF-16 no sería la mejor opción. Ya sea UTF-8 (si quieres eficiencia de memoria y no te importa alguna complejidad de procesamiento en términos de llegar al enésimo personaje) o UTF-32 (al revés) sería una mejor opción. (Incluso llegar al carácter n. ° tiene "problemas" debido a cosas como diferentes formas de normalización. El texto es difícil ...)