Abilitazione dell'input cinese semplificato

Question

La società per cui lavoro è un'offerta per un progetto che richiede la nostra soluzione di eCommerce per accettare input semplificati in cinese. Dopo aver fatto un po 'di ricerca, sembra che ASP.net rende la configurazione globalizzazione facile:

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

Domande:

1. questo è davvero tutto quello che c'è ad esso in ASP.net? Sembra bello essere vero.
2. Esistono considerazioni su DB con SQL Server 2005? Il DB accetterà il cinese semplificato senza configurazione aggiuntiva?

Answer 1

Ad 1. La vera domanda è: quanto lontano si vuole andare con l'internazionalizzazione. Perché i18n non consente solo l'input Unicode. È necessario almeno supportare i formati locali di data, ora e numero, le regole di confronto locali (principalmente correlate all'ordinamento) e assicurarsi che l'applicazione funzioni correttamente su sistemi operativi localizzati (a meno che non si stia sviluppando la soluzione ospitata dal cloud). Potresti voler leggere di più sull'argomento here.

Per quanto riguarda il supporto per l'immissione di caratteri in cinese, se si intende offrire software in Cina, è necessario almeno supportare GB18030-2000. Per fare ciò, è necessario utilizzare la corretta versione di .Net Framework, quella che supporta Unicode 3.0. Credo che sia stato supportato da .Net Framework 2.0.
Tuttavia, se si desidera compiere un ulteriore passo avanti (che potrebbe essere necessario per ottenere vantaggio competitivo), è possibile supportare GB18030-2005. L'unico problema è che il supporto completo per questi personaggi (CJK Unified Ideographs Extension B) è avvenuto più tardi (non sono sicuro che sia Unicode 6.0 o Unicode 6.1) nel processo. Quindi potresti essere costretto a usare l'ultimo .Net Framework e ancora non essere sicuro che copra tutto.
Si potrebbe leggere Unicode FAQ on Han characters.

Ad 2. Consiglio vivamente di non utilizzare SQL Server 2005 con caratteri cinesi. Il motivo è che il vecchio motore di SQL Server supporta solo UCS-2 anziché UTF-16. Questa potrebbe sembrare una leggera differenza, ma questo pone davvero il problema con gli Ideogrammi Han a 4 byte. In realtà, vuoi essere in grado di usarli nelle query (ad esempio le clausole LIKE o WHERE) - riceverai tutti i record. Ecco come funziona E per sostenerli, è necessario impostare regole di confronto cinesi molto specifiche, che interromperanno semplicemente il supporto per altre lingue.
In pratica, l'utilizzo di SQL Server 2005 con gli ideogrammi cinesi è a non valido idea.

Answer 2

Prima di tutto, mi chiedo se sei sicuro di aver scelto l'identificatore cultura corretto con zh-Hans, che è un neutral culture. Forse sarebbe più appropriato per te indirizzare una cultura specifica, come ad esempio zh-CN (il cinese viene usato in Cina) se questo è il mercato che stai mirando a sostenere.

In secondo luogo, l'utilizzo del file web.config per impostare la cultura va bene se si sta pianificando una distribuzione destinata esclusivamente a questa coltura. Spesso vorrete che una stessa implementazione si adatti dinamicamente alla cultura dell'utente finale, nel qual caso impostate in modo programmatico lo Thread.CurrentCulture (e anche lo Thread.CurrentUICulture se fornite risorse localizzate) basate, ad esempio, su uno schema URL (ad esempio www.myapp. com userebbe en-US e www.myapp.com/china userebbe zh-CN) o l'intestazione accept-languages ​​o un selettore di lingua in-app.

Oltre alle limitazioni Unicode a cui Paweł fa riferimento (il che significa che potrebbe essere necessario utilizzare il più recente .NET Framework/SQL Server), non c'è nulla di specifico che dovresti fare per il cinese semplificato - se segui lo standard internationalization guidelines dovresti essere tutto pronto. Forse dovresti considerare di localizzare (tradurre) la tua app in cinese come parte di questo, a proposito.

Informazioni su SQL Server, i punti di Paweł sembrano abbastanza chiari. Detto questo, fintanto che si utilizzano i tipi di dati nvarchar (Unicode) e non si eseguono query su queste colonne o si ordinano in base a queste colonne sul lato DB, sarei sorpreso se si riscontrassero problemi in SQL Server 2005. Quindi dipende davvero da cosa fai con questi dati.