2015/12/04

この記事はPowerShell Advent Calendar 2015の4日目の記事です。

はじめに

今回はPowerShellでWebページのスクレイピングをする際の、ちょっとしたノウハウ集を前後編に分けて紹介したいと思います。

スクレイピングというのは、Webページから文字列を取ってきて、スクリプトから利用可能な形に加工する処理です。昨今は多くのWebサイトやサービスでWeb APIが公開されていて、スクレイピングをせずとも比較的簡単にデータを取得できます。PowerShellだとInvoke-RestMethodコマンドレット等が使えます(その話はまた次回とかにやります)。

しかし現実には、APIが公開されていない等の理由で、HTMLを取ってきて自前で解釈せざるを得ないケースが多々あります。さて、PowerShellではどうやりましょうか、というのが今回の話。様々な方々によってもう色々と語られている分野ではあるのですが、結構細かいハマりどころがあるのでちょっとまとめてみようと思いました。

前編ではまず、Webページからの文字列の取得方法ついてまとめます。

なお、スクレイピングには技術的な問題以外の、微妙な問題(著作権の問題とか、Webサイトへの攻撃と見なされる可能性とか)を含むものなので、その辺りは各自どうかご留意ください。この辺りの話はPowerShellに限った問題ではないので、ここでは詳説いたしません。参考記事:Webスクレイピングの注意事項一覧 - Qiita

Invoke-WebRequestコマンドレットで文字列を取得する

PowerShellでのスクレイピング、基本は何はなくともInvoke-WebRequestコマンドレットです。ただしこのコマンドレットはPowerShell 3.0で追加されたものなので、2.0環境にはないことに注意です。その場合は.NETのWebClientクラス等を使う方法があり、後で述べます。

基本は、

$response = Invoke-WebRequest -Uri "http://winscript.jp/"

のように、Invoke-WebRequestコマンドレットを実行する、だけです。「-Uri」は省略可能です。

このとき$responseにはHtmlWebResponseObjectオブジェクトが格納されています。このうち、指定URLのWebページに含まれているHTMLなどの文字列データは、Contentプロパティに格納されます。つまり、$response.Content に欲しいデータが格納されているので、あとはそれをよしなに利用すればいいわけです。

実はInvoke-WebRequestは、文字列データを取得すると同時に、HTMLの場合はパースしてタグの構造をオブジェクト化までしてくれます。が、それについては次回。

なお、Invoke-WebRequestコマンドレットでは文字列を取得する他、バイナリデータをダウンロードしてファイルとして保存する機能もあります。それについては過去記事をご参照ください。

リクエストにパラメータを付与する(GET)

GETメソッドを用いてクエリを指定する場合、要はhttps://www.google.co.jp/search?q=PowerShell のようなURLのデータを取得する場合は、Invoke-WebRequest "https://www.google.co.jp/search?q=PowerShell" のようにQueryStringを含んだURLをそのまま指定するだけでOKです。

ただし、動的にクエリを組み立てる場合は、URIエンコード(URIエスケープ)を考慮する必要があります。もっとも簡単なのは

$searchWord = "PowerShell 配列"
$response = Invoke-WebRequest "https://www.google.co.jp/search?q=$([Uri]::EscapeDataString($searchWord))"

のように、Uri.EscapeDataStringメソッドを使う方法かと思います。

リクエストにパラメータを付与する(POST)

POSTメソッドでリクエストボディにパラメータを付与するには、Invoke-WebRequestコマンドレットの-Methodパラメータに"Post"を指定し、-Bodyパラメータにリクエストボディに付与するデータを連想配列で指定します。

たとえばブログのトラックバックを手動で撃つにはこんな感じでいけます。

$body = @{title="テスト";url="http://example.com/";excerpt="テスト";blog_name="test"}
Invoke-WebRequest http://ご自分のブログのトラックバックpingURL -Method POST -Body $body

なお、リクエストボディに含めるパラメータの各値(連想配列の値)は、自動でURIエンコードしてくれます。

(12/16追記)
また、-Bodyには連想配列のみならず、任意の文字列(URIエンコード要)やバイト配列(バイナリを送信する場合)を指定することも可能です。

標準認証が必要なページを取得する

ページの取得に標準認証が必要な場合は、-Credentialパラメータにユーザー名とパスワードを指定したPSCredentialオブジェクトを指定すればOKです。

セキュリティのことは取りあえず置いておき、簡易的にスクリプトに生パスワードを直書きしてもいいかな、という場合には以下のように書くことができます。

$userName = "user"
$password = "pass"
$credential = New-Object PSCredential $userName, (ConvertTo-SecureString $password -AsPlainText -Force)
Invoke-WebRequest 認証が必要なページのURL -Credential $credential

しかしこの方法はもちろんお勧めできないので、スクリプトとして保存する場合は通常はパスワードを暗号化しておきます。

まず、Get-Credential ユーザー名 | Export-Clixml cred.xmlを、スクリプトを実行するコンピュータ上で、スクリプトを実行するアカウントと同じアカウントで実行します。パスワードを入力するダイアログが出るので、Webサイトにログオンする際のパスワードを入力します。すると、ユーザー名と暗号化されたパスワードがcred.xmlに出力されます。

スクリプトからは

$credential = Import-Clixml cred.xml
Invoke-WebRequest 認証が必要なページのURL -Credential $credential

のようにすると、cred.xmlからユーザー名と復号したパスワードを、そのまま-Credentialパラメータに渡すことが可能です。

なおcred.xmlに含まれる暗号化パスワードは、ConvertFrom-SecureStringコマンドレットと同様、Windows Data Protection API(DPAPI)を用いてWindowsアカウントのパスワードをキーに利用して暗号化されているので、他のユーザーが復号することはできません。

ちなみに同一スクリプトファイルに暗号化パスワードを含めておくこともできなくはないです。過去記事参照。あと本当は資格情報マネージャーを使うのがいいんですが、…略。参考:PowerShell で Windows の 資格情報マネージャー を利用する (Jenkins などでの Git Credentialなど) - tech.guitarrapc.com

セッション情報を引き継ぐ

多くのWebアプリケーションは、同一クライアントからの連続したアクセスを、セッションという単位で管理します。

サーバーはクライアント(普通はWebブラウザ)の初回アクセス時にセッションIDを含むcookieを返し、クライアントからの2回目のアクセス時に、サーバーはcookieにセッションIDが含まれているかどうかを確認し、同一クライアントからのアクセスかどうかを判断するわけです。(ざっくりした説明ですが)

WebブラウザではなくInvoke-WebRequestを使ったアクセスでも同様に、以下のようにすれば受けとったcookie等のセッション情報を次回アクセスに引き継ぐことができます。

$url = "https://ログオンが必要なサイト"
$body = @{リクエストボディ(例えばユーザー名とかパスワードとか)}
$response = Invoke-WebRequest $url -SessionVariable sv -Method POST -Body $body
Invoke-WebRequest $url -WebSession $sv

初回アクセス時に-SessionVariableパラメータに指定した変数名(sv)の変数($sv)にはWebRequestSessionオブジェクトが格納されます。この中に、サーバーから受け取ったcookie等の情報が格納されています。

次回アクセス時には、-WebSessionパラメータに、初回アクセス時に得られたWebRequestSessionオブジェクト($sv)を指定します。

さて、実際のWebアプリケーションではcookie以外にも、Formのhiddenフィールドの値などもセッション管理に用いていることがあります。その場合は、初回アクセスのレスポンスからFormに含まれるinput type="hidden"なフィールドを抽出し、次回アクセスのリクエストボディに含ませる必要が出てきます。この辺りの話は後編で述べるパースが必須になってくる(し、長くなる)ので今回は詳説しません。Invoke-WebRequestコマンドレットのリファレンスのExample2に、Facebookにログオンする例なんてのがあるので、そちらで雰囲気をつかんでください。(今でも動作するかは確認してないですが)

エラートラップ

さて、Invoke-WebRequestは、タイムアウトになった、名前解決ができなかった、ページが無かった(404エラー)等々、正常にWebページを取得できなかった場合は、System.Net.WebExceptionというエラーを出します。

コマンドレットの出すエラー(Errorストリームに出力されるErrorRecord)は、try...catchステートメントでは捕捉できない、というのが原則ですが、Invoke-WebRequestコマンドレットのエラーは一般的なコマンドレットと異なり、普通の.NETの例外(System.Net.WebException)なので、try...catchステートメントでエラートラップを行います。

とは言え、Invoke-WebRequestコマンドレットの仕様上、エラートラップをして適切な処理を行うのは非常にめんどいです。何故かというと、Invoke-WebRequestがエラーを出した時点で、HtmlWebResponseObjectオブジェクトの出力は行われないので、このオブジェクトから得られる様々な情報(レスポンス文字列、ステータスコード等々)が取得できないからです。

じゃあどうすればいいのかという話なんですけど、どうもWebExceptionオブジェクトのResponseプロパティを見るしかないようです。具体的にはこんな感じ。

try
{
    $response = Invoke-WebRequest http://存在しないページなど
}
catch [System.Net.WebException]
{
    # HTTPステータスコード取得
    $statusCode = $_.Exception.Response.StatusCode.value__

    # レスポンス文字列取得
    $stream = $_.Exception.Response.GetResponseStream()
    $reader = New-Object System.IO.StreamReader $stream
    $reader.BaseStream.Position = 0
    $reader.DiscardBufferedData()
    $responseBody = $reader.ReadToEnd()
}

せっかくInvoke-WebRequestコマンドレットは、生のレスポンスを利用しやすくHtmlWebResponseObjectという形で返してくれるのに、エラー発生時はその恩恵を受けることができず、泥臭い処理が必要になります。これはかなりいけてないですし、どうせここまで書かないといけないのであれば最初からWebClientクラスを使った方がいいと思います。

httpsで無効な証明書が使われている場合

(12/16追記)
Invoke-WebRequestコマンドレット(およびWebClient)では、httpsで始まるURLからもダウンロード可能ですが、サイトで用いられている証明書に問題がある場合(期限が切れている、暗号化形式に問題がある、いわゆるオレオレ証明書である等)には、「要求は中止されました。SSL/TLSセキュリティで保護されているチャネルを作成できませんでした」というエラーが出てしまいます。

これを回避するには、Invoke-WebRequestコマンドレット実行前に、

[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}

という1文を記述しておきます。

ただし、証明書に問題があるということは、その通信相手が正当かどうか、通信内容が正しく秘匿されているかどうか、保証がされなくなるということですから、その点は念頭においてください。

文字化けの問題

Invoke-WebRequestコマンドレットのもう一つの悩ましい問題、それは文字コードです。実はInvoke-WebRequestコマンドレットには、Webページの文字コードを指定する方法がありません。(多分)

ではレスポンス文字列の文字コードがどのように決まるかというと、サーバーが返すレスポンスヘッダのContent-Typeフィールドで指定されているcharsetです。具体的には、$response.Headers["Content-Type"]の値が例えば"text/html; charset=UTF-8"であれば、$response.Contentの文字コードはUTF-8になります。

このときページ(HTML)を記述している文字コードと、レスポンスヘッダで指定されている文字コードが一致すれば全く問題はないのですが、異なる場合は容赦なく文字化けします。

異なる場合だけでなく、レスポンスヘッダのContent-Typeフィールドに文字コードの指定がない場合はASCIIと見なされるので、日本語のページの場合はやはり文字化けします。

この問題を回避する方法は、私はまだ見つけていません。よって文字化けが起きる場合は、諦めてWebClientを使って文字コードを指定するようにしています…。

WebClientを用いる

以上で述べてきたとおり、Invoke-WebRequestコマンドレットは、ページをさくっと取得して、さくっとパースするのには重宝するのですが、細かい所で融通が利かない印象があります。

そこで細かい処理が必要な場合(と、PowerShell 2.0環境)は、素直にWebClientクラスを用いるのがいいと思います。今回WebClientの使い方も入れようかと思いましたが、長くなったので詳しくは省略します。

基本は以下のような感じでDownloadStringメソッドを使って文字列を取得します。文字コードも指定できます。

$client = New-Object System.Net.WebClient
$client.Encoding = [System.Text.Encoding]::UTF8
$content = $client.DownloadString("http://アドレス")

なお、WebClientを用いた場合でも、Invoke-WebRequestと同等のHTMLパースを行う方法は存在するので、それは次回に。

おわりに

今回はまず、Webページから文字列データを取得する部分にフォーカスしてみました。といっても、Invoke-WebRequestの機能を全部網羅したわけではなく、使用頻度が高そうなものと個人的ハマリポイントがあるところだけです。なので詳しくはリファレンスを見て下さい。というかハマリポイントたぶんまだまだ一杯あると思います。

後編では、とってきた文字列データを「パース」して、扱いやすいデータ形式に変換する方法についてまとめようかと思います。

2013/09/23

(※12/22付記。12/21にこのセッションのブラッシュアップ版セッションを行いました。こちら

9/21に福井県あわら温泉で実施された ITごった煮勉強会vol.2@福井 で、PowerShell 4.0 の新機能である、PowerShell Desired State Configuration (DSC) についてのセッション(30分)をしてきました。以下が発表で使ったpptxの資料となります。

DSC とは Desired (望まれる) State (状態に) Configuration (構成する) の略で、サーバー設定が「望まれる状態」に構成されることを実現するための、Windows Server 2012 R2 / Windows 8.1 で新たに追加されたシステム管理機能です。

PowerShell DSC は、Configuration という新しいキーワードで定義される PowerShell の拡張構文で記述します。

Configuration は、従来の命令型(Imperative)構文 = 「どのように行うか」ではなく、宣言型(Declarative)構文 = 「どういう結果になるべきか」で記述することができます。

Configuration 構文は、例えば、条件分岐して○○のときは○○して…といった手順をプログラミングする必要はなく、「設定ファイル」のように設定項目と設定値を列挙するだけで、DSC 実行後に保証される状態を記述することができるので、プログラミングに明るくないシステム運用者の方にも抵抗なく使うことができると思います。

開発者は従来通りアプリケーションの機能を呼び出すコマンドレットを作成するのに加えて、DSCで用いる「カスタムリソース」も実装することになります。

DSC を用いたシステム構築を行えば、開発者と運用者がより密に連携できるようになるので、継続的デプロイが可能となり、 DevOps 実現のための道具の一つとなるものと思います。

先日、Windows Server 2012 R2 および Windows 8.1 の RTM 版がMSDN /TecnNet Subscription でダウンロード可能になりましたが、目玉機能(?)となる PowerShel DSC についての情報、特に日本語のものがあんまりネット上に見当たらないので、このスライドを参考にしていただければいいかな、と思います。

2013/03/24

Windows 8[業務アプリ]開発読本:書籍案内|技術評論社

9784774156057

というわけで、私が企画協力させていただいた「Windows 8 [業務アプリ] 開発読本」という書籍が技術評論社さんから3/27に発売となります。この書籍は書名通り、Windows 8対応の業務アプリを作成するためのノウハウを、私のお友達を中心とした皆さんによって書かれたものとなります。執筆者を募集したときは特に意識はしてなかったのですが、結果的にMicrosoft MVPやMicrosoftエバンジェリストをはじめとしたエキスパートで占められるという何とも豪華な執筆陣となっています。

Windows 8の開発書籍ということで、Windowsストアアプリ開発法をメインに据えた構成となっているのはもちろんのこと、従来のデスクトップ(Windows Forms / WPF)アプリとの違いや移行方法、ストアアプリとデスクトップアプリをどう作り分けていくか(既存のデスクトップアプリのうちどこをストアアプリ化するのか)、といった視点も盛り込んでいます。

というのもストアアプリはタッチデバイスを想定した新しいプラットフォームではあるものの、業務システムすべてをストアアプリに置き換えるというのは得策とは言えないケースが多々あるためです。逆に業務システムのうちストアアプリ化すると効率が上がる部分も多く存在しており、本書では業務システムをグレードアップさせるためのストアアプリ開発を、概念、UI設計から具体的なコードにいたるまで詳しく取り上げています。

私もWindows 8業務アプリを開発する上で、DevOps(開発と運用の協調)を実現するためにPowerShellモジュールをアプリに組み込み、運用サイドでもアプリ操作の自動化を容易に行う方法についての記事を書かせていただいてます。

本書はストアアプリを中心にクラウド等の周辺テクノロジーを包括した、Windows 8時代の業務システム開発とはどのようなものであるか、どのように行っていけばいいのか、という指針を提示できているのではないかと思っています。Windows開発に携わる方はぜひお手にとって見ていただきたい一冊です。どうぞよろしくお願いします。

3/29追記。
本書のサポートページが公開になりました。特集1と私の記事のサンプルファイルがダウンロード可能になっていますので、ご活用ください。

2012/11/21

先日、Windows Server 2012がRTMされたのと同時に、Windows 7/2008/2008 R2用のPowerShell 3.0を含むWindows Management Framework (WMF) 3.0パッケージも公開になりました。

Download WMF 3.0 from Official Microsoft Download Center

また、Windows Server 2012を管理するためのWindows 8用リモートサーバー管理ツール(RSAT)も公開されました。サーバーマネージャーやAD管理センターなどの管理ツール、Windows Server 2012の「役割」と「機能」に対応するPSモジュールが含まれています。

Download: Windows 8 用 RSAT - Microsoft Download Center - Download Details

(残念ながらWin Server 2012を管理するWin7用のRSATはないようです)

さて、PowerShell 3.0はローカルヘルプが標準では含まれていないので、Update-Helpコマンドレットを管理者権限で使ってダウンロードする必要があります。が、現状では日本語ヘルプが存在しないので、ローカルでヘルプが引けないというちょっとアレな状況になってます。

この状況、いつかは改善されるとは思うのですが、とりあえずの回避策を書いておきます。以下のスクリプトを管理者権限で実行してください。

Update-Help -UICulture en-us -Force
mkdir $pshome\ja-JP_backup
copy $pshome\ja-JP\*.* $pshome\ja-JP_backup\
copy $pshome\en-US\*.* $pshome\ja-JP\

このスクリプトはUpdate-Helpコマンドレットにより英語ヘルプ(ロケールen-us)を$pshome\en-USにダウンロードします。その後、ダウンロードしたヘルプファイルをそのままja-JPフォルダにコピーします。その際、念のためにバックアップをja-JP_backupフォルダにとっておきます。

これで日本語環境のpowershell.exeでもとりあえずは英語版のヘルプを引くことが出来るようになります。

(2013/01/18追記。Windows 8とServer 2012では、Update-Help -UICulture en-us -Forceを管理者権限で実行するだけで、日本語環境でも英語ヘルプが表示されます。)

日本語ヘルプがダウンロード可能になればこの作業は必要ないですが、それまでの暫定措置としてご利用ください。

この作業に抵抗がある方は、オンライン版英語ヘルプを参照するのでもいいかと思います。

Windows PowerShell Core Modules
これはPowerShell 3.0に標準添付のモジュールとそれに含まれるコマンドレットのリファレンスです。

Windows PowerShell Support for Windows Server 2012
これはWindows Server 2012 / Windows 8に付属のモジュールとそれに含まれるコマンドレットのリファレンスです。

powershell.exeで Get-Help コマンドレット名 -Online とすることでWebブラウザを開いてこれらのヘルプページを直接表示することも可能です。

さて、ヘルプが揃ったところで、さっそく新しいコマンドレットを試してみましょう。そしてその成果をぜひ、PowerShell Advent Calendar 2012で発表してください!!

2007/11/08

元ネタ:ひろえむさんとこ田辺さんとこ

PowerShellの付属ヘルプをHTMLヘルプ形式(.chm)にしたものが公開になりました。

Windows PowerShell Graphical Help File (Version 2.0) (英語)
http://www.microsoft.com/downloads/details.aspx?FamilyID=fefb2572-559a-46fe-978d-5a00490b20fa&DisplayLang=en

Windows PowerShell Graphical Help File (英語)
http://www.microsoft.com/downloads/details.aspx?FamilyID=3b3f7ce4-43ea-4a21-90cc-966a7fc6c6e8&DisplayLang=en

Ver 2.0なんてまだCTPなのになんて気が早いw
前に公開されてたやつに加えて、Technetの記事も同梱されたみたいですー。ただ英語版のみなのがつらいところですね、相変わらず。

加えて、田辺さんのブログによるとスクリプトセンター総集編がダウンロード可能になったそうです。

Script Center All-in-One (英語)
http://www.microsoft.com/downloads/details.aspx?FamilyID=75cca21a-53b9-4949-9b62-a8fc7926e914&DisplayLang=en

Sesame Script, 2005-2007 (英語)
http://www.microsoft.com/downloads/details.aspx?FamilyID=ff973fbe-9382-4e4c-80de-e7de14fd83e6&DisplayLang=en

The Hey, Scripting Guy! Archive: Volume 2
     (August 2004 - September 2007) (英語)
http://www.microsoft.com/downloads/details.aspx?FamilyID=5f5e0bda-923a-4744-8289-afb73f6a5ed8&DisplayLang=en

これも英語なのが(ry でもあると便利かもしれないですね。

元記事:http://blogs.wankuma.com/mutaguchi/archive/2007/11/08/107001.aspx

2007/01/15

平日の夜というお忙しい時間の中、わんくま同盟大阪勉強会#5にご参加いただきありがとうございました。

今回は私の単独セッションで、1時間20分みっちりPowerShellの話をさせていただきました。前回(PowerShellのシェルとしての機能紹介)の復習を前半に、スクリプト言語としてのPowerShellについてを後半に、それぞれデモを交えながらの講演でした。

皆様にPowerShellの魅力が伝えられたようで嬉しく思います。

講演のPowerPointスライドおよびデモの手順を記したテキストファイル、デモで用いたスクリプトファイルは勉強会のページから後ほどダウンロード可能になりますのでご参照ください(「zip」にあるのがデモ用ファイルです)。また、講演のようすをビデオ撮影していただいたので、その動画も後日公開予定ですのでこちらもどうぞ。

今度もし機会があれば、PowerShell実践編として、実際にシステム管理に使う方法をまとめてご紹介したいですね。こんな風に使いたい、こんなことはできないの?、等々、いろいろ意見をお待ちしています。わんくまでブログをお持ちの方はそちらで書いていただければ見に行きますw

元記事:http://blogs.wankuma.com/mutaguchi/archive/2007/01/15/56343.aspx


Copyright © 2005-2018 Daisuke Mutaguchi All rights reserved
mailto: mutaguchi at roy.hi-ho.ne.jp
プライバシーポリシー

Books

Twitter