Transición a Unicode para una aplicación que maneja archivos de texto

Question

La aplicación My Win32 Delphi analiza archivos de texto producidos por otras aplicaciones que no son compatibles con Unicode. Por lo tanto, mis aplicaciones necesitan leer y escribir cadenas ansi, pero me gustaría proporcionar una experiencia de usuario mejor localizada mediante el uso de Unicode en la GUI. La aplicación realiza un análisis bastante pesado carácter por carácter de la secuencia en objetos descendientes de TList.

Al hacer la transición a una interfaz gráfica de usuario Unicode al pasar de 2.006 a Delphi Delphi 2009, debería planificar a:

1. ir completamente Unicode dentro de mi aplicación, con la excepción del archivo de E/S AnsiString?
2. encapsula el código que maneja los ansistrings (es decir, continúa manejándolos como ansistrings internamente) desde una aplicación Unicode.

Me doy cuenta de que una respuesta realmente detallada requeriría una cantidad sustancial de mi código; solo estoy preguntando por las impresiones de quienes hicieron esta transición y que todavía tienen que trabajar con archivos de texto sin formato. ¿Dónde colocar la barrera entre ansistrings y Unicode?

EDITAR: si es # 1, ¿alguna sugerencia para correlacionar cadenas Unicode para salida ansistring? Supongo que la conversión de las cadenas de entrada será automática usando tstringlist.loadfromfile (por ejemplo).

Answer 1

No existe la salida AnsiString, cada archivo de texto tiene character encoding. En el momento en que sus archivos contienen caracteres fuera del rango ASCII, debe pensar en la codificación, ya que incluso cargar esos archivos en diferentes países producirá resultados diferentes, a menos que utilice una codificación Unicode.

Si carga un archivo de texto, necesita saber qué codificación tiene. Para formatos como xml o html, esa información es parte del texto, para Unicode existe el BOM, aunque no es estrictamente necesario para los archivos codificados UTF-8.

Convertir una aplicación a Delphi 2009 es una oportunidad para pensar sobre la codificación de archivos de texto y corregir errores del pasado. Los archivos de datos de una aplicación a menudo tienen una vida útil más larga que las aplicaciones en sí, por lo que vale la pena pensar cómo hacer que sean a prueba del futuro y universales. Sugeriría ir a UTF-8 como la codificación del archivo de texto para todas las aplicaciones nuevas, de esa manera es fácil trasladar una aplicación a diferentes plataformas. UTF-8 es la mejor codificación para el intercambio de datos, y para los caracteres en el rango ASCII o ISO8859-1 también crea archivos mucho más pequeños que UTF-16 o UTF-32.

Si sus archivos de datos solo contienen caracteres ASCII, está todo listo, ya que también son archivos válidos codificados en UTF-8. Si sus archivos de datos están en codificación ISO8859-1 (o cualquier otra codificación fija), utilice la conversión correspondiente al cargarlos en listas de cadenas y guardarlos de nuevo. Si no sabe de antemano qué codificación tendrán, pregunte al usuario al momento de la carga, o proporcione una configuración de la aplicación para la codificación predeterminada.

Use cadenas Unicode internamente. Dependiendo de la cantidad de datos que necesite manejar, puede usar cadenas codificadas en UTF-8.

Answer 2

Sugiero ir completo a Unicode si merece la pena el esfuerzo y el requisito. Y manteniendo la E/S de archivo ANSI separada del resto. Pero esto depende en gran medida de su aplicación.

Answer 3

Usted dice:

"La aplicación hace algunos bastante pesada análisis del carácter por carácter de la cadena en objetos descendiente de TList."

Dado que Windows se ejecuta de forma nativa Unicode, es posible que su análisis del carácter corre más rápido si se carga el archivo de texto como Unicode internamente.

Por otro lado, si se trata de un archivo grande, también encontrará que se necesita el doble de memoria.

Para más información sobre esto, ver el artículo de Jan Goyvaert: "Speed Benefits of Using the Native Win32 String Type"

Por lo tanto, es un compromiso que tiene que decidir.

Answer 4

Si va a tomar la entrada Unicode desde la GUI, ¿cuál será la estrategia para convertirla en salida ASCII? (Esto es una suposición cuando mencionas la escritura de texto de Ansi, supuestamente para estas aplicaciones no basadas en Unicode que no vas a reescribir y supuestamente no tiene el código fuente). Sugiero que te quedes con AnsiString en toda la aplicación hasta que estas otras aplicaciones estén habilitadas para Unicode. Si su trabajo principal de su aplicación es analizar archivos tipo ASCII no Unicode, ¿por qué cambiar a Unicode internamente? Si el trabajo principal de su aplicación implica tener una mejor GUI habilitada para Unicode, entonces vaya a Unicode. No creo que haya suficiente información para decidir una elección adecuada.

Si no existe la posibilidad de que los caracteres no traducibles fácilmente se vuelvan a escribir para estas aplicaciones que no son Unicode, entonces la sugerencia de UTF-8 es la mejor opción. Sin embargo, si hay una posibilidad, ¿cómo van a manejar las aplicaciones que no son Unicode caracteres multi-byte? ¿Cómo vas a convertir (supuestamente) el juego de caracteres ASCII básico?