タグ

xpathに関するcyokodogのブックマーク (9)

  • 今からでも遅くない JAXPを学ぼう!(前編) XPathとXSLTを体験する

    JAXP(Java API for XML Processing)とは JAXPとはJava API for XML Processingの略であることから、どのようなものか推測できます。XML文書を処理するためのJava APIと言えば何となく理解できるかと思いますが、XML文書を処理すると言ってもJava自らが処理するわけではなく、既にXMLの世界にあるXML文書を処理するための方法を用いて処理することになります。 具体的には次のような仕様を基礎にしています。これらの仕様はJAXPの仕様ではありません。JAXPはあくまでこれらの仕様の上に作られています。 XSLT(XSL Transformations) XPath(XML Path Language) XInclude(XML Inclusions) DOM(Document Object Model) Level 2 DOM Le

    今からでも遅くない JAXPを学ぼう!(前編) XPathとXSLTを体験する
  • JavaのXPath実装の比較 (2007-05-05)

    いままで日語のAPIドキュメントがあるという理由でjavax.xml.xpath.XPathを使っていたのだけれども、隣の芝生であるところのorg.apache.xpath.XPathAPIが異様に青く見えて仕方ないので違いを調べてみた。 一番の違いは、前者はファクトリクラスで生成したオブジェクトを使ってXPath式を評価するのに対し、後者はスタティックメソッドを使ってXPath式を評価する点だと思った。あとはメソッドに渡す引数の型が java.lang.Object か org.w3c.dom.Node かの違いとか、返ってくるのが java.lang.Object か org.w3c.dom.NodeList かの違いとかそんなところ。ちょっと細かく見ていってみよう。 こういうXMLを処理させたい。 <?xml version='1.0' encoding='UTF-8' ?> <d

  • XPath に文字列を埋め込むときの注意 - IT戦記

    よく、以下のように XPath に文字列を埋め込む事があります document.evaluate('//*[@class="' + text + '"]', document, null, 7, null); まあ、僕もよくこんなコード書くんですけど。 でも、これって text が外部から来るものだったら、意図通りの動作をしないんですよね たとえば、以下のような例です。 var text = '"] | /hoge/fuga/piyo | .["'; document.evaluate('//*[@class="' + text + '"]', document, null, 7, null); というわけで 任意の文字列を XPath の式に変換する JavaScript を書いてみた 以下で試せます http://amachang.sakura.ne.jp/misc/xpath_es

    XPath に文字列を埋め込むときの注意 - IT戦記
  • WSH で HTML を XPath したいんじゃあああぁぁ - Wisteria::Diary

    CompleteX で文脈依存のヘルプを表示するために、各種ライブラリ (たとえば 田楽 DLL) のドキュメントを INI ファイル形式に変換したい。ただし、できるだけロバストな記述で*1。具体的には 素の Windows + IE 環境で (不特定多数の一般ユーザーのマシンで*2 ) 必ずしも well-formed でない HTML 文書を対象として XPath を使って内容をスクレイピングしたい という、一見ありがちな要求。なんだけど……これが全く一筋縄では行かないどころか五筋縄以上かいくぐる羽目になりましたことよ。 結論 現在のところ Windows + IE だけでは不可能。サードパーティの XPath 実装を使えば可能。 0 筋縄: 方針の確認 まず、対象が純粋な XML なら簡単にできることを確認。 var dom = WScript.CreateObject("MSXML

    WSH で HTML を XPath したいんじゃあああぁぁ - Wisteria::Diary
  • FirefinderはJavaScriptプログラマ以外も使うべき - monjudoh’s diary

    Firefinderとは何か? https://addons.mozilla.org/en-US/firefox/addon/11905/ CSSセレクタやXPathで要素を検索出来るFirebugの拡張です。 どんな人にお勧めか? hiddenフィールドの値を閲覧したり、 formのどの要素のnameが何かとかさくっと見たくなることないですか? あるならお勧めです。 Firebugには既に$$というCSSセレクタで要素を検索出来る関数があるんだが? CSSセレクタのサポートの度合いが違います。 $$関数では基的なCSSセレクタしかサポートされていないので、 例えば、ここなら、http://images.google.co.jp/advanced_image_search?hl=ja $$('input'); // [input, input ja, input Google 検索, i

    FirefinderはJavaScriptプログラマ以外も使うべき - monjudoh’s diary
  • HTML と XHTML で同じ XPath を使う: Days on the Moon

    通常、XPath を書くときは //p のようにすることが多いと思いますが、これには名前空間の指定が含まれていないため、XHTML 文書 (MIME タイプが application/xhtml+xml で提供されている文書) では使えません。これに対するアプローチとしては、//h:p のようにあらかじめ XPath 式に名前空間の指定を含めておき、リゾルバによる名前空間接頭辞の解決時に HTML と XHTML とで処理を分けるというのが一般的でした。「XPathNSResolver のクロスブラウザとか」や「document.contentType == "application/xhtml+xml"なページでの$X」で扱っている方法です。 とはいえ、いちいち名前空間接頭辞を指定するのは面倒くさいですし、同じ名前空間に対する接頭辞が人によって違うのも不便です。XPath 式の中で要素名

  • XPath で "//" を使う時は気をつけようという話 � のっち大好きの会 分室

    document.evaluate の第二引数に適切なノードを指定していても, XPath expression が "/" で始まるとルートノードから走査されるので, 意図通りの結果が得られない可能性が高い. ありがちなのは AutoPagerize で 2 ページ目以降を処理しようとして XPath に "//" を使ってしまい,結局ページ内の全ノードを舐めてしまうとか. 面倒でも "descendant::" もしくは "descendant-or-self::" を使用されたい. もしくは, getElementsByTagName で済む場合であればそちらを使えば意図通りの結果が得られるし, なにより速いはず. 一応,実験 (要 javascript/).IE では動作しない.

  • XPathGraph がすごい件と、XPath で出来ることのヒント - IT戦記

    XPathGraph とは http://xpath.kayac.com/ URL と XPath を指定すると一日に一回その URL をスクレイピングして XPath 式が示す値をグラフにしてくれる!という画期的なサービスです。 例えば、 URL と XPath を指定するだけで以下のようなグラフが作れてしまいます。 当に楽しいことが出来そうでワクワクしてます! でも まだ XPath を登録している人が意外と少ないので、「ひょっとして、このサービスの使いどころが分からないのかなあ。」と思いました。 というわけで XPath で出来ることのヒントを少し紹介したいと思います。 足し算、引き算、かけ算、割り算 XPath では普通に数値の演算ができます。 たとえば、 //div[@class=counter] で取得してきた div 要素が 1000 という数値を持っていたとすると 2 *

    XPathGraph がすごい件と、XPath で出来ることのヒント - IT戦記
    cyokodog
    cyokodog 2008/04/11
    xpathでグラフ化できるサービスの使いどころのヒント。
  • XPath - 枕を欹てて聴く

    調べてみるとちょっと衝撃を受けたので書いておく。 以下XPathによるFirebug上からの抽出速度。抽出対象はLDR Full Feedで文として指定しているもの。 速度計測法はid:os0xさんのjottit.comのLDRize用XPath - FFFF - 0xで使っているFirebug組み込み関数である$xによる抽出1000回の所要時間。 調査目的は、前から疑問に思っていた、抽出対象がclassなど特定条件で一発で抽出できる場合(//div[@class="entry_body"]など)の以下3つの疑問点 全体からclassなどで一発で抽出するのと、祖先ノードにidのある場合、それをid関数で抽出した後子要素を検索するのではどちらが速いのか。 //div[@id="ほにゃらら"]はマジで遅いのか。 //div[@class="ほにゃらら"]と//div[contains(con

    XPath - 枕を欹てて聴く
    cyokodog
    cyokodog 2008/04/11
    xpathのノード指定の違いによる速度計測。ネイティブ実装でid取得した後絞りこむのが良さそう。
  • 1