@jsakamoto

Haskell で Fizz-Buzz 問題を解いてみる

関数プログラミングもとんとご無沙汰だったので、リハビリから。
とういうことで、Fizz-Buzz 問題を Haskell で解いてみる。

main = putStrLn $ unlines $ map fizzBuzz [1..100]
　where fizzBuzz n
　　| mod n 3 == 0 && mod n 5 == 0 = "FizzBuzz"
　　| mod n 3 == 0 = "Fizz"
　　| mod n 5 == 0 = "Buzz"
　　| otherwise = show n

1から100までの数値のリストに対して、各要素ごとに fizzBuzz 関数を適用。
fizzBuzz 関数は文字列を返すので、結果、map 関数の戻り値は "文字列のリスト" となる。
これを、改行を区切り文字として単一の文字列に連結 ( unlines ) して、結果をコンソールに表示 ( putStrLn ) ... するアクションを返して main の評価により実行。

いっぽうの fizzBuzz 関数の定義は、ガード ( | ) によって、引数の数値 n が3の倍数か5の倍数かに応じて "Fizz" や "Buzz" などの文字列を返し、いずれの倍数でもない場合は、数値 n をそのまま文字列に書式化 ( show ) して返す。

とまぁ、こんな感じか?

ガードの判定が冗長だな。"Fizz" と "Buzz" を連結して "FizzBuzz" にするほうがいいのかも。

F# や Prolog ではどう書くのだろう、Fizz-Buzz問題。

2010/02/09 追記

Fizz-Buzz 問題ではないが、「世界のナベアツ」問題を同じく Haskell で解いておられる方がいらっしゃった。
http://d.hatena.ne.jp/zecl/20080515/p1


また、F# での Fizz-Buzz 解法については、検索してみると上記と同じ方を含め、数件ヒットする。
http://www.google.co.jp/search?q=F%23+Fizz+Buzz

T-SQL の LIKE 演算子でパターン検索、ワイルドカードはどうエスケープする? - SqlHelpers が使える!

LINQ to SQL や ADO.NET Entity Framework / LINQ to Entity などの登場により、コード上で文字列として SQL 文を組み立ててクエリ発行、といった実装はめっきり減りつつあるのかもしれない。そもそもストアドプロシージャにすれよ、という話もあるが。

しかし、それでも、そんなアドホックなクエリを発行したい場面はゼロじゃない。
動的LINQなどでも WHERE 節を文字列で渡すことになるし、LINQ to SQL の .dtml を起こすほど大仰にやりたくないときだってある。

さてそんなとき、悩ましいのが、LIKE 演算子を使ったパターン検索。

SQL文を、

　SELECT * FROM Hoge WHERE Foo LIKE @p0

として、パラメータ @p0 に "%Bar%" と指定してクエリ発行すれば、「列 Foo に "Bar" という文字列を含む行」が返されるわけだ。

しかし、「列 Foo に "%" という文字を含む行」を取得したい場合はどうする?

文字 "%" はすでに LIKE 演算子によるパターン検索上のワイルドカード文字である。
したがって、何らかのエスケープシーケンスが必要となるのが正解。

SQL文を、

　SELECT * FROM Hoge WHERE Foo LIKE @p0 ESCAPE '~'

とすれば、文字 "~" がエスケープ文字として機能するようになる。
よって、パラメータ @p0 に "%~%%" と指定してクエリ発行すればよい。

となると、残るは、どうやってパラメータ @p0 に渡す検索語句をエスケープ処理するか、だ。

ものすごく難しいわけではないのだろうが、自分でスクラッチでエスケープ処理を行うコードを自作するのもなんだかなー、と思ってしまう。
それに、この種のコードは、すでに実績のあるコードを再利用できるものなら再利用すべきだろう。

目をつけたのは LIQ to SQL のコード。
LINQ to SQL も、内部ではこのようなエスケープ処理を施した T-SQL 文をアドホックに組み立てて発行しているのだから、LINQ to SQL の内部をのぞき見れば、エスケープ処理をどうやっているのかわかるはず。

そう思い立って、ソースでもひもといてみようかとしたが、いやいや、はやる気持ちを抑えて、msdn library を少し眺めてみることにした。

そうしたところ、運良くすぐに目に飛び込んできたのが、System.Data.Linq.SqlClient.SqlHelpers クラス。
次のように、SqlHelpers クラスの static メソッドを呼び出してやれば、

　SqlHelpers.GetStringContainsPattern("%", '~')

"%~%%" という文字列が手に入る次第。
ワイルドカード文字 "%" をどこに挿入するかにあわせて、GetStringStartsWithPattern メソッドと、GetStringEndsWithPattern メソッドも用意されている。

"%" 以外の、"_" などのワイルドカード文字も組み合わせてより精緻な検索を行いたいときはさすがに SqlHelpers のメソッドでも歯が立たないが、しかし、上記 Contains/StartsWith/EndsWith の3パターンで事足りるのであれば、ちゃんと "_" などもエスケープされる。

SqlHelpers のこの3メソッド、万人向けじゃないかもしれないが、いざというときには必要となる "武器" だ。

Internet Explorer でのダウンロード時、既定のファイル名の空白が "+" に化けてしまう

本業多忙につきとんと2ヶ月も無沙汰にしてしまったブログだが、ぼちぼちと再開。
リハビリがてら軽めのネタから。

先々月の最後の投稿、「Internet Explorer 6 でのダウンロード時、既定のファイル名として日本語使うと16文字にカットされてしまう」の類似ネタである。

Webサーバーからの応答ヘッダに、content-disposition: attachment; filename=～ を指定することで、Internet Explorer (以下、IE) はじめ各種Webブラウザにダウンロードダイアログを表示させることができるのは周知のとおり。

特に IE においては、UTF-8エンコードされた文字列を、URLエンコードした形式で、filename=～ に指定してやれば、既定の保存ファイル名に日本語を指定することもできる。

そんな実装を、ASP.NET による Webアプリで実装していたら、とある日、不思議な現象を発見。

既定の保存ファイル名に空白を含む場合、なんと、IE のファイル保存ダイアログには、空白が "+" に化けたファイル名が表示されるのだ。

いや、"化ける" とは言ったが、厳密には、たしかに "+" は空白を URL エンコードした結果には違いない。
言い換えると、ほかの文字列(とくに日本語文字など)はちゃんとURLデコードされているのに、"+" だけはデコードされないようなのだ。

手元の環境では、IE 6 でも IE 8 でも現象は同じ。
まぁ、これはそういうものなんでしょう、IE の仕様なんでしょう。

ということで、空白をURLエンコードするには、"+" とする以外にもうひとつ、"%20" とすることもできる。
試しに、finelame=～ に "%20" を含む文字列を指定したところ、IE 6/IE 8 でも、ちゃんと %20 は空白にデコードされて、ファイル保存ダイアログに表示された。

しかししかし。
HttpUtility.UrlEncode メソッドを使って URL エンコードしていたのだが、どうも、このメソッドは空白を "+" ではなく "%20" にエンコードできるようなオプションはないらしい。

致し方ないので、

HttpUtility.UrlEncode(fileName).Replace("+", "%20");

というように、エンコード後の文字列に対して、愚直に string.Replace メソッドで置換を行うようにした。

なんだかなー、という気がしないでもないが、これにて収めることにした。

なお、某所から教えて頂いたところでは、CodePlex 上で公開されている、AntiXSS というライブラリを使えば、空白を "%20" で URL エンコードできるそうだ。

まだ使ったことはないが、ソースコードを見るに、

AntiXss.UrlEncode(string)

でURLエンコードできるようなので、使い方に迷うことはなさそうだ。
こだわる向きは、AntiXSS ライブラリの採用を検討するのもよいかもしれない。