dev >> Others

XHTML で見た目を変えず Excel ダウンロードさせよう

THREE-ONE — Mon, 01 Sep 2008 16:35:00 GMT

たとえば、こんなテーブルがあったとして。

品目	コード	金額	仕入日
モニタ	001	100,000	2008-02-11
キーボード	002	5,000	2008-02-12
マウス	003	2,000	2008-02-13

HTML を Excel としてダウンロードさせると、下記のようになります。（環境やバージョンにより異なるかも）

品目	コード	金額	仕入日
モニタ	1	100,000	2008/2/11
キーボード	2	5,000	2008/2/12
マウス	33	2,000	2008/2/13

CSV などでも同様ですが、001とかは数値とみなされて1になってしまうのですね。
この場合だと、日付の形式も若干変えられています。
これでは困る。画面に表示されているのと同じ形式で表示したい！！
そんな場合、下記のような (x)html をダウンロードするようにすれば OK。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:x="urn:schemas-microsoft-com:office:excel" xml:lang="ja" lang="ja">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  </head>
  <body>
    <table>
      <thead>
        <tr>
          <th>品目</th>
          <th>コード</th>
          <th>金額</th>
          <th>仕入日</th>
        </tr>
      </thead>
      <tbody>
        <tr>
          <td x:str="モニタ">モニタ</td>
          <td x:str="001">001</td>
          <td x:str="100,000">100,000</td>
          <td x:str="2008-02-11">2008-02-11</td>
        </tr>
        <tr>
          <td x:str="キーボード">キーボード</td>
          <td x:str="002">002</td>
          <td x:str="5,000">5,000</td>
          <td x:str="2008-02-12">2008-02-12</td>
        </tr>
        <tr>
          <td x:str="マウス">マウス</td>
          <td x:str="003">003</td>
          <td x:str="2,000">2,000</td>
          <td x:str="2008-02-13">2008-02-13</td>
        </tr>
      </tbody>
    </table>
  </body>
</html>

Excel で html 形式で保存するときに出力する形式から一部ぱくって来ただけです。
x:str 属性の値が表示されるので、td タグの内容は空になってもかまいません。
ただし、これをすると当然文字列として扱われるので、Excel のそれぞれのデータ形式の恩恵を受けたければ、その部分だけ外してやりましょう。
offiec 2000, XP, 2003 では大丈夫のはずです。
2007 でも、xls ならば警告は出るものの開いてくれます。
ですが、拡張子を xlsx にすると警告だけ出して開いてくれません。容赦なくお断りされます。
素直に OOXML を使えということでしょう。

万能ではありませんが CSV なんかでダウンロードするぐらいなら、HTML でダウンロードした方がはるかにマシです。
CSS である程度見た目をいじれるし、このように Excel 独自の問題も回避できたりします。
サーバに Excel 入れたくなくてもかまいません。条件は CSV と同じです。
各地の CSV の仕様のあいまいさを考えると、こっちの方が共通ライブラリ化しやすいかもしれません。
CSV はグリッド形式しか表現できませんが、HTML なら他の形式だって表現できます。
文字列でゴリゴリ組むなら、HTML の方がしんどそうですが、DataTable.GetXml() と XSLT でコードも簡潔です。
なおかつ、テンプレートとして外出しできます。
転送量の増大はどうしようもありませんが・・・・・

というわけで、さっさと CSV ダウンロードは消えてしまえキャンペーンでした。

[追記]
ちなみに、下記は残念ながらダメなんだよね。
テーブルと認識してはくれるのに、x:str 属性は認識してくれない。
だから、x:str 属性がない場合と同じ表示になってしまう。

タブのポイント

THREE-ONE — Wed, 20 Aug 2008 16:07:00 GMT

使いやすいタブ型ナビゲーションの5つのポイント(コリス)

大事ですね、こういうの。
常に全部満たさないとダメってわけじゃないですが、気にしておきたいです。
というわけで、メモ

# ただ、アクティブタブの文字を差別化するのはわかるけど、見にくい色にするのはサンプルとして微妙じゃないかと。
# 私はよくアクティブタブだけボールドにするかなぁ。

とりあえずメモ

THREE-ONE — Thu, 31 Jul 2008 09:17:00 GMT

http://itpro.nikkeibp.co.jp/article/COLUMN/20080730/311764/

Flexigrid には DOCTYPE を書こう

THREE-ONE — Thu, 24 Jul 2008 15:30:00 GMT

後々使う予定の Flexigrid をちょっといじっていた。
が、なにをいじっても中途半端に表示される。
ヘッダ部分の背景色が body のままだったり、showTableToggleBtn オプションでのトグルボタンの位置が微妙にずれたり、横スクロールバーが表示されなかったり、列表示選択のパネルがすぐ消えてクリックしにくかったり。
基本的な機能はちゃんと使えているんだけど、本家サイトのような感じにならなかった。
あれこれやってわかった原因は DOCTYPE を書いていなかった。
ちなみに XHTML でなくてもよいようだ。
たとえ初期検証であったり、遊びがてら軽く評価しているだけだとしても、やるべきことはしっかりやっておかないと、せっかく有用なものを逃してしまうかもしれないな。

BOMはいらない子？

THREE-ONE — Sat, 15 Mar 2008 01:17:00 GMT

net start "coLinux"
たったこれだけのバッチが動きませんでした。
原因は、UTF-8で保存してて BOM がついていたから。
UTF-8 の BOM っちゅうのはちょくちょく問題おこしやがります。
少し前は Java との連携でひっかかったり（昔は Java は BOM を認識しなかった）
そもそも UTF-8 にBOM が必要かって話もありますわね。
基本、BOM 付きの UTF-8 をテキストエディタのデフォルトにしているので、結構 BOM の認識エラーは出くわします。
BOM は UTF-8 にはいらない子なんでしょうか・・・・

ちょっとがんばって

THREE-ONE — Wed, 12 Mar 2008 01:43:00 GMT

あまってるデスクトップをちょびっといじって勉強用に自宅サーバでも立てようかと思いました。

CPU ファンがうるさいので新しいのを買ってきました。

少し大きかったので、ペンチで出っ張りを引きちぎりました。

よくわからない引っかかりがあったのですが強引に取り付けました。

動かなくなりました・・・・・・・orz

諦めてホスティングにするかなぁ

それともやっすいデスクトップ買ってがんばろうかな？

コレとかどうなんだろ？

後悔先に立たず

THREE-ONE — Wed, 20 Feb 2008 22:21:00 GMT

来週 Vista ノートが届いたら、メイン開発環境を移行することになるので、ついでに Visual Source Safe 2005 を買った。
年末に Visual Studio 2005 Standard Edition なんて買わずに、Visual Studio 2005 Professional with MSDN Professional Subscription にすればよかったと思った。

どうやらハンガリアンだったらしい

THREE-ONE — Tue, 12 Feb 2008 20:51:00 GMT

コチラのコメントでＲ・田中一郎さんが wikipedia でのハンガリアン記法の項目をのっけてくださいました。
んで、うすうすは感づいていたのですが、私の C# での流儀である「プライベートなメンバ変数にはプレフィクスとして "_" をつける」というのは立派なシステムハンガリアンなわけです。
好きじゃないといっていたシステムハンガリアンを好んで使用していたのです。ちょっとショックです。
というわけでもうシステムハンガリアン・アプリケーションハンガリアンとかどうでもいいです。
「型をプレフィクスとする命名規則は好きじゃない」という主張にします。
ああ、もうややこしい。

ハンガリアンについてつれづれ

THREE-ONE — Tue, 12 Feb 2008 18:36:00 GMT

ネタ元

私もハンガリアン記法は好きではありません。
理由は「ほとんどのハンガリアン記法は既存の型のことしか考えてないから」です。
とある ASP.NET のプロジェクトではハンガリアン記法が採用されていたのですが、こんなルールがありました。

ユーザーコントロールのプレフィクスは uc
カスタムコントロールのプレフィクスは継承元のコントロールと同じ

ハンガリアン記法とは、一目で型を知れるのが利点なんじゃないんでしょうか？
型を知れば、振る舞いや扱い方を想像することができます。
uc とついてればユーザーコントロールなのは理解できます。
具体的にはどんな型なのでしょうか？役割は？ボタンですか？リンクですか？
そこから振る舞いや扱い方を想像できますか？
カスタムコントロールを継承元と同じプレフィクスにしたら、混在したときにどうするんでしょうか？
どう考えてもハンガリアン本来の役目を果たしているとは思えません。

コントロールから抜けて、新規にクラスや構造体を作ったとします。
そのつど、プレフィクスを決めなければなりません。
時間の無駄です。
既存のデータ型しか扱わず、それだけで成り立っていたころはハンガリアンは便利だったかもしれません。
しかし、型を増やせば増やすほど崩壊していくハンガリアンは、現在主流のオブジェクト指向やコンポーネント指向と親和性が低いように思われます。

ネーミングルールやコーディング規約は採用する技術によって様々です。
たとえば私が最近勉強している Ruby では変数の最初の文字が @ だと private フィールドになります。
最初の文字が大文字だと定数として扱われます。
そんな環境ではさすがに @m_Name とかしませんよね？

コーディング規約というものは、技術を選定したときにたいてい新たに書き起こされます。
そんな時にわざわざ別の技術で使用していたルールを持ってくるのは不自然です。
せっかく新規に技術を選定したわけですから、社内標準ではなく、もう少し目を広げて一般標準を取り入れてほしいものです。
いくら、それまで社内標準だったとはいえ、教育コストがそんなに低くなるとは思えません。
デファクトスタンダードを採用することによって、それこそ中途参加者や新規参入者への教育コストが低くなると思います。
そもそも、ほとんどのハンガリアン利用者は、それがデファクトスタンダードだったから利用しはじめたんじゃないんでしょうか？

つまるところ、ハンガリアンがどうこうではないのです。
技術を取り入れる際に、仕様や手法だけでなく文化も取り入れようということです。
ほとんどは、これから文化を作り上げるパイオニアではないのです。
あらゆる会社がデファクトスタンダードを利用すれば、きっと幸せです。理想論ですが。

[追記]ここでいうハンガリアンはいわゆるシステムハンガリアンを取り上げています。
[追記]とか言っていましたが、自分がシステムハンガリアンを好んで使用していました。

気づいたら 200 超え

THREE-ONE — Fri, 01 Feb 2008 15:14:00 GMT

気づいたら Google Reader の登録フィードが 200 超えてた。
友人の blog とか趣味の blog はたぶん 5% に満たないので、ほとんど技術系の blog か情報発信。
もちろん、全部がわっせわっせと活性化しているわけじゃないけれども。
そりゃ、blog チェックに時間かかるわけだ。
コレでも技術は絞ってるんだけどなぁ。
.NET, XML, Ruby ぐらいか。あとはわんくまと IT 系総合情報発信。
でも、200 ぐらいどーなんだよ。たいしたことねーよ。って人もたくさんいるでしょうな。
ホントにこの業界の人は、情報発信・情報収集に余念がないなーと改めて尊敬します。