miauのブログ

ScanSnap 内部の埃は静電気で飛ばせる（こともある）

Thu, 03 Nov 2016 20:23:29 +0900

ScanSnap の読み取り部のガラス裏面に付着した埃はやっかいなものですが、運良くこれを静電気で飛ばすことができましたので、そのお話。

問題

ScanSnap でスキャンする際、読み取り部に埃があると縦線が入ってしまいます。

↑今回の症状。黒ベタの箇所に緑の線が入ってしまっています。

通常は読み取り部のガラスを拭けば解消するのですが、今回は何かの拍子に読み取り部のガラスの内側に埃が入ってしまったようで、いくら拭いても縦線が解消しませんでした。

よくよくガラスを見ると、白い粒が見えるような・・・。ということで顕微鏡で拡大して見てみました。

↑肉眼では粒にしか見えませんでしたが、L 字形になっており、わりとしっかりと付着してしまっていそうです。

正攻法は？

こういった場合には分解清掃が必要、ということになっています。

以前も似た症状でサポートセンターに修理依頼したことがあるのですが、その場合の金額は ¥27,324 とかなり高額（※私が使ってる業務用の fi-7160 の場合）でした。ビックカメラの長期保証に入っていたのでその時は自腹は切らなくてよかったのですが、その後スキャナを机から落としてしまったことがあり、今回はビックカメラの保証は受けられなそうです。

そんなわけで S1500 なんかは自分で分解してしまう人もいるんですが、fi-7160 の分解の仕方はググっても出てきませんでしたし、機種によっては粘着シートが付いていたりで分解が面倒そうなので、分解しなくていい方法を模索することに。

試したこと(1) ひたすら揺らす→効果なし

点滴石を穿つとも言うし、ひたすら揺らしたら埃も取れるのでは？

ということで、スマホのバイブレーションを動かし続けるあやしげなアプリを導入。振動するスマホを埃が付着しているところに当てて半日くらい放置してみたのですが、効果はありませんでした。

試したこと(2) 静電気で飛ばす→成功

これまでも埃が静電気で読み取り面に付着してしまうことがあったので、今回も静電気のせいで付着しているのでは？

ということで、まずは調べ物。

摩擦帯電 - Wikipedia

によると、帯電列というものがあって、物質によって正に帯電しやすかったり負に帯電しやすかったりするらしい。ガラスは正に帯電しやすいらしいので、付着しているのは負に帯電しやすい何か？だとすると負に帯電させたものを近付ければガラス面から離れてくれるのかな？そして

正逆電気クラゲについて（２）（PDF）

を見ると、テフロンは負に帯電しやすいので使い勝手がいいとのこと。

ということで、とりあえずモノタロウで 201-595 スロットルテフロンシート 1個 KIJIMA(キジマ) と、擦り合わせるための 1×200×200 アクリル板(透明) 1枚ノーブランドを購入。テフロンシート（¥539）＋アクリル板（¥700）＋配送費（¥500）−クーポン値引（¥1,000）で合計 ¥699。

届いてから気付いたけど、テフロンシートが予想よりも小さかった（69mm x 96mm くらい）。こういう実験をやりたいのなら、もっと大きいもののほうがいいかも。

とりあえずアクリル板とテフロンシートを擦ってみて、試しにアクリル板を目標に近付けてみると・・・あっさり埃が飛んで行きました。ということは埃は正に帯電していたということ・・・？よくわからないのですが、スキャンすると縦線は出なくなっているし、運良く問題が解消してくれました。

電荷によっては逆に埃を集めてくる可能性もあったと思うんですが、ガラス面の埃が問題になっている人（センサー側に埃あるような場合はダメだと思う）で分解する覚悟があるような人は試してみてもいいかもしれません。たぶん下敷きとキッチンペーパーあたりでも同じことはできるんじゃないかと思うので。

試さなかったこと

強力なレーザーとレンズを使ってピンポイントで焼けないか？とも思ったのですが、センサー部にレーザーが当たってしまうと大変なのでやめました。（大変なことになってしまった例→iPhoneのカメラにレーザーポインターを当てたらカメラで撮影するとき... - Yahoo!知恵袋）

ITサービスマネージャ（試験）

Sun, 16 Oct 2016 21:27:56 +0900

二年ぶりにITサービスマネージャを受験してきましたので、例によって色々メモです。

今回の対策本など

受験する度に本を買ってるので色んな本がたまってきた。10 冊くらい参照してる気がするけど、今回買ったのだけ紹介。

新人ガール　ITIL使って業務プロセス改善します!

作者: 沢渡あまね
出版社/メーカー: シーアンドアール研究所
発売日: 2015/04/17
メディア: 単行本（ソフトカバー）
この商品を含むブログ (3件) を見る

新米主任 ITIL使ってチーム改善します!

作者: 沢渡あまね
出版社/メーカー: シーアンドアール研究所
発売日: 2015/11/26
メディア: 単行本（ソフトカバー）
この商品を含むブログ (3件) を見る

ITILの復習と論文ネタに使えたりしないかなという期待で。前者は広く浅く入門っぽい内容。後者はサービスデスクの雰囲気がわかっていいかも。

2016 ITサービスマネージャ「専門知識+午後問題」の重点対策 (重点対策シリーズ)

作者: 平田賀一
出版社/メーカー: 株式会社アイテック
発売日: 2016/05/02
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る

2013年のを持ってるけど、午後Iのよくある出題みたいなのがまとまっててわりとよかったので。
買ってみたけど、午後Iの構成が結構変わってる。重点解説x3、演習問題x12だったところが、重点解説x5+演習問題x7でテーマ毎に整理されている。そして目当てだったコーナーがなくなってた・・・。まあ傾向分析はあるし、これはこれで役に立つかな。

ITサービスマネージャ合格論文事例集第4版 (論文事例集シリーズ)

作者: アイテック教育研究開発部
出版社/メーカー: アイテック
発売日: 2015/06/10
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

新しいのが出てたので。第3版が2007（H19）〜2011（H23）年の内容だったのに対して、第4版は2009（H21）〜2014（H26）年の内容になってる。時期が重なってる2009（H21）〜2011（H23）年の内容は同じ。

ITILの基礎 -ITILファンデーション(シラバス2011)試験対応-

作者: 官野厚
出版社/メーカー: マイナビ
発売日: 2013/10/19
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る

どうもリリース管理と変更管理の境界がわからなくなってきたので、その辺を整理すべく。
Tポイントキャンペーンをやっていたので試しにマイナビで電子書籍を買ってみたけど、達人出版会（各ページにメールアドレスが入る）と違って、最終ページに氏名等が入ったページが追加される形。どっちで買っても大差なさそう。

勉強

去年の春以来、午後Iの対策もちゃんとやるスタンスなので、午後Iは重点対策本の重点解説の 5 題を解いたり。

午後IIは2009（H21）〜2015（H27）の骨子を考えて、苦手な分野は後でじっくり考えたり。実際に論文書いたのは前日の一回のみ。
「論述の対象とする IT サービスの概要」とアの前半を書く練習は 3〜5 回くらい。「論述の対象とする IT サービスの概要」シートはチーム名なんかも入った新しいフォーマットが見当たらなくて困ってたけど、よく見たら情報処理教科書高度試験午後II論述春期・秋期 (EXAMPRESS) のダウンロードページから落とせた（書籍は購入しておく必要あり）のでこれを使った。

午前IIの対策は、重点対策本を読んだし、空き時間に

情報処理技術者試験の勉強をやり直し　−ITパスポート、基本情報技術者、応用情報技術者、高度試験の過去問題の解説−

このサイトで過去問を 3 年分解いたしで、ちょっとやりすぎた。似たような問題が多いから、何度も受けてるらなもっとさらっとで大丈夫。

試験

受験会場はTKPガーデンシティPREMIUM秋葉原。こんな近い会場あるんだなー。
いつもは受験票が来たら「こんな遠くまで行くのか・・・」ってテンションが下がってたけど、今回は逆にやる気になってた。
当日もちゃんと受験会場に来てる人が多かった気がする。

午前II

厳しめ自己採点で 73%、実際に採点すると 88% で間題なし。
間違えたうち一問は勘違いだけど、まあ通過してるだろうからいいや。

午後I

問1はだいたい解けたけど、問2がどの設問でどこまで答えるべきかがピンと来なかった。6 割くらいは解けてると思うんだけど、どうかなー・・・。

午後II

始まる前に注意事項を読んでたら「ただし, 問題冊子を切り離して利用することはできません。」とか書かれてて驚いた。調べてみたら2005年の秋からこの注意書きはなくなってたんだけど、久々に NG になったらしい。最近切り離して下敷きにするのが気に入ってたんだけど。

今回のテーマは要員の育成とプロセス不備への対応・・・。前者はすぐには書けなそうだから書くなら後者かな。
ということで 25 分くらいで骨子をまとめて書き始めたんだけど、全体的に流れがおかしくなってしまった。不備の内容をアで軽く書いてイでその調査を〜っていうのがきれいな形なんだろうけど、不備の対応の中で原因がわかっちゃうような事例を選んでしまったので、題意に沿っていない感じに。
ア: 650字、イ: 1250 字、ウ: 650 字ということで、イを書きすぎてウがあまり内容書けずに尻切れトンボな感じだし、A 判定はなさそう。イの文字数を抑えて 5〜10 分でも軌道修正の時間が取れたらよかったんだけど・・・。

題意に添ってない論文を長々と書いても仕方ないし、論文の骨子にもう少し時間をかけたほうがよかったのかも。いつも「骨子に時間かけすぎた。やばい」みたいなことを言ってるけど、それで合格してるケースもあるし。

反省＆感想

ここ数回の受験では片手間に勉強してたけど、今回はわりと時間をかけてしまった。そのわりにいい論文が書けないままで、どうしたものだか。
論文の練習は過去三年とかに絞って、論文の精度を高めることを優先したほうがいいのかもしれない。添削を受けることも考えたほうがいいのかも。

（2016-12-16 追記）成績照会

午前I得点
***.**点
午前II得点
88.00点
午後I得点
72点
午後II評価ランク
A

またなぜか合格してました・・・。
講評がまだ出てない（＋試験後に意気消沈してて、骨子にどう肉付けしたかをメモし忘れてた）のでなんともいえないけど、出題趣旨にあった「プロセス単体、プロセス間の連携の観点から〜」といった部分は書けていたっぽいので、そこが評価されたとか・・・？
2ch を見てると午後Iで落ちてた人が多かったみたいなので、午後Iを通過して規定文字数を書ければ合格率は高かったとか、そういうのかも。

微妙にすっきりしないところではあるけど、形はどうあれ論文系の資験は一通り受かったので、しばらく論文が必要な試験は受けないつもり。
来年の春は気が向いたら情報セキュリティマネジメント試験か情報処理安全確保支援士を受けるかも、くらいで。
合格している試験区分でも知識が古くなってしまっているものは多いので、受験するかはともかく、たまに最新のテキストを読んで知識を整理したい。

システム監査技術者（試験）／成績照会

Sat, 18 Jun 2016 15:59:00 +0900

情報処理試験の日に書き損ねましたが、昨日成績照会したのでこの機会に投稿しておきます。
春に受験したのはシステム監査。気が付いたらもう 6 度目の受験です。

勉強っぷり

午前II対策

例によって

情報処理技術者試験の勉強をやり直し　−ITパスポート、基本情報技術者、応用情報技術者、高度試験の過去問題の解説−

を通勤中に解いたりしていたくらい。

午後I対策

去年午後IIがわりと書けたと思ったら午後Iで足切りされていて勿体なかったので、今年は午後Iをしっかりとやる方針で。

まずは去年の点数が低かったか原因を確認すべく、解答例と採点講評を確認してみた・・・のだけど、あまり納得いく感じではなかった。問題文に「具体的に答えよ」とか書いているわけでもないのに、講評では「具体性を欠く解答が散見された」とか書かれたりして。
過去問の講評でも「○○のように答えている解答が散見されたが、△△を答えてほしかった」みたいなコメントは頻繁に見かけたし、出題の仕方にも問題あると思うなー・・・。とりあえずの教訓として、「どう答えるか迷った時には具体的に答える」方針でいこう。

次に午後I対策として、↓この本を読んでみたり。まあ色んな人が色んなやり方で対策してるんだなー、といった感じ。「小問の数が多い問題を選んだほうがリスク分散になっていい」みたいな意見についてはなるほどと思った。

情報処理教科書高度試験午後I記述春期・秋期

作者: ITのプロ46,三好康之
出版社/メーカー: 翔泳社
発売日: 2015/03/17
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

これを読んでも回答ポイントの絞り方がわからなかったので、その点について解説されていた情報処理教科書 ITストラテジスト 2015年版も読み返したり。この方法でもやっぱり自信を持って答えられる感じにはならないなぁ・・・。

あとは試験前日＆当日に

AU速攻サプリの公開 - mr_sorao’s diary　2015年度システム監査技術者受験に取り組んだ記録と備忘録

ここで書かれているAU速攻アプリと、公式の講評を読んだりもした。

午後II対策

午後I の対策に時間をかけすぎて午後IIの勉強時間が取れなくなってしまった。
仕方がないので、数冊持っている対策書／論文集について、どの年度のどの問題の論文例が多いか調べて、例が多いものから順に骨子を考える練習をした。中心として使ったのは情報処理教科書高度試験午後II論述春期・秋期 (EXAMPRESS) になるのかな。
いつもは骨子をマインドマップでまとめてるんだけど、リスク要因→コントロール→監査の流れを整理するには表形式のほうがよさそうだと（今更）気付いたので、今回は表形式で考える練習をした。
あと、前回のITストラテジスト受験時に参考書に出てきた考え方（モジュール）を意識して、学習中に使えそうな表現が出てきたらメモとして書き貯めていったりもした。

その他、去年受けた添削の結果を見直したり、2ch で「論文を書く上でも参考になる」と紹介されていた数学文章作法基礎編 (ちくま学芸文庫) も読んでみた。個々のテクニックについては日経SYSTEMSの連載なんかでも見かけた内容なので真新しさはなかったけど、「第一章読者」はこの人の本らしくてよかった。

全体的な対策として

以前読んだ本の改訂版が出ていたので、気になるところを拾い読みしたりも。細かい単語の違いなんかを整理できてよいです。

よくわかるシステム監査の実務解説(改訂版)

作者: 島田裕次
出版社/メーカー: 同文舘出版
発売日: 2015/09/12
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る

試験

受験会場は何度目かの東京都市大学世田谷キャンパス＠尾山台。

午前II

厳しめ自己採点で 65%、実際に採点すると 80%。
最終的な得点だけ見ると問題ないけど、「過去問を解いておけば自信を持って答えられる」みたいな出題がいつもより少なかった気がするので、あまり油断しないほうがよさそう。

午後I

問1 は得意分野（セキュリティ）だし、だいたい答えられていると思うのだけど。
その後「小問の数がやや多いから」という理由で選んだ問2 は、どう答えていいものかかなり迷う問題で、手ごたえがよくわからなかった。問3 のほうにしていたほうがよかったのかも・・・と軽く後悔したり。

午後II

問1 が情報システム投資、問2 が設計・開発段階の品質管理ということで、ここは問2を。
骨子を考えるのに 28 分くらい使ってしまって。急いで書いたけどア: 750 字、イ: 875 字、ウ: 725 字ということで、文字数はわりと少なめ。監査では文字数は多めのほうがいいって話があったし、ダメな気がする。
内容のほうも、イで書いたコントロールがありきたりな感じになってしまったので、ウの監査手続きも「まあ、それくらいしかやることないよね」と思われてしまいそうな内容。よくて B かなー、という印象・・・だったのですが。

成績照会

午前I得点
***.**点
午前II得点
80.00点
午後I得点
72点
午後II評価ランク
A

なんだか合格してました。勝因がまるでわからない・・・。
まあ去年ほどではないにせよ、比較的書きやすいテーマ（設計・開発）に当たった、ってことなのかなと。

反省

結局は「得意なテーマが来るまで根気よく受け続ける」戦略になってしまった・・・
秋はITサービスマネージャを受けるつもりなので、ちゃんと手ごたえのある合格を目指したい

漢直でPCの操作性も変わってくる

Mon, 14 Dec 2015 23:41:49 +0900

また日付が変わる前に漢直 Advent Calendar 2015 の 14 日目の記事として上げてみます。

前回は誤変換のストレスについて書きましたが、今回は漢直でまた別の不満を解消しよう、という話です。私は Windows を使っているので Windows 限定での話になります。*1

以前から不満だったこと

現在使われている OS（やアプリケーション）はほとんどが欧米で開発されたもので、欧米の人に使いやすくできています。

例えば、こんなセレクトボックス。

（動く例を http://jsbin.com/hahoke/1 に置いています。先頭のテキストボックスは IME が切り換わる様子を確認するためのもので、深い意味はありません。）

州名を選択するためのセレクトボックスですが、フォーカスして「c」のキーを押せば、「c」で始まる「California」にジャンプできます。「c」のキーを何度も置せば「C」で始まる「California」「Colorado」「Connecticut」を順に移動できますし、「co」のように 2 文字以上入力すれば、その文字で始まる「Colorado」に最初からジャンプできるわけです。

このようにある程度使いやすくなっているわけですが、これが日本の場合だと・・・。

↑こうなっています。「東京都」にジャンプしたい場合はどうすればいいでしょう？

Internet Explorer ではセレクトボックス上でも IME を有効にできます。「とうきょうと」と入力して変換すれば、ちゃんと「東京都」にジャンプできるわけです。*2 Edge も多少表示が変ですけど、同様の操作ができます。一方で Firefox や Chrome は IME が強制的に OFF になるので IME からは入力できません。

じゃあ IE や Edge を使っていれば満足かというと、そんなことはありません。欧米の人が 1〜2 ストロークで目的の選択肢に達することができる場面で、「toukyou」とか「higasi」といった入力しないといけないのは、なんとも不満です。

わかりやすいサンプルとしてプルダウンメニューを挙げましたが、エクスプローラでファイル選択する時なんかにもこの不便を強いられているわけです。

そこで漢直ですよ

漢直の中でも 2 ストロークで漢字を入力できる T-Code で考えてみましょう。「東」のストロークは「is」ですから、2 ストロークで目的の選択肢に到達できます。そして「福」のストローク「vb」を何度も入力すれば「福島県」「福井県」「福岡県」を順に移動できます！*3 「fuku」をくり返すのに比べると、ずいぶん欧米の人に近い――OS の設計に沿った使い方ができているんじゃないでしょうか。

そして、Firefox や Chrome では IME 有効にならないと書きましたが、漢直の入力を可能にするツールには IME の形式を取っていないものがあります。例えば漢直Win を使えば、Firefox や Chrome であっても、「is（東）」や「vb （福）」を打つだけでジャンプできるようになります。

このように、入力方式や採用するツールを適切に選べば、理想的な PC 操作に一歩近づけるかもしれません。

（蛇足）そうは言っても・・・

漢直は漢字直接「入力」なので、あくまでも入力に最適化されたものです。入力に適した道具が検索にも最適ということはありません。州名の例でも「Colorado」を選択するのに「Co」のように大文字の「C」から入力する必要があると、ちょっと不便でしょう。

本当の理想を言うと、OS や GUI ツールキットのレベルで Migemo が使えるのがいいと思うんですが*4 ・・・それでも、そういったサポートがない現状では、漢直という選択肢もありだと思います。

*1:他の環境でも有効なのか知りたいので、気が向いたら教えてください。

*2:Microsoft はこの辺の国際化対応を促進していたので、当然といえば当然です。

*3:書いておいてなんですが、こんな使い方をしたい人がいるのだろうか・・・

*4:外部アプリケーションでよければ Migemize Windows もあります

誤変換しないことの魅力

Thu, 10 Dec 2015 23:05:58 +0900

枠が空いていたのでまた滑り込みで登録した漢直 Advent Calendar 2015 の 10 日目の記事です。（Advent Calendar の使い方が間違ってる）

今回は漢直の魅力の一つである「誤変換のストレスがない」というのを、ちょっと掘り下げて書いてみます。以前行われた社内LT大会で発表した内容を抜粋した感じで、漢直をあまり知らない人向けの内容です。

かな漢字変換を使う上でのストレス

かな漢字変換を使用している時に感じるストレスといえば、誤変換に伴うものでしょう。

誤変換された場合には、

変換候補を確定してしまった場合、打ちなおして変換*1
まだ未確定の場合、誤変換された文節まで移動して正しく再変換

といった操作が必要になります。

かといって誤変換を防ごうとすると、「変換」→「候補が正しいか確認して、正しくない場合は次候補を表示」というステップをくり返すような形になり、これはこれで疲れます。

そこで漢直ですよ

漢直を使えば、基本的に変換／確定といった操作がないため誤変換が発生しません。

「再変換の必要がない」という利点はわかりやすいと思うのですが、個人的には「誤変換を防ぐために変換候補を注視する必要がない」という点のほうが大きいと思っています。というのも、PC からのフィードバックを得ることなく、一方的に打ち込んでいくだけでよくなるからです。

一方的に打ち込めるということは、画面を見ずに入力しても問題ないということです。画面を見ないで済むのなら、この時に視線をどこに向けることができるのか、いくつか考えてみましょう。

1: 入力したいテキストを見る

これはよく言われる利点ですね。原稿から目を離さずに入力できるので、コピータイプ作業はかなり楽になります。

2: 話し相手を見る

打ち合わせの際にノート PC でメモを取っていると、話を熱心に聞いていないと思われるケースがあると聞きます。漢直を使えば相手の目を見ながらメモを取れるわけで、話を熱心に聞いている雰囲気が十分に出せます。

3: 何も見ない

特に何も見る必要がない場面であれば、目を瞑ったまま入力できてしまいます。目が疲れて困っている人には嬉しいでしょうし、老後に備えて漢直を覚えておいてもいいかもしれません。

まあ実際には・・・

漢直は（入力方式にもよりますが）ミスタイプした場合にわけわからない文字になってしまいがちです。

例えば「漢字が違う」と入力しようとして、2文字目を打ち損ねた場合のことを考えます。ローマ字入力であれば「ｋン字が違う」のような変換になり、後で見ても何を入力しようとしたのかは想像できるでしょう。ところが漢直（T-Code や私が使っている Try-Code）の場合は・・・



 漢 字 が 違 う

(l4 z/ ;s sp yd)
↓2文字目の「4」を打ち損ね
(l  z/ ;s sp yd)
↓以下のように解釈されてしまう
(lz /; ss py d)

 小 光 熟 談 d

この結果、「小光熟談d」のようにまるでわけのわからない文字になってしまいます。

なので、たまに画面はチェックしたくなりますし、私が未熟なこともあり、

脳内で思い描いた漢字が間違っている
覚えてない漢字を交ぜ書き変換で変換することがある
ミスタイプもある

ということで画面からずっと目を離すわけにはいかないのですが・・・それでも見る頻度は下げられてきていると思います。

- - -

（2015-12-11 追記）ミスタイプの例がおかしかったので少し修正しました。

*1:Ctrl+Backspace で再変換できたりもするけれど

漢直の練習に向いているフォント

Mon, 07 Dec 2015 23:13:00 +0900

（昨日の記事がまだ書かれていないようですが）せっかく今日までカレンダーが埋まってるので、流れに乗って漢直 Advent Calendar 2015 の 7 日目の記事として、小ネタを書いてみます。

私が漢直の練習を始めた当初は、覚えた文字をランダムに（一行おきに）出力して、テキストエディタでその下の行に同じ文字を入力する形で練習していました。

こんな感じ。

最初はこのやり方でうまくいっていたのですが、ひらがな、一部の漢字に続いてカタカナを全部覚えた頃（※T-Code はひらがなとカタカナのストロークが別々に定義されています）に困ったことが起きました。というのも・・・

さて、↑カーソルの上のこの文字は、ひらがなの「へ」なのか、それともカタカナの「ヘ」なのか、見分けることができますか？

たいていのフォントでは両者の字形は同一になっているので、見分けられないと思います。

こんな時は文字の区別がやりやすい MIGU（の 2015-07-12 版以降）を使うと大丈夫です。

プログラマに嬉しい

0O（数字ゼロ・大文字オー）の区別
1Il（数字１・大文字アイ・小文字エル）の区別

といった特徴以外にも、

「カ力エ工ロ口ー一ニ二（カタカナ・漢字）へヘ（ひらがな・カタカナ）の区別」

という特徴があります。

先程判別がつかなかった練習テキストも、このフォント（Migu 1M）を使うと・・・。

左側がくいっと曲がっているものがカタカナ、曲がっていないものはひらがななので、カーソルの上にるのはカタカナ、次の行にあるのはひらがなだとわかりますね。

実はこの字形の変更、私が漢直の練習をしていて困っていたので、フォーラムで要望として出したものだったりします。

スレッド公開討議:ひらがな「へ」、カタカナ「ヘ」の区別について - mixfont-mplus-ipa - OSDN

このリンク先にも書いたのですが、漢直ユーザの体験談では

「何年間も『へ』と『ヘ』の位置を間違って覚えていた」
「『へルプ』（※「へ」がひらがな）になっているのを他人に指摘された」

といった話もあるようで。漢直をお使いの方は、そのような悲劇を起こさないためにも MIGU を使うといいかもしれません。

Jenkins のグラフで縦書きの文字がちゃんと回転しない対策

Mon, 16 Nov 2015 23:56:49 +0900

Jenkins のグラフについて「日本語が表示されない（お豆腐で表示される）」みたいな問題はわりと見かけるんですが、今の環境で起きてたのは別の現象で。

本来は

↑こうなるべきところが、

↑こうなってました。

y軸の「count」が下から「c」「o」「u」「n」「t」が、各文字は回転せずに積み上げられてしまっています。x軸も「#3」が同様に下から「#」「3」が書かれていってるので、識別できません。

あまり報告を見かけないので、ほとんどの環境では発生しないんだと思いますが、一応対策を書いておきます。環境は CentOS5、OpenJDK7 です。

先に結論を

原因（あまり深く調べてない）

手元の環境（CentOS5）では、



/usr/share/fonts/ja/TrueType/kochi-gothic-subst.ttf

  -> /usr/share/fonts/japanese/TrueType/sazanami-gothic.ttf

のようなシンボリックリンクが設定されています（東風代替フォントとしてさざなみフォントが使われています）が、グラフの描画にこの辺りのフォントが使われると上記の現象が発生してしまうみたいです。

対策

もっと適切な対応があるかもしれませんが、とりあえずこのファイルが使われなければいいようなので、

システム全体で設定していいのであれば /etc/fonts/local.ini として
特定のユーザ（jankins ユーザとか）だけに設定したいのであれば ~/.fonts.conf として

こんなファイルを配置して、fc-cache を実行。

ただ、こうすると日本語が表示できなくなってしまうので、日本語を表示したい場合は IPA フォントでも入れておけばよいです。



yum install ipa-gothic-fonts ipa-mincho-fonts ipa-pgothic-fonts ipa-pmincho-fonts

Jenkins を再起動すれば、キャッシュされていないグラフについては正しい状態になります。

解決策に行き当たるまで＆URL のメモなど

この現象は長いこと気になっていたので、Jenkins のメンテナンスついでに修正しようと思い立ちまして。

Jenkins やらその中でグラフの描画に使われている JFreeChart のソースを読んでみたんですが、特にあやしい処理が見付からず。よくわからないので JFreeChart で簡単なグラフを書いてみたら、そちらでも現象は再現するようなので、環境のほうを疑うようになって。

#637250 - openjdk-7-jre-headless: hardcodes font paths instead of querying available fonts - Debian Bug report logs

を見ると OpenJDK7 では libfontconfig が使わているようで。

フォント設定 - ArchWiki

あたりに fontconfig まわりの詳しい情報が載っていたのでこれを参考にしつつ、設定をいじりまわしていたらうまくいった、という感じです。
（ちなみに Java では ~/.java/fonts/*/fcinfo-*.properties あたりに設定がキャッシュされるっぽいので、検証をする時は rm -rf ~/.java/fonts としてキャッシュを消す必要がありました。）

色々書きましたが、今回は Jenkins でしか使っていないサーバなので、



yum erase fonts-japanese

として日本語フォント自体を消してしまってもよかったかもしれません。

eelll/JS を GitHub に上げました

Wed, 28 Oct 2015 01:47:25 +0900

ブラウザで動作する漢直（漢字直接入力）の練習プログラムに eelll/JS というものがあったのですが、残念ながら公開サイト（※リンク切れ）が消えてしまっていました。

今回作者のゆせさんに過去バージョン＋未公開のバージョンを提供していただきましたので、GitHub に上げました。

https://github.com/miau/eljs

UTF-8 に変換して gh-pages ブランチも作っているので、GitHub Pages でも動くようになっています。

https://miau.github.io/eljs/

以下、経緯やリポジトリの説明です。

経緯

実は 2 年ほど前から漢直（Try-Code が基本で、記号類は TT-Code）を使っています。

私が漢直を練習していた当時（2013/06〜2013/09）は「漢直を体験してみたいなら漢直/JS を使うといいよ」「漢直を練習するなら eelll/JS を使うといいよ」と言えるような状況だったのですが、2014/04 に漢直/JS と eelll/JS のサイトが消えてしまい、漢直に興味を持った人にも紹介しづらい状況でした。

私自身は eelll/JS のソースコード（0.2.3）を手元に持っていたので、そんなことはすっかり忘れていたのですが・・・最近になって、

こんなつぶやきを見かけまして。

0.2.3 のソースコードは持っているのですぐに GitHub に上げることはできたんですが、せっかく Git 管理にするなら過去バージョンもちゃんと履歴を残したほうがいいですし、作者の方が再公開してくれるのが一番スムーズな流れだと思ったので作者のゆせさんに連絡してみました。

少なくともすぐに再公開される予定はないとのことでしたが、快く過去バージョンと未公開のバージョンを提供してくださったので、軽く整理して GitHub にひとまず上げました。

未公開のバージョンについて

公開されていた最終バージョンは 0.2.x でしたが、その後 0.3 以降のバージョン（0.3.1 相当）までバージョンが上がっていたそうで、

L-code 実際に練習できる環境が欲しくて機能拡充させていったバージョン
バグフィックスなども入れている

とのことでした。L-code というのは何かというと・・・

また履歴の中で『L-code』や『F131215』などと書いているのは、
ゆせが個人的に試作した“ローマ字漢直”の入力方式の名前で、
『YALLLTXT』や『LLLLLTXT』はその練習テキストです。

とのことです。こちらについても簡単に (と言いつつかなりしっかりと）説明していただきましたので、その内容も HTML にして上げてあります。

https://miau.github.io/eljs/l.html

リポジトリの説明

Committer は私ですが、Author はゆせさん、AuthorDate は .zip または .tar.gz の公開日時（未公開バージョンはファイルの最終更新日時）としています。コマンドでいうと以下のような感じです。

git commit -m "eelll/JS 0.1" --date="2005-06-24T20:43:00" --author="xxxx"

公開バージョンについてはタグを設定しています。（0.1、0.2、0.2.2、0.2.3）

オリジナルのコンテンツについては org-master、org-0.1、org-0.2... のように、先頭に org- を付加しています。公開されていたままの（EUC-JP の）コンテンツが取得したい場合はこちらのブランチ／タグから取得してください。

「org-」が付加されていないブランチ／タグについては、ファイルが元々 UTF-8 で作成されていた（コンテンツ中の charset も UTF-8 指定だった）かのように履歴を作ってあります。GitHub Pages で文字化けしないようにするのが目的ですが、GitHub 上で diff 等も見やすいと思うので、今後メンテナンス対象とするのはこちらのブランチ／タグだけの予定です。

今後の予定？

最低限の整理だけ行っている状態ですので、

外部サイトのリンク切れ修正
Try-Code の定義を最新版に更新
README.md を何かしら書く？

くらいは行おうかと思ってます。もしかしたら自分用に加えた eelll/JS への変更（ミスしたら次の行に進めない）もオプションとしてコミットするかもしれません。

また、過去ぶんのコミットをもっと細かく分割するかもしれません。その場合は git push --force でブランチやタグの位置を強制的に変えるような行儀のよくないことをするかもしれませんが、ご了承ください。

ITストラテジスト（試験）

Sun, 18 Oct 2015 21:40:42 +0900

情報処理試験を受けてきました。今回は 3 年ぶりの IT ストラテジスト。

動機／今回の対策本

IT ストラテジストは IT サービスマネージャに合格してから受けよう、とか考えてたんですが。↓この本が「別の区分を受験す場合にも参考になる」として紹介されているのを見かけて。

ITストラテジスト午後2 最速の論文対策第2版 (TACの情報処理技術者試験対策シリーズ)

作者: 広田航二
出版社/メーカー: TAC出版
発売日: 2013/10/15
メディア: 単行本
この商品を含むブログを見る

だったら今回はこの本で勉強してみようかな、と思ったのがきっかけ。

読んでみると確かに面白い考え方で。

論文をまるごと用意しておくのではなく、論文の部品（モジュール）を用意しておく
試験会場では考える作業は一切行わず、モジュールを機械的に組み立てるだけでよい

という内容。こういう手法について説明されている本は他にもあったと思うけど、具体的でわかりやすかった。

あと、Amazon のレビューで「午後1対策のPDF書籍が良かったので〜」と書かれてたので、どの本のことかわからないけど同じ著者のこの本を買ってみた。

情報処理教科書 ITストラテジスト 2015年版

作者: 広田航二
出版社/メーカー: 翔泳社
発売日: 2015/02/17
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

午後IIの対策は前出の本と被る部分もかなり多い。どちらかというとこちらの本のほうが詳細に書いてあったり、（文字は小さいけど）モジュール例も多かったりする。時間がない人がざっと勉強するなら前者の本、みたいな選び方でいいかと。
こちらの本には午後Iの対策も載っているけど、こちらも特徴的。「こういう風に読みましょう」「こういう風に考えましょう」とステップ毎に解き方を説明する感じなので、電車の中でも読み進められそう。そういうスタイルで勉強したい人にはいいかも。

その他前回買った情報処理教科書高度試験午後II論述春期・秋期 (EXAMPRESS) も IT ストラテジストのところだけ読んだ。問題の分類なんかはこの本のほうが詳しいし、どういう論文だとダメかがわかるので、どちらのほうがいいとも言えない感じ。

勉強っぷり

午前Iは免除なのでいいとして、午後IIは今回も情報処理技術者試験の勉強をやり直しで過去問を 3 年ぶんくらい解いておいた。
午後対策はは上の本を一通り読んで・・・午後Iを2問、午後IIを1問くらい解いてみた程度。モジュールを準備する時間がなかったので、この本に載ってた方法がちゃんと試せなかったのが残念。
そして最後本当に時間がなくなってきてからは、試験センターの「出題趣旨」「採点講評」をざっと読んだり。

時間がなかったといっても、今回は主に怠けてたせい。今回は日常のタスクの一つとして試験勉強を進める（毎日 30 分だけ勉強して、他の時間はいつも通りに過ごす）スタンスだったけど、そうすると勉強以外のことを先にやりはじめてしまって、結局一日がそのまま終わってしまうこともちらほら。もう少し制約がないとダメらしい。

試験

受験会場は日本大学商学部＠成城学園前。
乗り換えが面倒で最寄り駅の祖師ヶ谷大蔵を避けたのだけど、閑静な住宅地で歩きやすかった。（ただしコンビニは少ない）

午前II

厳しめ自己採点で 69%、実際に採点すると 19/25 で 76%。
消去法で選べるのがわりと多くて助かった。

午後I

春の試験で「午後IIが書きやすいテーマだったのに午後Iで足切りされてた」のがわりとトラウマで。今回しっかり解こうと思ったら 1 問目で時間を使いすぎて、なんとか時間内に全問回答できた程度。

時間がかかった原因は、どういう詳細度で答えるのが正解かわからず考え込んでしまったこと。
例えば問1の設問1(2)。出題が「対策を述べよ」で、問題文中にはヒントとして「運用負荷を低減するための対策が必要となっている」とあるような場合に、「運用負荷を低減するための対策」とそのまま抜き出して答えるべきか、具体的な対策の内容を挙げるべきか迷ってしまったり。

やっぱり午後Iの対策では、ちゃんと自分で回答を書いてそれを模範解答と見比べる形のほうがいいのかも。「こういう聞かれ方をしたらこう答えればいい」っていうのをちゃんと覚えるために。

午後II

モジュールを準備できてないので、結局いつも通りの解き方で。
骨子に 42 分くらいかかって、概要にも 5 分くらいかかったと思うので、文書を書くのに使える時間が 73 分くらい。90 分くらい欲しいところなので、これはまずい。
ひどい字で書きなぐったら、一応ア: 625 字、イ: 975 字、ウ: 675 字くらい書けた。なので（午後I通過してたら）採点はされると思うけど、ちょっとテーマと違う方向に話を展開してしまったので、よくて B 評価かなと。

よかった点としては、問題用紙を破るテクニックが試せたこと。一時期禁止されてたり、紙を破る音がうるさかったりで今まで試したことはなかったけど、わりと静かに破ることができた。問題とメモ用紙を横に並べて広いスペースを使って考えることができるし、余った紙を下敷きとしても使えば裏写りも多少減るのでオススメ。

悪かった点としては、午後Iが終わった段階ですでに手が疲れてプルプルしていたこと。書いたけど読めないような字になっちゃったので消して書き直す〜みたいな頻度が高くて、ずいぶん時間を無駄にした気がする。手を鍛えるためにも、何かしら文字をたくさん書くフェーズを勉強に組み込んでおいたほうがよさそう。

（2015-12-19 追記）成績照会

午前I得点
***.**点
午前II得点
76.00点
午後I得点
75点
午後II評価ランク
A

なぜか合格していました。全体システム化計画というよりは「緊急で発生したシステム化要求をどうこなすか」みたいなところを中心に書いてしまったので、ダメかなと思っていたのだけど。背景の説明やら事業戦略との整合性やらについても書いておいたので、逸脱しているというほどではなかったのかな？

ちなみに

例えば問1の設問1(2)。出題が「対策を述べよ」で、問題文中にはヒントとして「運用負荷を低減するための対策が必要となっている」とあるような場合に、「運用負荷を低減するための対策」とそのまま抜き出して答えるべきか、具体的な対策の内容を挙げるべきか迷ってしまったり。

この部分の解答例は「運用の負荷を軽減しサポート可能な要員の割合を増やす」でした。どちらか迷ってた 2 つの案を半分ずつ混ぜ込んだくらい。まあ「具体的に書け」とか言われなくても、ある程度具体的に答えておいたほうが安全な問題もあるということで。（システム監査だと抽象的に答えたほうがいい場面もあるので、一概には言えないだろうけど。）

システム監査技術者（試験）

Sun, 19 Apr 2015 03:37:25 +0900

情報処理試験の日の定期更新。
今回受験したのはシステム監査。去年は受験できなかったので、2 年ぶり 4 度目の受験。

勉強っぷり

情報処理教科書高度試験午後II論述春期・秋期 (EXAMPRESS)

作者: ITのプロ46,三好康之,秋田智紀,佐久間賢次,藤田章康
出版社/メーカー: 翔泳社
発売日: 2013/07/23
メディア: 単行本（ソフトカバー）
この商品を含むブログ (8件) を見る

半年前にちらっと書いた、この本を中心に勉強。「他の試験ではこうだけど、監査の試験ではこういう書き方のほうがいい」みたいな他の試験区分と比べた論文のポイントなんかも書いてあって、いくつか勘違いしていたことが修正できてよかった。

あと、この本を買った時に

自分らしい働き方 : 書店購入読者特典サービスに関して

にある読者特典サービスを受けられたので、初めて論文の添削というのを受けてみた。自分では「どこか拙い論文だけどどこを直せばいいかわからない」というよう状態だったけど、明確に「ここがダメ」と指摘されたのでよかった。自分では具体的に書いたつもりのところも「具体性がない」とか指摘されたりとか。

その他去年（受験はしてないけど）買ってあった

システム監査技術者合格論文の書き方・事例集 (情報処理技術者試験対策書)

作者: 岡山昌二,樺沢祐二,清水順夫,長嶋仁,落合和雄
出版社/メーカー: アイテック情報処理技術者教育センター
発売日: 2011/01/01
メディア: 単行本
購入: 1人クリック: 4回
この商品を含むブログを見る

システム監査技術者合格テキスト 2014年度 (情報処理技術者試験対策)

作者: TAC情報処理講座
出版社/メーカー: TAC出版
発売日: 2013/08/21
メディア: 単行本
この商品を含むブログを見る

このあたりを読んだり、評判がよかった

よくわかるシステム監査の実務解説

作者: 島田裕次
出版社/メーカー: 同文館出版
発売日: 2012/09/12
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

この本を拾い読みしたり。それ以外に前回使った対策本を読んでみたり、といった感じ。

午前II については、例によって

情報処理技術者試験の勉強をやり直し　−ITパスポート、基本情報技術者、応用情報技術者、高度試験の過去問題の解説−

を通勤中に解いたり。

午後の過去問対策は、最初の本に載っていたシステム監査の問題 5 題の骨子を考えた程度。
本当はもっと過去問を解きたかったんだけど、ずっと体調を崩していて無理だった。途中から目標が「合格すること」じゃなくて「体調を整えて当日ちゃんと会場に行くこと」になったりしてたくらいなので、まあ受験できただけよしとしよう。

試験

受験会場は東京都市大学世田谷キャンパス＠尾山台。またここに来る機会があるかはわからないけど、注意点は

駅から15分くらい歩くので時間に注意
大学だけあって会場に時計がなかったので時計は必須
地下の部屋で日中の気温のわりに寒かったので防寒は忘れずに

くらいかな。

午前I

厳しめ自己採点で 70%、実際に採点すると 83%。
諸々の試験区分の受験をしたことがあれば特に勉強しなくていい感じ。とりあえず次回の午前Iの免除は確保と。

午前II

厳しめ自己採点で 86%、実際に採点すると 92%。こちらも過去問をやってれば問題なし。

午後I

75 分くらい経ったところで一応回答はできたので、午後IIの準備をちょっとでもするために途中退室。監査は午後Iで落ちたこともあるし、今回あまり勉強してないしで手ごたえはよくわからない。

午後II

例年書けそうなテーマがなくて困るんだけど、今回のテーマは

問1 ソフトウェアの脆弱性対策の監査
問2 消費者を対象とした電子商取引システムの監査について

みたいな感じで、どっちも（監査じゃないけど）どっぷり経験済みな分野が来たりして。「えっ？どっちを選べば・・・？」と逆に焦ったりしてた。別々の年に出題してくれたら合格率上がって嬉しかったんだけど、それはさておき。

とりあえず、より専門性が活かせそうな問1 を選択。ア: 715 字、イ: 1200 字、ウ: 1150 字ということで、今までになく十分な文字数は書けた（その分手はものすごく疲れた）。ちゃんと採点されたら B くらいは行ってくれると思うんだけど、経験済みだからといって、監査人の立場でいい論文が書けているかというと別の話なのでどうだろう。あと思い返してみると記述が足りない点やら誤字やら、減点要素が多い気がする・・・。

反省＆感想

体調が悪いと学習のスケジュールとか無意味な感じになってしまうので、なんとかしたい。
やっぱりテーマによって書けたり書けなかったりの差が激しい。得意なテーマが来るまで根気よく受け続ける戦略も悪くないかも、なんてことも考えてしまう。
合格を確実にしたいなら、論文の添削はかなり有効そう。有料のサービスとか受けてみるのもいいかもしれない。
秋の試験は・・・負債の片付け（主に本のスキャン作業）が終わるまで、それ以外の物事の優先順位を下げようと思ってるので、まだ片付いてなかったら受験しないかも

（2015-07-15 追記）成績照会

午前I得点
85.00点
午前II得点
88.00点
午後I得点
51点
午後II評価ランク
-

午後Iがダメダメだったので、論文は採点対象にすらならなかった模様。残念。

今までも「わりと論文が書けた気がする」ってタイミングで午後Iを通過できないパターンはあったので、対策を考えたいところだけど。午後Iって実際に問題を解いて解答例と見比べて勘所を掴むやり方しか知らないからどうしたもんだろう・・・。

とか思っていたところで、2ch の合格報告でよさげな対策を見かけたのでメモ。

AU速攻サプリの公開 - mr_sorao’s diary　2015年度システム監査技術者受験に取り組んだ記録と備忘録

これなら移動中に勉強できそうでよさげ。

PHP fputcsv/fgetcsv の $escape オプション

Sun, 14 Dec 2014 01:29:42 +0900

fputcsv と fgetcsv には $escape オプションがあります。
（fputcsv のマニュアルが更新されていませんが、PHP 5.5.4 で $escape オプションが追加されています。）

この動作を勘違いしていたので、ちょっと整理しておきます。

前提

以下 fputcsv/fgetcsv ともにデフォルトの

$delimiter = ","
$enclosure = '"'

として呼び出した前提で書きます。（説明文中で $delimiter とか $enclosure とか書いても読みづらいと思うので。）

動作は PHP 5.6.0 で、ソースは現時点の master 最新版を確認しました。

期待した動作（勘違い）

期待した動作は、

fputcsv を $escape = "\\"（デフォルト）で呼び出した場合、「"」は「\"」として、「\」は「\\」として出力される
fgetcsv を $escape = "\\"（デフォルト）で呼び出した場合、「\"」は「"」として、「\\」は「\」として読み込まれる

というものです。なので、RFC 4180 の仕様や Excel の動作に合わせるならば、fgetcsv/fputcsv の呼び出し時に $escape = '"' を指定して

fputcsv 時に「"」を「""」として出力する
fgetcsv 時に「""」を「"」として読み込む

必要がある・・・のだと思っていました。

実際の動作

実際の動作は fputcsv/fgetcsv ともに、$escape の指定とは関係なく

fputcsv 時に「"」を「""」として出力する
fgetcsv 時に「""」を「"」として読み込む

の処理が入っています。

では $escape = "\\" の動作はどういうものかというと、以下のような動作になっている模様です。

fputcsv の $escape は、fputcsv に渡された文字列中の「"」がその文字でエスケープ済みであることを示す
- 「"」は通常「""」として出力されるが、「\"」の場合は「\""」とせず「\"」としてそのまま出力される
fgetcsv の $escape は、その文字でエスケープされている場合はフィールド終端の「"」とみなさないよう指示する
- 「"ab\",cd"」を読み込んだ場合に「ab\"」「cd"」として読み込むのではなく「ab\",cd」として読み込む
- エスケープを解除して「ab",cd」としてくれるわけではない点に注意

上記の動作なので、もし「"」を「\"」にエスケープする仕様で CSV を作成したければ、

あらかじめ「"」を「\"」に置換した上で、fputcsv を $escape = "\\" で呼び出す
fgetcsv を $escape = "\\" として呼び出した上で、「\"」を「"」に置換する

必要があります。

また、RFC 4180 に従った CSV を扱いたいのであれば、fputcsv/fgetcsv ともデフォルトの $escape = "\\" のまま使うのはよろしくないですね。余計な処理が入ってしまうので。

書いてる途中で気付きましたが、stackoverflow で同じような疑問を挙げてる人がいました。やっぱりわかりにくい動作ですよね。

php - fgetcsv/fputcsv $escape parameter fundamentally broken - Stack Overflow

$escape = '"' を指定した場合の挙動

とまあ $escape の意味合いは期待した動作とは違ったわけですが、$escape = '"' を指定した場合に期待した通りに動いてくれれば問題はないわけで。どうなるか確認すると・・・

fputcsv では「"」を「""」ではなく「"」のまま出力してしまうため NG
fgetcsv では $escape の判定よりも「""」の判定が先に来ており、「""」を「"」としてうまく読み込んでくれるため OK

という結果でした。

まあ fputcsv は

そもそも PHP 5.5.4 まで $escape オプションがなかった
改行を RFC 4180 で決められている CRLF ではなく、LF で出力してしまう
自前で同じ処理を書くのもわりと簡単

ということで、自前で実装するケースも少なくなかったところではあるのですが・・・コミットメッセージを見ると RFC 4180 に対応できるよう $escape オプションが追加されたようなのに、~~結局状況が変わってないのがちょっと残念ですね。~~

（追記）
書いた後で気付いたんですが、$escape の意図に沿って使うのであれば、あらかじめ「"」を「""」に置換した上で、$escape = '"' を指定して fputcsv を呼べばいいですね。
（追記ここまで）

keboola/csv の動作は？

Composer で CSV を扱うライブラリでは、keboola/csv というのが人気らしいです。

keboola/csv - Packagist

この実装（1.1.3）を確認したところ、

CSV の読み込み
- fgetcsv を使用
- コンストラクタに $escapedBy を渡すことで $escape オプションを変更可。デフォルトでは chr(0) が使われる
CSV の出力
- 自前で処理を行っている
- 「"」がある場合は「""」にして出力する形
- 改行コードは LF 固定

ということで、「どうせフィールドの末尾に \0 なんて入らないよ」というのであればデフォルトのまま、そうでないならば $escapedBy = '"' として使用すればいいでしょう。（改行コード LF が許容できるならですが。）

ライブラリに頼りたくない＆自前で実装したくない場合は、これを見習って fputcsv で $escpae = "\0" を指定しても実用上問題はない気がしますね。

ロケールの設定について

ただ、keboola/csv を使えばそれで OK ということはなく、マルチバイト文字には注意は必要です。fgetcsv は内部でロケールの情報を使ってマルチバイト文字の境界を調べるので、適切なロケールを設定しましょう。

適切なロケールというのは・・・ちょっと乱暴ですが、Windows や Linux を使ってる人であれば、基本的に C ロケールでいいんじゃないかと思っています。理由を以下に 3 つ挙げます。

理由その1: どこでも使える

ロケールを ja_JP.UTF-8 にしている例を見かけますが、en_US.UTF-8 じゃないと入っていない環境もあったりしますし、変に細かい指定をしてしまうと可搬性が下がってしまいます。C ロケールならどこでも使えるのでその点では安心です。

id:moriyoshi が fgetcsv がロケールに依存している理由（これを読むと納得せざるを得ない）とともに C ロケールを使う場合の注意を書いてくれていて、

なぜPHPのfgetcsv()はロカール依存という糞仕様なのか - muddy brown thang

ただし "C" ロカールでは portable characters 以外での標準関数の挙動は未定義なので、libcによってはうまく動かないかも。

とのことなので、C ロケールで portable characters 以外の文字を 1 バイトとして扱ってくれない例を調べてみたのですが、

Behavior of extended bytes/characters in C/POSIX locale - Stack Overflow

によると Plan 9、Minix、*BSD family あたりのようです。このあたりの環境でも使用するスクリプトを書く場合は C ロケール以外にしましょう。

理由その2: 文字境界を気にする必要はあまりない

RFC 4180 における CSV 上でのメタキャラクタは

LF (U+000A)
CR (U+000D)
「"」(U+0022)
「,」(U+002C)

の 4 つなので、UTF-8 だろうと Shift_JIS だろうと 2 バイト目以降に出現しない文字です。「"」を「""」でエスケープしている限りは 1 バイト単位で扱っても問題ありません。

一方「\」(U+005C) は Shift_JIS の 2 バイト目に出現します（UTF-8 の 2 バイト目以降には出現しない文字です）ので、Shift_JIS でかつ「"」が「\"」で表現された CSV ファイルを読む場合だけ文字境界に注意が必要です。とはいえ、現在の PHP ではフィルタが使えるので、あらかじめ UTF-8 に変換して読み込んでしまえば問題ありません。以下に例がありました。

巨大なSJISのCSVファイルをfgetcsv関数で処理する - hnwの日記
- ここで使っている Stream_Filter_Mbstring を Composer で使えるようにしている方もいました。
- xcezx/Stream_Filter_Mbstring

理由その3: マルチバイトの処理がバグってそう？

もう一つ C ロケールを勧める理由があって。$escape = "\\" ではマルチバイトの扱いにバグありそうなのです。

PHPのfgetcsvでうまく読み込めないケース - F.Ko-Jiの「一秒後は未来」

ここで「1,"\あ",おはよう」が読めない例が挙がっていますが、ソースを見ると、エスケープ文字の直後であることを示す state=1 がマルチバイトを読んだときに解除されず、シングルバイトの文字に出会った時に始めて処理されるようになっていそう（「1,"あ\",おはよう」と書いたのと同じような動作になっていそう）でした。C ロケールならこの動作は回避できます。
（上のほうにも書きましたが、$escape = '"' の場合は $escape の判定よりも「""」の判定が先に来ているので、この影響を受けません。）

蛇足:「Excel で開いた時におかしくなるんだけど」と言われたら

蛇足ですが、CSV ファイルに「0123」のようなコードを出力していたとしても、Excel で開くと「123」になったりするので、「なんとかならないの？」と言われることもわりとあります。

この場合は「'0123」のように文字列型であることを明示したり「="0123"」のように計算式を埋め込んだり、といった胡散臭い対策が知られてますが、人間が Excel で開くのが目的なら .xls やら .xlsx を出力したほうがいいんじゃないかと思います。

2014/12/16 追記

ソースを読み返してみると、ロケールが合っていなかった場合（mblen が -1 を返した場合）もシングルバイトの文字として処理しているので、Shift_JIS の CSV ファイルを $escape = "\\" で読む場合を除いては、ロケールが合っていなくてもうまく読めるケースがほとんどのような気がします。というかこれ以外のケースで問題になるケースが思いつかない・・・。

そのわりに「ロケールを設定したらうまくいった」と書いている人がわりと多いので、何か勘違いしているかもしれません。余裕のある時にもうちょっと調べてみます。

Laravel Homestead の SSH が 2 分に一度固まる問題

Tue, 09 Dec 2014 23:51:57 +0900

最近プライベートで仕事を頼まれてて Laravel を使っているんですが、この開発用 Vagrant box である Homestead に SSH で接続すると、たまにターミナルの応答がなくなることがありました。
（Windows 上の VirtualBox 4.3.12 での話。Ubuntu 上の VirtualBox では問題は再現しませんでした。）

地味にイラッとする感じなので、とりあえず簡単に回避策を調べてみました。

調査

まずは

php -r '$c = 0; $last = microtime(true); while (1) { $now = microtime(true); printf("%4d: %f\n", $c++, $now - $last); $last = $now; sleep(1); }'

みたいなコマンドを実行して、どれくらいの間隔で発生しているかと、OS 全体が固まってるのか応答がなくなっているだけなのか調べてみました。

応答がなくなっている間も出力は 1 秒間隔に行われるようなので、OS 全体が固まってるわけではなく、SSH の応答がなくなっているだけの模様。また、応答がなくなるのは 120 秒間隔であることがわかりました。

次にサービスを落としていって確認すると、どうも puppet サービスが原因のようで。service puppet start 時にもターミナルが固まる現象が見られたので、strace で動作を見てみると、DNS サーバ（10.0.2.3）に puppet という名前の A レコードと AAAA レコードを問い合わせている間にターミナルが固まっている様子でした。

試しに

dig puppet

とやってみたら、これだけでもターミナルが固まるようですので、Homestead や puppet というよりは VirtualBox の DNS まわりの問題なんでしょうね。

回避策

puppet のこともよくわからないので適切な解決策かはわからないのですが、

sudo service puppet stop

で止めてしまえばターミナルは固まらなくなりました。/etc/hosts で puppet を 127.0.0.1 に向ける等の対策でもよいみたいです。

・・とまあ簡単な対応ですが、気になっていた挙動がなくなってすっきりしました。もっと適切な対応方法がある場合は教えてくださいませ。

謎のリクエスト「88952634」

Mon, 20 Oct 2014 01:46:36 +0900

今運用をお手伝いしているサイトでログを監視していると、パラメータに「88952634」が指定された謎のリクエストが来ることがあります。

この数字で検索をかけると、被害に遭った大量のサイトが出てくるし、Q&A サイトに「このリクエスト何？」という質問が挙がっていたりもします。

パラメータは「88952634' and 's'='s」みたいになっていることもあるので、脆弱性検査ツールの類によるアクセスなのは間違いないと思うんですが、具体的にどんなツールか気になったので調べてみました。

結論

先に結論を書いておくと、Safe3WVS（Safe3 Web Vulnerability Scanner）という脆弱性検査ツールによるものだと思われます。

Safe3 Web漏洞扫描系统 v9.6免费版 - Safe3 - 博客园

このページにリリースノートがありますが、スクリーンショットで「88952634」という数字が使われているのが確認できます。

Safe3 について

上記ツールの開発元は Safe3 という会社のようで。公式ページは http://www.safe3.com.cn/ のはずですけど、改装中？なので、Internet Archive で見るのがよさそうです。

安全伞网络 - 值得信赖的网络安全顾问！（Internet Archive）

セキュリティ関係のサービスを行っている会社とのこと。

現在は QQ空间（Q-Zone）を使って公報活動を行っていそうです。

http://88952634.qzone.qq.com/

ドメインを見るとわかるように、88952634 という数字はこの会社が使っている QQ number（テンセントQQ を使用する時に使われる ID）のようです。試しに QQ に利用登録してみたのですが、勝手に発番されるものなので、この数字自体に何か意味があるわけではなさそうです。

ツールについて

この Safe3 という会社、Google Code と SourceForge でいくつかセキュリティ関連のツールを配布しているみたいです。
（Google Code や SourceForge に置いてるわりにソースは公開されていませんが・・・）

Google Code
- Safe3WAF(Safe3 Web Application Firewall)
  - http://code.google.com/p/safe3waf/
- Safe3WVS(Safe3 Web Vulnerability Scanner) ※バイナリ配布もなし
  - http://code.google.com/p/safe3wvs/
- Safe3SI(Safe3 Sql Injection Tool) ※バイナリ配布もなし
  - http://code.google.com/p/safe3si/
SourceForge
- Safe3WVS(Safe3 Web Vulnerability Scanner)
  - http://sourceforge.net/projects/safe3wvs/
- Safe3SI(Safe3 SQL Injector)
  - http://sourceforge.net/projects/safe3si/

SourceForge のアップロード者は David Shee という人物のようで、この名前（や「Safe3」の文字列）も被害サイトでたまに見かけました。

せっかくなので Safe3WVS を実際に動かしてみたのですが（ブラウザのスタートページを hao123 に変えられたりするので、捨てていい VM 等で試しましょう）、9.0 無料版だと GET での SQL Injection のチェックしかできないせいか、88952634 のリクエストは再現できませんでした。残念。

なので Safe3WVS 以外のツールによるアクセスの可能性も残っていますが、とりあえず目星がついてすっきりしたので調査はこの辺りで終了、と。

ITサービスマネージャ（試験）

Sun, 19 Oct 2014 02:22:07 +0900

去年に続いてITサービスマネージャを受験してきましたので、例によって色々メモです。

今回の対策本など

まず前回の受験時に使った本をさらっと読んで、知識面の復習をして。

今回は午後IIに集中したかったので、この本を購入。

ITサービスマネージャ合格論文の書き方・事例集第3版 (情報処理技術者試験対策書)

作者: 粕淵卓,庄司智浩,鈴木久,長嶋仁,森脇慎一郎,岡山昌二
出版社/メーカー: アイテック
発売日: 2012/07/02
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

H19（2007）〜H23（2011）の 5 年分についてサンプル論文が載ってる。H21（2009）から試験制度が変わってるわけだし、H21〜H25 のものが載った改定版でも出てくれれば完璧だったんだけど。
サンプル論文は「読者が材料として使えるように色々と情報を盛り込む」というスタンス。こういう方針がはっきりしているのはいい。

この試験は何度も受けているので過去問で練習しててもどうも見覚えがあって、初見の問題でどの程度書けるようになっているか判断できなくなってきたので、オリジナル問題が載っている本も買ってみた。

ITサービスマネージャ分野別予想問題集 (情報処理技術者試験対策書)

作者: アイテック教育研究開発部
出版社/メーカー: アイテック
発売日: 2013/08/16
メディア: 単行本
この商品を含むブログを見る

午後IIの問題は10問載ってて、うち8問が完全なオリジナル？解答のポイントは載っているけど、解答例がないものもあるのでそこは要注意。

あとは、ネットで対策を調べてたら【ワカヤマン】ITサービスマネージャ Part4 なんてスレがあって。>>389 で紹介されてた以下の二冊を試験前日に書ってさらっと読んだり。

システムはなぜダウンするのか

作者: 大和田尚孝,日経コンピュータ
出版社/メーカー: 日経BP社
発売日: 2009/01/22
メディア: 単行本
購入: 24人クリック: 345回
この商品を含むブログ (45件) を見る

こちらは障害の事例がたくさん載っているので、確かに障害に関するネタ出しには使えそう。

情報処理教科書高度試験午後II論述春期・秋期 (EXAMPRESS)

作者: ITのプロ46,三好康之,秋田智紀,佐久間賢次,藤田章康
出版社/メーカー: 翔泳社
発売日: 2013/07/23
メディア: 単行本（ソフトカバー）
この商品を含むブログ (8件) を見る

複数の試験区分を並行して学習することを勧めていたり、もっと早く読んでおいたら役に立ったかも、と思える本。
午後II の問題を読み込むことを重視してる。あとなぜか乃木坂46。

その他、

重要インフラ障害情報の分析に基づく「情報処理システム高信頼化教訓集（ITサービス編）」　〜障害の再発防止のため、業界を越えて幅広く障害情報と対策を共有する仕組みの構築に向けて〜：IPA 独立行政法人情報処理推進機構

この資料も読んでみたり。「教訓例：待機系システムへの切替えが失敗する原因一覧」とか、イメージしやすくてすごくいいと思うので、こんな図がもっと増えるといいな。

勉強っぷり

試験前の 1 ヶ月を勉強期間に設定して。平日は体調悪かったりで勉強できない日も多かったけど、休日はちゃんと図書館に籠って勉強してた。

午後II は H19（2007）〜H25（2013）の 7 年分でひととおりで骨子を考えたり、設問アの前半を書く練習をしたり。実際に二時間かけて論文を書いたのは前日に一回のみ。

午前IIの対策は、通勤中に

情報処理技術者試験の勉強をやり直し　−ITパスポート、基本情報技術者、応用情報技術者、高度試験の過去問題の解説−

このサイトで過去問を 2 年分解いたくらい。このサイトは高度試験の解説がちゃんと載ってるので助かる。（たまに誤字や解説の間違いもあるけど・・・）

午後Iの対策は、2013 ITサービスマネージャ「専門知識+午後問題」の重点対策 (情報処理技術者試験対策書) に載っていた設問パターンを読んだのと、前回受験時の注意点

午後Iで間違えるパターンは、汎用的な対策を問われている場面で個別の対策を答えてしまっているのが多かった。マネージャとしてプロセスを改善するつもりで答えることを意識すればいいみたい。

を思い出しておいた程度。

試験

受験会場は明治学院高等学校＠高輪台。ここ来るの何度目だろ。

午前II

厳しめ自己採点で 79%、実際に採点すると 88% で間題なし。やっぱり過去問やってれば大半は解ける感じ。

午後I

去年もそうだったけど、慎重に解いてたら時間が足りなくなってしまった。問題数が少ないから、一問答えられなかったのは結構痛い。
午後Iの勉強をしておけば解答の勘所がわかって多少マシだったかもしれないけど、やったからと言って大幅に得点が変わったりはしない気もする。もし今回通過ラインだったら、次回もこれくらいの対策でよさげ。

午後II

テーマは移行と障害なので、例年に比べると 2 問とも多少は書きやすいテーマ。
とりあえず問2「ITサービスの障害による業務への影響拡大の再発防止について」を選んだ・・・ところまでは良かったんだけど。骨子を考えるのに 30 分使ってしまった上、「論述の対象とするITサービスの概要」も練習していたのとはフォーマットが違ってちょって手こずったり。チーム名をどう表現するのがわかりやすいか、なんて考えてなかったよ・・・。
なんとか時間内に最低限の文字数は書いたけど、文のまとまりは悪いし、「したした論文」だし、マネージャーの視点がどうとか考える余裕がなかったし、システムの複雑化っていう状況も盛り込めてない・・・のでダメそう。文字数を数える余裕もなかったけど、ア: 700 字、イ: 900 字、ウ: 600 字くらい。（ウは最終行を「以上」で水増しした）

反省＆感想

今回は論文を中心に対策してきたつもりだけど、あいかわらずいい論文が書けない。

個人的には「情報処理試験は、対象者像に合致している人にはちゃんと解ける問題が出る」という印象があって。ここ数年は運用に近い経験を積んでいるので、できれば想像で作った事例ではなく、実務経験をベースに論文を組み立てたいという思いがあったのだけど、今の運用はマネジメントがそれほどきっちりしていない（見えてない部分で何かやってるかもしれないけど）ので、「あらかじめ備えておいたけど問題があった」みたいな手ごろなレベルの経験がなかなか書けない。

そんなわけで、次回は情報処理教科書高度試験午後II論述春期・秋期 (EXAMPRESS) に書いてたみたいに、実務ベースで組み立てるんじゃなくて、想像で事例を作っていこうかな、と考えているところ。

学習のスタンスもこの本に従って午後IIの問題から入ってみようかなと。前回は「午後Iがネタの宝庫だ」みたいな意見に従って午後Iを解いていたけれど、どうもピンとこなくて。ところが今回午後IIをある程度解いてから午後Iの問題を解いてみると、確かにこれはネタになるなと思えたので。午後IIをひととおり解く→午後Iを解きながら午後IIの準備をブラッシュアップ、のイメージで。

もう一つ、たまに試験のことを思い出すように 2ch のスレもヲチしよう。

（2014-12-20 追記）成績照会

午前I得点
***.**点
午前II得点
88.00点
午後I得点
64点
午後II評価ランク
B

テーマが書きやすかったおかげで前回の C よりはマシでした、と。

Solr検索クエリの（たぶん）正しいエスケープ

Sat, 05 Jul 2014 21:50:44 +0900

Solr で検索するときの特殊文字のエスケープ方法を調べていたんですが、ちゃんと実装＆説明されているケースが見あたらなかったので、自分なりに説明を書いておきます。

想定するケース

ユーザが入力した文字列 str を使って、

query = "title:" + escape(str);

のように検索式を組み立てる場合に、その文字列自体で検索するにはどのようにエスケープすればいいかを考えます。デフォルトのクエリパーサの動作しか調べていませんので、別のクエリパーサ（DisMax 等？）を使っている場合は何か変更が必要かもしれません。

エスケープの方法

エスケープは「\」を直前に挿入する前提で説明します。ダブルクォートで囲むことでも特殊文字を解釈させなくすることは可能ですが、フレーズ検索になってしまって期待とは違う結果が返ってしまうこともあるでしょうし、フレーズ検索の内部でも結局「"」のエスケープは必要になりますので。

SolrQueryParserBase の実装を見ると、エスケープが不要な文字を「\」でエスケープした場合、例えば「\あ」とした場合は「あ」そのものとして解釈されるようです。\uXXXX によるエスケープも解釈してくれるようですが、特にそうする必要もないので「\」を使ったエスケープを使えばいいでしょう。

エスケープの対象

以下の 3 つをエスケープする必要があります。

エスケープが不要な文字を「\」でエスケープしても問題ないので、極端な話をしてしまうと、全ての文字をエスケープしてしまっても問題ないといえばないです。

(1) 特殊文字

Solr Wiki に載っている情報です。

SolrQuerySyntax - Solr Wiki

Certain characters are special (pre-4.0) or (4.0+) and those characters need to be escaped using quotes or a backslash if you want them to be treated as literals.

ということで、Solr 4.0 以降では

+ - && || ! ( ) { } [ ] ^ " ~ * ? : \ /

のエスケープが必要です。Solr 4.0 から正規表現が使えるようになって「/」のエスケープも必要になっているんですが、最近書かれた記事でもこれが足りないものは結構ありました。

ちなみに、「&&」「||」の 2 つを「\&&」「\||」にエスケープしている実装を見かけて「この実装だと『&&&』が入力された場合に『\&&&』になる（『&&』が残る）から SyntaxError になるのでは？」とも思ったのですが、間に空白がないとトークンとして扱われないので問題なさそうでした。

(2) 空白文字

ユーザが「a b」を入力した場合、そのまま文字列を組み立てると「title:a b」となり、df（デフォルト検索フィールド）が「text」、q.op（デフォルト検索式）が「OR」の場合は「title:a OR text:b」の意味になります。たぶんこれは期待した結果ではないと思うので、空白もエスケープしましょう。

空白として扱われる文字は明言されていないのですが、ソースコードを見ると

 | <#_WHITESPACE:  ( " " | "\t" | "\n" | "\r" | "\u3000") >

となっていました（U+3000 は全角空白です）ので、この 5 文字を含む形でエスケープしましょう。

SolrJ の ClientUtils.escapeQueryChars は Character.isWhitespace を使っており、この 5 文字以外の空白も全てエスケープしています。Unicode 対応の正規表現が使えるのであれば、これを見習って \s や [:space:] でマッチしたものをエスケープしてしまってもいいでしょう。（実装によってエスケープされる文字が違ったりするので、ちゃんとテストして使いましょう。）

(3) AND/OR/NOT

特殊文字は一切含まれていませんが、「title:AND」とすると

org.apache.solr.common.SolrException: org.apache.solr.search.SyntaxError:
Cannot parse 'title:AND': Encountered " <AND> "AND "" at line 1, column 6.

のように SyntaxError になってしまいますので、これもエスケープしておきましょう。

文字列が「AND」「OR」「NOT」のいずれかと一致する場合は、それぞれ「\AND」「\OR」「\NOT」にエスケープすればよいです。小文字を含む「and」「And」等はただの文字列として扱われますので、この 3 パターンだけ対応すれば大丈夫です。

一番対応が漏れやすいと思われる部分で、私も別システムでのエスケープ実装を見ていなかったらちゃんと実装できていなかったと思います。

実装例

調査が間に合わなかったので、実際に使っているコードは少々違うのですが・・・。Java で SolrJ を使っているのであれば、AND/OR/NOT に対応するために ClientUtils.escapeQueryChars を軽くラップすれば大丈夫です。

    private String escape(String str) {
        if ("AND".equals(str) || "OR".equals(str) || "NOT".equals(str)) {
            return "\\" + str;
        }
        return ClientUtils.escapeQueryChars(str);
    }

PHP だとたぶんこんな感じで期待通りに動作します。/u 修飾子を使わないと \s が U+3000 にマッチしないようなので要注意です。

<?php
function escape($str) {
    if (preg_match('/\A(?:AND|OR|NOT)\z/', $str)) {
        return '\\' . $str;
    }
    return preg_replace('#([+\-&|!(){}[\]^"~*?:\\\\/\s])#u', '\\\\\\1', $str);
}

セキュリティ的にはどうか

正しい（と思われる）エスケープ方法を説明してきましたが、クエリのエスケープに漏れたからといって、それがセキュリティ面で問題になってくることは少ないと思います。操作できるのは検索クエリなので、できるのはせいぜい全ドキュメントをヒットさせることくらいです。（上限値の設定が不適切なら、それはそれでメモリを枯渇させることも可能かもしれません。）

Solr 4.0 で正規表現が使えるようになっているので、効率の悪い正規表現を実行させて DoS に使えないかとも思ったのですが、DFA の dk.brics.automaton が使われているようなので、その心配もありません。

ただしクライアントライブラリを使わずに自前で Solr サーバにリクエストを投げていて URL エンコードを怠っているような場合は、

aaa&fl=id:"<script>alert();</script>"

といった文字列を渡すことで、

/select?q=aaa&fl=id:"<script>alert();</script>"

のように本来 HTML エスケープが不要な項目に HTML を返させて XSS を起こすくらいはできるかもしれませんし、本来ユーザに見せるべきでないフィールドの値を返すこともできるかもしれません。自前で実装しているなら、クエリ中のエスケープなんかよりも先に URL のエンコードを気をつけたほうがよさそうです。

エスケープすれば十分か

数値フィールドに数値以外を渡すと「Invalid Number」エラーになる
入力値が長すぎると Jetty の「HttpParser Full」エラーになる

といった問題があるので、エスケープすればそれで OK というわけではないです。バリデーションもちゃんとやっておきましょう。

Solrのフレーズ検索についてちょっとメモ

Sat, 21 Jun 2014 16:52:12 +0900

最近 Apache Solr を触ってます。基本的に

［改訂新版］Apache Solr入門――オープンソース全文検索エンジン：書籍案内｜技術評論社

この本を読めば基本的なところはわかるのですが、フレーズ検索のところだけわかりづらかったので、ちょっとメモしておきます。

この本の p82〜p83 に検索式の記述方法が載っていて、フレーズ検索の説明は

検索式の例: title:"Webプログラミング"
説明: 2つ以上の単語の出現順序を保証した検索

となっています。出現順序を保証するということは、"Webプログラミング" で検索する例だと「Webプログラミング」や「Webアプリケーションプログラミング」にはヒットするけど「プログラミングWeb」にはヒットしないということだと理解していました。

じゃあ厳密に「Webプログラミング」の単語を含む場合だけヒットさせたい場合はどうするんだろう？と調べてみると「フレーズ検索を使え」という情報が出てきて、ちょっと混乱してきました。それなら本にも「2つ以上の単語が連続して出現することを保証した検索」とか説明が書いてそうなものだけど。

図書館で Apache Lucene 入門 ~Java・オープンソース・全文検索システムの構築を借りていたので、こっちの説明も見てみます。
p171

Luceneは「フレーズ検索」をサポートする。フレーズ検索というのは，次のようにダブルクオーテーションで2語以上からなる検索質問語をくくって，指定された語が連続して現れるドキュメントを検索するように指示できる機能のことだ：
"Java プログラミング"

あれ？やっぱり連続する部分を検索するの？

・・・と思ったけど。p190 より。

Luceneのフレーズ検索では，フレーズを構成する語は互いに離れていてもよい。1つのフレーズとみなせる語と語の最大距離をslopと呼び，PhraseQueryのsetSlop()メソッドでフレーズ検索時に許容するslopを設定する。デフォルトのslopは0であり，その場合は，PhraseQueryにadd()メソッドで追加した語が追加した順番に隙間なは現れている Documentが検索される。

slopを1以上にすれば連続してなくても検索できるそうで。Solr でもそういう指定が可能なのかはわからないですが、確かにそれなら「出現順序を保証した検索」という説明で正しいみたいです。ちょっとわかりにくいですけどね。

ということで、Apache Lucene 入門を返却する前にメモでした。この本は Solr を使う上では知らなくていい情報も多いのですが、上記のように個々の説明が詳しかったり、スコアの計算がどんな感じになっているか書いてあったりで、参考になりました。

paizaオンラインハッカソンVol.2 と PHP コード最適化の話

Sun, 18 May 2014 17:44:28 +0900

女子大生とペアプロするだけの簡単なお仕事です！｜paizaオンラインハッカソンVol.2

会社の人からこのネタを振られて。「業務で PHP を使ってる身だし、PHP で最速を目指してみるかー」とやってみたので、そのお話。

さっそくやってみた

30 分くらいでてきとうに解いたところ・・・。

miauさんの採点結果[28点]

Test case 3 失敗（出力結果が間違っています）

えー？時間切れならともかく、答えが合わないってことは無いと思うんだけどなぁ。

後に判明したんだけど、

PHP,Ruby,Python,Perlは全テストケースで以下の条件を満たします。
1 ≦ H ≦ 130　※ 画面縦の区画数
1 ≦ W ≦ 130　※ 画面横の区画数
1 ≦ N ≦ HW　※ ウィジェットの個数
1 ≦ S_i ≦ 300 (1 ≦ i ≦ N)　※ ウィジェット縦大きさ
1 ≦ T_i ≦ 300 (1 ≦ i ≦ N)　※ ウィジェット横大きさ

「この『1 ≦ S_i ≦ 300 (1 ≦ i ≦ N)』は『1 ≦ S_i ≦ 130 (1 ≦ i ≦ N)』の誤記だよなー」、と勝手に問題を読み換えてたせいでした。チューニングする→答えが合わない、みたいなことを繰り返してるうちに応募受付期間が終ってしまったので、「※130 ではなく 300 です」みたいに明示しておいてくれると嬉しかったなー、とか思いました。

考えたアルゴリズム

今回の問題に興味がある方だけどうぞ。PHP のコード最適化にしか興味がない方は、「最適化」のところまで読み飛ばして大丈夫です。

ステップ1

こういうホーム画面があるとして。まずは各座標から、右に連続する 0 の個数を数えます。

ステップ2

この各列の末尾に番兵っぽく 0 を入れた上で、縦方向に

523000 412340 301230 220120 111010

と読んでいきます。

523 という並びは、この列から右向きにこの幅のウィジットが置ける、つまり

00000
00
000

といった領域に配置が可能だという意味でした。ここから各列に置ける最大のウィジットの個数を

$preCount = [
    1 => [3 => 1], // 1 列目には高さ 3 のウィジットが 1 つ置ける
    2 => [3 => 1], // 2 列目には高さ 3 のウィジットが 1 つ置ける
    3 => [1 => 2], // 3 列目には高さ 1 のウィジットが 2 つ置ける
    5 => [1 => 1], // 5 列目には高さ 1 のウィジットが 1 つ置ける
    4 => [1 => 1], // 4 列目には高さ 1 のウィジットが 1 つ置ける
]

といった形で求めます。これは、各列ごとに 0 が始まった時点での y 座標を覚えておいて、0 が終わった時点での y 座標との差分を求めることで埋めていきます。

ステップ3

上記のデータ上で「2 列目には高さ 3 のウィジットが 1 つ置ける」となっていても、実際は

高さ 3 のウィジットが 1 つ
高さ 2 のウィジットが 2 つ
高さ 1 のウィジットが 3 つ

置けるので、これを展開して、

$count = [
    1 => [3 => 1, 2 => 2, 1 => 1],
    2 => [3 => 1, 2 => 2, 1 => 1],
    3 => [1 => 2],
    4 => [1 => 1],
    5 => [1 => 1],
]

この形に変えます。

ある列から見て n 列目にウィジットを置けるというのは、結局幅 n のウィジットを置けるのと同じことなので、$count[$width][$height] は $width x $height のウィジットをいくつ置けるかというデータになります。あとはウィジット毎にこの配列からルックアップするだけ、と。

これを実装したコードがこれ（最初に投稿したコードではなく、変数名とかをわかりやすく書き換えたもの。）で、

https://gist.github.com/miau/f69653684c084f1f3ccd/383ac4ee2ddaea4212876bc0cf66e6a1eb73e33d

この状態では

http://paiza.jp/poh/paizen/result/8bbaa2b1b9885fe85f21ddbdcca56a8e

Test case 7 は 0.12 秒と。（以下 Test case 7 の時間を基準で考えます。）

もっと効率のいいアルゴリズムもあるかもしれませんが、思いつかないのでこれベースで最適化について説明します。

最適化

競技プログラミングでも、業務アプリでも、計算のオーダーを減らすことが大切です。O(N^2) で済む処理を O(N^3) で書いたりしていたら、最適化してもほとんど効果はないです。

十分計算のオーダーが減って、それでもさらに処理を速くしたい場合は、最適化に手を出すことになります。

最適化については以下の URL に色々と載ってました。

PHPコード最適化Tipsのウソと本当(解説) - カタコト日記
- 実例つきでいくつか解説されてます
徹底検証！PHP最適化Tips：特集｜gihyo.jp … 技術評論社
- もっと詳しい話。計測やデバッグについても書かれているのがいいです。

遅くならないコードを書く（未定義のローカル変数を参照して warning が出ないように書くとか）のが大切ですが、PHP コードを最適化をする上で重要なのは、前者の URL に載っていた

39. もとから用意されてる関数たちを活用しよう。

これだと思ってます。

C のように自前で処理を書いても十分な速度を出せる言語では、最適なデータ構造とアルゴリズムを自前で実装すればいいのですが、PHP でがんばって複雑な処理を書いても実行が遅くなります。PHP の処理を減らして、C で書かれている標準関数をいかにうまく使ってやるかがポイントになります。

わかりやすい例では、さきほどのコードにあった

for ($x = 0; $x < $w; $x++) {
    $map[$h][$x] = 0;
}

この処理は、

$map[$h] = array_fill(0, $w, 0);

と書けます。こうしたほうが処理が速いですし、可読性も高くなることが多いです。

さて、さきほどの処理でボトルネックになっているのは、実はここ。

fscanf(STDIN, '%d', $n);
for ($i = 0; $i < $n; $i++) {
    fscanf(STDIN, '%d%d', $wh, $ww);
    echo isset($count[$ww][$wh]) ? $count[$ww][$wh] : 0, "\n";
}

最後に各ウィジットのサイズを読み込んで結果を出力するループですが、PHP 側で最大 16900 回

ループの駆動
標準入力からの読み込み
配列のルックアップ
標準出力への書き出し

の処理を行っているので、まあ遅いわけです。

こんな感じに書き換えるとどうでしょうか。

fgets(STDIN);
$data = stream_get_contents(STDIN);
echo preg_replace_callback(
    '/([0-9]+) ([0-9]+)/S',
    function($m) use ($count) {
        return isset($count[$m[2]][$m[1]]) ? $count[$m[2]][$m[1]] : 0;
    },
    $data
);

ループの駆動は preg_replace_callback() の内部で行われるようになり、PHP 側で行っている

標準入力からの読み込み
標準出力への書き出し

も一度ずつしか行われなくなりました。PHP 側で 16900 回行われるのは、配列のルックアップ（とクロージャの呼び出しに伴なうオーバーへッド）だけです。
（ちなみに正規表現では S 修飾子を使ってます。詳しくはこちらを参照。
　正規表現処理エンジン PCRE のパータン分析スイッチの有効性について [nao-pon/blog/2013-06-27] - UsersWiki - XOOPSマニア）

変更後のコード全体は

https://gist.github.com/miau/f69653684c084f1f3ccd/4269fa28a86e6fe415eab0998192dbc94f70c5cc

これで、結果は・・・

http://paiza.jp/poh/paizen/result/292cc179848685787e496ab6f5f373e2

0.12 秒から 0.05 秒になりました。
（2014/05/22 追記）
・・・と偉そうに書いておいてなんですけど、

 fscanf(STDIN, '%d', $n);
+$out = '';
 for ($i = 0; $i < $n; $i++) {
     fscanf(STDIN, '%d%d', $wh, $ww);
-    echo isset($count[$ww][$wh]) ? $count[$ww][$wh] : 0, "\n";
+    $out .= isset($count[$ww][$wh]) ? $count[$ww][$wh] : '0';
+    $out .= "\n";
 }
+echo $out;

のように出力を一度にするだけでも十分速いですね。ローカルでの計測だと preg_replace_callback() のほうが 0.002 秒くらい速い程度でしたが、環境によってはこちらのほうが早いのかも？
（2014/05/22 追記ここまで）

ダメ押しでもう一つ最適化してみましょう。ステップ1 で 0 の連続を、

for ($y = 0; $y < $h; $y++) {
    $width = 0;
    for ($x = $w - 1; $x >= 0; $x--) {
        if ($rawMap[$y][$x] == '0') {
            $map[$y][$x] = ++$width;
        } else {
            $map[$y][$x] = $width = 0;
        }
    }
}

のようにして数えてますが、これも標準関数に任せられないでしょうか。残念ながら PHP は今回の用途に使えるような配列関数が充実していないのですが、文字列であれば preg_replace_callback() に任せられます。幸い幅も高さも 130 までで、1 byte に収まりますので、

$map = [
    ['5', '4', '3', '2', '1'],
    ['2', '1', '0', '2', '1'],
    ['3', '2', '1', '0', '1'],
    ['0', '3', '2', '1', '0'],
    ['0', '4', '3', '2', '1'],
];

ではなく、

$map = "\x05\x04\x03\x02\x01"
     . "\x02\x01\x00\x02\x01"
     . "\x03\x02\x01\x00\x01"
     . "\x00\x03\x02\x01\x00"
     . "\x00\x04\x03\x02\x01";

この形に持ってしまいましょう。すると、上記部分の処理はこうできます。（左右どちらから数えても同じなので、54321 ではなく 12345 のようにしています。その他細かい変更もあるので詳しくは diff を見てください。）

$chars = "\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f !\"#\$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\x7f\x80\x81\x82";
$rawMap = preg_replace_callback(
    '/0+/',
    function($m) use ($chars, $w) {
        return substr($chars, 0, strlen($m[0]));
    },
    $rawMap
);

コードの最終形は

https://gist.github.com/miau/f69653684c084f1f3ccd/24cfd0b449b0fe2754089ddca65c4485d15a69a6

これで、結果はこう。

http://paiza.jp/poh/paizen/result/ab1174e7dd0e3a3350228da90220cfce

・・・あれ？タイムは変わらず 0.05 秒のままですね・・・。
ローカルでは 0.002 秒くらい速くなってましたし、以前これと同じ処理を書いたときは 0.04 秒になったので、調子がよければ 0.04 秒に乗るんじゃないかと思います。

とまあこんな感じで、PHP での最適化は標準関数を組み合わせるパズルみたいになってくるので、個人的にわりと楽しいです。

最後に

最適化のやり方をいくつか書きましたが、業務では可読性優先で書いています。上記のような最適化をするのは、呼び出し回数が多く、他の人の目に触れることが少ないフレームワークやライブラリの内部だけです。それもボトルネックがあったであることが判明してからで、上記の例だと 1 つめの最適化はやっても、2 つめは実コードとしては残さないでしょう。

実際にやった例を載せておきます。

https://gist.github.com/miau/f84374fe13b9a1ef5523

Doctrine2 で Oracle にクエリを投げる際に使われるパラメータ置換処理（「?」を「:param1」等に書き換える処理）が遅かったので、まさに今回書いた preg_replace_callback() での最適化を行ったのでした。この処理はコールバックが呼ばれる回数が少ないので preg_replace_callback() による最適化は特に有効で、確かこの処理単独で 20 倍くらい速くなった気がします。

「速くしたいなら拡張モジュールを作れば？」って意見もあるかと守いますが、保守性の問題で手を出していません。元々 PHP しか知らない人でも保守できるように PHP で開発しているわけで、C を書けないと保守できないようだと意味がないので。

とはいえ、自分で拡張モジュールを作って「やっぱり C で書くと速いよなー」とかなんとか遊んだりはしてました。これをやっておくと最適化するときにある程度処理コストの予想ができるようになるので、知識として知っておいて損はないですね。まあ予想が裏切られることも多いので、最終的には計測が重要ってことになるのですが。

ScanSnap S1500 と fi-7160 の比較(2)

Tue, 13 May 2014 00:59:07 +0900

ということで、前回の続きです。ScanSnap S1500 と fi-7160 で、ぐにょり以外のスキャン時の画質（裏写り、ぼやけ、縦線）を比べてみました。

比較その2: 裏写り

fi-7160 では裏写りが改善しているという噂なので、ここも軽く比べておきます。検証用に中古で買った咲 Saki (4) (ヤングガンガンコミックス) から、裏写りが目出つコマを抜き出してます。

まず、ScanSnap S1500 での RAW 画像（↓）。わりとはっきり裏の文字などが見えると思います。

ScanSnap Manager で出力された画像がこちら（↓）。

私の環境では裏写りがずいぶん軽減されて見てるのですが、実際はカラープロファイルを使って色変換をかけているだけで、裏写りを除去する特別な処理が入っているわけではなさそうです。ImageMagick で

convert ScanSnap0.jpg -profile "ScanSnap S1500.icm" -profile "sRGB Color Space Profile.icm" scansnap_raw_profile.jpg

を実行したのとほぼ同様でした。（.icm は %SYSTEMROOT%\system32\spool\drivers\color からコピーして使っています。）

次に、fi-7160 で ScanSnap Manager for fi Series を使った場合。RAW 画像はこんな感じ（↓）です。裏写りは ScanSnap の RAW 画像と同じか、やや目立たない程度ですかね。

ちなみに ScanSnap の RAW 画像と比べると、かなり暗い画像で出力されているのがわかると思います。参考のために RAW 画像の全体像も貼っておきます。

（S1500 の RAW 画像）

（fi-7160 の RAW 画像）

ここからの処理はまだ詳しくは追っていないのですが、ScanSnap 同様色変換は行っているようです。ImageMagick で

convert "ScandAll PRO0.jpg" -profile "SSM_fi-7160.icm" -profile "sRGB Color Space Profile.icm" fi7160_raw_profile.jpg

として再現してみました（↓）。少しだけ裏写りが目立たなくなりました。

これに加えて ScanSnap Manager for fi Series では何かしら変換をかけているようで、最終的に出力される画像はこの状態になります（↓）。私の環境だと判別できない程度に裏写りは消えました。

Leeyes で平均化フィルタをかけて見ると裏写りした情報も残っているようなので、これも特別に裏写り除去の処理が入っているわけではなく、コントラストを強くする類の補正じゃないかなと思います。

fi-7160 は TWAIN ドライバが使えるので、BTScan でスキャンしたものも貼っておきます。一つ前の最終形に比べるとやや裏写りが目立つかな、という程度ですね。

結論としては、S1500 よりも fi-7160 のほうが裏写りが減った画像が出力されるけど、光学系で何か工夫しているわけではなく、画像処理が優れているだけなんじゃないかという気がします。
（2024-05-01 追記）
コメントいただいているように fi-7160 では裏当てを白→黒に変えられるので、「光学系で何か工夫しているわけではなく」というのは正しくなかったです。
（2024-05-01 追記ここまで）

比較その3: ぼやけ

前回「ニ行目に色ずれが発生している」として貼ったこの画像ですが。

その前後の行もぼやけてますよね。fi-7160 で改善しているか見てみましょう。

まずは見本ということで、フラットベッドスキャナの GT-X820 で、1200 dpi でスキャンした画像です（↓）。

次に ScanSnap S1500。600 dpi でスキャンした時の RAW 画像と最終出力をまとめて貼っちゃいます。ぐにょりが少なそうな部分を選んでいます。

（↑S1500 RAW 画像）

（↑S1500 ScanSnap Manager 出力）

やはりぼやけて見えますね。「題」の最後の二画が不鮮明ですし、ひらがなのハネもきれいに見えません。それと RAW 画像の裏写りしている箇所がノイズっぽくなっています。RAW 画像といいつつ JPEG なので仕方ないですね。

fi-7160 も 600 dpi でスキャンしたものを、前項と同じく 4 種類。

（↑fi-7160 RAW 画像）

（↑fi-7160 RAW 画像の色変換後）

（↑fi-7160 ScanSnap Manager for fi Series 出力）

（↑fi-7160 BTScan 出力）

こちらも S1500 と同程度にぼやけています。また、細かい色ずれは上の S1500 の画像よりも多そうです。前回の検証では目立たなかったんですが、黄色っぽい原稿だと目立つんですかね・・・。
この画像だけ見てもわからないとは思いますが、BTScan は TWAIN で取得した画像を JPEG の最高品質で保存しているので、変なノイズが乗ったりしないのは嬉しいです。

「1200 dpi と 600 dpi で比べてるから不明瞭になるのは当然なのでは？」という疑問もあると思うので、最後に GT-X820 で 600 dpi でスキャンした画像も載せておきます（↓）。

同じ 600 dpi でもやっぱりフラットベッドスキャナーだと綺麗ですね。まあ 1 ページをスキャンするのに数十秒かかる＋1 ページスキャンする度に作業が発生するのは堪えられないので、よほど気に入った本でないと使わないつもりですが。

比較その4？: 縦線

ホコリ等が読み取り部に留まり続けるせいで、RGB いずれかの輝度が縦のラインで常に一定になってしまう現象です。

原稿を移動させる ADF では避けられないものなので、fi-7160 でも発生します。

発生は避けられなくても検出はできるはずで、fi-7160 では「Software Operation Panel」→「装置設定2」に「縦スジ検知設定」と「縦スジ検知レベル」の設定があります。ということで「有効」「感度-高」にして実験しているんですが、今のところ検知してくれたことはありません・・・。あまり頼りにせず、こまめに清掃するのがよさそうです。

まとめ

fi-7160 は ScanSnap S1500 と比べると

ぐにょりがかなり少なくなっている（ゼロではない）
画像の補正がいい感じにかかるので裏写りが目立たない
TWAIN 対応なので、劣化のないデータが取り出せる

といった利点がありました。（速度が向上したりもしているんですけど、読むのがボトルネックになっているのでそこは重視していないです。）

ClearScan に失敗する問題は解消しなかったので、S1500 で文章中心にスキャンしている人が 9 万円近く出して買い換えるほどかというと、そうでもないと思います。マンガ等をスキャンする時には恩恵は受けられるので、こだわり次第では悪くない選択なんじゃないでしょうか。

最後に

色々とそれっぽいことを書いてきましたが、なにかしら勘違いしている部分もあるかもしれません。何かおかしな点に気付いたらご指摘ください。

ScanSnap S1500 と fi-7160 の比較(1)

Mon, 12 May 2014 01:35:35 +0900

最後に ScanSnap S1500 と fi-7160 の比較を書いて S1500 の話は終わりにしようと思ったのですが・・・長くなったので二回に分けます。

まずは ScanSnap S1500 の不満点（いわゆるぐにょり）と、それが fi-7160 で改善されたのか、です。

ScanSnap S1500 の不満点

前回書いたとおり技術書は ClearScan で OCR をかけているんですけど、たまに OCR に失敗している箇所があります。例えば以下の画像は、1 行目と 3 行目は ClearScan がうまくいっていて文字の境界がはっきりしているのですが、2 行目はぼやけた感じになっています。

読みづらいし、この箇所は検索に引っかからないことがあるしで、わりと困ります。

OCR 前の画像を見ると、OCR に失敗した行で、妙な色にじみが発生しているのがわかります。

文字だからまだ「読めればいい」と割り切れもしますけど、マンガは絵を楽しむ部分もあるので、こうなってしまうとがっかりです。

fi-7160（と GT-X820）の購入

上位機種である fi-7160 ではこの辺りが改善されているということで、消費税が上がる前に買ってしまいました。ビックカメラで長期保証をつけたので、85,800円 + 3,431円 = 89,231円。

ついでにハードカバーのスキャンや、見開きページを断栽前にスキャンするために、フラットベッドスキャナーの GT-X820 も買いました。こちらは 24,117 円。

ということで、主に fi-7160 と比較しつつ、たまに GT-X820 の話も挟んでいきます。

比較その1: ぐにょり

スキャナー - 自炊技術 Wiki* に説明があるように、

本をデジタル化しよう ScanSnapは歪むのか？
原稿の左右の端に近い部分が歪む。
なお、自炊スレの一部の人たちは、この歪みを「ぐにょり」と読び、この歪みのためにScanSnapを毛嫌いし、ScanSnap所有者に冷たい態度で接する。

この例のように画像（特に直線）が極端に歪むことを「ぐにょり」と呼ぶことが多いようです。冒頭で挙げた文字の色にじみ（とそれに伴う ClearScan の失敗）も、歪みが原因で発生したものですので、この現象を抑えることができれば改善しそうです。

S1500 のぐにょりの傾向

Printable Paper というサイトで方眼紙その他の PDF が作成できるので、これを作って検証してみます。使ったパターンは Hexagonal で、オプションは以下のとおりです。

PDF Document Size: A4
Minimum Border: 0.05 cm（余白なのでてきとうで OK）
Line Weight: 1 points
Hexagon Size: 0.05 cm
Hexagon Color: Black

余白を切り落としてスキャンするとこんな感じになりました。

（クリックで拡大）

歪みの原因はと原稿の揺れだと言われています。原稿の送りが一定でないと、歪みとともに色ずれが発生するので、色がついている箇所に注目すればその歪みがわかりやすいです。

この画像でもよく見ると色がついているのがわかるのですが・・・さすがにわかりにくいので、PIL（Python Imaging Library）を使って、歪み部分を強調させてみます。

使ったスクリプト → https://gist.github.com/miau/ef3fdc496b17da4df2da

RGB それぞれの輝度が 20% 以下の範囲に納まっている場合は歪みはないものとして黒で塗りつぶしています。

Python なのでわりと時間がかかりますが、結果はこんな感じです。

（表面。クリックで拡大）

（裏面。クリックで拡大）

何度かスキャンしてみましたが、傾向は変わらず。横一列の歪みがコンスタントに発生しているのは

表面
- 上から 2.5cm 付近
- 下から 5.3cm 付近
- 下から 2.3cm 付近
裏面
- 上から 1.7cm 付近
- 下から 6.1cm 付近
- 下から 3.1cm 付近

でした。これ以外にも、左右の端に強い歪みが発生している箇所もあります。（表は下から 3.3cm、裏は 4.3cm 付近）

ぐにょりの原因をもっと詳しく

原因については

空の果て: ScanSnap S1500 と DR-2510C

にわりと詳しい説明があり、前項で調べた歪みが生じる位置と、S1500 の部品の配置を見比べた上で整合性を合わせると、以下のようになるのではないかと。

こんな感じで左から原稿が流れてくるものとして。原稿が排出ローラーに達するまでは、ぶらぶらと揺れながら送られるので、細かい歪みが発生します。

排出ローラーに達したタイミングで、一度めの大きなぐにょりが発生します。ローラーの端に当たったりしているのかもしれません。
そこからは両側のローラーで送られるので、しばらくは比較的安定した状態が続きます。

ピックアップローラーを離れるタイミングで（？）二度目の大きなぐにょりが発生します。距離からするとピックアップローラーのあたりで何か起きているとは思うのですが、何が起きているかはよくわかりません。
今回の原稿では、このしばらく後に、左右の端で特に強いぐにょりが発生しています。紙のたわみ具合に起因しているのだとは思いますが、こちらも原因はよくわかりません。

最後の大きなぐにょりは、原稿がフィードローラーを離れるタイミングです。支えがなくなるので、ここは納得です。その後はまた紙がぶらぶらするので、細かい歪みがまた発生すると。

とまあ色々説明してきましたが、紙質やサイズが変わると、傾向も変わってくると思います。何よりも、排紙時に原稿が引っかからないように気をつけたほうがよいです。特にこのスタッカーのくぼみに引っかかると、わりと大きなぐにょりが発生しますので、あらかじめコピー用紙を敷いておく等の対策をオススメします。

fi-7160 ではどうか

さきほどと同じ原稿を fi-7160 で読んで、同じように強調してみました。ScanSnap Manager for fi Series でスキャンすると黒い部分が青〜緑がかってしまいうまく色ずれが強調で検出できなかったので、BTScan を使用しています。

（表面。クリックで拡大）

（裏面。クリックで拡大）

色ずれは fi-7160 でも完全になくなってはいません（そのせいか、ClearScan の失敗は fi-7160 でも発生しています）が、全体的に S1500 よりは穏やかになっていますね。

実際に歪みがどの程度見えるか、格子状の原稿を読み込んでみました。使った原稿はさきほどと同じサイトの Plain で

PDF Document Size: A4
Minimum Border: 0.5 cm
Grid Line Weight: 1 points
Grid Sacing: 2 lines per cm
Grid Color: Black

の設定で出力したものです。

こちらが S1500 で・・・

（ScanSnap S1500 表面。クリックで拡大）

（ScanSnap S1500 裏面。クリックで拡大）

こちらが fi-7160。

（fi-7160 表面。クリックで拡大）

（fi-7160 裏面。クリックで拡大）

歪みもかなり改善しているのがわかると思います。

サイズが大きくなるので画像は上げていませんが、同じ原稿を何度が読み取った場合、S1500 はスキャンする度に歪み方が変わるのですが、fi-7160 は毎回ほぼ同一の画像がスキャンされました。このあたりは fi-7160 のほうが安心感があります。

ScanSnap S1500 でのスキャン方針

Sat, 10 May 2014 01:47:36 +0900

自炊話みっつめ。ScanSnap S1500 は主に技術書のスキャンに使ってきたわけですが、その目的や方針について書いておきます。わりと普通だと思います。

目的

2006 年くらいに本棚を新調して、「これで心置きなく新しい本が買えるぞー」と喜んでたわけですが。調子に乗って本を買ってたら、あっさり一杯になってしまって。置けない本は会社に置いたりしてました。

ところが会社がフリーアドレス制になるとかで、これを持ち帰る必要が出てきて。ただでさえいっぱいだった部屋に 100 冊くらい本が増えてしまいました。このままでは身動きできないし、仕事中に参照したい情報も結構あるし、これはスキャンするしかないなということで当時定番だった ScanSnap S1500 と PK-513L を買ったのでした。

いざってときに色々な情報を参照できるように本を増やしていたわけですが、それぞれの本についてスキャンされた状態がゴールに変わった場合、資産と思っていた大量の本が負債になって返ってきます。本をいずれスキャンしようと思ってるなら早く着手しておいたほうがいいです。

ターゲット

うちにあるのはほとんどが技術書とマンガなんですが、

スキャンして外で読めるようになるとメリットが多い
一冊あたりの体積が大きい
余白が大きいし見開きがないので断裁の難易度が低い

ので、技術書から手をつけることにしました。洋書ではたまにハードカバーのものもありますが、これは後回しということで。

本を断裁したり捨てたりするのは、心理的にわりとこたえます。リファレンス性が高くて優先的にスキャンしたい本ほど、長く読まれることを想定してしっかり製本されていて断裁が大変だったりして。「本で読みたくなったらまた買えばいいし」「絶版書は国会図書館で読めるし」とかなんとか自分を騙して進めてました。もっと色々な本が電子書籍で出てくれるといいんですけどね・・・。

スキャンの前に

全ページに目を通してからスキャンするようにしてます。せっかくデータが引き出せる状態になっても、データを引き出すためのインデックスが脳内にないと意味がないので。

つい時間をかけて読んでしまうこともあって、この作業がボトルネックになってたりするんですが・・・。10 年前に読んだ本は内容もわりと忘れてしまっているので、復習になってなかなかいいです。

方針

ジャケット（カバー）＆帯

技術書サイズだと ScanSnap S1500 で読み込めないものがほとんどですし、読み込めるものも

360mm 以上の長さがあると長尺読み取りにする必要がある
画質がエクセレントの設定では長尺読み取りできない

という制限があり、300dpi に落とさないとスキャンできなかったりするので、フラットベッドスキャナーを買ってから考えることにして、スキャンせずにとってあります。

保管用にはリヒトラブクリヤーブック G3117-8 A2L 20ポケットブルーを使っています。職場近所の文具屋で買ったんですが、買うときに「売っといてなんだけど、こんな大きいの何に使うの？」って言われたりする程度に大きなファイルです。それでも大きめの本のカバーは入りきってませんけど、傷めずに保管はできてそうです。

表紙＆裏表紙

本体と一緒に断裁してます。

一時期は

漫画をスキャナで電子書籍化する初心者向け自炊解説サイトカバー下の背表紙もちゃんとスキャナで取り込めるようにする

この方法で分離していたんですが、技術書は背の部分にそれほど重要な情報がないし、見返しが破れてしまうこともあるのでやめてしまいました。マンガのスキャンときは分離したほうがよさそうですね。

見返し

表紙をめって一枚目に色のついた紙がついていることがありますが、この紙のことです。

ジャケットと本体と貼り合わせるためにあり、表紙側を「きき紙」、反対側を「遊び紙」と呼んで区別するそうです。

技術書の中にはこの部分にチートシートがついていることもありますし、そうでなくても色はわりと記憶を刺激してくれるので、1 ページくらいはスキャンしておきたいと思っている部分です。

ということで、

表紙ときき紙をスプレーのりで接着する
- 試しに買った 3M スコッチスプレーのり77 ミニ缶 50ml S/N 77 MINI 50ML で 15 冊くらい持ちました。今は 430ml のものを使ってます。
チートシート等がない場合は遊び紙はスキャンしない

という方針でやってます。

表紙ときき紙を接着した場合、裏側の摩擦形数が大きくなるため、パッドユニットを採用している S1500 ではブレーキがかかる形になり用紙読み取りがスムーズにいきません。（fi シリーズや ix500 ではブレーキローラーを採用しているので問題ないと思います。）結果として、グラデーションがかかった縦長なスキャン結果になったりします。

（失敗例。元は単色刷りですが、上部にカラフルな帯が入っています。関係ないですけどグラデーションのかかり方を見ると ~~BGR の順でセンサがありそうですね。~~ ※他の画像を見ると逆のグラデーションもあったので違うかも。）

対策として、表紙をスキャンする時は原稿を一枚だけセットし、パッドユニットを取り外すようにしていました。キャリアシートを使ってもいいかもしれません。

本体

技術書は余白が大きいし見開きもないので、多めに断裁していました。ぎりぎりのラインを攻めると糊が残ることがあって、読み取り面に付着すると面倒なので。

スキャン時の設定

本については

画質: エクセレント（カラー 600dpi）
カラーモード: カラー
読み取り面: 両面
継続読み取り: 有効
その他オプション: すべて OFF
ファイル形式: PDF
圧縮率: 圧縮 1

の設定です。物を捨てるのが苦手な私は情報を捨てるのも苦手なので、なるべく情報の欠落が少ない設定にしています。データの保存先が足りないなら HDD を足せばいいですし、読みやすくするのは後でいくらでもできるので。

技術書だからこの設定でよかったのですが、マンガをスキャンする際は端の情報が失われないように JPEG で保存したほうがいいかもしれないですね。

その他書類等もスキャンしてましたが、その時はグレースケールにしたり 300 dpi にしたり、1枚だけでプレビューしたほうが便利そうなものは JPEG にしたり、「捨ててもいい」と思える割合に応じて色々です。

あとは、サイズが大きかったりページ数が多い本については、%TEMP%\JpgTmp を見て 2GB になる前にスキャンを終わらせたりしてまました。

スキャン後

S1500 のスキャン後の画像はややぼやけた感じになります。

（オプションなしでスキャンしたもの）

「文字をくっきりします」オプションを使うと改善はするんですけど、まだぼやけた感じは残ります。

（「文字をくっきりします」オプションでスキャンしたもの）

Acrobat で ClearScan で OCR 認識させると、境界がくっきりします。

（オプションなしでスキャンし、ClearScan を通したもの）

文字がぼやけていると、目のフォーカスがあってないと勘違いして脳ががんばるせいか、読んでいて妙に疲れるんですよね。ClearScan は字形が多少崩れたり、まれに不要な回転がかかったりと問題も多いんですが、サイズは小さくなるし検索もできるようになるしでお手軽なのでこの方法を使ってます。

電子書籍と比べた利点？

ちなみに、スキャンして OCR にかけるくらいなら、電子書籍を買ったほうが

手間がかからない
元データから作るので、精度が高くファイルサイズも小さい
割安な場合も多い

ということでいいのですが。唯一スキャン＋OCR の利点かもしれないなと思ったのが、画像部分に対してもたまに検索が可能になることです。

（画像が検索できた例）

これが役に立つかは謎ですけどね。

ScanSnapHelper（ScanSnap Manager 補助ツール）を作ってみた

Tue, 06 May 2014 01:46:21 +0900

前回 ScanSnap S1500 のスキャン時の動作などで

(3) RAW画像の出力
（中略）
後続の処理に進むとすぐ消されてしまうファイルですが、このファイルを保存したり差し換えたりする方法については後日また書こうと思います。

と書きましたが、この「RAW画像を保存したり差し換えたりする方法」というのは、自作のツールを使うものでした。公開できる程度にまとめたので Github に上げました。

https://github.com/miau/ScanSnapHelper

プログラムの説明は README.md にざっと書いているので、ここでは補足的な内容を書いておきます。

検証環境

Windows 7/8 上で

ScanSnap Manager（PfuSsMon.exe）+ ScanSnap S1500
ScanSnap Manager for fi Series（PfuSsMff.exe） + fi7160

といった組み合わせで動作確認しています。

見た目

こんな感じです。地味です。

処理のタイミング

ScanSnap Manager（PfuSsMon.exe）では

(1) C:\WINDOWS\SSDriver\fi5110\fjtw32.dll 経由で ScanSnap*.raw に書き込み
(2) %PROGRAMFILES%\PFU\ScanSnap\Driver\PfuSsCtl.dll 経由で ScanSnap*.raw を読み込み

という動作になっていました。この (2) のタイミングで hook.bat を呼び出すため、CreateFileA が

dwDesiredAccess が GENERIC_READ
lpFileName が SSRawData\ScanSnap を含む

状態で呼び出されたことを条件に hook.bat を起動しています。

ScanSnap Manager for fi（PfuSsMff.exe）では、RAW ファイルのパスは

%APPDATA%\PFU\ScanSnapManagerForFi\ScandAll PRO【0からの連番】.raw

という名称になりますが、こちらは

(1) C:\WINDOWS\Twain_32\Fjicube\fjictwsv.exe で書き込み
(2) PfuSsMff.exe で読み込み

という動作になっていました。PfuSsMff.exe を監視している限りは、うまいこと ScanSnap Manager と同一の条件で引っかけることができたので、こちらにも対応した次第です。

RAW画像の差し換えについて

サンプルスクリプト replace_images.py の説明として、

RAW 画像を images ディレクトリにある同名のファイルで置き換えます。

copy_here.py で保存した RAW 画像を再利用し、ScanSnap Manager の設定によって結果がどう変わるかを検証するのに使えます。

と書きましたが、差し換え後のファイルはどんなものでもいいわけではありません。適当な JPEG ファイルに差し換えると

イメージの処理中にエラーが発生しました。
ケーブル類を一度抜いてから、再度接続してください。

のエラーになります。%PROGRAMFILES%\PFU\ScanSnap\Driver\PfuSsCtlErr.log によると

ExtractImageFromJFIF() Failed. Error = FFFFFFFF.

だそうで、詳細は不明です。

ちゃんと確認していないのですが、ScanSnap が RAW 画像を作る際に使用しているのが LEADTOOLS なので、LEAD Command Line Image File Converter であらかじめ変換をかけてやれば RAW 画像として読み込んでくれるようでした。

LEAD Command Line Image File Converter を C:\LEADCMD にインストールしたものとして、Python Imaging Library (PIL) で作成した画像を RAW として使えるようにする例を

https://gist.github.com/miau/756fb8b14e33c6bb837e

に make_raw_files.py として上げていますので参考にどうぞ。

ちなみにこのスクリプトは、背景の上に 4000x4000 pixel の白い正方形を描き、その四隅に赤いマークをつけるものです。これを RAW 画像として取り込むと、3997x4003 pixel となり、左は 4 pixel、上は 2 pixel が削られていました。逆に右は 1 pixel、下は 5 pixel 背景部分が残っています。実際にスキャンしたものと違って影がないので、そのあたりの調整でずれているのかもしれません。

ついでに、上の gist に上がっている pick_jpg.py は引数で渡された .pdf から .jpg を抽出するものです。生データがそのまま埋め込まれているだけなので、かなり簡単なスクリプトで抽出できちゃいます。

原稿の回転について

元々このツールを作った動機は、サンプルスクリプト rotate_for_comic.py の処理で、

右綴じ・右開きの本を横向きにスキャン可能にするためのものです。

実際にやってみるとクロッピングがおかしなことになったので、実用には向きません。

JPEG Lossless Rotator を .\jpegr_portable64 として配置した上で使う必要があります。

偶数ページは左に 90 度、奇数ページは右に 90 度回転させます。

これです。

原稿を横向きにして取り込む
- スキャンする距離が短くなるので取り込みが速くなる
- 自分で断裁した面を上に向けられるので、断裁面が多少曲がっていたり破れたりしていても問題ない
RAW 画像時点でロスレス回転する
- RAW 画像は 8 の倍数 pixel になっているようなので、問題なくロスレス回転できる
ScanSnapHelper を起動しておくだけでよく、その後の加工の手間も要らない

ということで利点だらけなのですが、実際やってみると、クロッピングがおかしく・・・あれ？極端にクロッピングがおかしくなったりはしませんね。どうも以前検証した際に勘違いしただけっぽいです・・・。

気が向いた方は使ってみてもいいかもしれませんが、影の向きは本来とは 90 度違う方向にできますので、クロッピングが多少ずれる可能性はあると思います。

（2014-11-03 追記）
iX500 を使っている場合、ScanSnap Manager V6.3L22 以降で向きの補正ができるようになったそうです。

スキャナ ScanSnap：書籍スキャンを快適にする”向き補正”機能 : 富士通

（2014-11-03 追記ここまで）

その他やりたかったこと

RAW 画像の PDF への埋め込み

なるべく高品質なデータを残したいのであれば、RAW データを残すのがいいことになります。ですが元の RAW データは背景部分も無駄に大きく、PDF や JPEG と両方のファイルを残すのももったいないです。

なので理想的には

RAW データをやや大きめにロスレスクロッピング
前回「画質がエクセレント PDF 保存する場合の動作」で書いたように、PDF に画像を傾けて埋め込むことで傾き補正
カラープロファイルを PDF 側に埋め込む

ができればいいなと。

がんばれば実現できそうな気もするのですが、埋め込む際の原点を計算しなおしたりが手軽にできなそうなので、手を出せませんでした。

残り容量の表示

技術書をスキャンしていると、

処理できる総ファイルサイズの上限(2GB)に達しました。
読み取りが完了した部分のファイルを保存し、最後のページを確認して残りの部分を、再度読み取りしてください。

と言われて、変なページで区切られることがあって。これを防止するために

%TEMP%\JpgTmp のサイズをチェック
「この調子でスキャンすると、あと○枚で 2GB に達するよ」みたいな情報を表示

をやりたいなとは思いつつ未実装です。

EasyHook について

フック部分で使っているライブラリです。

EasyHook - The reinvention of Windows API Hooking - Home

こういう処理を書く場合は C++ で書くのが定番だったのですが、C++ だと GUI を作るのがちょっと面倒です。また、普段 GC がある言語を使っていると、C++ でうまくメモリ管理できる自信もなかったりします。

EasyHook を使えば、わりと簡単に .NET からフック処理が呼び出せるので、オススメです。コミットログを見てもらえばわかると思いますが、今回のアプリケーションは EasyHook のサンプルである FileMon を元に作っています。

参考にした URL をいくつか貼っておきます。

EasyHook for systemcall hooking | Saddam Abu Ghaida
- 結局 CreateFileA だけしかフックしていませんが、ファイルまわりの API のサンプルが色々とありました。
厳密な名前付きアセンブリ - WebSurfer's Home
- EasyHook を動作させるにはこの作業が必要でした。

ScanSnap S1500 のスキャン時の動作など

Mon, 05 May 2014 14:12:41 +0900

2010年の5月に ScanSnap S1500 を買っていたのですが、fi-7160 を買って ScanSnap S1500 を手放すことにしたので、ノウハウを軽くまとめておこうかと。

まずはスキャン時の動作やら、各種設定によって画像ファイルの属性がどのように変わるかを書いておきます。S1500 を持っている人であっても、ほとんどの人が気にしないくらい細かい話なので、気をつけてください。

以下 Windows 7/8 あたりでの検証結果です。

ScanSnap Manager のプロセス構成

以下のような構成みたいです。

  PfuSsMon.exe             -> ScanSnap Manager の GUI。スキャン時の画像処理もこのプロセス。
    PfuSsOrg.exe
      PfuSsOrgPDF2JPEG.exe
    PfuSsQuickMenu.exe     -> 何に保存するか聞いてくるウィンドウ
      Scan2Folder.exe      ->「指定したフォルダに保存」時に起動するウィンドウ
                              このタイミングでは 【イメージの保存先】\yyyymmddhhmiss.pdf を参照している

スキャンに関わるほとんどの処理は PfuSsMon.exe が行っているので、このプロセスだけ追えば大丈夫そうです。

スキャン時の動作

ScanSnap S1500 でスキャンを行った場合の PfuSsMon.exe の動作を追ってみました。

(1) 設定の読み込み？

深くは追っていませんが、%APPDATAR\PFU\ScanSnap\*.cfg がいろいろと読み込まれます。

(2) カラープロファイルの読み込み

OpenColorProfile で以下のカラープロファイルが読み込まれます。

%SYSTEMROOT%\system32\spool\drivers\color\ScanSnap S1500.icm
%SYSTEMROOT%\system32\spool\drivers\color\sRGB Color Space Profile.icm

(3) RAW画像の出力

まず %TEMP%\SSRawData に、ScanSnap0.raw（表面）、ScanSnap1.raw（裏面）のように一面に対して 1 ファイルずつ画像が出力されます。RAW と言いつつ中身は JPEG ファイルなのですが、クロッピング（トリミング）も行われていない、かなり生データに近いファイルです。

（その辺にあった半券を取り込んだもの。意図的に傾けて取り込んだもので、普通はこんなに傾きません。）

JpegAnalyzer Plus で見ると、以下のような情報が出ました。（「★dpi」を付加した部分は、dpi 設定によって変わる部分です。また、上記の画像に対応する情報ではありません。）

Address  Length Message
00000000 ****** SOI  :Start Of Image ******
00000002 [0010] APP0 :JPEG File Interchange Format Ver 1.2 (JFIF)
                 密度 600:600 dots/inch ★dpi 600:600, 300:300, 200:200, 150:150
00000014 [0084] DQT  :Define Quantization Table
                 00000018 QT0-8bit LEADTOOLS色差 画質015 ★dpi 600,300,200:015, 150:002
                 00000059 QT1-8bit LEADTOOLS輝度 画質015 ★dpi 600,300,200:015, 150:002
0000009A [0004] DRI  :Define Restart Interval (MCU blocks=653) ★dpi 600:653, 300:326, 200:217, 150:163
000000A0 [0011] SOF0 :Start Of Frame 0 - Baseline DCT
                 5224[0] x 2816[0] pixel - 24bit color (YCbCr 4:4:4)
                 ComponentID-01 Y  1x1 QT0
                 ComponentID-02 Cb 1x1 QT1
                 ComponentID-03 Cr 1x1 QT1
000000B3 [01A2] DHT  :Define Huffman Table 【汎用ハフマンテーブル】
                 000000B7 HT0-DC   汎用輝度HT-DC
                 000000D4 HT0-AC   汎用輝度HT-AC
                 00000187 HT1-DC   汎用色差HT-DC
                 000001A4 HT1-AC   汎用色差HT-AC
00000257 [000C] SOS  :Start Of Scan 0-63[00]
                 HT Selector[DC/AC] Y[0/0] Cb[1/1] Cr[1/1]
00000265 ****** Image Data ******
                 Data Size 3,706,553 bytes
0038911E ****** EOI  :End Of Image   ******

なお、カラーモードがグレースケールでも白黒であっても、カラー画像として保存されます。白黒は「1200 dpi 相当」とは書かれていますが、実際 600 dpi のデータが元になっているので、ちょっと引っかかります。（ベイヤーパターンの CCD ならそうなる表記されるのもわかるのですが、スキャナーの CCD はリニアイメージセンサだと思いますし・・・。）

片面読み取り時も 2 枚出力されますが、裏面の画像は以降の処理では使用していないようです。ということは、裏側の画像情報を使った裏写り除去の処理は行っていないようです。

次の紙を読み込むと ScanSnap2.raw、ScanSnap3.raw のように連番で続いていきますが、継続読み取り時は 0 にリセットされるようです。

後続の処理に進むとすぐ消されてしまうファイルですが、このファイルを保存したり差し換えたりする方法については後日また書こうと思います。（20140509 追記: 書きました。ScanSnapHelper（ScanSnap Manager 補助ツール）を作ってみた）

(4) カラープロファイルによる色変換

最込に読み込んだカラープロファイルを利用して（CreateMultiProfileTransform と TranslateBitmapBits を使って）色変換がかかります。

(5) %TEMP%\JpgTmp 等への出力

変換＆切り出しが終わった画像が以下のファイルに出力されます。

%TEMP%\JpgTmp\Spool_For_ScanSnap*.jpg ※PDF 出力時のみ
- 最終出力画像を作るための中間ファイル
- この総サイズをチェックすれば「処理できる総ファイルサイズの上限(2GB)に達しました。」エラーを事前に防げる
【イメージの保存先】\YYYYMMDDHHMISS.jpg ※JPEG 出力時のみ
- 最終出力ファイル
%TEMP%\ImfrTemp\ImfrImg*.jpg
- プレビュー用の画像？直近の二枚だけ残る
%TEMP%\BizCardTemp\sstmp*.jpg
- 名前からすると名刺用の画像？JpgTmp と同じくらいのサイズだけど見開き画像が入ってない

この時点でクロッピングや傾き補正も行われていて、このように画像になっています。

RAW 画像と見比べると、色合いが変わっているのもわかると思います。確かに RAW 画像はやや青が強いのですが、ちょっと補正が効きすぎて赤〜黄色がかってしまっているように感じますね。

「傾き補正も行われ〜」と書きましたが、実は例外があります。画質がエクセレント（600dpi、白黒は1200dpi）で PDF で保存する場合は傾き補正は行われず、クロッピングのみが行われた以下のような画像が出力されます。（理由については後述）

カラーの場合、JpegAnalyzer Plus で見るとこんな情報が出ました。

00000000 ****** SOI  :Start Of Image ******
00000002 [0010] APP0 :JPEG File Interchange Format Ver 1.0 (JFIF)
                 密度 600:600 dots/inch ★dpi 600:600, 300:300, 200:200, 150:150
00000014 [001D] COM  :Comment
                 PFU ScanSnap Manager #S1500
00000033 [0043] DQT  :Define Quantization Table
                 00000037 QT0-8bit IJG輝度 画質95 ★圧縮率 1:95, 2:80, 3:67, 4:45, 5:15
00000078 [0043] DQT  :Define Quantization Table
                 0000007C QT1-8bit IJG色差 画質95 ★圧縮率 1:95, 2:80, 3:67, 4:45, 5:15
000000BD [01A2] DHT  :Define Huffman Table 【汎用ハフマンテーブル】
                 000000C1 HT0-DC   汎用輝度HT-DC
                 000000DE HT0-AC   汎用輝度HT-AC
                 00000191 HT1-DC   汎用色差HT-DC
                 000001AE HT1-AC   汎用色差HT-AC
00000261 [0011] SOF0 :Start Of Frame 0 - Baseline DCT
                 3552[0] x 2459[5] pixel - 24bit color (YCbCr 4:2:0)
                 ComponentID-00 Y  2x2 QT0
                 ComponentID-01 Cb 1x1 QT1
                 ComponentID-02 Cr 1x1 QT1
00000274 [000C] SOS  :Start Of Scan 0-63[00]
                 HT Selector[DC/AC] Y[0/0] Cb[1/1] Cr[1/1]
00000282 ****** Image Data ******
                 Data Size 3,610,577 bytes
00371A53 ****** EOI  :End Of Image   ******

RAW データと比べると、サンプリング比が 4:4:4 から 4:2:0 に変わっており、間引きが入っています。圧縮率の設定によって画質が変わっています。それがどういう意味を持つかは、このページを参照ということで。

グレースケールの場合もカラーとほぼ同じ情報でしたが、以下の点が変わっていました。

000000BD [00D2] DHT  :Define Huffman Table
                 000000C1 HT0-DC   汎用輝度HT-DC
                 000000DE HT0-AC   汎用輝度HT-AC
00000191 [000B] SOF0 :Start Of Frame 0 - Baseline DCT
                 3542[2] x 2461[3] pixel - 8bit grey scaled (Mono)
                 ComponentID-00 Y  1x1 QT0
0000019E [0008] SOS  :Start Of Scan 0-63[00]
                 HT Selector[DC/AC] Y[0/0]

白黒だとこうでした。TIFF ですね。

ヘッダのない TIFF CCITT T.6
FAX4（CCITT T.6）

00094F98-00095045 0th IFD Tag-14   Next IFD 00000000 (Value-00000000)
00094F9A 0100 画像の幅                      7088
00094FA6 0101 画像の高さ                    4912
00094FB2 0102 画像ビットの深さ              1 (bit)
00094FBE 0115 コンポーネント数              1
00094FCA 0116 ストリップ中のライン数        4,912
00094FD6 0111 画像データへのポインタ        00000008 (Value-00000008)
00094FE2 0117 ストリップのデータ量          610,192 bytes
00094FEE 0103 圧縮種類                      T.6MMR圧縮(Group4)
00094FFA 0106 画素構成                      グレイスケール(白=0)
00095006 010A Fill Order                    MSB to LSB
00095012 011C 画像データの並び              点順次 Chunky format
0009501E 011A 画像の幅の解像度              72 
0009502A 011B 画像の高さの解像度            72 
00095036 0128 画像の幅と高さの解像度の単位  インチ(dpi)

(6) PDF 生成の中間処理

ファイル形式が PDF の場合、以下のような処理が行われます。

【イメージの保存先】\YYYYMMDDHHMISS.pd~ に空ページの PDF ファイルを出力
%TEMP%\SSMon\【32桁の16進数】_【5桁の連番】.tmp として JPEG ファイルを出力
- ただし先頭に 80 bytes 謎データが入っている
%Temp%\PFUSSMON_SPL.LST にファイル名書き出し
%TEMP%\SSMon\【32桁の16進数】_【5桁の連番】_Compressed.pdf.tmp として単一ページの PDF に変換
- AdobeScanLibrary.dll や PDFL70.dll を使って処理（処理中で %Temp%\Acr【32桁の16進数】.tmp を使用）
JpgTmp\SPOOL【5桁の連番】.ini には都度画像の情報を出力
- その後の処理では使われてないっぽい

SPOOL*.ini についてはフォーマットも軽く調べていたので書いておきます。

[File]
FilePath=C:\Users\****\AppData\Local\Temp\JpgTmp\Spool_For_ScanSnap001.jpg
BuffSize=561818
DataType=2
InCompression=3  ★color,gray:3, binary:1
Width=3551
Height=2455
Color=24         ★color:24, gray:8, binary:1
Resolution=600   ★binary は 1200 等
OutCompression=3 ★color,gray:3, binary:1
SegmentMono=1
RotationAngle=0  →270 だったら左に 90 度回転してくれる。
DeskewAngle=-20  →傾きっぽい。強制回転された場合は 0 になる。
GBJPG=1          ★color,gray:1, binary:0
Flag=1

ちなみにファイル形式が JPEG の場合はこのあたりの処理は行われず、%Temp%\PFUSSMON_FCN.INI にファイルの一覧が出力されるだけです。

(7) ファイルの保存

ファイル形式が PDF の場合は、

【イメージの保存先】\aa【32桁の16進数】として YYYYMMDDHHMISS.pdf~ を退避？（でも使ってない気がする）
*Compressed.pdf.tmp を結合して YYYYMMDDHHMISS.pd~ に格納
YYYYMMDDHHMISS.pd~ を YYYYMMDDHHMISS.pdf にリネーム

といった感じで最終的な PDF が出来上がります。

ファイル形式が JPEG の場合は、すでに保存済みなので特に何も行われません。

ファイル名をつけたりする部分は後続の exe に処理させているようです。

画質がエクセレント PDF 保存する場合の動作

画質がエクセレント（600dpi、白黒は1200dpi）で PDF 保存する設定だった場合、傾いてスキャンされた画像は、PDF 中に逆向きに傾けて埋め込むことで補正を行っているようです。

PDF では変換マトリックスを定義できて、これを使えば画像その他を引き伸ばしたり傾けたりして表示できます。

（PDF Reference second edition【PDF】の 129 ページあたりを切り貼りして引用）

この変換マトリックスを変える命令が cm なのですが、傾けて保存される場合は

212.3054962 -13.8981018 26.2519531 401.0214996 -12.8987274 7.3783112 cm

のように第 2、3 オペランドが 0 以外になっていることが確認できます。

PDF ビューアで開くと、傾きが正されているのがわかります。白い部分が目立ちますが、普通はこんなに傾きませんので技術書を取り込んでいる限りでは気になりませんでした。

何が嬉しいかというと、より元画像に近い（回転処理による画像劣化がない）情報を保持しながら、通常の使用ではその傾きが気にならない動作になっていることですね。

調査のためのツールとか

もっと詳しく調べたい方もいるでしょうし、後継機種である ScanSnap iX500 で動作が変わっているかもしれませんので、このあたりの動作を調べるのに役立つツールを紹介しておきます。

Process Monitor

Process Monitor

ファイルやレジストリのアクセスを表示するプログラムです。Process Explorer や TCPView も含めて必須のツールなので、Sysinternals Suite でまとめて入れてます。

API Monitor v2

API Monitor; Spy on API Calls and COM Interfaces (Freeware 32-bit and 64-bit Versions!) | rohitab.com

API の呼び出しをトレースするプログラムです。ファイルアクセスよりも上の層の情報を知りたいときや、API hook のあたりをつけるのに使います。

ただし、環境によっては API 呼び出しがうまく拾えないケースもあるようですので、そういうものだと思って使ったほうがいいと思います。.icm に対する CreateFileW の呼び出しが、ある環境（Win8.1 64 bit）では拾えないのに、別の環境（Win7 32 bit）なら拾える、なんとことがありました。（スキャナの設定が悪いのかと思って数時間ハマってました。）

HHD USB Monitor

USB Port Monitor Software Data Transfer Protocol Analyzer Data Logger

USB の生データを覗けるツールで、ライセンスは $64.99 ですが 14 日間試用できます。
Usb Sniffer for Windows は Windows 7 以降で使えないし、Bus Hound のフリー版はデータサイズに制限があって今回の用途には向かない＆価格が $799 と高いので、こちらを使ってデータを覗いたりしてました。プロトコルが公開されてるわけでもなく、USB 通信の勝手がわかってるわけでもないので、眺めただけで終わりましたが・・・。

PDFtk

PDFtk - The PDF Toolkit

PDF の内容は（元々圧縮されている JPEG や TIFF 以外の箇所は）圧縮されているので、それを解除したい場合なんかに使います。
xxx.pdf の圧縮を解除して xxx_uncompressed.pdf として出力するコマンドは下記のとおりです。

pdftk xxx.pdf output xxx_uncompressed.pdf uncompress

msysgit(Git for Windows) で STATUS_ACCESS_VIOLATION が出る時の対策

Sun, 29 Dec 2013 16:25:13 +0900

git のコマンドを叩くと



      0 [main] sh.exe" 6768 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION

   1620 [main] sh.exe" 6768 open_stackdumpfile: Dumping stack trace to sh.exe.stackdump

こんなエラーが出る状態になってしまったので、対策方法のメモ。ちなみに試したバージョンは Git-1.8.4-preview20130916.exe です。

Process Monitor で見てみると、sh.exe が起動する時に %TEMP% に対して QueryDirectory を実行して、ファイルの一覧を拾った直後で落ちている様子。このタイミングでこんなエラーが出るってことはどうせ日本語ファイルがらみだろうなー・・・。

ということで、%TEMP% （C:\Users\【ユーザ名】\AppData\Local\Temp）直下にある、名前に日本語を含むファイルとディレクトリを全て消したら、あっさり解決。

条件はよくわからないけど、拡張子部分に日本語があると起きやすいみたいで、いくつか試した感じだと「あああ.あ11」って名前のファイルが一つあるだけで上記のエラーが起きるみたい。

白い鏡: msysGitでエラーが出たら

Git-1.7.8-preview20111206.exe
なら正常動作。

という情報もあったけど、Unicode 対応が入ったのが Git-1.7.10-preview20120409.exe 以降なので悩むところ。日本語を使わないリポジトリしか触らないなら、古いバージョンを入れなおしたほうが手っ取り早いかも。

（さっそく追記）

Fails with Exception: STATUS_ACCESS_VIOLATION · Issue #25 · msysgit/msysgit

古いバージョンの msys-1.0.dll を使えば OK って話も見つけた。でもこれって Unicode 対応を捨てるってことだよなぁ・・・。

Cisco VPN Client の起動が遅くなったときの対策

Sun, 08 Dec 2013 23:19:02 +0900

社外からメール読んだりするのに、Cisco VPN Client を使っているのですが、最近起動するのに 90 秒くらいかかるようになってしまって。調べてみると Fiddler で「Decrypt HTTPS traffic」を有効にしている場合に発生する問題のようなので、解決方法のメモです。

まあググったらすぐ出てくるんですが。

Cisco VPN Client says "Opening cert store." for 5 to 10 minutes|2196895 - Cisco Support Community

Fiddler で「Decrypt HTTPS traffic」オプションを使っている場合、Fiddler が HTTPS の接続先ごとにダミーの証明書を作るそうで。Cisco VPN Client が起動時にその証明書を全て開くので、そこで時間がかかっていると。

このダミーの証明書を消せばいいそうですが、具体的なやり方はこのあたりに載ってました。

ssl - How do you remove the root CA certificate that fiddler installs - Stack Overflow

以下の 2 つやり方があるそうです。

1) Fiddler から削除する
- Fiddler の「Tools」→「Fiddler Options」→「HTTPS」を開く
- 「Decrypt HTTPS traffic」のチェックを外して「Remove Interception Certificates」を押す
2) certmgr から削除する
- 「ファイル名を指定して実行」で certmgr.msc を開く
- 「証明書」→「個人」→「証明書」のリストで「発行者」が「DO_NOT_TRUST_FiddlerRoot」になっているものを削除する

今回は 2) の画面で確認しながら 1) の方法で実行しました。
証明書の数は 295 個あったのが 3 個に減って、Cisco VPN Client の起動時間も数秒に戻りました。めでたしめでたし。

（おまけ）スプラッシュスクリーンの画像差し換え

「起動するのに 90 秒くらいかかる」と書きましたが、この起動中にスプラッシュスクリーンが最前面にやってきて別のウィンドウを隠されるのが非常に鬱陶しかったので、最初はスプラッシュスクリーンの画像を小さくする消極的な対策をとったりしてました。

Cisco VPN クライアント管理者ガイドリリース 5.0 - VPN クライアントソフトウェアのカスタマイズ - Cisco Systems

splash_screen.png
（中略）
ブランドが変更されたスプラッシュ画面グラフィックは、ステータステキストを表示するボックスが収まるように少なくとも 280 ピクセル幅である必要があります。グラフィックの最下部には、フル幅の空白領域がなくれはならず、その高さは 36 ピクセル以上でなければなりません。

とのことなので、%PROGRAMFILES%\Cisco Systems\VPN Client\Resources\splash_screen.png を 280x36 にリサイズしたり。もう起動が速くなったのであんまり意味ないですが、萌え化して遊びたい人にはいいかなと思ったのでとりあえずメモでした。

ITサービスマネージャ（試験）

Tue, 22 Oct 2013 02:21:48 +0900

なんだか受験報告ブログになりつつありますが、それは置いといて。

今回は 3 年ぶり 5 度目のITサービスマネージャの受験でしたので、色々とメモ。

下調べ

最近はさすがに慣れてきて、まず公式情報も見るようになってきた。

前にこの試験を受けたのは 2010 年で、この時に買った対策書はあるけど、

IPA 独立行政法人情報処理推進機構：プレス発表　情報処理技術者試験の「出題範囲」および「シラバス」改訂版の公開について

みたいに 2012/05 にシラバスが変わってるし、

情報処理技術者試験の「出題範囲」及び「シラバス」における一部分野の構成・表記の見直しについて

2013/04 に JIS Q 20000 の用語が使われるように変わってるので新しいのを書ったほうがよさげ、と。

今回の対策本

ということでその後の発行された本を探したけど、私が探したタイミングでは出ていなかったので、前回わりとよかった気がする

2013 ITサービスマネージャ「専門知識+午後問題」の重点対策 (情報処理技術者試験対策書)

作者: 平田賀一,粕淵卓
出版社/メーカー: アイテック
発売日: 2013/05/30
メディア: 単行本
この商品を含むブログ (2件) を見る

この本を購入。好感触な点は前回の受験時に書いたとおり変わってなくて。前回不足していた ITILv3 や JIS Q 20000 の説明もちゃんと入ってた。

今回気付いたけど、この本は午後 I の過去問が 3 年分載っているものの、直近の 3 年分ではなくその前の 3 年分になっている。（直近の 3 年間は各 1 問ずつ重点解説に入っている。）どうも徹底解説ITサービスマネージャ本試験問題〈2013〉 (情報処理技術者試験対策書) と問題が被らないようにそうしてるみたいなので、新しめの過去問を解きたいならこれもまとめて買ったほうがいいし、一冊で完結させたいなら別の本のほうがいいのかも。

あと、問題の解説でたまに「？」となることがあった。例えば、平成20年春午後I問4 は試験センターの解答例が間違ってる（理由の説明が足りない）と思うんだけど、その誤った解答に沿って解説してるので筋が通ってない。別の本を立ち読みすると、

情報処理教科書 ITサービスマネージャ 2013年版はやや補足してるけどまだ説明不足
ITサービスマネージャ合格トレーニング 2013年度 (情報処理技術者試験対策)（だったと思う）はちゃんと「これじゃ足りない」「こう書くべき」と説明されてる

という感じだった。次回対策書を選ぶときに参考にしよう。

あと、今年はこの機会に ITIL の勉強をしておきたかったので、試験対策書以外にも二冊購入。

要点解説 ITサービスマネジメント [ITIL V3][JIS Q20000]対応

作者: 黒崎寛之
出版社/メーカー: 技術評論社
発売日: 2010/11/20
メディア: 単行本（ソフトカバー）
購入: 1人クリック: 11回
この商品を含むブログ (5件) を見る

こちらの本で ITILv3 と JIS Q 20000 をひととおり。さすがに一冊まるまるこのテーマを扱っているだけあって、サービスマネジメント上どういうプロセスが必要かはよくわかった。
プロジェクトの運用について、理想像が一つ固ったのもよかったかな。仕事でも役に立ちそう。

ITIL V3実装の要点　?一問一答でよくわかる

作者: 久納信之
出版社/メーカー: 技術評論社
発売日: 2011/05/10
メディア: 単行本（ソフトカバー）
購入: 1人クリック: 4回
この商品を含むブログ (3件) を見る

ITサービスマネジメントを導入するときの疑問に一問一答形式で答えている本。上の本を読んでると企業間でサービス提供しているイメージが強かったけど、この本でいう「IT組織」は社内の組織のイメージが強かった。まあ多少は論文書くときに役に立つのかも、くらい。

勉強っぷり

今は客先に常駐していて、社員さんより早く帰らないといけないので、わりと早めに帰れてはいる。まあ帰ってからも結構仕事をしているんだけど、試験前の 1 ヶ月程は帰ってからの時問を勉強にあてたので、めずらしく勉強時間がとれた。

本はひととおり読んで。問題を解いたのは、午後Iが11問、午後IIは過去問から 1問（実際に原稿用紙に書いた）+ 11 問（骨子考えた）。あと午前Iは試験会場に向かう途中で 2009 年くらいに買った対策本を読んでいた程度。

午後Iで間違えるパターンは、汎用的な対策を問われている場面で個別の対策を答えてしまっているのが多かった。マネージャとしてプロセスを改善するつもりで答えることを意識すればいいみたい。
午後IIはテーマによって「これはいけるんじゃない？」って骨子が書けるものから「このテーマが出たら諦めよう」ってものまで様々。ここは運次第かなぁ。

あと、これまで担当したプロジェクトをサービスの視点で整理してみたり、午後IIを解くときも 3 問中 1 問を選ぶところから時間を計りながらやってみたり、わりと色々なことが試せた。

試験

受験会場は明治学院高等学校＠高輪台。
高校の教室は生活感があって面白いなー。

午前II

厳しめ自己採点で 73%、実際に採点すると 93%。まあ過去問やってれば大丈夫と。

午後I

慎重に解答を考えてたら時間がギリギリになった。本番だと解答用紙に清書する時間が必要だし、ちょっと急ぐくらいのほうがいいかも。
まあ 6 割以上は解けてると思う。

午後II

2 問中 1 問選択なんだけど、2 問とも苦手テーマ・・・。

とりあえず「サービスレベルが未達となる兆候への対応について」を選んで、骨子をなんとか考えて「論述の対象とするITサービスの概要」を書いたところで残り 80 分。ア: 725 字、イ: 875 字、ウ: 825 字と最低の文字数は書けたけど、出来はイマイチ。関連部門との連携とか、期待されてる設問と別のところに書いてしまった気が。あと、試験中にウの規定文字数が 800 文字だと勘違いして、ウの内容を薄っぺらく伸ばしてしまったので流れが変になっていた気がする。

反省＆感想

今回は勉強時間がとれたので、色々試せて満足
次回午後IIの対策をするときは、苦手なテーマを重点的に攻めよう

（2013-12-20 追記）成績照会

午前I得点
***.**点
午前II得点
88.00点
午後I得点
78点
午後II評価ランク
C

やっぱ午後IIが課題と。

Google Code Jam 2011〜2013 の話

Sun, 12 May 2013 00:15:37 +0900

今年も（私の中では）終わってしまったわけですが。ここ数年ぶんの出来事を、

その時々でどんな言語に興味を持っていたのか
各言語に対してどんな感想を持ったのか

を中心に、まとめてさらっと書いておきます。

Google Code Jam 2011

結果

Code Jam 2011 Statistics - Participant Details: miau

ということで、Round1 を通過できずに終了。

方針

何かのめりこめる言語を探したい
- 「どんな処理でも Perl で書いてやる！」と考えてた頃のような情熱がほしい
- 条件はこんな感じ
  - Ruby くらい簡単に書けて、速く動作する言語（Windows だと妙に遅いとか不可）
  - メモ化やら末尾最適化やらが簡単にできる言語
  - 実用性が高いもの（DLL が作成できるとか、仕事でつかえそうだとか、配布が容易だとか）

ちなみに前年の反省を活かして、触りたい言語についてはあらかじめ入出力くらいは書けるようにしておいた。

使った言語

Go
- 当時流行ってた（？）ので。
- もっと簡単に解けるのに、無駄にゴルーチンやらチャンネルを使って解いて遊んでた。
- 悪くはないけどすごくハマったりもしなかった
  - 最近「クロスプラットフォームでかけるからいいよ！」みたいな話を見かけたので、また触るかも
Clay
- 手軽に DLL が作れるということで。
- 最近の言語っぽく書きやすく、コンパイルはちょっと重いけど実行は速い。
- わりと気に入ってたんだけど、その後使ってないのは、文字コードまわりのサポートが少ないから・・・だったかな。
Perl6
- たまには触っておきたかったので
- やっぱり動作遅い・・・
Factor
- たまたま Factor 座談会 - あしたのオープンソース研究所あたりを読んで、スタック指向言語に興味を持ったので
- スタックが一つずつ消費されてくんだけど、インタラクティブシェルがあるからこの様子がわかりやすい。
- うまい人はもっと簡潔にかけてるから、たまに触って感覚を掴んでおきたい感じ。
F#
- 「他に普段触らない言語なかったっけ？」という感じで適当に
D
- Round 1A を Groovy で解こうと思ったら、家の PC でうまく動かなかったので、適当に入っていたやつで
Groovy
- この年の本命。
- 「配列のメソッドが最初から Ruby + ActiveSupport くらい充実してるし、it とか使えるし、Ruby よりいいかも！」「Groovy++ を使えば速くなるし末尾最適化もできるっぽいし、Groovy かわいいよ Groovy」と急に気に入ったので。
- ところが Groovy++ を使うと型を書かないといけない箇所が増えるしコンパイル通らなくて苦労するし、かわいい部分がどっかに行ってしまうことに気づいて、その後は Jenkins 関係でしか使ってない

Google Code Jam Japan 2011

結果

http://codejam-source-viewer.appspot.com/#!/889487/miau

予選と決勝しかないけど、決勝を一問くらい解いたくらいでイマイチ。

方針

時間的にあんまり余裕がなかったので使い慣れてる Ruby で
他の言語を触るにしても、Ruby で解いた後におまけ的に触る感じ

使った言語

Ruby
- いつの間にか Enumerable のメソッドが増えてて、Groovy と比べても見劣りしない感じに
  - それでもやっぱりアルゴリズム系は Python のほうが充実してる気はするけど
- Windows での動作が遅いので、損した気分になる・・・
CoffeeScript
- コーヒーの問題だから CoffeeScript 使っておくかー、みたいな
- submit したら答えが合わず（JavaScript の sort() が文字列でソートされてたせい）、Ruby のほうを submit したのでソースコードは残ってなかったり
D
- ビット配列が使える気がして触ったけど、あんまり意味がなかった気がする。

Google Code Jam 2012

結果

Code Jam 2012 Statistics - Participant Details: miau

Round 1 で終了と。

方針

前年に触った Factor がわりと面白かったので、パラダイムが違う言語を触りたい
プログラミングコンテストチャレンジブック [第2版]　?問題解決のアルゴリズム活用力とコーディングテクニックを鍛える? を解いてまじめにアルゴリズムの勉強をする
- と言いつつ初級編の真ん中くらいまでしかやってない

使った言語

Prolog
- パラダイムが違う言語代表（論理型言語）。普段とは違う考え方が必要で新鮮だった。
- 最初は SWI-Prolog を使ってたけど、入力が面倒なので GNU Prolog に乗り換えたりとか、これだけで 22 時間使ってしまった・・・
PowerShell
- 当時 cmd.exe から乗り換えようとしてたので
- スクリプトを書く上では、他のスクリプト言語ほど使いやすくないかなぁ
PHP、Perl、Ruby
- 時間がなくなってきたので適当に使っただけ
Julia
- この年の本命。
- なぜ僕らはJuliaを作ったか - 丸井綜研を読んで期待が高まった＋Windows 用のバイナリも正式ではないものの上がっていたので
- マクロが強力な言語を触るのが初めてだったので、いろいろ作って遊んでた
  - そのせいでアルゴリズム寄りの練習できなかった・・・
- 若い言語だから、言語が成長していく過程を見られたり、要望を出したりバグ報告したりで楽しかった
- 「もっと深く関わりたいけど、関数型の言語やら、よく比較されてる R や Mathematica の知識を身に着けからにしよう」とか思っているうちに放置気味に。

Google Code Jam 2013

結果

Code Jam 2013 Statistics - Participant Details: miau

今年も Round 1 で終了。

方針

1 つくらいはパラダイムが違う言語を触りたい、くらい？

使った言語

GolfScript
- またスタック指向言語を触っておこうか、って感じで。
- ネタっぽい言語だけど、APL を ASCII にした感じなので、うまくハマるとかなり簡潔に書ける気がする
- とはいえインタラクティブシェルがないので、スタック指向言語の利点が活きてないような
  - golfscript.rb の簡潔さも芸のうちだから仕方ないのかな
Nemerle
- C# で書いてた処理を簡潔に書きなおせそうで、しばらくマニュアル読みこんでたので記念に
- マクロが強力なのがいい。printf() のフォーマットと引数が合わないと IDE でエラー教えてくれたりして新鮮。
  - でも IDE の動作はまだ不安定で、たまにエラーが出なくなるので再起動してた・・・
Haskell
- すごいHaskellたのしく学ぼう! を読んだ記念
- もう数か月前のことだから、いろいろ忘れてて汚いコードになってしまった・・・
Groovy
- Ruby より書きやすいかなーと思ったんだけど、今触ってみると「あれ？この機能ないの？」みたいなのが結構あった
  - shift/unshift、all、zip、リスト内包表記とか
- Ruby のほうが Perl っぽい部分が残ってて、自分のスタイルには向いてる気がする
PHP
- 多次元（連想）配列を作るのが楽かなってことで使ってみたけど、Perl と違って ++ で新しい要素を作ってくれないから、あんまりきれいにならなかった
- あと多次元配列を扱うときは変数名の先頭に $ があるとうるさく見えるので、Perl や PHP は避けたほうがいいのかも、と思ったり
Perl
- Qualification Round A. Tic-Tac-Toe-Tomek で使ったけど、これだけは Perl らしく（？）簡潔に書けた気がするので gist で晒しておこう
  - https://gist.github.com/miau/5563798
- 普段はまずやらないけど、$_ を多用すると見た目がすっきりするなー、とか思った
Ruby
- 時間がなかったので適当に
Scala
- 今年の本命。
- 「仕事で Java を使うから何かしら勉強になるかなー」って思って触りはじめたけど、Scalaスケーラブルプログラミング第2版を読み終えた頃に、ほとんど Java の勉強ならないことに気づいた
  - Round 1A の A を力技で解くにはどうすればいいか調べてて、BigDecimal やら MathContext やらの知識が身についた程度？
- 関数型とオブジェクト指向がうまいこと合わさってるなーって印象。
  - 関数型の部分は Haskell っぽい部分が多いので、Haskell 触ってるとすんなり入れるかも。
- いざってときについ手続型っぽい処理を書いちゃうので、関数型の特訓には向かないかも。
  - 関数型っぽく書くなら Haskell のほうが簡潔に書けちゃうし・・・。

- - -

という感じでした。今後の方針としては

年に一回だけだといつまでたっても成長しないので、TopCoder やら AtCoder に参加したい（毎年言ってる気がする・・・）
Haskell で解いたりして、もっと関数型っぽい考え方に詳しくなっておきたい

ってところですかね。

システム監査技術者（試験）

Sun, 21 Apr 2013 23:02:06 +0900

久々にブログを更新したと思ったら情報処理試験の感想だったりする、わりとよくあるパターンですけど。とりあえずこれ書いておくと「誰もこんなの興味ないだろうから、さっさと次の話題を書こう」って気になって、ブログの更新が続いたりするので、ご容赦ください。

今回受験したのはシステム監査。去年は受験できなかったので、2 年ぶり 3 度目の受験。

勉強っぷり

ちょっと古い本だけど、前回買っておいたこの本で、解説＋午前の問題については二周くらい読んだ。

情報処理教科書システム監査技術者 2009年度版

作者: 落合和雄
出版社/メーカー: 翔泳社
発売日: 2008/10/03
メディア: 単行本（ソフトカバー）
クリック: 1回
この商品を含むブログ (2件) を見る

時間がそれほどなかったので、午後I や午後II の問題は実際に解答を書いたりせず、頭でぼんやり考えて解答を見る程度。

ちなみに情報処理推進機構：情報処理技術者試験：試験要綱・シラバス・過去問題などを見ると 2012 年の 5 月にシラバスが変わっているようで。試験対策書を買うならこれ以降に出たもののほうがいいんだろうけど、上記の対策所は 2010 年版が最後なので、他のを選んだほうがいいのかも。

あと、以前から「監査のイメージを掴むために試験対策書じゃない本も読もう」と考えていたので、今回はこの本を読んでみた。

IT監査とIT統制―基礎から事業継続・ネットワーク・クラウドまで―

作者: 社団法人日本内部監査協会編
出版社/メーカー: 同文館出版
発売日: 2012/09/27
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

教科書的な本なのであまり監査人の生活について具体的なイメージがつかめたわけではないけど、個別監査計画書のサンプルが載っていたりで、前よりはイメージができるようになった。

内部監査に関する本で、内部監査人協会の用語が使われている（試験はたぶん経済産業省の用語がベース）ので、そこは注意が必要かも。

あと応用例としてクラウドに関する監査について書かれてる章があって。ちょうどシラバス変更のポイントに「クラウドの普及」なんて書いてあったから、「出題されたらラッキー」くらいに思ってた（けど、結局出題されてない）。

試験

受験会場は東海大学高輪キャンパス＠白金高輪。
「駅から会場に向かう途中でコンビニの一つくらいあるだろう」と思ってたらなかったので、入り口の反対側まで行って昼食を買って、ちょうどいいくらいの時間に到着。

午前II

厳しめ自己採点で 65%、実際に採点すると 88% と。
監査がらみは過去問と似たような問題が多くて午前対策が役に立った＋知らなくても考えればわかる感じの問題が多かった。

といいつつ前回間違えたところをまた間違えたので、前回のメモを引用。

SECIモデルの I が何の略か

SECIモデル − ＠IT情報マネジメント用語事典

この図は何度か見ていたのに頭に入ってなかったので、知識管理から知識経営へ -ナレッジマネジメントの最新動向- みたいなモデル入りの図で覚えたほうが

あと、ファイブフォース分析も間違えた。ここがわかりやすいかな。

5フォース分析（5つの競争要因）［ITCサンシャイン・ブレインズ］

午後I

今まで結構解答のポイントを外しがちだったので、確実に解答できそうな問題を選ぼうとフラフラしてたら 10 分ほどロスして。急いで解きはじめたものの、90 分まるまる使った。

通過してるかは微妙なライン。「この運用に問題があるのはわかるけど、どっちの問いで答えるべきなんだろう？」と迷うことが多いので、やっぱり実際に問題を解いたりして感覚を掴んでおいたほうがいいみたい。

ちなみにアジャイル開発の監査についても出題されてて、ちょっと新鮮だった。

午後II

消去法で「要件定義の適切性に関するシステム監査について」を選択したものの、文章の流れが思い浮かばない。30 分くらいで骨子が何とか書けたので急いで書き始めて。
ア: 750 字、イ: 850 字、ウ: 950 字と最低の文字数には達したものの、「要件定義の適切性」というポイントは外してしまったので、採点されても C くらいじゃないかと。

やっぱり練習してないといきなりは書けないなー、という印象。

反省＆感想

今回はわりとモティベーション高く勉強できてたのでよかった
- 「システム管理基準とか普通に開発するときのチェックリストとして使えそうだなー」とか「電子消費者契約法で『確認画面を表示してれば、間違って申し込みしても取り消せない』みたいに決まってるからみんな確認画面が好きなのかなー」とか、業務に絡めて興味を持って勉強できてた
- 試験対策書じゃない別の本を読むのも楽しい。次回も別の本を読めたらいいな。
今回は計画的に勉強してたんだけど、やっぱり直前に忙しくなったりして問題を解く時間が作れなかったので、早めに問題を解こう
秋はITサービスマネージャ？でも日程見たらリリースとかぶってそうだから、未受験になるかも。

（2013-07-07 追記）成績照会

午前I得点
***.**点
午前II得点
88.00点
午後I得点
65点
午後II評価ランク
C

まあ予想通りと。

ITストラテジスト（試験）

Sun, 21 Oct 2012 23:33:57 +0900

（当時書いていたのに用語をいろいろ調べているうちに投稿する機会を逃したので、2013-04-21 にこっそり投稿してます）

ここ 2 回ほど色々あって受験できなかったので、1 年半ぶりの情報処理試験です。今回は IT ストラテジスト。2 年半ぶり 2 度目の受験。

勉強っぷり

前回受験したときの

ITストラテジスト（試験） - miauの避難所

とほぼ同じ。

今回は午前Iもあるので午前の本は計算問題以外ひととおり眺めておいた。時間がないので計算問題の類は飛ばして。
午後の対策は実際に解いたりせずに、各章の冒頭を読んだくらい。

まあ要するに一夜漬けです。

試験

受験会場は東京都市大学世田谷キャンパス＠尾山台。
コンビニで昼食買おうと思ったらすごい列で驚いた。10 分くらい並んでたのかな？
そんなわけでちょうどいいくらいの時間に到着。

午前I

回答出てたので採点したら 25/30 で 83% と。（厳しめ自己採点では 69%。ちょっと厳しすぎたか。）
とりあえず次回の午前I免除権は確保できた。

午前II

厳しめ自己採点で 59%、実際に採点すると 52% といった感じ。今回はここで足切りみたい。
1問回答選ぶの間違えてたのがあったし、午前Iの対策せずに午前IIの対策に集中してたらなんとかなったレベルだと思うからちょっと惜しいところではあるけど、まあ仕方ない。

あの午前対策本だけだと余裕を持って通過するのは難しそうなので、次回は何か別の対策書を買おう。

午後I

75 分くらいで完了。足切りだから採点されないけど、たぶん合格ラインは超えてたと思う。
比較的時間に余裕あるし、考えればわかる問題が多いから、次回はここは軽めでよさそう。

午後II

システム化計画まわりの話であれば、今やってる案件がらみで何か書けそうだなー、と妄想してたんですが。今回はシステム化計画まわりで手頃な出題がなくて。仕方がないので「IT を活用した事業戦略の策定について」を選択。

骨子に 40 分、概要に 10 分くらいかかって、文書書けるのが 70 分しかない。
ア: 450 字、イ: 850 字、ウ: 625 字でなんとか最低ラインの文字数は書きなぐったけど、文字はひどいし、事業戦略に意識がいく余り IT をあまり活用できてないし。わりとひどい感じでした。

もし採点されていても D だった気がします。

反省＆感想

前回がわりと書きやすい論文だった＋たまたま午前IIも通過できてたんで油断してた
今まで経験した案件の一覧を作っておいて「この分野で出題が来たらこういうこと書けそう」ってのを作っておきたい・・・と前から思っているんだけど作れてない。次はやりたい。

春はまあシステム監査です。

成績照会

午前I得点
88.40点
午前II得点
56.00点
午後I得点
---点
午後II評価ランク
-

次回の午前I 用メモ

午前I で解答を間違えたり、理解があやふやだった用語をいろいろメモ。

SMP
VLIW
スーパスカラ
スーパーパイプライン→パイプライン
ETL
OLAP
データマイニング
BPO
技術のSカーブ→技術進歩のS字カーブ
GAAP
IASB
IFRS
SEC
EMS
LBO
CSF = KFS
IVR（音声自動応答）
プロダクトライン開発
SPA
TOC (Theory of Constraints)
IRR (Internal Rate of Return)
XBRL
コンジョイント分析

文字集合の包含関係とテストに使うべき文字

Mon, 19 Sep 2011 19:22:40 +0900

先月あたりから文字コードまわりの調査をしていたので、そのことについて書こうと思ったのですが。もろもろの説明の前提としてエンコーディングに対する説明が必要で、エンコーディングの説明にはその対象となる文字集合についての説明が必要で・・・ということで、まずは文字集合についての概説です。

目的

冒頭に書いたように、私が行った文字コードまわりの調査結果を書くための前提部分の説明が目的ではあるんですが、もうひとつ目的がありまして。

Web を見てまわっていると、いくつかの文字を不適切に選んで「この文字で確認したらうまくいったから大丈夫」というように不十分な調査がなされている事例が多々ありました。せっかく調査結果をまとめてくれているのに不十分なせいで活用できない＝同じ調査を再度行う、という残念なことになってしまっているので「今後調査／テストを行う際にどのような文字を抽出すればよいか」という基礎情報的なものを示すことができればいいなと。

説明の方針

いちおうテーマは文字集合なのですが、プログラマが実際に扱うことになるのは符号化されたデータのほうなので、そちらについても必要に応じて言及しています。主に「可能な限り文字化けしない」（＝入力した文字がそのまま保たれる）ことを目的としていますので、字体の変化や文字の入れ替え等には言及していません。

なお、気になっているのは Shift_JIS や EUC-JP のような JIS ベースの符号化ですので、ISO-8859-1 のように JIS と関係のない文字集合には言及しません。

包含図

各包含関係の中に、そこの含まれる代表的な文字と、可能であればその領域に含まれる文字数（多数ある場合は * 等で省略）を記載しています。

理解不足や間違い等もあると思いますので、気づいた点があればご指摘ください。

各文字集合の概説

これだけ見ても「何がなにやら」という感じだと思うので、簡単に説明しておきます。

右下で背景色がカラフルになっている部分がありますが、これは細かい話になってくるので、まずは枠で囲んだ部分だけ説明します。

ASCII

キーボードに記載されている英数字＆記号たちです。（日本語キーボードの ¥ を除く）

JIS X 0201

ラテン文字（基本的に ASCII と同じ英数字）＋カタカナ（いわゆる半角カナ）です。

英数字の部分は ISO 646（ASCII のうち 12 文字を各国の事情に合わせて差し替えられるようにした規格）に従っており、「\」（バックスラッシュ）と「~」（チルダ）は JIS X 0201 では「¥」と「‾」に置き換えられています。現在主流のエンコーディングでは ASCII と互換性を持った形でマッピングが行われるので、あまり気にしなくて良い部分ではあるのですが、これが円記号問題の発端になっています。

JIS X 0208-1978

ひらがなや標準的な漢字、全角の英数字、記号、カタカナが含まれています。ここで規定されている英数字、記号、カタカナについては、厳密には全角に割り当てることにはなっていないのですが、実際は全角の記号に割り当てられているのでこのように考えていていいと思います。

機種依存文字

広義では絵文字なんかも機種依存文字になるようですが、ここでは Windows の機種依存文字である NEC 特殊文字、IBM 拡張文字、NEC選定IBM拡張文字の総称として説明します。図はかなり見づらくなってしまったので、ここだけ簡単にして抜き出します。

NEC 特殊文字、IBM 拡張文字
- JIS X 0208-1978 に含まれない文字を、NEC と IBM がそれぞれ独自に定義したものです。共通している文字もあれば、そうでないものもあります。
NEC選定IBM拡張文字
- IBM 拡張文字のうち、NEC 特殊文字に含まれていなかった部分を NEC が追加したものです。

このような包含関係になっているため、以下のいずれかの組み合わせで機種依存文字はカバーできることになります。

NEC 特殊文字＋IBM 拡張文字
NEC 特殊文字＋NEC選定IBM拡張文字

なお、CP932（日本語の Windows 環境で標準として使われる Shift_JIS の拡張。IANA では Windows-31J の名称。）では NEC 特殊文字、IBM 拡張文字、NEC選定IBM拡張文字を全て取り込んでいます。NEC 特殊文字とNEC選定IBM拡張文字だけですべての文字集合が表せるわけですから、IBM 拡張文字に元々含まれている文字については二箇所に出現することになります。

JIS X 0208-1983

JIS X 0208-1978 に 75 文字追加されています。うち 10 文字については機種依存文字として存在していた部分であり、CP932 では機種依存文字に加えこれらの文字も保持していますので、これらも二重登録（もともとIBM 拡張文字と NEC 系で重複していた「∵」「¬」に至っては三重登録）されます。

JIS X 0208-1990 / JIS X 0208:1997

JIS X 0208-1990 では JIS X 0208-1983 からさらに 2 文字追加されています。JIS X 0208:1997 では文字の追加は行われていないので、JIS X 0208 といったらこの範囲だと考えればよいです。JIS X 0208-1983 の流れがあったので図示しましたが、調査の際は特に意識する必要はない部分です。

JIS X 0212（補助漢字）

JIS X 0208 に足りない文字を新しく定義したものです。いろいろ情報を見ていると「JIS X 0213 に置き換えられる予定」みたいな書き方になっていて軽視されていそうですが、本来の EUC-JP では利用可能な領域なので少し注意が必要です。とはいっても Windows 上で EUC-JP という場合は CP932 と同じ文字集合からなる CP51932 を指す場合が多く、JIS X 0212 の範囲が扱えないことが多いのですが。（これについては次回詳しく書きます。）

JIS X 0213:2000（拡張漢字／第三水準、第四水準）

JIS X 0208 で不足している文字を補うという目的は JIS X 0212 と同じなのですが、JIS X 0208 を包含する形で、Shift_JIS の余った領域に詰め込めるように文字を選びなおしたものです。JIS X 0212 は使わず JIS X 0213 を使っていく方向だったみたいですが、CP932 と非互換な部分があるためか、エンコーディングとしてはあまり使われていないようです。

もともと Unicode 外の領域を使用していましたが、Unicode 3.1、3.2 で全ての領域がカバーされており、現時点では JIS X 0213 の文字を扱う際は Unicode で扱うことになります。

Unicode では BMP 外の文字（UTF-16 でサロゲート･ペアとなる、いわゆる 4 バイト文字）が含まれるので注意が必要です。また、一部の文字については Unicode で 1 文字にマッピングされず、Unicode 2 文字を合成して表すことになっています。

JIS X 0213:2004

いわゆる JIS2004 で、JIS X 0213:2000 から 10 文字が追加されました。包含図では JIS X 0213:2000 を囲む形で図示すべきなんですが、さすがにごちゃごちゃしすぎるので追加部分だけを図示しています。

Windows Vista がこの領域の文字を扱えるようになったことが話題になっていましたが、現時点ではエンコーディングとして利用できないため、Web アプリケーションを作る立場では「Vista からはこの領域の文字も送られてくる」という程度の認識でよいと思います。注意点は Unicode の扱いと同じです。

Unicode 3.0、3.1、3.2

JIS X 0213 の範囲が Unicode の範囲に収まっていることを示すために図示したかっただけで、調査の際はバージョンはあまり気にしなくていいはずです。（今後 6.0 の絵文字等は気にする必要があるかもしれませんが。）

NEC 選定 IBM 拡張文字の文字種について

さきほど説明を省略した右下のカラフルな部分についてですが、参考にしたページを先に挙げておきます。ほぼこのページの受け売りです。

ユニコード CJK互換漢字 F900〜FAFF

NEC 選定 IBM 拡張文字の領域には記号と漢字が含まれていますが、漢字については Unicode 上で

CJK 統合漢字（CJK UNIFIED IDEOGRAPH）
CJK 互換漢字（CJK COMPATIBILITY IDEOGRAPH）

の 2 つに分類されています。CJK 統合漢字は通常どおりに使ってよいのですが、CJK 互換漢字はその名のとおり互換性のために残されている文字で、Unicode 本来の立場からすると CJK 統合漢字にある別の文字に置き換えてしまいたいけれど、それをやってしまうとラウンドトリップ変換が行えないので仕方なく残している、という文字です。

CJK 互換漢字は Unicode 上でいくつかの領域に分かれて定義されています。基本的に NEC 選定 IBM 拡張文字の領域については「The IBM 32 compatibility ideographs（IBM拡張文字に基づくもの）」に含まれているんですが、「朗」「隆」の 2 文字については「Pronunciation variants from KS X 1001:1998（KS X 1001:1998（韓国）における発音重複に基づくもの）」に含まれています。

このあたりはわざわざ分類しなくてもいいんですが、The IBM 32 compatibility ideographs はカナダ文字とも言われる領域で、私が調査中に「32 文字って書いてあるけど、数えると 34 文字あるぞ？どこかで分類間違えたかな？」と焦ってしまったので、念のため図示しました。

「The IBM 32 compatibility ideographs（IBM拡張文字に基づくもの）」については、参考ページの注意書きに

「備考」の項目に「統合漢字」とあるものは、互換用ではなくCJK統合漢字です（詳細）。

と書かれており、この部分については CJK 統合漢字と同じように使用してもよいそうです。結果としてこの領域右側の黄色とピンクの領域が CJK 互換漢字ということになり、この領域のものはアプリケーションによって CJK 統合漢字に置き換えられることがあるので注意が必要です。たとえば Skype がこういった動作になっていて、テスト用に機種依存文字を送ったつもりがちゃんと送れてなくてハマったりしました。Chrome も条件によっては一部の文字で不思議な動作をしたりしていたんですが、これについてはまた後日。

図の左側に、JIS X 0213 に含まれる CJK 互換漢字も表記してあります。こちらは「JIS X 0213 compatibility ideographs（JIS X 0213における包摂基準変更に基づくもの）」に含まれており、すべて互換漢字として扱ってよいようですので、こちらについても CJK 統合漢字に置き換えらえられると困るのであれば、注意が必要になります。

CP932 のマッピングが特殊な文字について

文字集合の話からは逸れてしまうんですが、せっかくテスト用に使える文字種を羅列しているので、CP932 で注意が必要な文字についても簡単に記載しておきます。

Windows の変換が特殊といわれているのは以下の 8 文字だと思います。

CP932	CP932 での名称	Win		other
0x815C	HORIZONTAL BAR	U+2015	―	U+2014	—
0x8160	FULLWIDTH TILDE	U+FF5E	～	U+301C	〜
0x8161	PARALLEL TO	U+2225	∥	U+2016	‖
0x817C	FULLWIDTH HYPHEN-MINUS	U+FF0D	－	U+2212	−
0x8191	FULLWIDTH CENT SIGN	U+FFE0	￠	U+00A2	¢
0x8192	FULLWIDTH POUND SIGN	U+FFE1	￡	U+00A3	£
0x81CA	FULLWIDTH NOT SIGN	U+FFE2	￢	U+00AC	¬
0xFA55	FULLWIDTH BROKEN BAR	U+FFE4	￤	U+00A6	¦

Win が Windows のマッピング方式で、other はそれ以外での方式で発生しえるマッピング先です。Windows の API を利用するとすべて Win の文字になりますが、それ以外のものについてはライブラリや製品、指定する文字コードによってこの組み合わせはまちまちなので、注意が必要です。

特に「〜」のマッピングに失敗して「?」等になる問題が発生するケースが多いです。これと「−」（全角ハイフン）以外の文字はあまり使わないので問題視されにくいですが、もし入力されたら同じように「?」になったりするわけなので、適切に処理されることは確認しておくべきでしょう。

MS 公式にもちゃんとまとまっていないんですが、参考となる情報としては以下のものがありました。

[XWEB] 修正プログラム Q283214 の適用後に一部の日本語文字が疑問符になる
- 上記 8 文字のうち、HORIZONTAL BAR 以外の 7 文字が記載されています。
[NT] JIS X 0221 とコードページ 932 のマッピングが異なる
- HORIZONTAL BAR を含む 4 文字について記載がありました。

上記以外に、JIS の原理主義に近い形でマッピングを行うと、以下のようになっているケースもあるかもしれません。ただ、現在ではほとんど見かけることはないと思います。

CP932	CP932 での名称	Win		other
0x5C	REVERSE SOLIDUS (YEN SIGN)	U+005C	\	U+00A5	¥
0x7E	TILDE	U+007E	~	U+203E	‾
0x815F	FULLWIDTH REVERSE SOLIDUS	U+FF3C	＼	U+005C	\
0x8150	FULLWIDTH MACRON	U+FFE3	￣	U+203E	‾
0x818F	FULLWIDTH YEN SIGN	U+FFE5	￥	U+00A5	¥

結局どの文字をテストに使えばいいの？

目的によって違うので「これで十分」というものはないのですが、不適切な選び方をしないように気をつければいいんじゃないかと思います。

NEC 特殊文字をテストするのであれば「①」のように JIS X 0208 に含まれないものを選ぶ（※JIS X 0213 はあまり使われてないのでとりあえずここでは無視）
EUC-JP が関わる環境で NEC 選定 IBM 拡張文字をテストするのであれば、「髙」のように JIS X 0212 に含まれないものを選ぶ
Unicode の文字をテストするのであれば、問題の切り分けが容易なように「☺」のように JIS 外の文字を選ぶ
- もし切り分けの容易さよりも手順の簡単さを選ぶなら、いきなりサロゲートペアの「𠮷」を選ぶというような選択もあり

といった感じです。

文字の一覧（コピペ用）

本当は図を SVG 等で出力してコピーできるようにしたかったのですが、機種依存文字が含まれまくっているせいか Cacoo でうまくエクスポートできなかったので、コピペ用に文字の一覧を記載しておきます。

「この文字が化けるけどどの領域に含まれているんだっけ？」という場合にも使えるよう、機種依存文字と CJK 互換漢字についてはすべての文字を記載しました。図中で代表として使った文字については太字で示しています。

追記: 最初は図と見比べながら使う前提でただ羅列していたんですが、見比べにくい気がしたので説明を追加しました。このリスト単独でもそれなりに使えるとは思いますが、たとえば JIS X 0212 の項にすべての JIS X 0212 の箇所が載っているわけではない（機種依存文字に含まれる部分はそちらに載せている）というような部分もあるので、図と見比べて過不足がないか確認した上でご利用ください。

JIS X 0201
- ¥‾（※多すぎるので入力しづらい 2 文字のみ）
JIS X 0208
- あ亜Ａア￥凜熙♪堯（※多すぎるので図に記載したもののみ）
NEC 特殊文字にのみ存在
- JIS X 0208 に含まれるもの
  - ≒
- JIS X 0213 に含まれるもの
  - ①②③④⑤⑥⑦⑧⑨⑩⑪⑫⑬⑭⑮⑯⑰⑱⑲⑳㍉㌔㌢㍍㌘㌧㌃㌶㍑㍗㌍㌦㌣㌫㍊㌻㎜㎝㎞㎎㎏㏄㎡㍻〝〟㏍㊤㊥㊦㊧㊨㈲㈹㍾㍽㍼∮∟⊿
- JIS X 0213 に含まれないもの
  - ∑
NEC 特殊文字とIBM拡張文字の重複部分
- JIS X 0208 に含まれるもの
  - ∵
- JIS X 0212 に含まれるもの
  - №
- JIS X 0212 に含まれないもの
  - ⅠⅡⅢⅣⅤⅥⅦⅧⅨⅩ℡㈱
NEC 選定IBM拡張文字
- 記号（全て JIS X 0213 に含まれる）
  - JIS X 0208 に含まれるもの
    - ￢（※Windows と異なる変換では ¬）
  - JIS X 0212 に含まれないもの
    - ⅰⅱⅲⅳⅴⅵⅶⅷⅸⅹ＇＂
  - JIS X 0212 に含まれるもの
    - ￤（※Windows と異なる変換では ¦）
- CJK 統合漢字
  - JIS X 0212 にも JIS X 0213 にも含まれるもの
    - 丨仡伀伃佖侊侒侚侔俉倞倢偀偂偆偰傔兊冝刕劦劯勛匀厓厲咜咩哿喆垬埇埈夋奛奝妤孖寀寘尞岦岺崧嵂嵭嶸嶹弴彅彧忞悊惕惲愰愷憘抦揵摠撝擎昀昉昕昞昤昱晗晙曻晳暙暠暲暿曺杦枻柀桒桄棈棏楨榘槢樰橆橳橾櫤毖氿汜沆泚洄涇涬淏淼渧渼湜溿澈澵濵瀅瀇炅炫焄焏煆煇煜燁燾犱犾獷珉珖珣琇琦琪琮瑢璉璟甯畯皛皜皦睆砡硎硤禔禛竑竫箞絈絜綷繒纊罇茁荿菇葈蒴蓜蕓蕙裵褜訒訷詹誧誾諟諶賰贒鄧釗釚釤釥釭釮鈊鈐鈹鈺鈼鉀鉎鉑鉙鉧鉸銈銧鋐鋓鋗鋙鋠鋧鋹鋻鋿錂錝錞錡錥鍈鍗鍰鏆鏞鑅隝隯霳靏靕顗顥驎髜魵鮏鮱鰀鵫鵰鸙
  - JIS X 0213 には含まれるが JIS X 0212 には含まれないもの
    - 炻匇匤咊增寬嵓德晥栁橫瀨甁皞礰竧綠緖荢薰譿賴郞鄕霻靍馞魲黑
  - JIS X 0212 には含まれるが JIS X 0213 には含まれないもの
    - 伹俍俿僘兤冾劜勀卲叝坥墲奓奣妺巐弡恝惞愑戓昮朎汯浯涖渹猤玽珒珵琩硺羡菶蕫譓軏遧釞鈆鉷鋕鎤鏸鐱鑈靃餧鮻
  - JIS X 0212 にも JIS X 0213 にも含まれないもの
    - 仼僴凬坙峵悅愠敎昻櫢淸淲皂蠇赶閒靑髙
- CJK 互換漢字（全て JIS X 0212 に含まれない）
  - 統合漢字として扱うべきもの
    - JIS X 0213 に含まれるもの
      - 﨏﨑﨓﨔﨟﨡﨤
    - JIS X 0213 に含まれないもの
      - 﨎﨣﨧﨨﨩
  - The IBM 32 compatibility ideograph
    - JIS X 0213 に含まれるもの
      - 塚凞猪神祥福蘒諸都
    - JIS X 0213 に含まれないもの
      - 晴益礼靖精羽逸飯飼館鶴
  - Pronunciation variants from KS X 1001:1998（すべて JIS X 0213 に含まれる）
    - 朗隆
JIS X 0212
- JIS X 0213 に含まれるもの
  - 骶
- JIS X 0213 に含まれないもの
  - 杮
JIS X 0213:2000
- 合成文字
  - か゚
- Unicode 3.0 の文字
  - 㐂
- Unicode 3.2 の CJK 互換漢字
  - 侮僧免勉勤卑喝嘆器塀墨層屮悔慨憎懲敏既暑梅海渚漢煮爫琢碑社祉祈祐祖祝禍禎穀突節練縉繁署者臭艹艹著褐視謁謹賓贈辶逸難響頻
- Unicode 3.2 の文字
  - ㉑
- Unicode 3.1 の文字（サロゲートペア）
  - 𠀋
JIS X 0213:2004
- Unicode 3.0 の文字
  - 俱剝吞噓姸屛幷瘦繫
- Unicode 3.1 の文字（サロゲートペア）
  - 𠮟
Unicode（JIS 外の文字）
- Unicode 3.0 の文字
  - ☺
- Unicode 3.1 の文字（サロゲートペア）
  - 𠮷
- Unicode 3.1 の文字（サロゲートペアではない）
  - ϴϵ
- Unicode 3.2 の文字
  - ⅊ （※おそらく通常のフォントでは表示できません）

参考情報

図をまとめるための情報源について多数あったのですが、まとめきれていないのでいずれ追記 or 別記事にまとめて記載します。まずは文字集合を理解する上で参考になった情報源を挙げておきます。

日本の文字コード

文字集合やエンコーディング、その他用語について、いい感じにまとまっています。上では機種依存文字を分類しすぎて全体像がつかみにくくなっているので、概要が知りたい場合は Windowsの機種依存文字のページを見るといいかもしれません。

JIS X 0213 コード表 (94×94)

JIS X 0213 のコード表ですが、JIS X 0208 の各規格、JIS X 0213 の各規格、Unicode 3.1／3.2 で追加された文字が色分けされており、イメージがつかみやすいです。ちなみに聖愛中学高等学校のコンテンツで、高校の授業に使われているんだと思います。周辺のコンテンツを見るとかなり充実していて、こんなのを授業で勉強できるのはすごく羨ましいです。

（追記）

いくつか注意書きをするつもりが書き忘れてました。

まず、こんなめんどくさいことを考えたくなければ、システム全体を Unicode 系（UTF-8 とか UTF-16 とか）で統一しましょう。Unicode だけで文字を扱うことができれば、JIS 系の文字集合や機種依存文字、MS932 の注意点からは解放されます。（サロゲート･ペアや合成文字、CJK統一文字／CJK互換文字の問題は残りますが。）

あと、上記に挙げた全ての文字種でテストすれば十分かというと、そういうわけではありません。たとえば Shift_JIS では 2 バイト目に \ が入るから問題になりやすいとか、Shift_JIS／EUC-JP で文字境界を意識しないと意図しない処理になるとか、ASCII では下位 7 bit しか扱わないから \xa5 が \x25 になるとか、そういった部分には一切触れていません。文字集合に絡まない部分については個別にご確認ください。

携帯サイトを UTF-8 で作りたくて au ブラウザのバージョンを調べてみた

Sun, 18 Sep 2011 23:00:41 +0900

現在構築中のシステム、全体的に文字コードは UTF-8 で統一するつもりだったのですが、携帯電話用のサイトは Shift_JIS で表示する流れになってしまったようで。UTF-8 で統一できると何かと楽なので、携帯電話が UTF-8 に対応してそうか情報を集めてみました。

結論ですが、サイトの特性によるので一概には言えなそうです。

まとまった情報

auブラウザ、いまだにUTF-8が使えず！ | 株式会社シンメトリック公式ブログ - 携帯開発から生まれる技術情報

2010-09-09 時点の情報で、見つけた中では一番詳細な比較になっていました。表示が正しく行われているかだけでなく、SSL 対応やパラメータの文字化けについても言及してされています。まとめを抜き出すと、

docomoとSoftBankはUTF-8に完全対応できているが、auは最新ブラウザ（バージョン7.2）ですら完全に対応できていない！しかもauはブラウザバージョンやSSLかどうかなどの要因で何やら複雑に変化している。

とのことで。

最近の au 端末にはブラウザ ver7.2 と ver6.2 の二種類がありますが、UTF-8 でサイトを構築した場合、

ブラウザ ver7.2 の場合
- XHTML のコンテンツであれば動作に問題なし
- HTML のコンテンツでは、非 SSL 通信時に GET 送信のパラメータが Shift_JIS で送られる
ブラウザ ver6.2 の場合
- XHTML や SSL を使用した場合正しく表示されない
- HTML で非 SSL だと表示は正しく行えるが、GET 送信のパラメータが Shift_JIS で送られる

といった感じみたいです。

パラメータが Shift_JIS で送られてくるのはプログラム側で対策できるし、HTML/XHTML どちらを使うかもこちらで選択できますが、EC サイトなんかを運営する場合は SSL が使えない（＝ユーザがサーバの正当性を確認できない）のは致命的です。今回のシステムはまさにそういうケース（SSL を使いたい）なので、サポートする端末に ver6.2 のものが含まれる場合は UTF-8 でのサイト構築は諦めるしかなさそうです。

（補足1）SSL 未使用でよければ・・・

もし構築するサイトが SSL 未使用でよければ、コンテンツを HTML で作成し、au 用に Shift_JIS の処理を入れることで UTF-8 でのサイト構築は可能なようです。この場合の注意点等については下記の 2 サイトが参考になりそうでした。

ケータイ飲食検索、au・ソフトバンク端末に対応｜blog｜たたみラボ

2007-02-26 時点の情報。au は Shift_JIS で送られてくるので対策として以下のような処理を入れたとか。
mb_convert_encoding($_GET["Keyword"],'UTF-8','UTF-8,SJIS')
「メモ」携帯サイトをUTF-8で出力する方法とSEO評価 - komoriyaのはてなダイアリー

2009-08-19 時点の情報。SEO 的にも問題なかったとか。

「サイトのリニューアルの際にShift_JIS -> UTF-8をやってみたんですけど、リニューアル前後でのAU Googleの検索流入数、INDEX数共に減少することなく、いくつかの最適化も行ったことも加えて増加傾向にあります。」
（補足2）ブラウザバージョンについて

バージョン 7.2 といわれる端末の UserAgent を見ても「UP.Browser/6.2〜」となっていて不思議だったんですが、ここのバージョンが「UP.Browser/6.2_7.2.〜」のものがバージョン 7.2 にあたるそうです。

テクニカルノート | 実機検証の現場から | 株式会社KSK フレックス・ファームビジネスユニット

また、従来端末（KCP 等）が 6.2 以下で、KCP+ 端末が 7.2 とのことです。

ブラウザバージョンを調べてみる

サポート対象の機種を「○年○月以降に発売のもの」だとか「過去○年以内に発売のもの」と決めて、うまいこと ver7.2 の端末までに絞り込めれば、UTF-8 でサイト構築してもよさそうなので、ここ数年発売されている機種のブラウザバージョンを調べてみました。
調査には以下のデータ（2011-08-25 版）を使用しました。

ケータイ端末プロファイルデータ（無償版）
- →サービス | 株式会社ウェブレッジ（移管先）

また、冒頭のサイトのブックマークで

id:tailtame Mobile, tips
「UP.Browser/7.2」でちょっと調べたら今度の800MHz帯の周波数再編で全部UTF-8対応携帯になるのか…もうちょっとだなぁ。

とありました。800MHz帯の再編により、新800MHz帯が利用できない機種は 2012年7月24日以降に使えなくなるという話のようで。

800MHz帯の周波数再編に伴う「CDMA 1X」などのサービス終了等のお知らせ〈別紙〉 | 2010年 | KDDI株式会社

に端末の一覧があったので、この情報も集めてみることにします。こちらについては 2006/12/15？発売の W47T が「au初のトリプルバンド（L800(在来800)MHz、N800(新800)MHz、2GHz）端末」とのことなので、これ以降の端末だけ情報を集めれば十分そうです。

（2012/08/06 追記）
わざわざ調べてしまいましたが、

機種情報一覧：：携帯向け開発者のための機種情報サイト：： KEITAIALL：ケータイ・オール

こちらで

キャリア: au
発売日: >2006/12/15

としてフィルタして、発売日でソートすれば同じ情報が最新の状態で見られます・・・。
（2012/08/06 追記ここまで）

調査結果

各月に発売された端末を分類すると、こんな感じになりました。これ以前の機種はすべて新800MHz非対応機種 or ver6.2 の機種でした。なお、スマートフォンは対象に入っていません。

まず、新800MHz 対応機種にも ver6.2 のものは多数あるようで。残念ながら「2012-07-24 以降は何も気にせずに UTF-8 でサイト構築できるようになる」とは言えないようです。

次に、最近発売されている機種はほとんど ver7.2 ですが、まだちらほらと ver6.2 が残っています。とはいえ、2009年11月以降に発売されている ver6.2 の機種はフルブラウザ非対応機種で、

簡単ケータイ
ジュニアケータイ
ビジネス用（あえて機能制限している）
800MHz帯周波数再編の代替機で、主に通話とメールだけの機能に集約している（P002）

とわけありの品ばかりなんですよね。KCP - Wikipedia にも以下のような説明がありました。

このため、2010年度以降に新規開発された従来のKCPに対応した機種は前述の通り、SANYOブランドおよびKCP+／KCP3.x対応機種[2]を除く京セラ全機種、および簡単ケータイS PT001[3]を除く韓パンテック全機種に見られるのみとなり、事実上、KCP対応機種は初心者向けおよび高齢者向け、児童向けにそれぞれ整理されつつある。

これらをどう扱うかが問題で。「わざわざこういう機種を選ぶくらいだから、ブラウジングはしない人たちでしょ」と切り捨ててしまえるサイトもあるでしょうし、逆にこういった層を対象にしているサイトであれば「見られない場合はフルブラウザで見てね」という逃げも打てず、サポート対象にせざるを得ません。本当は利用者の割合とか調べて決めるのがいいんでしょうね。

今回のサイトは携帯電話でのアクセスがかなり多いですし、Shift_JIS で表示する方針も妥当そうなので、おとなしくそれに従うことにしました。まあ方針に納得できたのでよかったです。