Permitir entrada de chino simplificado

Question

La empresa para la que trabajo licita un proyecto que requerirá que nuestra solución de comercio electrónico acepte la entrada de chino simplificado. Después de hacer un poco de investigación, parece que hace que la configuración ASP.net globalización fácil:

<configuration> 
    <system.web> 
    <globalization 
     fileEncoding="utf-8" 
     requestEncoding="utf-8" 
     responseEncoding="utf-8" 
     culture="zh-Hans" 
     uiCulture="en-us" /> 
    </system.web> 
</configuration> 

Preguntas:

1. Es ésta realmente todo lo que hay que hacer en ASP.net? Parece bueno ser cierto.
2. ¿Existen consideraciones de DB con SQL Server 2005? ¿El DB aceptará el chino simplificado sin configuración adicional?

Answer 1

Anuncio 1. La verdadera pregunta es, qué tan lejos quieres llegar con la Internacionalización. Porque i18n no solo permite la entrada de Unicode. Necesitará al menos soporte para formatos locales de fecha, hora y número, intercalación local (principalmente relacionada con la clasificación) y asegúrese de que su aplicación se ejecute correctamente en sistemas operativos localizados (a menos que esté desarrollando una solución hospedada Cloud aka). Es posible que desee leer más sobre el tema here.

En cuanto a la compatibilidad con la entrada de caracteres chinos, si va a ofrecer software en China, debe al menos admitir GB18030-2000. Para hacer eso, necesita utilizar la versión .Net Framework adecuada, la que admite Unicode 3.0. Creo que fue compatible desde .Net Framework 2.0.
Sin embargo, si desea ir un paso más allá (lo que podría ser necesario para obtener ventajas competitivas), es posible que desee admitir GB18030-2005. El único problema es que el soporte completo para estos caracteres (CJK Unified Ideographs Extension B) ocurrió más tarde (no estoy muy seguro de si es Unicode 6.0 o Unicode 6.1) en el proceso. Por lo tanto, es posible que se vea obligado a utilizar el .Net Framework más reciente y aún así no esté seguro si cubre todo.
Es posible que desee leer Unicode FAQ on Han characters.

Anuncio 2. Recomiendo encarecidamente que no utilice SQL Server 2005 con caracteres chinos. La razón es que el viejo motor de SQL Server solo admite UCS-2 en lugar de UTF-16. Esto podría parecer una pequeña diferencia, pero eso realmente plantea el problema con Han Ideographs de 4 bytes. En realidad, desea poder utilizarlos en consultas (es decir, cláusulas LIKE o WHERE) - recibirá todos los registros. Asi es como funciona. Y para apoyarlos, necesitaría establecer una intercalación china muy específica, que simplemente interrumpirá el soporte para otros idiomas.
Básicamente, el uso de SQL Server 2005 con Chinese Ideographs es a mala idea.

Answer 2

En primer lugar, me pregunto si está seguro de haber elegido el identificador de cultura correcto con zh-Hans, que es un neutral culture. Tal vez sería más apropiado para usted orientar su publicidad a una cultura específica, como zh-CN (los chinos se usan en China) si ese es el mercado que desea apoyar.

En segundo lugar, usar el archivo web.config para establecer la cultura está bien si está planificando una implementación que se dirige exclusivamente a esta cultura. A menudo querrá una misma implementación para adaptarse dinámicamente a la cultura del usuario final, en cuyo caso establecería programáticamente el Thread.CurrentCulture (e incluso el Thread.CurrentUICulture si proporciona recursos localizados) basado, por ejemplo, en un esquema de URL (p. Ej. Www.myapp. com usaría en-US y www.myapp.com/china usaría zh-CN) o el encabezado accept-languages ​​o un selector de idioma en la aplicación.

Aparte de las limitaciones de Unicode a las que se refiere Paweł (lo que significa que es posible que realmente necesite utilizar el último .NET Framework/SQL Server), no hay nada específico que deba hacer para el chino simplificado. Si sigue el estándar internationalization guidelines, debe tener todo listo. Quizás, por cierto, considere la localización (traducción) de su aplicación en chino como parte de esto.

Acerca de SQL Server, los puntos de Paweł parecen bastante claros. Dicho eso, siempre que use nvarchar tipos de datos (Unicode) y no ejecute consultas en estas columnas ni las ordene en base a estas columnas en el lado de la base de datos, me sorprendería que tuviera algún problema con SQL Server 2005. Entonces realmente depende de lo que hagas con estos datos.