私の経験では、行番号と解析位置を取得できて幸運です。
DTDを介して検証することを検討することもできますが、これにより、少し興味深いエラーが発生することがありますが、現在取り組んでいるプロジェクトでは、XSLTを使用して検証しています。変換は構文をチェックし、出力された変換テキストとしてエラーを報告します。よりわかりやすいエラーチェックが必要な場合は、そのルートを検討します。私たちにとって、空の出力はエラーがないことを意味します。そうでない場合は、XSLT処理から、エラーの内容と場所に関する詳細が得られます。
これは簡単な作業ではないようです。ロバート・ロスニーの答えは、プログラムで私の問題を解決することに最も近いので、今はそれを受け入れます。xslソリューションを引き続き使用します。検証エラーを解決するためのより良い方法を見つけた人は誰でも、このスレッドに応答できます。
個人的には、より詳細なエラーを取得する方法がわかりません。通常、ドキュメントを開いて、記載されている場所に移動すると、エラーを簡単に見つけることができます。
コードがファイルを有効な XML として解析できない場合、XPATH またはその他の名前付き XML の詳細を提供することは非常に困難です。
これは、XmlReaderSettings にスキーマが含まれる XmlReader を設定し、それを使用して入力ストリームをノードごとに読み取ることで、一種の方法で実現できます。最後に読み取ったノードを追跡して、検証エラーが発生したときにドキュメント内のどこにいるかを把握できます。
この演習を試してみると、エラー ノードの概念があまり意味をなさない多くの検証エラー (必要な要素の欠落など) があることがわかると思います。はい、その場合は明らかに親要素にエラーがありますが、実際にエラーを引き起こしたのは、リーダーが必要な要素を確認せずに終了タグに遭遇したことです。これが、エラー行と位置が終了タグを指している理由です。