Evitar el cambio de código con Microsoft SQLServer y Unicode

Question

¿Cómo puede hacer que el servidor MSSQL acepte los datos Unicode de forma predeterminada en una columna VARCHAR o NVARCHAR?

Sé que puede hacerlo colocando una N delante de la cadena que se colocará en el campo, pero para ser sincero, esto parece un poco arcaico en 2008 y en particular con el uso de SQL Server 2005.

Answer 1

La sintaxis N es cómo se especifica un literal de cadena unicode en SQL Server.

N'Unicode string'
'ANSI string'

SQL Server convertirá automáticamente entre los dos cuando sea posible, utilizando la clasificación de una columna o la clasificación de la base de datos.

Entonces, si sus literales de cadena no contienen caracteres Unicode, no necesita especificar el prefijo N .

Pero si los literales de cadena sí contienen caracteres unicode, entonces es necesario usar el prefijo N .

Answer 2

Si se trata de una aplicación web, probablemente pueda hacer que su servidor web use UTF8 como codificación predeterminada. De esa manera, todos los datos de ida y vuelta al navegador serían UTF8, que se pueden insertar en los campos VARCHAR. UTF8 es una buena manera de hacer que las aplicaciones que no son conscientes de Unicode lo manejen.

Answer 3

Realmente necesitan una forma de desactivar la necesidad del prefijo N ''. El " es necesario para la compatibilidad hacia atrás " el argumento no tiene ningún sentido para mí; claro, haga que ese comportamiento sea el predeterminado para las aplicaciones antiguas, pero proporcione una opción para activar las cadenas Unicode de manera predeterminada (es decir, no se requiere el prefijo N ''). Estoy descubriendo que necesito Vaya y ensucie con grandes áreas de mi aplicación para adaptarme a Unicode en SQL Server cuando NO es un problema en Oracle y Postgresql. ¡Vamos, Microsoft!

Answer 4

Si bien puede simplemente almacenar el contenido UTF8 en un campo VARCHAR en el servidor MSSQL, siempre que no se realice la traducción del juego de caracteres, debe tener en cuenta que:

1. Ninguna herramienta de administración / informes / datos fuera de su aplicación podrá entender sus caracteres que no están en inglés.

2. El manejo específico del idioma, como ordenar una lista de nombres, puede no realizarse en el orden aceptable para cada idioma.

3. Debe tener cuidado con el truncamiento de datos. Truncar un carácter UTF8 de múltiples bytes usualmente causa la corrupción de datos para el personaje involucrado. Siempre debe rechazar la entrada si excede la longitud del campo.

4. Puede que no sea tan fácil como cree desactivar la traducción del juego de caracteres ... Incluso si lo desactiva en el controlador de su cliente, aún puede anularse en algunos casos si hay una diferencia de configuración regional significativa entre el cliente y RDBMS página de códigos utilizada que conduce instantáneamente a la corrupción de datos.

5. Si crees que esto es todo, tendrás que preocuparte por engañarte a ti mismo.

En resumen, aunque puede que te sientas tentado a seguir este camino, no es una buena idea. Se requiere un cambio de código cuando se va de varios bytes.