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 • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244 -- TIP 3: Si encontraste la respuesta a tu problema, publ�cala, otros te lo agradecer�n
