PHPで形態素解析とMySQLで全文検索

備忘録メモです。長ったらしいタイトルっす。

ブログの簡易版みたいなスクリプト(管理者だけが書き込める掲示板みたいなやつ)の改造をちょっと前に依頼されたんですが、その中で検索機能(全文検索)を付けるというのがありました。全文検索っていっても、入力された単語にマッチしたレコードを全部表示する、要はSQLクエリーのselect文でlike演算子でマッチさせるだけでいい、ということだったんですが、ただでさえ、面白くないPHPの仕事だし(^^;;;、それだけでは僕にとっても得るものが少ないので(^^;、もうちょっと勉強になるものを作ってみよう、ということで調べました。

仕事しながら勉強って・・・ま、いいか。

日本語の文章をMySQLで全文検索させるには(FULLTEXTインデックスってことね。)、まず日本語の文章を形態素解析にかけて、名詞・動詞・助詞・・・といった風に分解することから始めなければいけません。英文などでは単語間は必ずスペースもしくはカンマで区切られますから、特に意識しなくても済むのですが、日本語の文章や主にアジア圏の言語では、そう簡単にはいきません。

幸いにもフリーで使用できる形態素解析エンジンは結構豊富にあります。有名なものとして、KAKASIやMeCab、Igoなどがあります。が、一般人が実際に使用するには、結構ハードルが高いものです。

まず、何よりレンタルサーバーなどの一般的なサーバーではほぼこのようなライブラリはインストールされていませんし、新たに追加できることは不可能でしょう。でも、最近では非常に低コストのVPSサーバーがあるので、それなりに知識がある人は導入できるでしょうけど、サーバー管理の知識がない方にとっては難しいでしょう。

ただ、PHP、しかも、レンタルサーバーでも利用できる・・・という条件だと、選択肢は非常に限られると思います。その中でも小規模なサイトに必要十分なものとして、Igo-PHPが手軽に利用できて、サイトへの組み込みも少ない工数で行えると思います。

Igo-PHPは、Javaの形態素解析エンジンIgoのPHP移植版で、Igo同様、MITライセンスで自由に利用できるというありがたいライブラリです。作者に感謝です。

流れとしては・・・

  1. Igo-PHPのダウンロード
  2. Igo本体のダウンロード(辞書生成に必要。別途Java実行環境が必要)
  3. 辞書の元となるファイルをダウンロード(MeCabサイト→ダウンロード→Mecab用の辞書(IPA辞書)
    (2017-10-22 リンク先修正)
  4. 2)でダウンロードしたIgo(Javaプログラム)を使用して辞書を生成。
    3)でダウンロードしたファイルを展開し、以下のコマンドをうつ。Windowsだと java.exeがあるディレクトリが%WINDIR%や%PROGRAMFILES%にあったりと環境によって違うと思います。

    >> java -cp igo-0.4.3.jar net.reduls.igo.bin.BuildDic ipadic mecab-ipadic-2.7.0-20070801 EUC-JP

といった感じになります。これらは全部Windows上で行えます。あとは・・・PHPスクリプトからIgo-PHP、生成した辞書を使って形態素解析ができます。

生成されたipadicディレクトリに辞書がビルドされていますので、以後、このipadicディレクトリとIgo-PHPだけを使用します。

WindowsにPHPをインストールされている方は、下記のようなスクリプトを作成して実行してみてください。

<?php
// test.php

// Igo-PHPとipadicディレクトリを 'lib'というディレクトリにまとめて置いとく。
require_once 'lib/Igo.php';
 
$igo = new Igo("./lib/ipadic");
$text = "私には夢がある。";

// 詳細な結果が欲しい場合は、parseメソッド
//$result = $igo->parse($text);

//単に区切ればいいだけなら、wakatiメソッド
$result = $igo->wakati($text);

//それぞれ、単語の配列が返ります。

echo mb_convert_encoding(implode('/',$result),'SJIS');

実行すると、こんな結果がでました。ちゃんと分解されてますね。

>>php test.php
私/に/は/夢/が/ある/。

さて、検索される文章・記事は、MySQLのデータベースに入れることが多いのでMySQL + PHPでの組み込みを中心に。

MySQLでテーブルを作成する際に、記事などを格納させるカラムとは別に、検索用のカラムを一個追加して、そのカラムにFULLTEXTインデックスを張ります。以下のような感じですかね?

CREATE TABLE  posts (id INT,title TEXT,content TEXT,content_s TEXT,FULLTEXT(content_s));

というようなテーブルを用意しておいて、INSERT,UPDATEする際に、contentの内容を形態素解析にかけ、名詞のみ抜き出し、content_sに抜き出した単語を半角スペース区切りでつなげた文字列を格納しておく。要は検索インデックスをcontent_sに貯めておくという方法です。

英語ならば、語と語は必ずスペースで区切られるから、こんなめんどっちーことをしなくてもいいんですが・・・。
データをINSERTするときは、こんな感じでしょうか。

<?php
$igo = new Igo("./lib/ipadic");
$pdo = new PDO('mysql:dbname=testdb;host=localhost','dbuser','password');

//テーブル作成
$pdo->exec('CREATE TABLE posts (id INT,title TEXT,content TEXT,content_s TEXT,FULLTEXT(content_s))');

//テストデータを用意
$id = 1;
$title = '私には夢がある。';
$content = '私には夢がある。私の四人の幼い子ども達が、いつの日か肌の色ではなく人格そのものによって評価される国に住めるようになるという夢です。';

//形態素解析
$result = $igo->wakati($content);
$content_s = implode(' ',$result);

//INSERT文組み立て
$sql = sprintf("INSERT INTO posts(id,title,content,content_s) VALUES(%d,'%s','%s','%s')",
               $id,
               $pdo->quote($title),
               $pdo->quote($content),
               $pdo->quote($content_s));

//クエリー実行
$pdo->exec($sql);

$pdo = null;
$igo = null;

こんな感じでデータをどんどん追加して、

で、全文検索させたいときは、contentカラムを検索するのではなく、content_sカラムを全文検索させるように、

SELECT * FROM posts WHERE MATCH(content_s) AGAINST('検索単語',IN BOOLEAN MODE);

と、するだけ。

ただ、これだけだと、ちょっと不便なことがあります。形態素解析にかけると、辞書にある単語を元に解析するので、二つ以上の名詞がくっついて一つの名詞になるような語がバラバラになってしまいます。

たとえば、「神戸市」の結果は、「神戸」と「市」に分かれてしまいます。「神戸市」と一つの単語で登録したい場合などは、ひと手間かける必要があります。

全文検索以外の他の用途でも使えそう。漢字混じりの文章をすべて平仮名や片仮名に変換したりも可能なので、使い道は結構あると思います。

またデスクトップアプリの機能として形態素解析エンジンを使いたい場合は、.NETアプリで使用できるNMeCabというMeCabの.NET移植版がありますし、形態素解析というと、ものすごく難しい、というイメージですが結構簡単に自分のアプリにも組み込めたりできますので、もっと活用の場があってもいいと思います。

iPadで簡易”view-source”

撮影した写真をその場で確認したり、机の前に置いて見るだけの高価なフォトフレーム化しているiPad(^^;;

先日、iPadのブラウザでホームページを巡回していたら、ちょっと気になったページがあって、HTMLソースを見ようとしたら・・・・見れない。というか、iPadのSafariは、ソースを見ることができない・・・。ダメ元で、アドレスバーに “view-source:http://hoge~ “と入力してみたけど、「アドレスが無効です」とかいうエラー。ま、当然やな。

しょうがないので、ブックマークレットでなんとかやってみる。

とりあえず、どこかのページを開いてブックマークを追加し、ブックマークの編集でURLに以下をコピペ。

javascript:(function(){var w=window.open();var d=w.document.open();var t=window.document.getElementsByTagName("html").item(0).outerHTML; t=t.replace(/</g,"&lt;");t=t.replace(/>/g,"&gt;");t=t.replace(/ /g,"&nbsp;");t=t.replace(/\n/g,"<br>"); t=t.replace(/\t/g,"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"); d.writeln("<!doctype html>");d.writeln("<html><head><title>View-Source</title><style type='text/css'><!-- body{font-size:12pt;} --></style><body>",t,"</body></html>");})();

やってることは、<,>と空白、タブ、改行をエスケープして貼り付けてるだけ。TextNodeを生成して<pre>タグに放り込めばもっと短くなるんだけど、非常に長い行があるソースだと改行されず非常に見づらいのであえてメタ文字をエスケープしてBODY要素に放り込んでます。

検索すると、ソースそのものを外部サーバーに送って整形する・・・という手法が一般的みたいですが、「ちょっとだけ確認したいんや!」という用途にはちょうどいいかな、と自己納得w

そういえば・・・ iPad mini って出るんですかね?出ても買えないけど。

C#でWordPressのエクスポートファイルを取得する

とある業務ソフトのヘルプをWordpressのブログシステム上で作成しよう、ということになってまして、まぁ、フツーはそのWordpressをユーザー認証をかけて、そのまま公開すれば話は済むんですが・・・普通はね・・・。でもクローズドな環境にも対応しなければいけません! とかいう、メンドクサイ仕様になってまして・・・。
それなら、Wordpressなんか使う必要あらへん、ホームページビルダなり、なんなり、使いやすいソフトにすればいいじゃねーの? とフツーはなるんですが・・・。
まぁ、ヘルプ作成について色んな方法を僕がいくら提案しても受け入れてくれないのは分かっているので、グダグダ文句を言っても始まりません。 結局は、ヘルプファイル(HTML)はローカルに置けるように、Wordpressの記事をすべてHTMLに落とすという全くもって本末転倒&意味不明のプログラムを組むことで落ち着きました。

はじめは、そんなの誰かがもうやってるだろう・・・とググったけど、探し方がまずいのか、ヒットしません。ま、そりゃ、そーだよな、わざわざWordpressの記事を全部HTMLに落とすなんてこと・・・する必要もねーし、そんなヘルプの作成の仕方しているの素人集団のウチだけだよな。

ま、グチを言ってても始まりません(笑)

WordPressはXML-RPCをサポートしてますので、XML-RPCで・・・と思ったんですが、Wordpressが吐き出すWXR形式のエクスポートファイル(XML)をダウンロードしてパースした方が早いんじゃねーの? という根拠のない脳内ベンチを信じて、C#で組み始めることに。

エクスポートファイルをパースしてHTMLファイルを一気に吐き出すコードは簡単にできたんですが、エクスポートファイルをWordpressから排出させるところで躓いた。

サーバー上のWordpressへのアクセスに System.Net.WebClient クラスを使ったんですが・・・ログイン処理、具体的にはクッキー処理がうまく行かず、ちょっと時間がかかってしまいました。ネットで検索して出てくる、WebClientを継承して、GetRequestメソッドをオーバーライドしてCookieを保存できるようにカスタマイズしたWebClientを試してみたんですが、どういうわけか、Wordpressへのログインは成功するんだけど、クッキーが保存されないのでログイン画面にリダイレクトされてしまう。
結局、HttpWebRequestの自動リダイレクトを無効/AllowAutoRedirectプロパティをfalseにすることで、解決しました。

/*
  エラー処理・タイムアウト処理はしていない。
*/
using System;
using System.Collections.Generic;
using System.Collections.Specialized;
using System.Text;
using System.Text.RegularExpressions;
using System.Linq;
using System.Net;
using System.Threading;

///<summary>
/// 自動リダイレクトを無効にするため、WebClientを継承します。
///</summary>
class XmlWebClient : WebClient
{
  protected override WebRequest GetWebRequest(Uri address)
    {
      WebRequest request = base.GetWebRequest(address);
      
      if (request is HttpWebRequest)
        ((HttpWebRequest)request).AllowAutoRedirect = false;
      
      return request;
    }
  
  ///<summary>
  ///エクスポートファイルを新規スレッドでダウンロードする。
  ///非同期APIを使えばいいんですが、ややこしいので、スレッドを一本起こしてます。
  ///</summary>
  public static Thread GetWXRFileAsync(string url,string user,string phrase,string ofilepath,Action cb)
    {
      try
        {
          var thread = new Thread(o =>
                                  {
                                    GetWXRFile(url, user, phrase, ofilepath);
                                    cb();
                                  });
          
          thread.Start();
          return thread;
        }
      catch(Exception exception)
        {
          throw exception;
        }
    }
  
  ///<summary>
  ///エクスポートファイルをダウンロードする。
  ///</summary>
  public static void GetWXRFile(string url,string user,string phrase,string ofilepath)
    {
      var xwc = new XmlWebClient { Encoding = Encoding.UTF8 };
      
      xwc.Headers[HttpRequestHeader.UserAgent] = "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)";
      xwc.Headers[HttpRequestHeader.Referer] = url + "wp-login.php";
      
      var param = new NameValueCollection();
      param.Add("log", user);
      param.Add("pwd", phrase);
      param.Add("rememberme","forever");
      param.Add("wp-submit","login");
      param.Add("redirect_to",url + "wp-admin/");
      param.Add("testcookie","1");
      
      xwc.UploadValues(url + "wp-login.php",param);
      
      string setCookie = xwc.ResponseHeaders[HttpResponseHeader.SetCookie];
      string[] cookies = Regex.Split(setCookie, "(?<!expires=.{3}),")
        .Select(s => s.Split(';').First().Split('='))
          .Select(xs => new { Name = xs.First(), Value = string.Join("=", xs.Skip(1).ToArray()) })
            .Select(a => a.Name + "=" + a.Value)
              .ToArray();
      
      xwc.Headers[HttpRequestHeader.Cookie] = string.Join(";", cookies);
      xwc.DownloadFile(url + "wp-admin/export.php?content=all&download=true", ofilepath);
    }
}

クッキー処理のところは、たまたま検索したページ(サイト失念(m_m))のコピペ。SetCookieヘッダーの処理って面倒なんですよね・・・助かる(^^)
あとは、下記のように WordPressのURLとログイン名・パスワード・ダウンロードするエクスポートファイルを保存するファイルパスを指定してコールするだけ。

//ダウンロード
XmlWebClient.GetWXRFile("ワードプレスのURL","ユーザー名","パスワード","ファイルパス");

//おまけで、コールバック関数を指定して別スレッドで動かす「なんちゃって非同期バージョン」
//Windowsフォームを使うアプリだと、非同期は必須っすね。
XmlWebClient.GetWXRFileAsync("ワードプレスのURL",
                             "ユーザー名",
                             "パスワード",
                             "ファイルパス",
                             () => {Console.WriteLine("エクスポートファイルの取得が終了しました。");});

iframeのloadイベント 【書き直し】

今月の初めに書いた投稿が、完全に勘違いだったので、削除して改めて書き直し。

jQuery(1.7.2)でiframeを動的に生成して、そのloadイベントを書いてたときに、どうしても理解できないことが一つあります。
たぶん、僕が無知なだけかもしれませんが・・・

// &lt;a id=&quot;test&quot; href=&quot;http://somewhere.url/&quot;&gt;iframeにリンク先をロードさせる&lt;/a&gt;
// というような、HTMLがあって、

;(function($)
  {
    $('a#test').click(function(ev)
                      {
                        ev.preventDefault();
                        ev.stopPropagation();
                                          
                        //クリックされたアンカータグのhref属性を保存。
                        var href = this.href;
                        
                        //デバッグ用のカウンタ
                        var count = 1

                        //iframeを生成して、そこに読み込ませます。
                        var $iframe = $(document.createElement('iframe')).appendTo(document.body);
                        
                        //onloadイベントでチェック
                        $iframe.load(function()
                                    {
                                      console.log([count++,this.src]);
                                    });

                        //普通に読み込むと、ログには [1,'http://somewhere.url/'] が表示されます。
                        $iframe.attr('src',href);
                        
                        //window.setTimeout(function(){$iframe.attr('src',href);},100);
                        //しかし、IEやFireFoxだとsetTimeoutメソッドで強制的に非同期で読み込ませると、
                        //ログには・・・
                        //---------------------------
                        //[1,'']
                        //[2,'http://somewhere.url/']
                        //---------------------------
                        //と表示され、2回コールされています。
                        //しかし、safariやchromeなどのwebkit系のブラウザでは1回しかコールされません。
                      });
  })(jQuery);

単純にsrc属性を設定してロードした場合だと、どのブラウザでも1回しかコールされない。
だけど、setTimeoutを使用してロードを遅延(非同期)実行させると、IE/Mozilla系ブラウザは2回コールされる。
ただ、タイムアウトミリ秒を1とか10とかのようにすると1回しかコールされないときもある。

よく分からない。そういうものなの???

サーバーサイドにHTMLビュー出力は要らない?

最近 jQuery Mobile のフレームワークを使って、今まで作ったWebアプリ(かっこよく言えば・・・ですがw)をスマートフォン向けに手を加えています。
jQuery Mobile をかじり立ての頃は、なんとなく、最終的に結果を吐き出すHTMLテンプレート部分をスマートフォン用に用意すればいいだろう?、なんて簡単に考えていたんですが・・・、それは甘い考えだったようです(ーー;;;

なんというか、極端に考えれば簡単なWebアプリなら、サーバーサイドでHTMLビューを作成してクライアントにHTML出力を返す、というような工程はハッキリ言って要らないんじゃない? と。サーバーサイドのプログラムを単にJSON形式を返す、簡単にいえばREST形式のウェブAPI仕様にしてしまえば、HTMLビューは、クライアントサイドのJavascript(ECMA Script)で全部任せることができる。

クライアントサイドJavascriptにHTMLビューの作成を任せてしまえば、サーバーサイド側の実装が簡潔になるし、メンテもラクになる。今時のクライアントマシン(モバイル端末を含めて)は例えエントリ向けであっても性能が無駄に?性能が向上しているので、スペック的なパフォーマンスは考えなくていい。

サーバーサイドのプログラム(PHPであれ、PerlのCGIであれ)は、単にデーターベース情報の出し入れを仲介するだけ、と割り切ってしまえば・・・とか思いましたが・・・クライアント側にJavascript実行環境が無ければ、全く機能しないことになる。そういう作り方が、はたして良いのか悪いのか。

どの程度までクライアントサイドにHTMLビューを任せればいいのか、そのバランスがなんとも悩みどころ。。。というか、サーバーサイドでHTMLビューの作成がどうしても必要なケースって僕が作る用途では少ない気がする。円グラフや棒グラフなんかも、HTML5で描けちゃうし。

それに、なんと言っても、DOM + jQuery の方がHTMLを組み立て易いし、はるかに簡単!
結局、僕の中では、Webアプリはクライアントとデータ(データーベースとかクラウド上の何かしらのデータ)をくっつけるグルーみたいなもん、という認識に変わりつつある。jQuery Mobile は、そのきっかけになった気がする。


HTMLビューを単にjQuery Mobile用のHTMLに書き換えただけのプログラム(CGI/Perl)。スマホならページナビゲーションは、「次のXX件を読み込む」でAjaxとかで続きを読み込むのが普通かな。