1

Word ドキュメントをコピーして通常のフォーム フィールドに貼り付けることができる ASP クラシック アプリを使用しています。次に、そのドキュメントを jQuery Ajax 経由で SQL Server に投稿します。SQL Server に情報が保存されます。

私の問題は、カーリー クォートやその他の単語の文字が戻ってきたときに奇妙な文字に変わることです。

保存ルーチン (古典的な ASP ストアド プロシージャ) でそれらをフィルター処理しようとしていますが、それでも問題を完全に排除することはできません。

ASP ページには、ISO-8859-1 文字セットを持つこのヘッダーがあります。テキスト入力フィールドに貼り付けると、文字がきれいに表示されます。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xml:lang="en" xmlns="http://www.w3.org/1999/xhtml" lang="en">
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

私の jQuery コードは、ASP ページで次の JSON を構築します。

var jsonToSend = { serial: serial, critiqueText: escape(critiqueText) };

データベースの照合順序はSQL_Latin1_General_CP1_CI_ASに設定されています

テキストを保持するためにTEXT とVARCHARフィールドを使用します (はい、テキスト フィールド タイプが好まれていないことはわかっていますが、現在はそれを使用しています)。

(1) Word 文字が取り除かれ、(2) エンコーディングが前から後ろまで一貫していて、奇妙な文字が表示されないようにするために、各ポイントで何をしなければなりませんか?

Oh- SQL Server 2005 に対して Windows Server 2003 で 32 ビット モードで実行されている ASP Classic 3。

4

3 に答える 3

0
于 2013-02-03T10:51:30.010 に答える
0

私は一日中クレイジーな文字をSQLにインポートすることに取り組んでおり、nvarcharがその方法です。それらが数値またはそのようなものでない限り、列を nvarchar(max) に設定するので、対処する必要はありません。覚えておく必要がある唯一の例外は、外部キーを使用する場合は、nvarchar(450) に設定する必要があることです。これは、タブの結果としてテキスト内のあらゆる種類のクレイジーな文字、スペース、およびギャップを処理します。

于 2013-02-06T18:00:24.753 に答える
0

バックエンドデータベースで nvarchar と ntext を使用するのは、手っ取り早いソリューションです。あなたが言及する奇妙な文字は、エンコーディングの問題です。たとえば、以下の例を参照してください。

  • トルコ語の İiıIÜĞ win-1254
  • 通常の ANSI の Ä°iıIÃœÄ
  • C4B069C4B149C39CC49E 両方の 16 進値が同じです。

Web ページで ISO-8859-1 エンコードを使用します。これは、完全な Unicode の最初の 256 ビットのみである ASCII 文字のみを保存できることを意味します。この回答を参照してください。データベースで Latin1 を使用します。この 3 つの文字セットはほぼ同じです。Latin1-General = Win 1252 = IEC_8859-1 .

  ISO/IEC_8859-1 is the basis for most popular 8-bit character sets, including Windows-1252 and the first block of characters in Unicode.

  SQL_Latin1_General_CP1_CI_AS:- Latin1-General, case-insensitive, accent-sensitive, kanatype-insensitive, 
  width-insensitive for Unicode Data, SQL Server Sort Order 52 on Code Page 1252 for non-Unicode Data

これは、最初の 256 ビット値のデータベースに入力した文字が安全であることを意味します。クライアントのデフォルトのエンコーディングがわかっている場合。このデフォルトのエンコーディングを試して、情報を復元できるかどうかを確認することをお勧めします。私はトルコで例を挙げました。ほとんどのクライアントが Win1254 を使用していることを知っているため、値をそのエンコーディングに変更して、何かを回復できることを確認します。

回答の 2 番目の部分は、情報を失うことなく varchar から nvarchar に安全に変更できるということです。ここで、情報の損失がない場合は、最初の部分の 16 進数値 (最初の 256 値) になります。あなたの奇妙なキャラクターは残りますが、他のキャラクターは残ります。

この回答とリンクされた記事は、より多くの情報を提供します。

于 2013-02-01T09:31:17.870 に答える