3

興味深い問題があり、SQL Server のスキルを習得するよりも早く解決する必要があります。

たくさんのテキストを含むテーブルがあり、すべてが異なる言語で書かれています。このデータのほとんどはブラウザーで正しく表示されますが、中国語または日本語のデータはブラウザーによって完全に破壊されます。

これは、MS SQL Server 2005 を実行しているサーバーからのデータを表示するために使用している ASP.old アプリです。

以前にも同じ問題があり、ASP ページのエンコーディングを変更することで解決しました。これらのファイルは変更されていませんが、問題が再発しています。したがって、問題はデータベースにあると結論付けなければなりません。これは、前回の修正以降に更新された唯一のものであるためです。

これまで照合について調べてみましたが、SQL の専門家にはほど遠いので難しいものでした。

必要に応じて、より多くの情報を提供できます。誰かが私を答えに導くのに役立つものであれば、URL 以外の情報 (機密性など) を提供できます。

誰かアイデアがあれば、よろしくお願いします。

追加情報：

-列タイプは「ntext」です

4

7 に答える 7

4

ここにはいくつかの問題がある可能性がありますが、以前にこれを解決したとのことなので、単にブラウザの表示の問題である可能性があります。エンコーディングが正しく設定され、言語パックがインストールされていることを確認する必要があります。いくつかの異なるコンピューターとブラウザーでこれを確認して、特定のマシン、ブラウザーの問題、または一般的な問題かどうかを判断できます。

それ以外の場合、すべてのデータベース テーブルで nvarchar または ntext フィールドを使用していますか? そうでない場合は、そのレベルの中国語と日本語の文字が失われています。また、ストアド プロシージャや関数などを使用している場合は、変数も nvarchar または ntext であることを確認する必要があります。

最後に、ASP ページがすべての場所でエンコーディングを保持していることを再確認します。私は ASP クラシックにあまり詳しくないので、他の人に手伝ってもらいます。

于 2009-02-20T15:19:36.990 に答える
4

照合はソート順のみに影響し、エンコードには影響しません。中国語と日本語のコンテンツのエンコーディングを決定する必要があります (これを参照してください)。UCS-2 でない場合は、問題があります (複数のページのエンコーディングを同時にサポートできないため)。UCS-2 の場合は、ASP ページのエンコーディングも UTF-8 に設定されていることを確認する必要があります (また、エンコーディングを UTF-8 に正しく設定することにより、ブラウザがそれを認識していることを確認してください - 表示/エンコーディングを参照してください)。

もっと簡単に言えば、コンテンツを作成したアプリケーションが Unicode 文字を使用していない場合、中国語、日本語、およびヨーロッパの文字を切り替える場合は、ページのエンコードを切り替える必要があります。

データベースで Unicode コンテンツを正しくエンコードし、ページで UTF-8 エンコードを使用している場合、(ページで Unicode フォントを使用している限り) 特殊文字の表示に問題はありません。

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

いくつかの編集を行うと、あまり明確ではないことがわかります。そのため、いくつかの基本を追加させてください。

文字セットは、文字セット (ASCII、UNICODE など) の標準化された表現です。

文字エンコーディングは、特定の文字セットの文字を格納するために使用されるバイナリ表現です。ASCII には独自のエンコーディングがあります。存在するすべての文字をサポートするように設計された非常に大きな文字セットである Unicode には、いくつかのエンコーディング (UTF-8、UTF-16、UCS-2 など) があります。

同じデータベースとアプリケーション設定で、西洋と極東のコンテンツを同時にサポートできるのは Unicode だけです。ただし、Unicode ではない中国語と日本語の古い文字セットがあります。コンテンツが Unicode (BIG 5 など) でない場合、UTF-8 でエンコードされた Web ページに表示できません。

コンテンツを作成したアプリケーションが 1 つのエンコーディング (BIG-5 など) を使用し、データベースがそれを Unicode データとして格納した場合、これは扱いにくくなる可能性があります。この場合、情報が失われる可能性があります。

文字を正しく表示するには、対応する言語パックを Windows にインストールする必要があります。残念ながら、エンコーディングの問題は簡単には診断できません。

于 2009-02-20T15:05:41.033 に答える
1

ASP ファイルに次のものがありますか?

<%@codepage=65001%>
Session.CodePage = 65001
于 2009-04-29T01:13:45.897 に答える
0

ManagementStudioからも読み取れないとおっしゃいました。すでに失われたデータがあるかどうかを確認することは非常に重要です。

それを復元する方法を知るためには、それがどのように破損するかを知る必要があります。

  1. これらの単語はどのようにデータベースに書き込まれましたか？DBに書き込まれる前に、トランスコーディング（ASPによって隠されているものを含む）が実行されていますか？

  2. 実際にデータベースに保存されているものは何ですか？「壊れた」単語の最初の2/3バイトを取得し、それらのバイト範囲を一般的な文字セットと比較できます。

データがブラウザからのものである場合は、フォームのページのエンコーディングを確認する必要があります。ブラウザは、ページのエンコーディングを使用してデータをエンコードおよび送信します。文字セット/エンコーディングがレシーバー（ASPページなど）と一致しない場合、単語が正しくデコードされない可能性があります。

于 2009-05-02T15:55:34.753 に答える
0

ntext は SQL 2005 で廃止されました ( http://geekswithblogs.net/johnsPerfBlog/archive/2008/04/16/ntext-vs-nvarcharmax-in-sql-2005.aspx )。役立つかどうかはわかりませんが、ntext を nvarchar に変換してみてください。

于 2009-04-29T14:31:49.770 に答える
0

データベースを変更した場合、最も可能性の高い原因はフィールドのストレージにあります。ntext ではなく、単なる text または varchar の変数を介してフィールドを渡すことができます。それは入ってくるデータを殺し、ウェブページに戻ってくるのは間違っているように見えます.

データベースにデータを挿入するために何を使用しますか?

于 2009-05-04T13:52:07.560 に答える
0

あなたにはいくつかの問題があると思います。

日本語と中国語のテキストを表す一般的な方法はいくつかあります。従来のエンコーディング (Shift_JIS、EUC-JP、および日本語の場合は JIS バリアント、中国語の場合はその他のいくつか) または Unicode (UTF-8 または UTF-16) を使用します。多言語アプリケーションの場合、ページ コンテンツを UTF-8 で送信することをお勧めします。Windows 自体は、コンテンツを UTF-16 で保存することを好みます (これは、MS SQL Server で NTEXT および NVARCHAR が使用するものです)。

日本語のコンテンツを正しく表示するには、データ パイプラインのすべての段階で適切な変換が行われていることを確認する必要があります。正気を保つために Unicode を使用すると仮定しましょう。ただし、Shift-JIS、big5、gb2312 などを意図的に使用することを選択した場合、答えは同様になり、さらに複雑になります。

データが主に Web フォームから取得されている場合は、コードページが 65001 に設定されていることを確認する必要があります。通常、各 ASP ファイルの先頭にある <%@codepage=65001%> ディレクティブを使用します。

さらに、UTF-8 を使用しているというヒントをユーザー エージェント (Web ブラウザー) に提供する必要があります。2 つの手法があり、1 つは HTTP ヘッダーを使用します。もう 1 つのオプションは、メタ タグを使用して HTTP ヘッダーを偽装することです。

メタ タグ ソリューション:

私のさびた ASP スキルを使用した HTTP ヘッダー ソリューション (javascript を想定していますが、おそらく vbscript を使用しているため、セミコロンを削除する必要があります) Response.ContentType="text/html"; Response.Charset="utf-8";

Web フォームではなくフィードで MSSQL にデータを取り込む場合は、データが適切に変換されていることも確認する必要があります。インポート メカニズムによって、ソース エンコーディングを指定する方法が異なるため、「読者の演習」として残しておく必要があります。

次に、データを SQL サーバーに送信するときは、正しい SQL 入力メカニズムを使用していることを確認する必要があります。クエリをパラメータ化していない場合 (そうすべきです)、クエリにテキスト パラメータを入れるときは、'MyText' ではなく N'MyText' フォームを使用することを忘れないでください。テキストをパラメータ化する場合、adVarChar を使用している場合は、代わりに adVarWChar を使用する必要があります。(各 ADO データ型に対応する「W」型があります)。

さらに、一部のブラウザでは、コンテンツの言語に適したフォントでテキストを表示するためのヒントとして、HTML の LANG 属性が使用されます。コンテンツの言語がわかっている場合は、任意の HTML 要素 (BODY を含む) に LANG="ja-jp" を追加できます。次に、その言語の適切なデフォルト フォントをブラウザで使用する必要があります (ただし、必要に応じて明示的に指定できます)。過去 5 年間に作成されたほとんどのブラウザーは、特定の言語に不適切な既定のフォントを選択した場合でも、フォント リンクの魔法を実行しますが、適切なフォントを使用すると、より信頼性の高い結果とわずかに優れたレンダリング パフォーマンスが得られます。

追加のメモとして、ブラウザでエンコードを手動で shift-jis として強制したときにほぼ正しい結果が得られた場合、それはおそらく文字セット <%@codepage=1252%> として windows-1252 を使用していることを意味します。コンテンツが完全に台無しにされていないことは幸運です。ホースをかけた Shift-Jis-in-1252 または iso-8859-1 を復元できるハックがいくつかありますが、100% 信頼できるわけではありません。

SQL サーバーでの照合に関しては、これには 2 つの影響があります。NVARCHAR および NTEXT フィールドでは、並べ替えとクエリ (大文字と小文字、アクセント、かなの区別を含む) にのみ影響します。varchar および text フィールドでは、エンコーディングにも影響しますが、問題に対する最も賢明な解決策ではありません。

于 2009-05-05T18:09:18.993 に答える