TidBITS: Apple News for the Rest of Us  TidBITS-J#515/31-Jan-00

先週のクイズは日のあたらない話題に興味を引き起こした。Windows ユー ザーに電子メールの添付書類を送るときに使うべき最良のエンコーディン グ方法はなにか、というものだ。これに対して、Adam はなぜ正しい答が次 点だったのか、なぜ最も多かった回答がそれぞれ必ずしも誤答ではなかっ たのかを腰を据えて説明する。また、Keyspan 社の Digital Media Remote と Internet Starter Kit on the Web の旧バージョンのリリースを眺め、 SETI@home 2.0 クライアントのリリースをお知らせする。

目次:

Copyright 2000 TidBITS Electronic Publishing. All rights reserved.
問い合わせは <info@tidbits.com> へ、感想は <editors@tidbits.com> へ。

TidBITS 日本語版は TidBITS 日本語版翻訳チーム メン バーのボランティアによって翻訳・発行されています。TidBITS 日本語版 では翻訳に協力してくれる方を募集しています。詳しくは以下の URL を 参照してください。

<http://jp.tidbits.com/join_us.html>


今回の TidBITS のスポンサーは:


MailBITS/31-Jan-00

(翻訳:西村 尚 <hisashin@hotsync.co.jp>)
(  :高島 均 <hitak@kk.iij4u.or.jp>)

SETI@home 2.0 で ET 探しは続く -- SETI (Search for Extraterrestrial Intelligence)プロジェクトは、SETI@home クライアン トをバージョン 2.0 にアップデートした。このアップデートでは、セキュ リティ機能の追加、プロキシサポートの向上、そして Arecibo 電波望遠鏡 からのデータを解析できるように、コンピュータの処理能力の利用配分に 関するバグを修正したところだ。( TidBITS-482 の“SETI が家庭の Mac に情報空間の探索をもたらす”を参照。)この新しいソフトウェアは、勝 手なデータ改変を検出してそのファイルを削除することにより、一部の人 間が SETI@home ランキングを上げるために行っている試みを邪魔をしての ける。その結果、新たな作業データには、SETI@home 2.0 が必要となる。 つまり、換言すれば、このプロジェクトに参加し続けるためにはアップデー トが必須となる。このアップデートはまた、SOCKS や HTTP プロキシのよ り強力なサポート、Mac OS 9 との互換性、より正確な CPU 時間の算出、 WindowShade でアプリケーションウィンドウを隠したときのより高速なデー タ処理を誇るものである。視覚的には、SETI@home 2.0 は分析結果をガウ ス曲線で表示するインジケータの新機能を搭載する。バグが存在している ため、Appearance Manager を一緒に動かしていない System 7.x ユーザー は、次回以降のリリースを待つ必要があるだろう。SETI@home 2.0 には 24 MB 以上の RAM を搭載した PowerPC ベースの Mac が必要で、フリーダウ ンロードは 360K のサイズだ。[JLC]

<http://setiathome.ssl.berkeley.edu/>
<http://db.tidbits.com/getbits.acgi?tbart=05401>
<http://setiathome.ssl.berkeley.edu/mac.html>

スターターキットの旧バージョンがオンラインに -- 先週、ある一人の 読者が、拙著 Internet Starter Kit のオンラインバージョン(Mac の第 3 版、Windows 3.1 の第 2 版)が、またまた行われた再編のせいで Macmillan Computer Publishing 社のサイトに見つからなかったと連絡し てきた。関係者を捜し当ててたくさんの作業時間の結果を待つのは止めに して、これらの本のテキスト全文を TidBITS の Web サイトに置くことに した。インターネットに関する基本的な議論ならたぶん今なおなんとか正 しいのだろうが、各プログラムの詳細についてはひどく時代遅れだ。でも、 そうした古い情報であっても、旧式の Mac や PC でインターネット接続の セットアップやトラブル解決をしようとする人々には役にたつかもしれな い。実は、私も MacTCP や MacPPP の設定を思い出せないときに、これら の本をよく参考にしているのだ。老齢ではあるけれど、人々がこれらの本 から有用性を引き出し続けてくれればと願う。 [ACE]

<http://www.tidbits.com/iskm/iskm3html/>
<http://www.tidbits.com/iskm/iskw2html/toc.html>

アンケート予告: 十人十色 -- 次号では、Deneba 社製 グラフィックプ ログラム界における Swiss Army ナイフの最新バージョン、Canvas 7 をお 送りする予定だ。我々のほとんどがテキスト中心の世界に住み着いている せいで、スタッフの Matt Neuburg がずっとご執心の Canvas を除いては、 グラフィックプログラムを取り上げようとはしてこなかった。そこで、あ なたがグラフィックの編集や作成に最もよく使っているプログラムは何か を教えて欲しい。アンケートの回答用にあらかじめいくつかのビッグネー ムを選んでおいたが、たくさんの他の選択肢もあるだろうから、他のどん なプログラムを使っていてなぜそれが気に入っているかが伝えられるよう、 TidBITS Talk に新しいスレッドを用意した。[ACE]

<http://www.tidbits.com/>
<http://db.tidbits.com/getbits.acgi?tlkthrd=928>


配線するよりも

by Adam C. Engst <ace@tidbits.com>
(翻訳:尾高 里華子 <rikako@pobox.com>)

私の家族は根っからのリモコン好きである。テレビにリモコンがついてく るのが当たり前になるよりもずっと前に、私の両親はブリーパーと呼ばれ るとある装置を持っていた。それは、テレビを見ていて、広告になると音 を消すための小さな電気スイッチだった。それが壊れて初めてその大切さ を実感した父は別の手段で解決した。(元来エンジンの空気吸入を調節す るのに使用する)チョークケーブルを買ってきて、テレビの調節つまみの ところにドリルで穴を開け、そこに釘をつけ、その釘をチョークケーブル に繋いだ。そして、便宜上チョークケーブルのハンドルをソファーの側の 壁に取り付けた。このハンドルを押したり引いたりすると、ケーブルが伸 び縮みし、釘が動いてボリュームを調節できるようなった。妙ではあるが、 ちゃんと機能した。テレビを動かす必要もほとんどなかったし、ソファー 以外からボリュームを変える必要もなかった。それにこの自家製のリモコ ンは行方不明になることもなかった。

今どきテレビにリモコンがついているのはごく普通のことであるが、コン ピュータではそんなことはずっと考えもしなかった。何しろパソコンはそ の前に座って使うものだから、リモコンの必要性などほとんどなかったの だ。赤外線マウスは少し前から登場しているし、長く Macintosh の記事を 書いている Andy Ihnatko 氏がロボットをリモコン制御にするフランケン シュタインぽいアプローチを紹介していたこともあった。それでも、私は コンピュータをリモートコントロールすることに興味が湧かなかった。と ころが、自分たちの CD を MP3 ファイルにして台所の Mac で聞くように なってからは事態は一変した。電話が鳴ると音楽を一時停止するか音をオ フにしなければならないとか、食事のために席についてからボリュームを 絞らなければならないようになったのだ。

<http://db.tidbits.com/getbits.acgi?tbart=05589>

買ってすぐに使える Keyspan -- MacSpeech 社の ListenDo が私たちの ジレンマを解決するには理想的かもしれない。インストールはしたものの、 まだ思うようなタスクを実行させるための設定を行っている時間がとれず にいる。それに、コンピュータに向かって指示する声の邪魔になるような、 ほかの人たちの話し声がしたり、何かと雑音が発生する台所で音声認識が ちゃんと動くかはまだ分からない。

<http://www.macspeech.com/>

しかし、現時点では、箱から出しただけですぐに利用できる Keyspan 社製 の 79 ドルの Digital Media Remote(通称 DMR)を利用している。この USB の DMR は 2 つのパーツからできている。一センチほどの厚みのクレ ジットカードサイズのリモコン部とそれを収めるくぼみのついた USB に繋 がるレシーバだ。リモコンにはボタンが 15 個ある。スタート、ストップ、 早送り・早戻し、ボリュームの高低といったものを示すアイコンつきのも のが 8 つ、菱形に配置された 4 つの方向ボタンとその真ん中の Select ボタン。そのほかに、Menu ボタンと、Cycle ボタンと呼ばれるアスタリス クつきのボタンだ。

<http://www.keyspan.com/products/usb/remote/>
<http://db.tidbits.com/getbits.acgi?tbart=05609>

DMR はハードウェアとしては完璧に動作する。赤外線リモコンというもの は見通し線を確保しなければ動作しないものだが、壁の跳ね返りを利用し て赤外線を届けることもできる。普通の家庭でおこりうるだろう距離(10 〜 12 メートルほど)で試してみたところ、信号を受け取る際のトラブル は一切なかった。巨大な講堂などでは問題が発生するかもしれないが、大 抵の状況では動作すると思われる。

私はこの DMR を iBook で試していたので、レシーバを常に繋いだままに はしておきたくなかったのだが、途中でレシーバを繋いだり外したりして も、Keyspan 社のソフトウェアは問題なかった。

キーボード役をこなす -- Keyspan DMR に付属しているソフトウェアは 使用には足るが絶賛するほどのものではない。DMR は元来キーボードをエ ミュレートするものなので、タイプできるものはなんでもリモコンのキー に割り当てることができる。DMR はデフォルトで一部のアプリケーション 用にキー割り当てをしており、さらに前面に未知のアプリケーションが来 たときにはそのデフォルト割り当てが適用されるようになっている。DMR は Finder や Microsoft PowerPoint 以外にも、主なマルチメディアアプ リケーション(QuickTime Player、SoundJam MP、AppleCD Audio Player など)を認識できる。これらだけでなく様々なアプリケーションに自分の 割り当てを指定することができるので、MP3 プレイヤーやプレゼン用プロ グラムなど異なるものを使用する方には便利だろう。

Keyspan は古いバージョンではコントロールパネルのフォルダに状況確認 や診断用の Keyspan DMR Assistant とキー割り当てを定義するための Keyspan DMR Manager の 2 つをインストールした。このソフトウェアは現 在バージョン 1.2 になっていて、無償で手に入る。最新版では Manager アプリケーションが初期設定フォルダに移動され、Assistant に Configure ボタンを追加してある。キー割り当て用のインターフェースも変更になっ ている。以前はメインの Manager ウインドウにすべて積み込まれていたの だが、別のダイアログボックスに移された。

<http://www.keyspan.com/products/usb/remote/downloads/>

残念ながら、便利にはなったものの前から抱えている基本的なインター フェースの問題はそのままになっている。たとえば、どのドライバーまた は割り当て操作がアクティブなのかを知らせるだけの Assistant のメイン ウインドウのステータス情報は、ステータスダイアログボックスにおいて もよいだろう。さらに、Manager はリモコンのボタンをリストアップして くれ、その名前ごとに定義するようなっているだが、リモコンに名前が出 ているのは 15 個中 2 個だけであるという事実が無視されている。ほかの ものはアイコンがついているだけで、アスタリスクがついたボタンが “Cycle”という名前だなどとても連想できない。リモコンにでているボタ ンのマークを用いてキー割り当てをすることができると、このソフトウェ アはもっと使いやすくなるだろう。そして最後に、ユーザーの立場からは ユーティリティを一つのコントロールパネルにまとめるのは簡単なことだ と思えるのだが、わざわざ 2 つに分けている理由が判らない。

先鞭の者より -- 私が見つけた DMR の知られざる機能は、OneClick、 QuicKeys、KeyQuencer のようなマクロプログラムと組み合わせることが可 能だということだ。たとえば、Cycle ボタンを続けさまに押して前面に SoundJam を持ってきて(デフォルトでは、Cycle ボタンは Command + Tab をエミュレートするようになっている)、Menu ボタンを押すようになって いるが(Keyspan ソフトウェアでは Command + M または Mute がデフォル トとして割り当てられている)、SoundJam に切り替えてから Command + M を押すという操作が一つのコマンドで済むようなもっとまともなマクロ を作れないのだろうか。リモコンのボタンは 15 個しかないが、アプリケー ションごとに 15 個のコマンドが可能である。ボタンの一つを Finder に 行くコマンドにすると、Finder から 15 個のマクロを利用できるようにな る。マクロプログラムを作って組み合わせをしてしまえば、あとは思いの まま。別の部屋にある Mac にリモコンを向けてボタンを押すと、Mac は時 間や次の予定(AppleScript を利用することになるだろうが)を読み上げ たり、指定しておいたアプリケーションを立ち上げたりできるようになる。 マシンの前にいなくてもすむようなことのほとんどすべてを実行すること が現実になってくる。

Keyspan DMR 用のソフトウェアは完全ではないが、高望みをしてはいけな い。ちゃんと動作するし、キーを割り当てるのはそんなにしょっちゅうす る作業ではないのだから。Mac にあるアプリケーションを操作する用の赤 外線リモコンの装置が必要な状況が考えられるのなら(Windows の場合で も、USB のついたマシンで Windows 98 が載っているのならちゃんと動 く)、Keyspan 社の Digital Media Remote は悪い選択ではないだろう。


Email 添付フォーマットについての説明

by Adam C. Engst <ace@tidbits.com>
(翻訳:松岡 文昭 <mtokfmak@mxa.mesh.ne.jp >)
(  :亀岡 孝仁 <tkameoka@fujikura.co.jp>)
(  :吉田 節 <benjamin.takashi@nifty.ne.jp>)

分かったよ。先週のクイズの“メールで Windows ユーザーにファイルを送 るときのベストなエンコーディングは?”では、何人かを混乱させてしまっ たようだ。すぐ正解に行くが、先ずその混乱について説明しよう。

専門用語 -- TidBITS-445 の“Macintosh のインターネット用ファイル フォーマット入門”で説明したように、Macintosh ファイルがメールで転 送される際には二つの事が起きる。バイナリパッケージングと転送用エン コーディングだ。バイナリパッケージングとは、AppleDouble、 AppleSingle、そして MacBinary 等フォーマットの領域で、Macintosh ファ イルがデータフォークとリソースフォークの両方を持つことができること を理解できない他のプラットフォームでの問題に対処するものだ。Base64 か uuencode で行われる転送用エンコーディングは、7 ビット ASCII デー タのみの通信を 保証する インターネットメールでの送信に耐えうるよ う、8 ビットファイルを 7 ビットの ASCII テキストに変えるものだ。 BinHex フォーマットはバイナリパッケージングと転送用エンコーディング の両方を組み合わせたものだ。

<http://db.tidbits.com/getbits.acgi?tbart=05066>

ここが何人かを悩ませた点だ。Eudora、Emailer、そして Outlook Express 等のほとんどのメールプログラムは、送信のために添付ファイルをフォー マットする処理を“エンコーディング”と呼んでおり、結果としてバイナ リパッケージングのステップと転送用エンコーディングのステップを合成 しているのだ。ユーザーにとってそれは一般的に問題とならないが、クイ ズでは Base64(最も多い票を得た)が送信用エンコーディングフォーマッ トで、AppleDouble(2番目に票が多かった)が技術的にはパッケージング フォーマットであることを知っている人達に、いく分か混乱を生じてしまっ た。

さて、“それならもし AppleDouble がバイナリパッケージングのフォー マットなら、メールで送られてもどうして壊れないのだろう?”と思われ るかもしれない。答えは、添付ファイルが AppleDouble でパッケージング されてメールで送られるときは、自動的にBase64 でも エンコードされ ているである。ほとんどの状況では Base64 のエンコーディングはユーザー 双方の目に触れるものではないのだ。更に個々のメール添付フォーマット について順番に説明してみよう。

正解: AppleDouble -- 我々が意図せず生じた混乱に関わらず、 AppleDouble は Macintosh や Windows ユーザーに添付ファイルを送るに は最も適したフォーマットで、特に同じファイルを Mac と Windows ユー ザーに同時に送るときにはそうだ。なぜなら AppleDouble は、ファイルの データフォークとリソースフォークを切り離して、別々にメッセージに添 付し、その時点ではそれ等は転送用に Base64 でエンコードされているの だ。最近の Macintosh 用メールプログラムはそれ等二個の添付ファイルを 見つけると、Base64 をデコードして、それ等を一つのファイルへと再結合 するのだ。他のプラットフォームのメールプログラムがそれ等二個の添付 ファイルを見つけると、Macintosh のリソースフォークを理解できない故、 リソースフォークを切り捨て、データフォークのみをデコードするのだ。

Windows ユーザーへのファイル送信には uuencode よりも AppleDouble が 良いという私の推薦に対しては、いく人かから質問を頂いた。実際、 uuencode はほとんどの場合に上手くいくが、私が uuencode よりも AppleDouble を薦めるのは以下の理由によるのだ。

“AppleDouble はインターネットメールメッセージにて同梱される Macintosh ファイルに望ましいフォーマットだ。何故ならそれは Macintosh コンピュータを使用する受信者に、アイコンやその他の Macintosh 固有の 情報を含んだ全てのドキュメントを提供し、その他のユーザーには AppleDouble エンコーディングで切り離されたデータフォーク(実際のデー タ)が簡単に取り出せるからだ。”

<http://www.cis.ohio-state.edu/htbin/rfc/rfc1740.html>

標準の支持と使用は良いことであり、それが今日我々がインターネットを 使用する主な理由でもある。旧式の添付フォーマットのみを理解する時代 遅れのメールプログラムを早くなくすことができれば、皆にとって良いこ とで、このような記事もすぐ不要となるだろう。

いくつかの Macintosh 用メールプログラムでは、“AppleDouble”という 用語は使わず、代わりに“MIME”と呼ぶものがあるので注意が必要だ。 Eudora でさえ最近は“AppleDouble ("MIME")”と呼んでいる。それは全く 不当と言えるものでもない。“AppleDouble”だと Windows ユーザーにファ イルを送る際にも使えると信じさせるものがないからだ。だが問題は MIME が Windows プログラム(Mac 用の Outlook Express 5.0 でも)では別の 事柄を指すことだ。Windows にはバイナリパッケージングは全く必要がな く、“MIME”は単にメールに添付されたバイナリファイル用の“Base64 エ ンコーディング”を意味している。

AppleDouble の主な問題は、二、三のまれなケースで上手くいかないこと だ。ほとんどの場合はインターネット標準を正しくサポートしていないメー ルゲートウェイを使用している人々が対象となる。その場合は考えられる 限りで上手くいく方法を試すのみだ。

AppleSingle -- AppleDouble が添付書類のデータおよびリソースフォー クを 2 つのファイルに分割するのに対して、AppleSingle はこれら 2 つ を一つのファイルにまとめる(メールには用いられていないが MacBinary に似ている)。AppleSingle のメール添付書類に関する可用性は最低限の ものであり、わずかに Macintosh のメールの世界の中でパラパラとサポー トされているだけである。AppleSingle がそれにもかかわらず今でも存在 し続けている主な理由は MacMIME の仕様が、データフォークを持たない Mac ファイルは AppleSingle として送られねばならないと定めているから である。しかし今日においては、AppleSingle はもはやほとんどの人にとっ ては意味をなさない存在となってしまった。

uuencode -- 再び uuencode だが、これは Macintosh ファイルのいかな るリソースフォーク情報も捨て去り、8 ビットのファイルを 7 ビット ASCII テキストに変換する転送用エンコーディングフォーマットである。 このリソースフォークに関する破壊的なふるまいはまずいように聞こえる かも知れないが、実際のところはそんなにひどい結果とはならない。と言 うのは、もし Macintosh ファイルのリソースフォークが一緒に転送された としても、どの Windows アプリケーションもそれを読むことができないか らである。もし Macintosh ドキュメントがリソースフォークを 必要 と したとしても、Windows 環境ではどっちみち読めないのである。そしても し Macintosh アプリケーションをメール経由で uuencode を使ってエン コードして送ると、そのアプリケーションは破壊されてしまうが、 Macintosh アプリケーションはどのみち Windows 上では走らないので、何 も失われてはいないのである。

uuencode が未だに存在している理由は歴史的なものである。それは MIME 以前の時代には非常に多く利用されていたので、ここ数年間自分のメール プログラムをアップグレードしていない Windows や他のプラットフォーム の利用者に対する救済手段として存在し続けている。

Base64 -- 転送用エンコーディングフォーマットとして、Base64 はかな り uuencode に似ているが、近代的で標準化されているという長所をもつ。 uuencode と同様、Macintosh ファイルを Base64 エンコーディングで送る とリソースフォークを失う。Base64 は AppleDouble を使うと自動的に使 われることを思い出して欲しい。さらに Windows のメールプログラムを見 たときに、添付フォーマットのコンテクストに“MIME”とあればそれは大 抵 Base64 エンコーディングを意味している。

<http://www.cis.ohio-state.edu/htbin/rfc/rfc2045.html>

私の AOL との試験はまだ完了できていないが、今のところ AOL ユーザー に添付書類を送るには Base64 が最適の選択の様である。他のフォーマッ トでも大丈夫だが、これほどシームレスには行かない。この結果について は来週報告できると思う。

BinHex -- 上で述べた様に、BinHex はバイナリパッケージングフォー マットと転送用エンコーディングフォーマットが一緒になったものである。 これは Macintosh ファイルの両方のフォークを結合し、次に送信のために 8 ビットのファイルを 7 ビット ASCII テキストに変える。BinHex は Macintosh ユーザー間でメール経由でファイルを送るのには今でも人気が ある。それは基本的にすべての Macintosh メールプログラムは BinHex を 理解するからである。しかしながら、Windows ユーザーにファイルを送る ときにはうまく行かない場合が多い。と言うのも、Eudora 以外の Windows メールプログラムは BinHex をデコードできないからである。多くの Mac ユーザーは今でもメール経由でファイルを送るときに全面的に BinHex に 頼っており、それでうまく行っているなら何も言う事はないが、私は、で きれば AppleDouble に変更する様お勧めしたい。その理由は以下のとおり である:

<http://db.tidbits.com/getbits.acgi?tbart=05050>

論議のもう一つの側面として、BinHex はファイルの最後に組み込まれた チェックサムを持っているので、メールプログラムは添付書類が破壊され ているかどうかのチェックを、BinHex が使われているときの方がずっとし やすいことがある。

Quoted-Printable -- quoted-printable は大抵の人には Eudora の中の QP ボタンとしてしか知られていないだろうが、これも一つの転送用エン コーディングフォーマットである。これは添付書類のために使われるので はなく、上位 ASCII 文字(例えば、区別発音符を持つような特殊文字)の ためのものである。これらは 7 ビット(または下位)ASCII の一部ではな いので、quoted-printable は、等号の後に数字が続くように特殊文字をエ ンコードする。quoted-printable でエンコードされても、すべての下位 ASCII 文字はそのまま保持されるので、メッセージそのものはだいたい人 間の目にも読める体裁を保持できる。

メールで行の終わりにイコール記号が付いているものは間違いなく quoted-printable メッセージでまだデコードされていないものである。こ れは通常 quoted-printable エンコーディングであることを示す Content-Transfer-Encoding ヘッダが失われたためである。この問題は大 抵メーリングリストのダイジェスト版で頻繁に発生する。というのもメー リングリストソフトウェアがダイジェストにまとめる前にメッセージから ヘッダを取り除いてしまうからである。この問題に対する主たる対策は MIME ダイジェスト機能である。この機能は、ダイジェスト内の個々のメッ セージに対するヘッダを維持する。そして、ダイジェストをメールボック スに入れるときに転送用エンコーディングを指定する特別なヘッダを残す。

圧縮の役割 -- ここまで全部をしっかり理解できたところで、もうひと つの要素である“圧縮”を取り上げよう。多くの場合、ファイルをメール で送る前に圧縮しておくのは良いことだ。大きなファイルを送ったり、ひ とつのメッセージに多数のファイルを添付したい場合は特にそう言える。 なぜなら、ファイルを単一のアーカイブに圧縮すると空間を節約でき、か つ受信側での作業がおそらく容易になるからである。ここで“おそらく” と言ったのは、主要な IMAP メールプログラムである Mulberry の開発者 のひとりが次のように特筆したからだ。IMAP の考え方ではクライアントが 要求するまですべてはサーバの中にある。そのため、複数の添付ファイル からひとつを選んでダウンロードできるのが IMAP のひとつの利点なのだ そうだ。

圧縮には、Macintosh のファイルが転送用エンコーディングを受けても壊 れずに済むかもしれない、というもうひとつの利点がある(ふつう、ファ イルのリソースフォークは転送用エンコーディングにより壊れてしまう)。 たとえば、StuffIt 5 アーカイブはすべてをデータフォークに入れるので、 uuencode や Base64 はアーカイブを壊すことはない。旧バージョンの StuffIt ファイルのフォーマットでは一部のデータがリソースフォークに 入ることがあった(これは本当だ。開発者から直接得た情報である)。ク ロスプラットフォーム化するためにすべてをデータフォークに移すという のが、Aladdin 社が StuffIt 5 フォーマットを導入した主な理由のひとつ だった。そういうわけで、ファイルを送信前に自動的に圧縮できるメール プログラムを使っているなら、uuencode や Base64 はとても役立つだろう。

もちろん、圧縮したファイルを Windows ユーザーへメールで送った場合、 添付ファイルはうまくデコードできるだろうが、それは伸長できない圧縮 ファイルにしかならない。もし相手に大量の圧縮ファイルを送る予定なら、 Aladdin Expander for Windows の無料コピーをダウンロードするよう相手 に勧めておこう。これは多種多様なフォーマットをデコードでき、Mac 上 の StuffIt Expander にとても似ている。いっぽう、圧縮ファイルを Windows ユーザーへ送ることがほとんどないのなら、DropStuff 5.5 と StuffIt Deluxe 5.5 がよい。これらは Windows 用の自己解凍アプリケー ション(拡張子は .sea でなく .exe)を作ることができ、受取人はそれを 起動すれば伸長させられる。

<http://www.aladdinsys.com/>

圧縮ファイルのもうひとつの利用法は、Windows または Unix マシンを経 由して、リソースフォークの必要なファイルを 2 台の Mac 間で転送した いという場合に見られる。ファイルを圧縮してデータフォークだけに入れ れば、目的の Mac へ着くまで(ネットワーク、フロッピーディスク、また は何か他の転送機構を介して)の途中のマシンにファイルが一時的に止まっ た時に、情報がまったく失われないことを保証できる。もちろんこれは、 目的の Mac で StuffIt Expander が利用できると仮定しての話だ。

添付されるもの -- ここまでの議論では、メールに添付するファイルの 種類にはほとんど触れなかった。だが、もし含まれている書類を受取人が 開けないとしたら、たとえ適切な添付フォーマットを選んでも受信者にとっ て意味がない。適切なフォーマットを選ぶということに関して考慮すべき ことはたくさんあるが、次のような点を守れば間違いはないだろう。

終わりに -- 昔から闇の中だった問題に、この記事が少しは光明を投ず ることを望む。この話題全部を思い付かせたクイズ(Windows ユーザーへ ファイルをメールで送る時に一番良いフォーマット)は比較的簡単だと思 われるし、理想的な世界ではそれを考えもしないかもしれない。私がすべ てに対して AppleDouble(透過的な Base64 エンコーディングと共に)を 勧める理由の大部分は、それであればインターネット標準に従う今風のど んなメールプログラムでもうまく働く はず だからだ。それが常にうま く働く訳ではないという事実は、古いメールプログラムのユーザーへ臨時 にファイルを送る時以外にも他のフォーマットに頼るべきだということに はならない。その事実はむしろ、どこでも AppleDouble が確実にサポート されるように我々みんなが努力すべきだということを意味する。そうすれ ば、このクイズは完全にインターネットの伝説の中へ、そうあるべき所へ 消え去っていくだろう。本来、誰も添付フォーマットについて考える必要 さえないはずだ。そしてそのような状況にたどり着くには、AppleDouble と Base64 の MIME 標準に完全に準拠するしかない。

次週は、今の主要なメールプログラムが添付ファイルを送るためサポート しているフォーマットに関する情報と、AOL で添付ファイルを受信するテ ストの結果をもって、この話題を終える予定だ。


非営利、非商用の出版物およびウェブサイトは、フルクレジットを明記すれば記事を転載またはウェブページにリンクすることが できます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありませ ん。書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017

tb_badge_trans-jp2Valid HTML 4.01!Another HTML-lint gateway