この記事は [クローラー／Webスクレイピング Advent Calendar 2015] の一つとして書きました。 公開遅いけど。ごめんね この記事の目標 curl コマンドの使い方を覚えつつ、スクレイピングをやっていきます。 この記事で紹介すること curl curl + grep curl -s curl + md5sum curl + md5sum + mail curl + cookie curl + cookie + xpath curl + xpath + xpath シェルスクリプト実行 用意するもの curl xpath libxml grep ruby nokogiri cookie pry 知っておくと便利な知識 css2 css3 xpath jq js への対応 基本方針は「JSに対応しない」 だって、リクエストヘッダ見てたらわかるもん。 curl コマンドでWE
PythonでスクレイピングをしようとするとBeautifulSoup4やlxmlを使った例が多くあります。今回はlxmlでスクレイピングするときのコツをいくつか紹介します。 lxmlはpip install lxmlでインストールできます。 parse()にはURLを直接渡せる urllibなどを使ってレスポンスをロードしてからlxmlに渡している例が多くありますが、parse()にURLを渡すとそのURLにアクセスして解析してくれます。 >>> import lxml.html >>> tree = lxml.html.parse('http://example.com/') base_urlオプションがURLをもとにセットされるので、相対リンクを絶対リンクに書き換えるでbase_urlを明示的に渡す必要がなくなります。 XPathをコンパイルして再利用する 同じXPathで複数回検索
この記事を三行にまとめると サーバーの数だけ用意するのはちょっと面倒だ 「$i」をインクリメントしてけば良い それで自分が分かるならば phpMyAdminを使ってデータベースの管理をする際、もしサーバーが複数に別れていたら、サーバーの数だけ用意するのはちょっと面倒だ。 そんなとき、一つのphpMyAdminで複数のデータベースサーバーを管理するにはどうすれば良いか。 答えは、config.inc.phpの書き方にあります。 人によって多少違うとは思いますが、config.inc.phpを見ると、こんなような内容が書いてあります。 $i++; $cfg['Servers'][$i]['auth_type'] = 'cookie'; $cfg['Servers'][$i]['verbose'] = 'サーバーの名前'; $cfg['Servers'][$i]['host'] = 'サーバーの
import sys import json import requests from bs4 import BeautifulSoup import codecs def scraping(url, output_name): # get a HTML response response = requests.get(url) html = response.text.encode(response.encoding) # prevent encoding errors # parse the response soup = BeautifulSoup(html, "lxml") # extract ## title header = soup.find("head") title = header.find("title").text ## description descriptio
module.js:340 throw err; ^ Error: Cannot find module 'cookie-parser' at Function.Module._resolveFilename (module.js:338:15) at Function.Module._load (module.js:280:25) at Module.require (module.js:364:17) at require (module.js:380:17) at Object.<anonymous> (path:5:20) at Module._compile (module.js:456:26) at Object.Module._extensions..js (module.js:474:10) at Module.load (module.js:356:32) at Func
英語わかんねっす。 Nightmare Nightmareはハイレベルな自動ページ表示ライブラリーです。 達成したいことは、ネストが深く分かり難いコールバック地獄なしに下のことを実現する シンプルに書ける 同期処理っぽく書ける これは、APIを持っていないサイトのE2Eテスト用に設計されています。 Electronベースでできてます。PhantomJSに似てますが、もっと早くてモダンです。 Daydream Daydreamは@stevenmiller888さんによって作られた、Nightmareを使う際のお助けツール chromeのエクステンションで、ブラウザ操作でNightmare用スクリプトを生成するものです。 Examples yahooをサーチしてみよう var Nightmare = require('nightmare'); var vo = require('vo'); v
この記事はクローラー／Webスクレイピング Advent Calendar 2016の9日目の記事です。 対象 趣味程度で、サクサクっとスクレイピングを始めたい いちいち要素(CSS Selector, Xpathなど)を調べてコードなんて書いていられない マクロみたいにブラウザの操作を記録して再生したいが、痒いところまで届くように柔軟に書き換えたい Seleniumを使ってみよう Webブラウザ操作の自動化などWebアプリケーションをテストするツール、API、フレームワークで有名なSeleniumを使ってみましょう。 Java、Ruby、Pythonといった様々なプログラミング言語で動かすことが出来ます。 言語ですが、自分はRubyが好きなのでRubyを例にとって説明していきます。 Seleniumの主な用途はテストツールで、Selenium Webdriverと呼ばれているライブラリを
スクレイピングのチュートリアルを書いてみた。 参考：http://nokogiri.rubyforge.org/nokogiri/Nokogiri.html まだまだたくさんのクラスやメソッドがあるが(読んでない)、HTMLのスクレイピングに限定すれば多分これくらいで十分。 2014-02-16追記 なんかたくさんブックマークされていることに気づいたので、サンプルコードのRuby1.9/2対応のアップデート。 Mechanize周りも修正。WWW::Mechanize → Mechanize 等 (0) 前提知識 Ruby、HTML、DOM、CSSセレクタまたはXPath (1) クラス構造の理解 Nokogiri::HTML::Document < Nokogiri::XML::Document < Nokogiri::XML::Node < Object Nokogiri::XML::
コピーチェックしたい文章を【文章を登録】に貼り付けて[チェックする]ボタンを押します。【CSV一括登録】、【ﾃｷｽﾄ一括登録】から文章一括登録も可能です。コピペチェック文字数は25文字から4,000文字です。有料プランは8,000文字になります。 コピーチェック実行回数制限はありません。
軽量PHPフレームワークPunyAppというの作りました
最近、ちまちまとPHP を書くことがあって、 ちょっとしたWebアプリ等作るときに CakePHP などのある程度規模のあるフレームワークを使うまでもないかなって思うことが多々あり、 そういった用途に 小規模向けなフレームワーク (マイクロフレームワーク) PunyApp というのを作りました。 以前から自分だけで使ってて少しずつ更新して温めていたもので、 ある程度形になったので公開しました。 軽量で中小規模向けなもので、 おおまかな設計は CakePHP を参考にしてて、使い方も似てます。 PunyApp は MVC モデルで他のPHP拡張等は必要ありません。 ダウンロード Download PunyApp 要件 PHP 5.2.0 + mod_rewrite が有効 (Apache Server) ライセンス MIT 機能/特徴 MySQL, PostgreSQL, SQLite, P
【2021/10/15 追記】 この記事は更新が停止されています。PHP を分かった気になって書いていた不正確な内容が多いため，過去の情報として参考程度にご覧ください。また，完成にたどり着けなかったことをお詫びします。原則的には，公式マニュアルの参照をおすすめします。 目次に戻る XSS攻撃 XSS(クロスサイトスクリプティング) 。JavaScriptを実行するコードを制作者の意図していない場所に埋め込む手法であって、PHPを使って実際にプログラミングをしていくうえで真っ先に考えなければいけないのがこの攻撃に対する対策です。 XSS攻撃が成功するまでの流れ TwitterがXSS攻撃への対策を怠っていたと仮定します。 1. 悪意のあるユーザーの下準備 悪意のあるユーザー(A)が
Warning: Use of undefined constant user_level - assumed 'user_level' (this will throw an Error in a future version of PHP) in /home/rontan/www/wp-content/plugins/ultimate_ga_1.6.0.php on line 524 PHPの設定は「php.ini」で行うことができるのですが、レンタルサーバーや共有サーバーとして利用している場合、「php.ini」を変更することはできません。 そんな時は、.htaccessを利用して、特定のディレクトリ以下のみPHPの設定を変更してあげることで解決できます。 しかし、.htaccessでは全ての設定を変更できる訳ではありません。 phpManualで「PHP_INI_PERDIR」また
fukasawaです。こんにちは。クリスマスイブですね。 つぼログ。のtanakaさんから頂いた熊鈴が机の上にあるのを見て、シャンシャン鳴らしつつ、そこいらを駆けずりまわる光景が一瞬頭をよぎったのですが、そんなキャラでもないことを思い出したので自重しておこうと思います。 最近、携わっているシステムがVPSからAWS環境に移行したのですが、以前と環境が違うこともありちょこちょことトラブルが発生しています。今回はそのトラブルのうちの1つについて書いてみようと思います。AWS初心者ということもあり若干手探りなので、公式ドキュメントの方も合わせて目を通していただけると幸いです。 現象 不具合が発生したのは、とあるシステムの管理画面です。管理画面にはメールを一括送信する機能があり、添付ファイルを付けてメールを送れるようになっているのですが、その添付ファイルがメール送信時に消えてエラーになってしまうと
Webサーバを複数台使用していて、それらをELBでロードバランシングしており、プログラムでセッション変数を使いたいのでSticknessの設定を「Enable Load Balancer Generated Cookie Stickiness」に設定。 まず疑うべきはコードだと思ったので、プログラムを念入りにチェックしてみたのですが、どうもおかしそうな箇所がない。確かにプログラムに問題があればIE8だけじゃなくて他のブラウザでも発生するはずと思い、試しにクッキーの状態を見てみると、「AWSELB」という名前のクッキーが大量に存在してることが判明。 ELBはこのクッキーの値を見て、どのWebサーバに接続するか判断しているのですが、これがURL単位で発行されているようで、そのため大量のクッキーが存在した模様。アクセスのたびにHTMLだけでなくCSSやJavaScriptなどのファイルにもクッ
ELBネタを少し追加でやってみます。 ELBのスティッキーセッションを有効にしてみましょう。 0.スティッキーセッション ELBはデフォルトでは配下のinstanceに均等に負荷分散するため、一定のinstanceにずっと繋ぎに行くといったことはできません。 しかし、Cookie情報を保持させ、一定のinstanceと通信を続けさせることができます。 スティッキーセッションを確立させる方法は2種類あります。 - 時間ベースのセッション維持（ELBデフォルトのセッション維持機能） - アプリケーション制御によるセッション維持 今回はELBの標準機能を使った時間ベースのスティッキーセッションの設定方法を見ていきましょう。 1.準備 ELBの準備をします。 ELBの設定方法はAWS入門 ELB〜マネジメントコンソールとCLI〜[2015年10月版]を参考にしてください。 使用するWEBサーバはA
はじめに 藤本です。 私事ですが、先週「AWS認定Sysopsアドミニストレーター - アソシエイトレベル」を受験しまして、 無事合格しました(8888 更に昨日「AWS認定デベロッパー - アソシエイトレベル」を受験しまして、 無事合格しました(8888 トリプルアソシエイトになりました。 今回はELBのスティッキーセッションがどういうものなのか理解できていなかったので調べてみました。 概要 ELBにクライアントとバインド先を固定するスティッキーセッションという機能があります。 HTTPレスポンスにELBでCookieを埋め込んで、 そのクッキーを基にバインド先のインスタンスを固定するというものです。 ELBのスティッキーセッションはCookieの有効期限設定が2種類あります。 任意の有効期限を指定する アプリケーションのCookieに従う スティッキーセッションを利用したい場合、 アプ
セッションという日本語のイメージこそ、最も注意すべき点です。 WEBサーバーとブラウザの間には、トンネルのような物理的な接続状態は存在しません。 一回ポッキリのデータのリクエスト・レスポンスしかHTTPには存在しないのです。 Cookieとセッションの違い ID・パスワードなど別の画面に遷移しても必要なデータは多々あります。 こうした場合によく使用されるのが、Cookieやセッションです。 CookieはWEBサーバーが発行し、ブラウザが保持するキーと値です。 ブラウザは同じサイトにアクセスする際にはそのCookieをWEBサーバーに送信します。 WEBサーバーはブラウザからのリクエスト毎にその値を参照することができます。 一方セッションはWEBサーバーで保持するキーと値です。 IDやパスワードなどを毎回ブラウザから送信してはセキュリティ的にも問題です。 ログインアクションにより、WEBサ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
