1

クラスのプロパティの文字列値が奇数になることがあります。それらには不正な文字が含まれており、次のように表示されます（ボックス付き）：

123[]45[]6789

それらは違法/認識されない文字だと思います。すべてのオブジェクトをXMLにシリアル化してから、Webサービスを介してアップロードします。それらを再度取得すると、一部の文字が奇数に置き換えられます。これは、Wordを使用して入力されたハイフンとダッシュで最も頻繁に発生します。それが原因ですか？

とにかく、文字列に正規表現などを介してこれらの認識されない文字が含まれているかどうかを確認できますか？

4

5 に答える 5

3

個人的には、正規表現を使用してこれらの文字をチェックすることが正しい解決策ではないと思います。これらの文字を保存していない場合は、明らかに何らかのエンコーディングの問題があります。

保存する必要のある文字をサポートするために、XMLドキュメント自体が正しいエンコーディングを使用して保存されていることを確認してください。次に、ファイルを読み取るときに、ドキュメントと同じエンコーディングを使用していることを確認します。つまり、XMLドキュメントがUTF-8として保存されている場合は、UTF-8としてエンコーディングで読み取るときに確認する必要があります。

于 2010-08-24T12:59:29.257 に答える
3

最初に覚えておくべきことは、「特殊文字」や「違法文字」などは存在しないということです。特定の状況で特殊な文字があり、文字以外の文字もありますが、一般的に「特殊文字」や「違法文字」はありません。

ここにあるのは次のいずれかです。

  1. フォントにグリフがない完全に通常の文字。
  2. 印刷できない完全に正常な文字（制御文字など）。
  3. デバッガーがどのように機能するかのアーティファクト。

まず、そのキャラクターが何であるかを知ることです。文字の整数値を見つけて調べます。

注意すべき重要なものはU+FFFD（�）です。これは、デコーダーが使用しようとしているエンコーディングのコンテキストでは意味をなさないバイトの束を受信したときに使用されることがあります（たとえば、0x80の後に0x20が続くUTF-8には意味がなく、考えられる応答の1つは、U + FFFDを「ここで何か奇妙な」マーカーとして使用することです。他の考えられる応答はエラーをスローし、エラーを黙って無視するか、最後の2つで意図を推測しようとします。セキュリティの問題をもたらします）。

これを理解したら、予期しない場合になぜそこに入るのかを推論し始めることができます。それはエンコーディングの問題である可能性があります（書き込まれた文字セットは読み込まれた文字セットではありません）？それは実際にそこにあることを意図しているのでしょうか？それは何か他のものでしょうか？バグに関する詳細情報が得られるまで、それに答えることはできません。

最後に、それについて何をすべきかという問題があります。これは、上記の調査で見つけた回答から明らかになることを願っています。おそらく、答えは「何も問題ない」、おそらく単純なものか難しいものになるでしょう。まだ言えません。

正規表現でフィルタリングするだけではいけません。おそらくそれが正しい解決策であることが判明するでしょうが、あなたはまだわからないので、おそらくあなたは現在よりも深いバグを見つけるのを難しくしている、または完全に良いデータに損害を与えています。

于 2010-08-24T13:15:59.263 に答える
1

許可される文字を定義し、他のすべてをブロックします。

// only lowercase letters and digits
if(Regex.IsMatch(yourString, @"^[a-z0-9]*$"))
{
    // allowed
}

しかし、あなたの問題はどこかにあるのではないかと思います。なぜなら、それは文字列のシリアル化（有効）とその後の逆シリアル化（無効）に起因すると言うからです。ISerializableデフォルトのシリアル化を使用していて、クラスに適切な実装を適用していない（またはSerializable属性を適切に使用していない）ために、シリアル化されたくないプロパティまたはフィールドがシリアル化されている可能性があります。

PS：他の人はエンコーディングの問題について言及していますが、これは考えられる原因であり、データをまったく読み戻せないことを意味する場合があります。エンコーディングについては、1つの簡単なルールがあります。どこでも同じエンコーディング（ストリーム、データベース、xml）を使用し、具体的にします。そうでない場合は、デフォルトのエンコーディングが使用されますが、これはシステムごとに異なる可能性があります。

編集：可能な解決策

新しい情報（元の質問の下のスレッドを参照）に基づいて、問題がエンコーディングに関係していることはかなり明らかです。OPは、ダッシュで表示されると述べています。ダッシュは、高度な編集環境で使用される場合、「—＆quot;（）」のようなかなりのダッシュに置き換えられることがよくあり—ます。適切なエンコードされた文字列を受け入れるようにSQL Serverを修正する方法に不明確な点があるようですが、 XMLでこれを解決することもできます。

XMLを作成するときは、エンコーディングを可能な限り最も基本的なものに変更するだけです（US-ASCII）。これにより、XMLライターは自動的に適切な数値エンティティを使用するようになります。デシリアライズすると、これは文字列で適切に解析されます。これらの線に沿った何か：

Stream stream = new MemoryStream();
XmlWriterSettings settings = new XmlWriterSettings();
settings.Encoding = Encoding.ASCII;
XmlWriter writer = XmlWriter.Create(stream, settings);
// make sure to output the xml-prolog header

ただし、StringBuilderまたはを使用することに注意しStringWriterてください。これはUTF-16の使用に固定されており、XmlWriterは常にそのエンコーディングで書き込みます。この問題の詳細については、SQLServerと互換性のないブログを参照してください。

注：ASCIIエンコードを使用する場合、より高い文字0x7Fがエンコードされます。したがって、éは次のように&#xE9なり、ダッシュはのよう&#x2014になりますが、これはまったく同じことを意味し、心配する必要はありません。すべてのXML対応ツールは、この入力を適切に解釈します。

注2：XMLの記述方法を変更する場所は、XMLを受信して​​SQLServerデータベースに格納するWebサービスです。SQL Serverに保存する前に、変更を適用する必要があります。チェーンの初期は役に立たない。

于 2010-08-24T12:58:33.520 に答える
1

キャラクター自体を詳しく見てみましょう。実際のcharの値は何ですか？

キャラクターが正方形を表示する場合、それは視覚的に表現できないことを意味します。これは、非視覚的な文字であるか、現在の文字セットの外にあるためです。

編集、いや

あなたの例では、あなたが見ている改行文字が埋め込まれていると思い切って思います。

于 2010-08-24T13:00:32.233 に答える
0 
public static T DeserializeFromXml<T>(string xml)
        {
            T result;
            XmlSerializerFactory serializerFactory = new XmlSerializerFactory();
            XmlSerializer serializer =serializerFactory.CreateSerializer(typeof(T));

            using (StringReader sr3 = new StringReader(xml))
            {
                XmlReaderSettings settings = new XmlReaderSettings()
                {
                    CheckCharacters = false // default value is true;
                };

                using (XmlReader xr3 = XmlTextReader.Create(sr3, settings))
                {
                    result = (T)serializer.Deserialize(xr3);
                }
            }

            return result;
        }
于 2013-04-16T14:24:01.780 に答える