C#, C♯, C＃相談室 Part61

XElement.Parse メソッドで質問があります。
HTMLを上記のメソッドに渡すと
EntityName を解析中にエラーが発生しました
と例外が発生しました。
半角のスペースがタイトルに含まれていたからなのかなと推測しました。
一般的にこういう場合はどのようにしてXElementで解析したらよいのでしょうか？

その原因に即して修正してから読み込むしかないだろ
一般的にはHTMLは正しいXMLじゃないんだから無理というしかない

>>60
つSgmlReader

>>54
＞「ParseとTryParse」のように、二つのメソッドを用意しておくべき。
そういう「べき論」を唱えてもいいけど、何故そうすべきなのかと聞かれたときに
合理的な理由を与えられる？

ただの教条主義じゃないのそれ。

>>55
論点がズレてるなあ。

そのメソッドは常に成功するとは限らない（例外が発生する可能性がある）
ことを示すためにわざわざ妙な値を返してるのに、それでもエラーを想定した
コートを書かない場合を想定しなければならない理由が分からない。

百歩譲ってそういう「馬鹿で怠惰な」プログラマを想定すべきだとして、
「例外が出る場所が問題の発生個所と一致」しないことが、あえて取り上げる必要がある
問題だろうか。

>>60
HTMLのパーサを自前で書くべし
ttp://japan.internet.com/developer/20051115/25.html

>>60
mshtml使う手もあるぞ

>>64
うん、あえてどころか、まじめに取り上げるべき大問題。

>>67
ではその理由をどうぞ。
どうして大問題なの？
NullReferenceExceptionが発生した理由を推定できないプログラマがいるから？

そんな奴はいないと思うが、いるとしてどうしてそんな「馬鹿でどうしようもないプログラマ」
を想定する必要があるのでしょう。

距離はなれてたらしんどいよ。
あと、そんな馬鹿でどうしようもないプログラマも相手にするのがC#だろ。

>>69
＞距離はなれてたらしんどいよ
それは、そういうことが起こるとしたら変数の初期化（または変数への代入）と
その変数の使用を意味なく離して書く悪しきプログラミングスタイルに起因する問題であって、
>>36的な方法を取ったことに起因する問題ではないでしょ。

＞そんな馬鹿でどうしようもないプログラマも相手にするのがC#だろ
もちろんフールプルーフに作ることは大事。
でも、フールプルールとは「ありえないような馬鹿を想定すること」ではないはず。

>>58
ありがとうございます。

>>65
.NETだけでやろうとした場合、自作しかないのでしょうか？
スペースなどの文字を&***のような形に変換するような
機能はないのでしょうか・・・

ダウンロードしたHTMLを解析するというのは
よくある要求だと思うのですが・・・

>>72
普通にDOMでやれよ。

htmlデコード

>>73
domでやるとはどういう意味でしょうか？
ActiveXを使うということでしょうか？

DOMでわかんないなら、初心者スレ行け。

>>72
HttpUtility.HtmlEncode

>>76
DOMは分かりますよ。
でも.NETとは無関係の一般的な用語ですよね。

>>77
求めていたものにとても近いです。
ただタグの<などすべて変換されてしまうので
結局は解析してやらないといけないみたいです。
でもありがとうございました。

>>79
ttp://neue.cc/2010/03/02_244.html
これだろ