Chinois/japonais langue des données dans la table SQL Server
Donc j'ai un problème intéressant que j'ai besoin d'aide plus vite que je peux obtenir mes compétences avec SQL Server à la hauteur.
Nous avons un tableau qui contient un tas de texte, le tout en différentes langues. La plupart de ces données s'affiche correctement dans le navigateur, cependant, quelque chose en Chinois ou en Japonais complètement déformés par le navigateur.
C'est un ASP.ancienne application que nous utilisons pour afficher les données d'un serveur qui exécute microsoft SQL Server 2005.
Avant, nous avons eu ce même problème et nous l'avons résolu en changeant l'encodage dans les pages ASP. Ces fichiers n'ont pas changé depuis que nous l'avons fait, mais le problème a refait surface. Donc je dois en conclure que le problème réside à la base de données puisque c'est la seule chose qui a été mis à jour depuis que nous nous sommes fixé.
Jusqu'à présent, j'ai essayé de regarder dans le classement, mais je suis loin d'être un expert en SQL, donc ça a été difficile.
Je peux donner plus d'infos si nécessaire, de quelque chose qui va aider quelqu'un à obtenir moi pour la réponse, à court d'URL (confidentialité et tout et tout).
Si quelqu'un a des idées, je l'apprécierais beaucoup.
INFORMATIONS SUPPLÉMENTAIRES:
-colonne est de type 'ntext'
OriginalL'auteur Blair Scott | 2009-02-20
Vous devez vous connecter pour publier un commentaire.
Classement n'affecte que l'ordre de tri, pas de codage. Vous devez déterminer quel est l'encodage de votre chinois et japonais de contenu (voir cette). Si elle n'est pas UCS-2, vous avez un problème (puisque vous ne pouvez pas supporter de multiples page codages simultanément). Si c'est UCS-2, vous devez vous assurer que le codage de votre page ASP est également mis en UTF-8 (et que le navigateur reconnaît qu'en réglant correctement le codage UTF-8 - voir Affichage/Codage).
Ou en termes plus simples: si l'application qui a créé le contenu n'a pas utiliser des caractères Unicode, vous aurez pour changer le codage de la page si vous basculez entre les Chinois, les Japonais, et des personnages Européens.
Si vous avez encodé en Unicode contenu de votre base de données, et que vous utilisez le codage UTF-8 sur vos pages, vous ne devriez pas avoir un problème avec l'affichage des caractères spéciaux (aussi longtemps que vous utilisez une police de caractères Unicode sur la page):
Je me rends compte que desite plusieurs modifications que je ne suis pas très claire, donc permettez-moi d'ajouter quelques notions de base.
Un jeu de caractères standard de représentation d'un ensemble de caractères (par exemple, ASCII, UNICODE, ...).
L'encodage des caractères est la représentation binaire utilisé pour stocker les caractères d'un jeu de caractères donné. ASCII a son propre codage. Unicode, qui est un très grand jeu de caractères conçu pour supporter tous les caractères dans l'existance, dispose de plusieurs jeux de caractères (UTF-8, UTF-16, UCS-2, ...).
Seulement Unicode vous donne la possibilité de soutenir Ouest et à l'est du contenu en même temps avec la même base de données et paramètres de l'application. Il ya, cependant, les plus anciens jeux de caractères pour les Chinois et les Japonais de langue qui ne sont pas Unicode. Si votre contenu n'est pas Unicode (BIG 5, par exemple), vous ne pouvez pas l'afficher sur une codé en UTF-8 page web.
Cela peut devenir difficile si l'application qui a créé le contenu utilisé un codage (par exemple, BIG-5) et de la base de données stockée en tant que données Unicode. Si cela se produit, l'information aurait pu être perdu.
Vous pouvez installer le correspondant des packs de langue dans Windows afin de voir les caractères correctement. Malheureusement, des problèmes de codage ne sont pas simples à diagnostiquer.
Lorsque vous interrogez la base de données dans Management Studio, que voyez-vous? Même les ordures que vous obtenez sur la page web, ou de corriger les données? Si vous ne voyez pas les données correctes, vos données est mauvais. Vous pouvez trouver ce qui est stocké à l'aide de l'asc() de la fonction, alors la recherche des codes. Faut courir, plus tard.
Ouais c'est le même non-sens dans la DB que sur la page. Nous allons essayer et obtenir une partie de ce à partir d'une sauvegarde et voir si c'est correct. Merci à tous pour les aider à bien, il est apprécié.
Lorsque vous accédez à yahoo.co.jp, voyez-vous des Japonais ou des petites boîtes? Vous avez besoin de la langue de support sur le client.
Ouais Japonais lorsqu'il est affiché correctement fonctionne très bien sur ma machine. En fait, il a bien fonctionné sur le site que je suis en train de corriger comme il y a 3 mois.
OriginalL'auteur cdonner
Il pourrait être une couple de questions ici, mais puisque vous dites que vous avez résolu ce problème avant, c'est peut-être simplement un problème d'affichage du navigateur. Vous devez vous assurer que vous avez de l'encodage correctement et les modules linguistiques sont installés. Vous pouvez vérifier cela sur un couple de différents ordinateurs et navigateurs pour déterminer si c'est un problème avec une machine, le navigateur, ou un problème général.
Sinon, êtes-vous à l'aide de type nvarchar ou ntext champs de vos tables de base de données? Si pas, alors vous êtes de perdre les caractères chinois et japonais à ce niveau. Aussi, si vous êtes à l'aide de procédures stockées, fonctions, etc. vous devez vous assurer que les variables sont de type nvarchar ou ntext.
Enfin, rechecl que vos pages ASP sont la préservation de l'encodage dans tous les lieux. Je ne suis pas très familier avec l'ASP classique, donc, je vais laisser quelqu'un d'autre aide que.
Le mien est en Unicode (UTF-8) et je suis en mesure d'afficher des caractères Chinois. Essayez de faire cela, et si vous avez encore un problème, alors il est probablement quelque chose à voir avec la page ASP. Est-ce la même page qui avait la question déjà?
C'est en fait un tas de pages, mais je suis juste à expérimenter avec le fixer sur une seule page. L'ancien correctif a bien fonctionné (changement de l'utf-8), mais maintenant, tout ne fonctionne pas encore et je n'ai pas personnellement d'avoir accès aux anciennes données, je dois attendre.
OriginalL'auteur Justin Gallagher
Vous avez de la suite dans vos fichiers ASP?
OriginalL'auteur Michael Pryor
ntext, a été déprécié dans SQL 2005 (http://geekswithblogs.net/johnsPerfBlog/archive/2008/04/16/ntext-vs-nvarcharmax-in-sql-2005.aspx). Vous ne savez pas si ça aide, mais vous pouvez essayer de convertir ntext nvarchar.
OriginalL'auteur David
Vous avez dit que vous ne pouvez même pas lire à partir de Management Studio.
Il est très important de vérifier que est-il de toute perte de données déjà.
Afin de savoir comment le restaurer, vous devez savoir comment il endommagé.
Comment ces mots en écriture à la base de données? tout le transcodage (y compris les cachés par l'ASP) a été fait avant qu'il a été écrit à la DB?
Ce qui est réellement stocké dans la base de données déjà?
Vous pouvez obtenir d'abord deux/trois octets de la "cassé" des mots, et de comparer leur plage d'octets à la commune de charset.
Si les données sont venus de navigateur, vous devez vérifier l'encodage de la page du formulaire.
Les navigateurs utilisent le codage de la page d'encodage et de soumettre des données. Si le jeu de caractères/de codage ne correspond pas au récepteur (par exemple, votre page ASP), il peut décodé les mots de manière incorrecte.
OriginalL'auteur Dennis C
Si vous avez modifié la base de données, le plus probable est dans le stockage de la les champs. Vous pouvez transmettre les champs via une variable qui n'est pas ntext, mais plutôt un simple text ou varchar. Qui va tuer les données qui vont dans, et puis il va chercher de mal de revenir sur la page web.
Qu'utilisez-vous pour insérer les données dans la base de données?
OriginalL'auteur Yishai
Je soupçonne que vous avez plusieurs problèmes.
Il ya en fait plusieurs façons de se représenter le texte Japonais et Chinois, utilisant les anciens codages (Shift_JIS, EUC-JP, et JIS-variantes pour le Japonais, et plusieurs autres pour les Chinois) ou Unicode (UTF-8 ou UTF-16). Pour une application multilingue, la meilleure solution est de transmettre le contenu de la page en UTF-8; Windows lui-même préfère stocker du contenu en UTF-16 (qui est ce que NTEXT et NVARCHAR MS SQL Server).
Afin d'obtenir Japonais contenu à afficher correctement, vous devez vous assurer de la bonne conversions se produisent à chaque étape de votre pipeline de données. Supposons que vous allez utiliser Unicode pour le bien de la santé mentale, mais la réponse serait similaire si vous délibérément choisi d'utiliser Shift-JIS, big5, gb2312 ou quelque chose, juste un peu plus compliqué.
Si vos données sont principalement en provenance de formulaires web, vous devez vous assurer que votre page de codes est définie à 65001, généralement en utilisant le <%@page de codes=65001%> directive en haut de chaque fichier ASP.
En outre, vous devez fournir une indication de votre user-agents (le navigateur web) que vous utilisez UTF-8. Il existe deux techniques, l'une comportant un en-tête HTTP; l'autre option consiste à falsifier les en-tête HTTP avec une balise meta.
La balise meta solution:
L'en-tête HTTP de la solution, à l'aide de mon rusty ASP compétences (en supposant que le javascript, mais vous êtes probablement à l'aide de vbscript, ce qui vous obligerait à déposer les points-virgules)
Réponse.ContentType="text/html";
Réponse.Charset="utf-8";
Si vous êtes à la prise de données en MSSQL dans les aliments, plutôt que de formulaires web, vous aurez également besoin de vous assurer que les données sont correctement convertis. En fonction de votre mécanisme d'importation, la méthode de spécification de la source de codage est différent, donc je vais laisser ça comme un "exercice pour le lecteur."
Prochain, lors de la présentation de vos données vers SQL server, vous devez vous assurer que vous utilisez la bonne SQL mécanisme d'entrée. Si vous n'êtes pas le paramétrage des requêtes (et vous devriez), vous devez n'oubliez pas d'utiliser le N'MyText la forme plutôt que sur le "MyText" quand mettre du texte paramètres de votre requête. Si vous êtes le paramétrage de votre texte, lorsque vous utilisez adVarChar, vous devriez être en utilisant adVarWChar à la place. (Il y a des "W" types pour chaque ADO type de données).
En outre, certains navigateurs utilisent l'attribut LANG HTML comme un indice pour l'affichage du texte dans une police de caractères appropriée pour la langue du contenu. Si vous connaissez la langue de votre contenu, vous pouvez ajouter LANG="ja-jp" à n'importe quel élément HTML (y compris le CORPS). Alors raisonnable de la police par défaut pour que la langue doit être utilisée par le navigateur (mais vous pouvez spécifier explicitement un si vous le souhaitez). La plupart des navigateurs fait dans les 5 dernières années n'certains de police de la liaison de la magie même si vous choisissez de inappropriées de la part de la police par défaut pour une langue particulière, mais vous obtiendrez des résultats plus fiables et un peu mieux les performances de rendu si vous utilisez une police appropriée.
Comme une note complémentaire,
Si vous avez de la presque-de bons résultats lors de forcer manuellement l'encodage shift-jis sur le navigateur, ce qui signifie que vous êtes probablement à l'aide de windows-1252 que votre jeu de caractères <%@page de codes=1252%>, et que vous êtes chanceux que le contenu n'a pas été foiré entièrement. Il y a quelques astuces qui peuvent restaurer arrosé Shift-Jis-en-1252 ou iso-8859-1, mais ils ne sont pas fiables à 100%.
Comme pour le classement sur SQL server, cela a deux impacts. Sur NVARCHAR et NTEXT champs, il n'affecte que le tri et l'interrogation (y compris les cas, l'accent et de kana-sensibilité). Sur varchar et les champs de texte, il affecte également le codage, mais ce n'est pas la plus judicieuse, la solution à votre problème.
OriginalL'auteur JasonTrue