Jump to content


Photo

Archivos fuente en UTF8, es mejor que ANSI


  • Please log in to reply
5 replies to this topic

#1 jacapu

jacapu

    Advanced Member

  • Miembros
  • PipPipPip
  • 56 posts

Posted 17 May 2022 - 02:56 PM

Hola, estoy actualizando una aplicación escrita en D7 a DBerlín y al hacer un "Sintax check" me salen muchas alertas del tipo:

 

[dcc32 Warning] altaassss1.pas(298): W1058 Implicit string cast with potential data loss from 'string' to 'AnsiString'

 

y un error al final:

 

[dcc32 Fatal Error] F2438 UCS-4 text encoding not supported.  Convert to UCS-2 or UTF-8

Failed
 
Sin embargo, si compilo el proyecto y lo ejecuto corre perfectamente.
 
Es mejor guardar todos los archivos fuente con formato UTF8, o esto creará más problemas?
 
Gracias por vuestro tiempo.
Saludos.

  • 0

#2 jacapu

jacapu

    Advanced Member

  • Miembros
  • PipPipPip
  • 56 posts

Posted 28 May 2022 - 05:03 PM

Formulo la pregunta de un modo distinto:

 

Para la lengua española, con acentos  y demás, ¿ es mejor guardar los archivos fuente en UTF8 ?

 

Gracias y saludos.


  • 0

#3 escafandra

escafandra

    Advanced Member

  • Administrador
  • 4111 posts
  • LocationMadrid - España

Posted 29 May 2022 - 04:56 AM

Es menos relevante el código fuente que el ejecutable compilado siempre que el texto presentado sea fiel.
El UNICODE presenta muchos problemas de compatibilidad de tipos y manejo del texto.

Desde el momento que un mismo carácter ANSI puede ser representado como uno o dos bytes diferentes, es decir "á" puede representarse también como "a"+"'", ya tenemos el lío a la hora de que nuestro compilador lo codifique correctamente. De hecho Lazarus no lo compatibiliza cualquier UTF8 (Old LCL Unicode Support).

Sobre los tipos char y wchar, en delphi son considerados de forma incoherente. Un char en delphi 7 es de tamaño 1 byte mientras que en Berlín es 2 bytes, siendo equivalente a WCHAR. En la práctica no se respetan los tipos. En C no ocurre esto, con lo que no se rompe la compatibilidad y el tipado es más fuerte.

Todo ello genera problemas de compatibilidad, sobre todo hacia atrás, y mucha confusión.

De esta forma y a día de hoy, prefiero tener mi código fuente como Ansi, no usar el Unicode si puedo y vigilar que el resultado compilado muestra los caracteres esperados del código fuente, usando las conversiones pertinentes si fuese necesario.

Saludos.


  • 0

#4 jacapu

jacapu

    Advanced Member

  • Miembros
  • PipPipPip
  • 56 posts

Posted 30 May 2022 - 05:57 PM

Entonces, si no he entendido mal, (por favor, corrígeme si estoy equivocado):

- Al llamar o asignar directorios, o escribir y recibir cadenas, (para MessageBox, GetDir, ShellExecute, etc .....), resumiendo: manejando strings, hay que usar las funciones especificas para UTF8.

De ahí los errores de síntaxis que manifiesta DBerlin, pero permite correr el programa.

Saludos.


  • 0

#5 jacapu

jacapu

    Advanced Member

  • Miembros
  • PipPipPip
  • 56 posts

Posted 16 August 2022 - 02:37 PM

He indagado en el tema y según el Sr. Mario Cantú se puede seguir usando el formato que se desee siempre y cuando no se usen puntos de código mayores del 255.

He creado una copia del directorio del programa y con CnPak he visto que tenía archivos "dfm" en binario y otros en texto.

Abriéndolos con Notepad++ y seleccionando la opción de mostrar todos los caracteres se apreciaba que los que estaban en binario tenían caracteres que no están en la tabla que llega hasta el 255.

Entonces mediante CnPack he convertido todos los archivos "dfm" a texto y he comprobado que no haya caracteres mayores del 255.

Tambien he borrado los archivos "dcu".

He vuelto a compilar el programa y sigue saliendo el mismo error.

Mi pregunta es:

¿No se ha corrompido el programa, (archivos res, dpr, etc.? 

Gracias por vuestro tiempo.

Saludos. 


  • 0

#6 escafandra

escafandra

    Advanced Member

  • Administrador
  • 4111 posts
  • LocationMadrid - España

Posted 16 August 2022 - 03:32 PM

Editar de esa manera los archivos del proyecto, no es una buena idea y puede terminar corrupto.

 

 

Saludos.

 


  • 0




IP.Board spam blocked by CleanTalk.