Giapponese/Cinese lingua di dati in una tabella di SQL Server

Question

Quindi ho un problema interessante, che ho bisogno di aiuto con la più veloce che posso ottenere la mia abilità con SQL Server fino a par.

Abbiamo una tabella che contiene un sacco di testo, il tutto in diverse lingue.La maggior parte di questo tipo di dati viene visualizzato correttamente nel browser, tuttavia, nulla in Cinese o Giapponese ottiene completamente maciullato da browser.

Questo è un ASP.il vecchio app che stiamo utilizzando per la visualizzazione di dati provenienti da un server che esegue SQL Server MS SQL Server 2005.

Prima, abbiamo avuto questo stesso problema e abbiamo risolto cambiando la codifica in pagine ASP.Questi file non sono cambiate da quando abbiamo fatto, ma il problema è ritornata.Quindi devo concludere che il problema resti con il database dal momento che è l'unica cosa che è stato aggiornato dall'ultima risolto.

Finora ho cercato di guardare in confronto, ma non sono per niente un esperto di SQL, quindi è stato difficile.

Posso fornire ulteriori informazioni, se necessario, qualsiasi cosa che possa aiutare qualcuno a farmi la risposta, breve di URL (riservatezza e di tutti).

Se qualcuno ha idee, lo apprezzerei molto.

INFORMAZIONI AGGIUNTIVE:

-tipo di colonna è 'ntext'

Answer 1

fascicolazione riguarda solo ordinamento, non codificante. È necessario determinare quale è la codifica dei contenuti cinese e japenese è (vedi questo ). Se non UCS-2 è, hai un problema (perché non si può supportare più codifiche pagina contemporaneamente). Se si tratta di UCS-2, è necessario assicurarsi che la codifica della pagina ASP è anch'essa destinata a UTF-8 (e che il browser riconosce che impostando correttamente la codifica UTF-8 - vedi View / Encoding).

O in termini più semplici:. Se l'applicazione che ha creato il contenuto non utilizzare i caratteri Unicode, si dovrà cambiare la codifica pagina se si passa da cinesi, giapponesi e europei

Se avete correttamente codificati contenuti Unicode nel database, e si utilizza codifica UTF-8 nelle tue pagine, non dovreste avere problemi con la visualizzazione di caratteri speciali (fino a quando si utilizza un carattere Unicode nella pagina):

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Mi rendo conto che desite vari interventi di modifica non sto essendo molto chiaro, quindi permettetemi di aggiungere alcuni principi fondamentali.

Un set di caratteri è una rappresentazione standardizzata di una serie di caratteri (ad esempio ASCII, UNICODE, ...).

Codifica caratteri è la rappresentazione binaria usata per memorizzare i caratteri di un dato insieme di caratteri. ASCII ha una propria codifica. Unicode, che è un insieme di caratteri molto grandi progettato per supportare tutti i caratteri di esistenza, ha diverse codifiche (UTF-8, UTF-16, UCS-2, ...).

Solo Unicode ti dà la possibilità di supportare contenuti orientale occidentale ed Estremo allo stesso tempo con le stesse impostazioni del database e delle applicazioni. Vi sono, tuttavia, i set di caratteri più grandi per la lingua cinese e Japenese che non sono Unicode. Se il contenuto non è Unicode (BIG 5, per esempio), non è possibile visualizzare su una pagina web codifica UTF-8.

Questo può diventare difficile se l'applicazione che ha creato il contenuto utilizzata una codifica (ad esempio BIG-5) e il database memorizzato come dati Unicode. In questo caso, le informazioni potrebbe essere stato perso.

È anche necessario installare i Language Pack corrispondenti in Windows per vedere correttamente i caratteri. Purtroppo, problemi di codifica non sono semplici da diagnosticare.

Answer 2

Ci potrebbe essere un paio di problemi qui, ma dal momento che si dice che si risolto questo prima, può essere semplicemente un problema di visualizzazione del browser. Si dovrebbe fare in modo di avere la codifica impostato correttamente e language pack installato. Si potrebbe verificare questo su un paio di diversi computer e browser per determinare se un problema con una specifica macchina, browser o un problema generale.

In caso contrario, stai usando nvarchar o ntext campi in tutte le tabelle del database? Se no, allora si sta perdendo i caratteri cinesi e giapponesi a quel livello. Inoltre, se si sta utilizzando qualsiasi stored procedure, funzioni, ecc è necessario fare in modo che le variabili sono anche nvarchar o ntext.

Infine, rechecl che le pagine ASP sono preservare la codifica in tutti i luoghi. Io non sono molto familiare con ASP classico, quindi mi lasciare che qualcun altro aiutare in questo.

Answer 3

Avete il seguente nei file ASP?

<%@codepage=65001%>
Session.CodePage = 65001

Answer 4

ntext è stato deprecato in SQL 2005 ( http://geekswithblogs.net/johnsPerfBlog/archive/2008/04/16/ntext-vs-nvarcharmax-in-sql-2005.aspx ). Non sono sicuro se aiuta, ma si può provare la conversione ntext a nvarchar.

Answer 5

Hai detto che non si può leggere anche da Management Studio.È molto importante verificare che c'è qualche perdita di dati già.

Per sapere come ripristinarlo, è necessario sapere come è danneggiato.

1. Come hanno fatto queste parole scrittura al database?qualsiasi transcodifica (compresi quelli nascosti da ASP) è stato fatto prima è stato scritto al DB?

2. Che cosa è effettivamente memorizzato nel database di già?È possibile ottenere i primi due/tre byte per il "rotto" le parole, e confrontare il loro intervallo di byte al comune di charset.

Se i dati provengono dal browser, si dovrebbe verificare la codifica della pagina del modulo.Browser utilizzano la codifica della pagina per la codifica e l'invio dei dati.Se il set di caratteri/codifica non corrispondere al ricevitore (ad es.la tua pagina ASP), può decodificato le parole in modo non corretto.

Answer 6

Se si è modificato il database, quindi la causa più probabile è nella memoria dei campi. Si può passare i campi tramite una variabile che non è ntext, ma piuttosto solo testo o varchar. Che ucciderà i dati che vanno dentro, e allora sembrerà sbagliato a tornare sulla pagina web.

Che cosa si usa per inserire i dati nel database?

Answer 7

Ho il sospetto di avere diversi problemi.

In realtà ci sono diversi modi comuni per rappresentare il testo giapponese e cinese, utilizzando le codifiche precedenti (Shift_JIS, EUC-JP, e JIS-varianti per il giapponese, e molti altri per il cinese) o Unicode (UTF-8 o UTF-16) . Per un'applicazione multilingue, la soluzione preferita è quella di trasmettere il contenuto della pagina in UTF-8; Windows stesso preferisce memorizzare i contenuti in UTF-16 (che è ciò che NTEXT e NVARCHAR uso in MS SQL Server).

Al fine di ottenere contenuti giapponese per visualizzare correttamente, è necessario assicurarsi che le conversioni appropriate stanno accadendo in ogni fase della tua pipeline di dati. Supponiamo che si sta andando a utilizzare Unicode per il bene della sanità mentale, ma la risposta sarebbe simile se intenzionalmente scelto di utilizzare Shift-JIS, Big5, GB2312 o qualcosa, solo più complicata.

Se i dati sono in primo luogo proviene da moduli web, è necessario assicurarsi che la vostra tabella di codici è impostato su 65001, di solito utilizzando il <% @ codepage = 65001%> direttiva nella parte superiore di ogni file ASP.

Inoltre, è necessario fornire un suggerimento per i vostri user-agent (il browser web) che si sta utilizzando UTF-8. Ci sono due tecniche, una coinvolgono un'intestazione HTTP; l'altra opzione è quella di falsificare l'intestazione HTTP con un meta tag.

La soluzione meta tag:

La soluzione intestazione HTTP, usando le mie capacità arrugginito ASP (supponendo javascript, ma probabilmente stai usando VBScript, che richiederebbe di eliminare il punto e virgola) Response.ContentType = "text / html"; Response.Charset = "utf-8";

Se si stanno prendendo i dati in MSSQL nei mangimi, piuttosto che moduli web, avrete anche bisogno di assicurarsi i dati vengono convertiti correttamente. A seconda del meccanismo di importazione, il metodo per specificare la codifica del sorgente è diverso, quindi dovrò lasciare che come un "esercizio per il lettore."

Quindi, al momento della presentazione dei dati al server SQL, è necessario assicurarsi che si sta utilizzando il meccanismo di ingresso SQL corretta. Se non sei parametrizzazione vostre domande (e si dovrebbe essere), è necessario ricordarsi di utilizzare 'forma piuttosto che 'l'N'MyText MyText' quando mette i parametri di testo nella query. Se stai parametrizzazione il testo, quando si utilizza adVarChar, si dovrebbe utilizzare adVarWChar invece. (Ci sono corrispondenti tipi "W" per ogni tipo di dati ADO).

Inoltre, alcuni browser utilizzare l'attributo HTML LANG come un suggerimento per la visualizzazione di testo in un carattere adatto per la lingua dei contenuti. Se vi capita di sapere quale lingua i contenuti sono in, è possibile aggiungere LANG = "ja-jp" a qualsiasi elemento HTML (compreso CORPO). Poi un carattere predefinito ragionevole per tale lingua deve essere utilizzato dal browser (ma è possibile specificare in modo esplicito uno se vi piace). La maggior parte dei browser realizzati negli ultimi 5 anni fare un po 'di magia font-collega, anche se si sceglie un tipo di carattere predefinito inappropriato per una determinata lingua, ma si otterrà risultati più affidabili e le prestazioni leggermente migliori di rendering se si utilizza un tipo di carattere appropriato.

Come nota aggiuntiva, Se stai ricevendo i risultati quasi-corretti quando forzare manualmente la codifica come Shift-JIS sul browser, il che significa che probabilmente si sta utilizzando windows-1252 come charset <% @ codepage = 1252%> e che state ottenendo fortunato che il contenuto non è stato del tutto incasinato. Ci sono un paio di hack che può ripristinare hosed Shift-JIS-in-1252 o ISO-8859-1, ma non sono affidabili al 100%.

Per quanto riguarda le regole di confronto su SQL Server, questo ha due conseguenze. Su campi NVARCHAR e NTEXT, colpisce solo l'ordinamento e l'interrogazione (con custodia, accento e kana-sensibilità). Su campi varchar e testo, colpisce anche la codifica, ma non è la soluzione più ragionevole per il vostro problema.