ねこめしにっき(2003年5月中旬)

2003年5月19日

Finder Scripts (2003/05/19 - 22:18)

ちうわけで、自分で使う用にテキトーに書いた OSX 10.2 Finder 用 AppleScript たち。 Script Menu から呼び出してとっとと使うとよさげ。

以上、完全無保証・現状渡し。何の確認も無しにイキナリ削除動作したりするんで取り扱い注意。Script Menu で使うなら、Script Editor にペーストして「コンパイル済みスクリプト」で保存して、所定の場所 (~/Library/Scripts/ 下など) に置くべし。 Script Menu のべんりな使い方は、Tales about Apple (2003/05/04) 記事「アプリ毎でScriptMenu」など参考に。

上記スクリプトのいくつかは、対象フォルダへのパスに日本語が含まれてる場合、 OSX に元から入ってる標準の tcsh だとうまくいかんと思われ。ウチはマルチバイト文字対応版 tcsh を使ってるので、そゆ場合でも何事もなく上手くいってる。

この程度のシェルコマンド、コマンドラインでシコシコ打てばいいじゃんとかいう向きもありますがー、そゆのがウゼェとかメンドクセーとか思うからマカをやっているわけなのです。ハイ。 SMB ボリュームの .DS_Store や ._hoge 等の「ゴミファイル」を消す作業については、そゆシェルスクリプトを cron で動かしとけばイイ気もするけど、なんとなしに任意のタイミングや場所で実行したいなと、こういうカタチで使用してる次第ー。

ネットワークボリュームの Finder マウントにまつわる不平不満 (2003/05/19 - 21:50)

MacOSX で Windows を SMB マウント
理由はわからんけど不安定。100BaseTX の LAN なのに転送速度が 200kbps しか出なかったり、Finder がお亡くなりになったり、転送途中のファイルはエクプローラで見えてたのに転送完了した瞬間に消えたり。勘弁してください。

[ はじめての Mac - 千熊屋ウラ日記 (2003/05/14) より ]

えー、その他にも、ウィンドウズ側で SharedDocs フォルダにファイルを追加してもマック側に反映されないとか、._.Trashes といったマックの都合によるファイルが作られるとか、マウント中にウィンドウズ側を落とすと固まってリセットする羽目にとか、もろもろのオプションもついてきます。わははは。

[ お笑いパソコン日誌 (2003/05/16) より ]

たしかに OSX の Finder で Windows の SMB をマウントして、いろいろとやってるといろいろな怪現象が起きがち。特にイヤンの筆頭は「マウント中の Windows 共有フォルダの共有が切れるとドツボ」。マウント中にウィンドウズ側を落とすと固まってリセットする羽目に。こいつだけはアポーへ鬼の激怒フィードバックを投下しつづけて早いトコなんとかしてもらわんと…。

あでも、同じ 100BaseTX な LAN のウチでは、転送速度は調子がいい時だと(笑。ってか巨大な単一ファイルの転送とかの好条件下) 40Mbps くらい出てるっぽいです。エクプローラで見えてたのに転送完了した瞬間に消えたりの怪現象も見たことないです。たぶん。…たぶんかよ。

ネットワークボリュームの Finder マウントは、あっち側で新しくファイルが増えたり消えたりしても、 Finder 上の表示がどうにも更新されにくいのが OSX 10.2 の現状だったりしてますやね。そもそも 10.1.x の頃の Finder なんか、ローカルボリュームのフォルダでさえ異様に鈍感だったとゆー。そこだけは 10.2 でだいぶ改善されたみたいけど。まだ時々鈍感。しっかりしてください。

マウントした SMB ボリュームとかは当然 HFS ファイルシステムじゃないゆえに、マクファイル固有のリソースフォークを保持できないわけで、なんというか AppleDouble 的というか、ともかくリソース部分を分離した隠しファイルのカタチで保持するしかなくて。んでそういう ._hogehoge なんてファイルが大量生産されちゃったり。ウゼェ。いや生粋マカとして、リソースフォークの利便性と価値とカッコヨサは重々理解してるんだけど、時と場合によってウゼェもんはウゼェのであった。 Win 機へ投棄する(あるいは逆にマクへ投棄される)データなんて、当家ではほぼタンスのコヤシ系の画像データとか動画なわけで、リソースフォークはあっても無くてもほぼ無問題だからして。

…まぁ、不平不満や揶揄の羅列だけでは無価値情報になってしまう(毒)とは思っても、スキルレスな自分にカッコイイ解決策を提示することなんか、できないわけなのだけど。でもまぁいちおう日曜スクリプターなりに「Finder Scripts」あたりで対症療法をしてはいる次第。

2003年5月18日

ブックマークレット作成関係のメモ (2003/05/18 - 08:20)

それとなしにメモ。

んで、上記経由でこんな記述を見たり。

Note that the entire javascript: URL should be as compact as possible. Long javascript: URLs tend to generate errors or crash the browser. We suggest that you stick to a maximum of about 500 characters.

[ Bookmarklets: The "javascript:" Protocol - www.docjavascript.com より ]

んなこと言われてもねぇ…。どうせ 500 文字以内に収まらない巨大スクリプトなんだから、可読性を鑑みて富豪な変数名とか関数名とか使いまくりのままでいいや、な次第。あ、 Camino べんりセットの事。

2003年5月17日

- (2003/05/17 - 06:00)

きょうは昼から親友のケコーン式に披露宴から出席でして。いいかげん寝ないとピンチー。

- (2003/05/17 - 02:41)

なんか Win ましんのサブ HD がときどきギョギョギョとかいう異音を出して、気が付けばファイルが壊れているー。そろそろだめっぽい。

style 要素/属性における文字参照 (2003/05/17 - 01:41)

CSS における文字参照の記述法」の続き。

いやもう、Opera なんて持ってないし、Mozilla でも試してないけどぴんときまくりですよ。察するに text/html で style 要素の内容に文字参照を書いたんじゃないでしょうか?

HTML4 では、style 要素の中の文字は全て単なる文字データ (CDATA) として扱われることになっています。つまり、<style type="text/css"> p:after { content:"&#9829;"; } </style> などと記述しても、各段落の末尾に &#9829; という文字列が付加されるだけです。ちなみに、XHTML では style 要素の内容も通常の PCDATA として解釈されるので、こういう記述をすれば段落末尾に が付加されることになります。

[ マーク付けノート (2003/05/15) より ]

ふむー。はてなダイアリー (HTML4.01 Transitional) において、 style 要素を使って HTML 中に直接 CSS を記述した際の話だったのかー。とすれば、 style 要素内容に書いた HTML の文字参照を解決しちゃったらしい WinOpera7.11 は「やりすぎ」という結論で。

そういえば CSS2 仕様書にこういう事が書いてあるですね。

HTML4.0では、style属性に用いる数値文字参照は展開されるが、STYLE要素の内容に用いる数値文字参照は展開されない。 この不整合を考慮して、style属性とSTYLE要素の両方で、数値文字参照よりもCSSのエスケープ文字を用いるよう推奨する。

HTML4 では style 属性style 要素も CDATA 型なワケですが、同じ CDATA であるのに文字参照の扱いが属性と要素で違うのは何、てあたりは以下を参照ってことでいいのかなぁ…。

…まぁ途方もなくワケワカラン事に巻き込まれそうなので、いついかなる時も、 CSS の記述をする時には CSS のエスケープ文字で文字参照を行って万難を排する方向で。

さらに、石川さんの解説によると、text/html (HTML4.01 Transitional) なソースを生成するはてなダイアリーでは、content にエスケープ文字は使えない or 使わない方がよいという結論になるのかなぁと。

[ content に文字参照を - らぶらぶだいあり (2003/05/15) より ]

えっと…。 HTML4.01 Transitional だからはてなダイアリーでは、content にエスケープ文字は使えない or 使わない方がよいという結論ってのは、何かズレてる気がするのですけど。エスケープ文字ってのは CSS のエスケープ文字、の意ですよね?)

「はてなダイアリー固有の一連のセキュリティ対策によって、 CSS エスケープは妙な置換(あるいは削除)されてしまうから使えない」ってのが正解じゃないのかな。「 HTML 4.01 Transitional だから」ではなくて。はてダーのそこらへんの事情はまるで知らないんですけど。

2003年5月15日

CSS における文字参照の記述法 (2003/05/15 - 18:12)

(´-`).。oO CSS で content の内容に文字参照を入れたい場合はどうしたらいいんだろう。Opera ではうまくいったけど、Mozilla ではダメだったよ…

[ love all ... personal memo ... より ]

えーと。一言で「文字参照」と言っても…。 HTML 的用法で言うトコロの「文字参照」の事かな。そのばやいは「数値文字参照」「文字実体参照」の二つに大別されてるわけでして。

んでもって、 CSS2 仕様書には以下のようなくだりがありまして。

場合によっては、現行の符号化方法では表現できない文字をスタイルシートに書き込む必要がでてくる。これらはISO10646文字集合を参照するエスケープ文字として記述しなければならない。この方法はHTMLやXMLでも数値文字参照として採用されている

[ 4.4.1 符号化できない文字を参照するには - REC-CSS2 邦訳 より ]

CSS2では、バックスラッシュ(\)に3種類のエスケープ効果がある。

(略)文書作成者が容易に打ち出せない文字を参照することもできる。この場合、バックスラッシュの後ろには、[ISO10646]の文字コードを表す16進数が続く(略)

[ 4.1.3 文字と活字ケース - REC-CSS2 邦訳 より ]

てなわけで、くだんの話が「 CSS 中で HTML 式の文字参照記法を使ったけども Mozilla では解釈されなかった」という物であれば、それは別段おかしな話じゃ無いかと。いや、 Opera がそういう妙な記述を解釈できるとしたら、それはそれで困った話。

うーんしかし…。試しに p:after { content : "&quot;" } とか p:after { content : "&#x22;" } とか p:after { content : "&#34;" } とかやってみたけど、Mozilla はもちろんの事、 Win 版 Opera6.05 でも MacOSX 版 Opera6.0 でも無効だなぁ。p:after { content : "\22" } は双方当然 OK だけど。いったいどういう形式の文字参照が、 Moz でダメで Opera で OK なんだろう。具体例を示してもらわないと資料的価値が。

style 要素/属性における文字参照 へ続く。

2003年5月14日

CSS なサイトをサムネールでドババ (2) (2003/05/14 - 04:40)

CSS なサイトをサムネールでドババ (1)」のつづき。

アクセス数が爆裂してるのは、俺ニュースその他でリンクされたことによってリンク集そのものへのアクセス数が爆裂しているから、というのが真相かと。

[ antipop より ]

なるほどー。実はいわゆるニュース系サイトってトコはあんまり見てない人なので、そういう事態になってるとは気づいてなかったのでありました。

御察しの通り WinIE6 を操縦してサムネール生成してる らしく、outsider reflex が XML パースエラーになったりしちゃって、御指摘を受けて慌てて修正したりもしたので、gecko エンジンをいじり回して、web server 上に gecko を置いて、レンダリング結果を画像バッファーにしてはいて、それを縮小 するプログラムを、どなたか…とか思いました。

プログラムっていうか、AppleScript でやってみた。非プログラマーでヘタレ日曜スクリプターでマカーでごめんなさいヒマ人ですいませんって感じ。ていうか、自分でも身の毛のよだつ、ものすさまじい力ワザで実現されているとゆー。

  1. サイトリストファイルを読む
  2. リストにある URL を Camino で開く。スクリーンショットを上手いこと撮るために、ツールバーもステータスバーもない、窓サイズも位置もバッチリ決め打ってある新規窓で開く。
  3. でも純 AppleScript でそういう窓を開くのは Camino にはまだ不可能っぽかったので、 javascript:window.open 〜 なる URL を開かせる作戦に出た。
  4. しかーし、 Camino がページをロード完了したかどうかを AppleScript 側から知る術なぞ無いので、とりあえず Camino に一連の処理を投げたらボーッと 3 秒待ってみる。3 秒以内に表示完了しなかったサイトは、その中途半端な画面のままサムネールが作られちゃうというオチ。ひでぇ。
  5. ともかく 3 秒経過したら、 AppleScript から /usr/sbin/screencapture -c なるシェルコマンドを発射。これで画面全体のスクリーンショットがクリップボードに格納されまする。
  6. 撮ったショットは GraphicConverter という超有名な定番シェアウェアで処理してみることにしますた。
  7. クリップボードから新規画像を作って、ガコッとページ表示部のみを切り抜き(このために Camino 窓のサイズや位置をキリキリに決め打ちする必要があった)、縮小リサイズして、 JPEG でファイル保存。
  8. それをしながら HTML (の断片)を書き出し。
  9. 終戦

…ああメチャクチャ。んでそこは AppleScript だもんだから、動作が遅くて遅くて。ついでに上記の事情で 3 秒の待ち時間もあるわけで。たかだか 36 サイトのサムネール作成に 5 分くらい掛かってたりして。しかも処理中は、次々に画面全体のスクリーンショットを自動撮影してる関係で、 Camino 窓は常に最前面にあったりするし、ショットに余計なモンが写り込む可能性とか考えると、他の作業はな〜〜〜〜んも出来ない、という。ひどすぎ。実用性無し。寝る前に仕掛けとけ、の世界。ダメダコリャ。

やっぱ本職のプログラマァ様にお願いするしか。

Webnail AppleScript」に続く。

2003年5月12日

CSS なサイトをサムネールでドババ (1) (2003/05/12 - 22:05)

壮観。そしてこーやって並べられちゃうと、自分トコの見てくれのショボさに改めて気づいてみたりとか。いや、パッと見のインパクト勝負はしてないとか、パパ強がっちゃうもんねー、みたいな。

それよりも、ここからのリファが、昨日あたりなんか一日で 1000 オーバーしてたりしてビビった。 TINAMI やサーパラの登録情報を更新したならともかく、 HTML/CSS 関連の生身の人間がウチのトップパゲへこんなに来るハズもないわけでして。誰ぞがこのサムネール一覧ページにアクセスするたびに、サムネール収集アクセスしてるのかな。解析 CGI 呼び出し画像は JavaScript で生成してるのに、アクセスが記録されてるのは、 WinIE6 を操縦してサムネール生成してるんスね。そのアクセス数も爆裂してるし。あちこちのサイトのサムネールも WinIE6 の時のモノのようだし。

いや、収集アクセスウゼェとか、そういうんでなくてですね。純粋にいろいろびっくりしたり、おもしろかったり。すばらしいという噂です。

CSS なサイトをサムネールでドババ (2)」へ続く。


Copyright © 1998-2006 ALIMIKA SATOMI/NYAN-NYAN-HANTEN.