Firebird 2.5 y UTF8

[guillotmarc]

Hola.

Empezado por Chandra_

Muchísimas gracias a los dos por despejar tan detalladamente mis dudas. Con gente así, da gusto preguntar

Gracias por la dirección, guillotmarc, me viene de perlas para futuras referencias.

Lo que no termino de tener del todo claro es las diferencias entre el estándar ISO 8859_1 y el Unicode. La Wikipedia, por ejemplo, define el ISO 8859-1 como "una norma de la ISO que define la codificación del alfabeto latino..." y el Unicode como "un estándar de codificación de caracteres diseñado para facilitar el tratamiento informático, transmisión y visualización de textos de múltiples lenguajes". A primera vista, parecen la misma cosa... no entiendo la diferencia y por qué unos ISOs son Unicode y otros no...

Todos los charsets sirven para codificar los alfabetos de un grupo de lenguas. Pero el iso8859_1 solo sirve para codificar el alfabeto de las lenguas de Europa Occidental, mientras que Unicode pretende poder codificar los alfabetos de todas las lenguas del mundo.

Como el iso8859_1 solo codifica un pequeño grupo de lenguas, puede guardar cada letra del alfabeto en un solo byte. En cambio Unicode tiene que codificar un montón de letras de distintos alfabetos, las letras más comunes A B C D ... las codifica en un solo byte, pero para codificar letras de alfabetos más complicados como el chino va a necesita bastantes más bytes para cada letra.

Esta es una de las grandes diferencias entre Unicode y los demás charsets (iso8859_1 y compañía) que Unicode tiene un tamaño de letra variable y los charsets tradicionales tienen un tamaño de letra fijo. Por eso a los lenguajes de programación, bases de datos, sistemas operativos, ... les resulta más complejo tener que lidiar con Unicode.

Empezado por Chandra_

Lo de los Collates es interesantísimo en las búsquedas para evitar diferencias entre mayúsculas/minúsculas y palabras con tildes. Buscaré por ahí los comandos necesarios para lanzar consultas a Firebird usando dichos Collates. Espero que no me den problemas con dbExpress, porque, como comentaba en otros hilos, no uso driver específico de Firebird, sólo el de Interbase de D2007. Pero, en fin, eso es ya otra historia

EDITO:

Ya he encontrado lo de los collates. Supongo que algo así me serviría:

SELECT * FROM tabla
ORDER BY lo_que_sea COLLATE ES_ES_CI_AI

Entiendo que así es para español y, además de ser case insensitive, no tiene en cuenta los acentos.

Me acabáis de descubrir un mundo Menuda solución a todos los problemas que siempre he tenido con mayúsculas/minúsculas/acentos! (sí... soy un bruto por no saber que esto existía )

Yo no lo especifico en las consultas, porqué mis campos ya tienen definido que usan este Collate (fíjate en IBExpert o en el programa que uses para gestionar tu base de datos que puedes especificar los Collates a nivel de campos). De esta forma, sin decirle nada a las consultas, ya saben que ordenación (Collate) hay que aplicar en función del campo implicado.

Para no complicarme la vida y no tener que andar siempre especificándolo cada vez que doy de alta un campo, lo tengo definido en los Dominios que utilizo para especificar los tipos de los campos. Como puedes ver, en los Dominios también puedes marcar el Charset y Collate de los campos que lo apliquen.

[Casimiro Noteví]

Empezado por guillotmarc

[..
Yo no lo especifico en las consultas, porqué mis campos ya tienen definido que usan este Collate (fíjate en IBExpert o en el programa que uses para gestionar tu base de datos que puedes especificar los Collates a nivel de campos). De esta forma, sin decirle nada a las consultas, ya saben que ordenación (Collate) hay que aplicar en función del campo implicado.

Para no complicarme la vida y no tener que andar siempre especificándolo cada vez que doy de alta un campo, lo tengo definido en los Dominios que utilizo para especificar los tipos de los campos. Como puedes ver, en los Dominios también puedes marcar el Charset y Collate de los campos que lo apliquen.

Para que Chandra_ lo tenga más claro, pongo un ejemplo:

Código SQL [-]
set sql dialect 3; 
 
set names none; 
 
create database "rankings.fdb" PAGE_SIZE 8192 user "SYSDBA" password "masterkey"; 
 
/**/ 
create domain domCodigoNoNulo integer not null; 
create domain domNombre varchar(64) character set ISO8859_1;  /* fb < 2.1 */ 
/*create domain domNombre varchar(64) character set UTF8 collate ES_ES_CI_AI default '';*/  /* fb >= 2.1 */ 
create domain domImagen blob sub_type 0; 
create domain domFecha date; 
create domain domHora time; 
create domain domFechaHora timestamp;
...

[Chandra_]

Empezado por guillotmarc

Hola.
Todos los charsets sirven para codificar los alfabetos de un grupo de lenguas. Pero el iso8859_1 solo sirve para codificar el alfabeto de las lenguas de Europa Occidental, mientras que Unicode pretende poder codificar los alfabetos de todas las lenguas del mundo.

Como el iso8859_1 solo codifica un pequeño grupo de lenguas, puede guardar cada letra del alfabeto en un solo byte. En cambio Unicode tiene que codificar un montón de letras de distintos alfabetos, las letras más comunes A B C D ... las codifica en un solo byte, pero para codificar letras de alfabetos más complicados como el chino va a necesita bastantes más bytes para cada letra.

Esta es una de las grandes diferencias entre Unicode y los demás charsets (iso8859_1 y compañía) que Unicode tiene un tamaño de letra variable y los charsets tradicionales tienen un tamaño de letra fijo. Por eso a los lenguajes de programación, bases de datos, sistemas operativos, ... les resulta más complejo tener que lidiar con Unicode.

Eso es lo que yo llamo una clase magistral sobre extándares ISO . Ahora ya queda todo claro, muchas gracias.

Yo no lo especifico en las consultas, porqué mis campos ya tienen definido que usan este Collate (fíjate en IBExpert o en el programa que uses para gestionar tu base de datos que puedes especificar los Collates a nivel de campos). De esta forma, sin decirle nada a las consultas, ya saben que ordenación (Collate) hay que aplicar en función del campo implicado.

Para no complicarme la vida y no tener que andar siempre especificándolo cada vez que doy de alta un campo, lo tengo definido en los Dominios que utilizo para especificar los tipos de los campos. Como puedes ver, en los Dominios también puedes marcar el Charset y Collate de los campos que lo apliquen.

Pues así lo voy a hacer a partir de ahora. Yo también uso IBExpert (que, por ciuerto, creo que está hecho con Delphi) y voy a definirlo también en los Dominios, como dices.

Muchísimas gracias, guillotmarc, por una respuesta tan currada y esclarecedora. Qué buena sensación da cuando te explican bien las cosas y las entiendes

Empezado por Casimiro Notevi

Para que Chandra_ lo tenga más claro, pongo un ejemplo: (...)

Un millón de gracias, Casimiro; muy interesante y útil el código. Has tenido incluso el detalle de ponermelo por si uso Firebird 2.5 (como es el caso) o por si uso versiones anteriores. Me lo guardo para futuras referencias. Muchas gracias por tu tiempo.

Qué gusto da saber que si hay problemas, siempre está ahí la gente del ClubDelphi para echarte una mano

[Gallosuarez]

Guillotmarc:

Gracias por todas las aclaraciones.... déjame hacer pruebas (a profundida), confieso que las anteriores solo fueron superficiales. Si esto es así, entonces si que no habría ninguna razón para no utilizar UTF8.

Saludos,
Gerardo Suárez Trejo

[Casimiro Noteví]

Empezado por Gallosuarez

Si esto es así, entonces si que no habría ninguna razón para no utilizar UTF8.

Código Delphi [-]
if razon then
  not razon = not usar