Re: Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Almacenar acentos y ñ

Agustin Ignacio Genoves dijo [Fri, Jul 10, 2009 at 09:50:04AM -0300]:
> Una duda que entra ahora, ¿no es que hay q poner la DB en UTF8 y
> trabajar el client_encoding, LATIN1 por ej., para poder insertar
> acentos, ñ, etc.?

NO.

Latin1 ya es considerado "legacy", bagaje del cual ojalá no nos tome
demasiados años desprendernos. Fue una solución necesaria en su
momento, pero a fin de cuentas una solución ingenua a un problema
complejo.

UTF-8 es la solución real - Todos los caracteres Latin1 (que son solo
256) pueden ser representados en UTF-8. Obviamente, no al inverso -
UTF-8 soporta a 2^32 caracteres únicos (4,294,967,296) en tablas
oficiales, y es extensible de manera ilimitada usando el espacio
privado (más alla de los 32 bits).

Al diseñar una aplicación, debes intentar que _todas_ las capas hablen
en UTF-8, para evitar que se pierda información (p.ej. que haya
cadenas en tu base de datos que el cliente no pueda desplegar -
Digamos, si tu cliente de correo no soporta UTF-8, en vez de ver
simbolitos divertidos aquí verás secuencias iniciadas con Ã:

‽¹²³⁴⁵⁶⁷⁸⁹⁰≡≈⍨☺☹☮☯☕⚛☭ⅰⅱⅲⅳⅴⅵⅶⅷⅸⅹ

Claro, es importante que en caso de que tu cliente pueda no entender
UTF-8, encuentres cómo especificarle las cosas en un modo más o menos
seguible - y por eso muchos se degradan a Latin1. Sin embargo, el día
que llegue un europeo oriental a tu sistema y quiera registrarse con
su nombre propio y no con una transliteración (digamos, un nombre que
incluya letras como la ł, la č o la ẃ, o letras turcas como la ı (i
sin punto) o la İ (I con punto superior), tendrás un problema entre
manos.

--
Gunnar Wolf • gwolf(at)gwolf(dot)org • (+52-55)5623-0154 / 1451-2244