TidBITS-J#445/31-Aug-98 TidBITS-J#445/31-Aug-98MacBinary、AppleDouble、Base64 などについて聞かされると目がどんより する? 一般的な Macintosh ファイルフォーマットについての包括的な考察 を読んでみてほしい。また今週は Mark Anbinder 氏が Adobe 社が発表し た Mac 用 PageMill 3.0 の詳細をお送りする。そしてニュースとして、 Quark 社の Adobe 社獲得への動き、Farallon 社が紹介した iMacs と StyleWriter に関する解決策、Norton Utilities 4.0 ベータ版が RAID を 破壊すること、そして AppleShare IP 6.0、MacLinkPlus Deluxe 10、 Virtual PC 2.1 など新しいソフトウェアのリリースについてお送りする。
目次：
Copyright 1997 TidBITS Electronic Publishing. All rights reserved.
問い合わせは <info@tidbits.com> へ、感想は <editors@tidbits.com> へ。
TidBITS 日本語版は TidBITS 日本語版翻訳チーム メン バーのボランティアによって翻訳・発行されています。
今回の TidBITS のスポンサーは：
（翻訳：秋山 晃子 <nobineko@club.udn.ne.jp>）
（翻訳：浦山 健 <den@axes.co.jp>）
Labor Day の休刊 -- 引き続き管理上の話だが、先ほど解決したばかり の US West 社のストライキの影響で、先週のうちにサーバを移転するはず だったが計画が遅れてしまいまだ移転をしていない。それより先に来週号 を休刊にすることにした。来週の発行日が米国で勤労者の日にあたり、祝 日を祝うには仕事を休む以上に最適な方法はないだろうと考えたから、と いうのは表向きの理由である。実は Tonya と私は友人の訪問を受け、Jeff Carlson は Peachpit Press 社から出版予定の PalmPilot Visual QuickStart Guide を仕上げることになっているのだ。我々の運が良けれ ば、株式市場にならって天候も陰鬱になるようなことはないだろう。 [ACE]
Adobe 社が Quark 社の買収申し出を拒絶 -- 先週 Quark 社が Adobe Systems 社を買い取りたいと発表した。価格は明かされてない。個人企業 の Quark 社は Adobe 社の経営陣に申し出たが、Adobe 社は Quark 社の申 し出には誠実さがなく“余計な手紙”（スパムと見なしていいだろうか? -Adam）を送りつけてきただけであると公言している。Adobe 社は Quark 社の提案を拒絶したが、Quark 社は Adobe 社と新たに話し合いを始める か、あるいは非友好的な買収の可能性を追求するつもりだ。Adobe 社のほ うがずっと大きな会社（1997 年度の総収入は 9 億 1190 万ドル、対して Quark 社は 2 億ドル）だが、株価は今年の最安値に落ち込みリストラを 行っている最中である。デスクトップパブリケーション用アプリケーショ ン QuarkXPress のメーカーである Quark 社はおそらく QuarkXPress の一 番の競争相手である PageMaker をはじめ独禁法取締官が赤旗を揚げる可能 性のある他の製品を Adobe 社から切り離すことになるだろうと述べた。 [JLC]
<http://www.quark.com/about/itn064.html>
<http://www.adobe.com/aboutadobe/publicrelations/HTML/9808/980826.offer.html>
Apple 社 AppleShare IP 6.0 をリリース -- Apple 社が同社の統合サー バソフトウェアの最新バージョンとなる AppleShare IP 6.0 をリリースし た。AppleShare IP 6.0 ではパフォーマンスが改善され新しく重要な機能 が加えられているが、その中には Server Message Block プロトコル （SMB）を使用する Windows クライアントのためのサポート、サーバ側検 索テクノロジーの Sherlock と連動する IMAP4 サポート、TCP/IP による 印刷機能、サードパーティのプラグインへのサポートなどが含まれる。 Apple 社によると AppleShare IP は PowerPC 601、604、604e か G3 プロ セッサの Power Macintosh（Power Macintosh 6500 もサポートされる）、 Open Transport 1.3 以降をインストールした Mac OS 8.1、48 MB の RAM （仮想記憶を使用時、不使用時は 64 MB）を必要とする。価格は 10 クラ イアントライセンスが 499 ドルである。Apple 社は、同時に 500 人のユー ザーをサポートするクライアント数が無制限の 1,499 ドルのライセンスを 上限として上記以外のライセンスも提供すると述べている。 [ACE]
<http://www.apple.com/appleshareip/>
MacLinkPlus Deluxe 10 出荷 -- Mac OS にバンドルされなくなったから といって、MacLInkPlus は消えてしまったわけではない。DataViz 社は、 この素晴らしいファイル変換ユーティリティの最新バージョンである MacLinkPlus Deluxe 10.0 をリリースした。このバージョンでは Word 98 や Excel 98 用の新しいコンバータや、電子メールで一般的に使われる様々 な圧縮や暗号化のフォーマットの解凍・復元機能、全ての MacLinkPlus の 機能についてのコンテクストメニューのサポートが追加された。新しいイ ンターフェースはドラッグ & ドロップをサポートしており、正体不明のファ イルについての情報を提供し、ファイル内の画像やテキストを見ることが できるようにしてくれる。アップグレード料は 40 ドルで、新規購入の場 合は 99 ドルである。
ただし、このバージョンには 2 つの問題がある。第一に、ClarisWorks 5 のファイルを MacLinkPlus で保存したり開こうとするとクラッシュすると いったものだ。DataViz は、ファイル変換を行う場合は ClarisWorks 5 を 使わないよう勧めている。もし ClarisWorks 5 のファイルを他のフォー マットに変換しなければいけない場合は、まず最初にそのファイルを ClarisWorks 4 形式で保存するよう警告している。また、MacLinkPlus の インストーラは、Contextual Menu Enabler 機能拡張ファイルを誤ってイ ンストールしてしまうが、このことによりトラブルが起こるユーザーもい るだろう。Apple Internet Address Detectors (IAD) 1.0.1 にはこの機能 拡張が必要なので、以前に IAD をインストールしていたのならこれを削除 すべきでないが、それ以外の MacLinkPlus のユーザーは Contextual Menu Enabler 機能拡張を無効にするよう DataViz は勧めている。[ACE]
<http://www.dataviz.com/Products/MLP/MLP_Home.html>
<http://www.dataviz.com/tech/MLP/MLPabove10/TS_Home_MLPabove10Home.html>
iMac と StyleWriter -- 先週号の（ TidBITS-444「iMac 接続ガイド」 を参照）に更新が必要になった。Farallon 社が EtherMac iPrint Adapter SL を発表したのだ。このタイプの iPrint は、LocalTalk をサポートして おらずシリアル経由で接続する StyleWriter を、iMac の 10Base-T Ethernet ポートに繋ぐためのものである。Farallon から LocalTalk プリ ンター向けのソリューションとして既に発売されている EtherMac iPrint Adapter LT と同様、EtherMac iPrint Adapter SL は 99 ドルである。 Farallon はこの製品を 1998 年 9 月に出荷するとしている。[ACE]
<http://db.tidbits.com/getbits.acgi?tbart=05049>
<http://www.farallon.com/ether/adapters/iprintadapter.html>
Connectix 社、Virtual PC を2.1にアップデート -- 先週、Connectix 社は Virtual PC のアップデータを発表した。これはほんの少し機能を追 加し、マイナーバグや互換性の問題を解決したものである。新バージョン は Voodoo2 グラフィックチップと Windows NT をサポートし、Ethernet デバイスを複数インストールしてある中から選択できるようになっている。 また、PowerBook のホットスワップドライブをサポートし、RAM Doubler と仮想記憶の互換性やビデオの互換性が改善されている。Virtual PC 2.0 / 2.0.1 のユーザーは、1.7 MB のアップデータをダウンロードすることに より無償で 2.1 にアップデートできる。[JLC]
<http://www.connectix.com/html/vpc_updates.html>
RAID ユーザーよ、Norton ベータ版は要注意だ -- Mark James 氏 <mjames@softraid.com> が Norton Utilities 4.0 for the Macintosh の パブリックベータ版と、Apple のサーバ機種にバンドルされている RAID ソフトウェア、SoftRAID でフォーマットされたボリュームとの重大な不具 合について明らかにしている。ストライピング（分割）されたボリューム を Norton Utilities で修復しようとすると、どうやらパーティション形 式を HFS にしてしまうらしく、そのボリュームにアクセスできなくなって しまう。独自の情報源から、Apple RAID、RAIDware、ImageRAID や FWB 社 の RAID ToolKit でも同様の問題が起こることを確認している。Symantec 社はこの問題を早急に解決すべきだ。とは言え、この問題の被害に遭って しまった人に同情はするものの、そもそも大事なディスクに対して完全に バックアップもせずに、発売前のディスク修復ソフトをどうして使うのか ということが我々には理解できない。（もしあなたが完全なバックアップ をしていないなら、Adam のバックアップについての最近の記事を参照して ほしい） [GD]
<http://www.symantec.com/cgi-bin/Core/Core.pl?REGION=na&]
LANGUAGE=english&PFT=897671280>
<http://www.fwb.com/cs/rtk/main.html>
<http://db.tidbits.com/getbits.acgi?tbser=1041>
by Mark H. Anbinder <mha@tidbits.com>
（翻訳：小川 浄 <tao@peanet.ne.jp>）
一ヶ月ちょっと前、 TidBITS-439 「Visual Page の最期」のなかで Adobe 社の Macintosh 版 PageMill は静かに消えさるだろうと Adam は予想し た。理由は Abobe が Windows 版 PageMill 3.0 の相棒を世に送りだす気 配がみられなかったからだ。一週間後 Adobe が Macintosh 版 PageMill 3.0 開発作業を行なっているのは確かだ、と我々はレポートし、そして今 日 Adobe は予想外の早さで印象深いアップグレードを発表し Mac 版 PageMill 3.0 試用バージョンを公開した。
<http://db.tidbits.com/getbits.acgi?tbart=05001>
<http://db.tidbits.com/getbits.acgi?tbart=05010>
<http://www.adobe.com/>
Windows 界に住むイトコと同じように Macintosh 版 PageMill 3.0 には Web 制作機能の軒なみの新設・改善に加え SiteMill から受けついだサイ ト管理機能がプラスされている。PageMill 3.0 の出荷は 10 月はじめの予 定だが、改善されたテーブル編集、<FONT FACE> タグのサポート、Java ア プレット配置サポート（Macintosh Runtime for Java［MRJ］2.1 がインス トールされていればプレビュー可能）、サイト単位の検索と置き換え、生 HTML 編集のさらなる簡潔化（コードに自分で手を加えたい人向け）、広範 なコンテクストメニューサポート、Mac OS 8.5 の強力なサポート、をう たっている。
PageMill 3.0 の一番の進化は SiteMill のサイト管理機能を取りいれた 点だろう。同機能は PageMill 3.0 のパッケージにシームレスに取りこま れている。PageMill ユーザーは、ほかの FTP クライアントをまったく使 わずに Finder に似た Web サイトコンテンツ・ビューによる直観的ドラッ グ & ドロップ機能とサイトの同期が可能なのだ。データベースソフトウェ ア、サーバ固有機能に使用されている非標準 HTML やその他のタイプのマー クアップをあつかう際のマナーが前バージョンより向上した点もとくに真 摯な Web デザイナーに歓迎されるだろう。
Appearance Manager、コンテクストメニュー、Navigation Service といっ た Mac OS 8.5 の機能強化に対する PageMill 3.0 側のサポートは、当初 ほとんどのユーザーの気をひかない程度だ。だとしても将来を見通す Adobe の姿勢がうかがえる点はうれしいものだ。アプリケーション内部でのコン テクストメニューの全面的サポートは、Mac OS 8 でコントロールキーを押 しながらオブジェクト・クリックするのになれた人にはよろこばれるだろ う。Adobe ではだれもがよろこんでこの機能を使うと考えなかったようで、 コンテクストメニュー中のコントロールやコマンドにアクセスできる他の 方法も用意されている。
PageMill 3.0 には Adobe のインターネットサーバにある PageMill アッ プデートをチェックするアップデート機能もある。チェックとアップデー トの実行は自動的になされる。チェックは定期的に行なわれ、アップデー トをダウンロードしてインストールするか、またはユーザーがマニュアル でアップデートをチェックするのを待つようにするか、ユーザーが選択で きる。これら選択機能によりソフトウェアを最新状態にたもつ簡単かつ手 間のかからない手段が提供され、知らぬ間になされるダウンロードにたく さんのユーザーがいだく不満を感じさせない。
PageMill のパッケージには Photoshop LE、Acrobat Reader 最新バージョ ン、QuickTime 3.0、Netscape 社と Microsoft 社の Web ブラウザ現行バー ジョン、Java アプレットと JavaScript のサンプル、Web ページテンプ レート数ダース、Web に使えそうな数千のグラフィックイメージがふくま れている。PageMill には PowerPC プロセッサと System 7.5.5 以降が必 須（Adobe では Mac OS 8 以降を推奨）。
PageMill 3.0 は 10 月はじめに入手可能になる。旧版 PageMill 所有者に は 49 ドルのアップグレード価格があり、新規に購入するなら Adobe Web サイトから製品の箱、CD、マニュアル付きで 99 ドル、電子版は 79 ドル。 他方 8.6 MB の公開プレビュー版（おそらく「ゴールデンマスター」とな るリリース候補版）をダウンロードし、小手調べもできる。
<http://www.adobe.com/newsfeatures/tryadobe/main.html#pagemill30>
by Adam C. Engst <ace@tidbits.com>
（翻訳：西村 尚 <hisashin@axes.co.jp>）
先週号 TidBITS-444「デベロッパー諸君、MacBinary III だ」 のデベロッパーが MacBinary III をサポートする必 要に関する記事は、インターネット上のさまざまな Macintosh ファイル フォーマットに関して混乱した人々から多数のメールをもらう結果となっ た。これらのファイルフォーマットは何を行うのか、どのようにやりとり するのか？この記事は Leonard Rosenthol 氏（StuffIt Expander の元の デベロッパー）の助言を借りて書かれたが、これがこの混乱状態を解消す ることを望む。
<http://db.tidbits.com/getbits.acgi?tbart=05050>
<http://www.aladdinsys.com/expander/index.html#Win>
第一に、Macintosh ユーザーは通常 3 種類のエンコード用フォーマットを 扱う。アーカイブ用フォーマット（StuffIt、Compact Pro、Zip など）、 バイナリパッケージ用フォーマット、それに転送エンコード用フォーマッ トである。アーカイブ用フォーマットは、複数のファイルを一つのファイ ルにまとめ、この処理の間にオリジナルを圧縮する。劣化しない圧縮の背 後にある概念は誰でも理解しているように思う。つまり、ファイル内のデー タの繰り返しパターンをこれらのパターンを表わす代用語で置き換えるの だ。こうしてオリジナルを表わすために必要なデータ量はかなり小さくな る。
バイナリパッケージと転送エンコード用フォーマットはもっと込み入って いて、さらに悪いことに、この 2 つを同じフォーマット内にまとめること ができる。バイナリパッケージ用フォーマットには MacBinary、 AppleSingle、AppleDouble などがある。転送エンコード用フォーマットに は、uuencode、Base64、quoted-printable などがある。最後だが軽視でき ない、敬うべき BinHex はどっちつかずで、バイナリパッケージと転送エ ンコードの両方を提供する。ファイルを手動でエンコードまたはデコード したいなら、いくつかの特定のフォーマット用にシェアウェアユーティリ ティが存在するし、Aladdin の StuffIt Deluxe 4.5 は多数のフォーマッ トのために翻訳機能も提供する。詳細はこの号の冒頭の広告欄を参照のこ と。
MacBinary -- MacBinary は古いフォーマットで、遡ること1985 年に CompuServe の MAUG で Dennis Brothers 氏によって最初に提案された。 2 年後、HFS と Mac OS の他の変更を扱うように、デベロッパーのグルー プがこのフォーマットに追加を行った。このフォーマット、MacBinary II は今日まで生き存えている。ただし、もともと Mac OS 8 のために予定さ れ、Mac OS 8.5 でこれから出現する新しいファイルフラッグによって持ち 上がった問題に対処するため、MacBinary III に置き換わろうとしている。 面白いことに、MacBinary II フォーマットには将来の拡張用に“第二の ヘッダ”のためのオプションがあるのだが、使われることは一度もなかっ た。
バイナリパッケージ用フォーマットとして、MacBinary は、データフォー クとリソースフォークを、ファイルに関する付随的な Finder 情報（タイ プ、クリエータなど）を添えてまとめる。Macintosh ファイルの 2 つの フォークを一緒にまとめることで、MacBinary は Unix マシンや PC にアッ プロードされたときにファイルを保護する。どちらも Macintosh の 2 フォーク構造のファイルをサポートしない。MacBinary でなければ、リソー スフォークは失われるので、ファイルによっては災難になるし単に迷惑に もなろう。
MacBinary はアプリケーション間で広くサポートされ、MacBinary のサポー トは一般に透過的なのでユーザーがこれを理解することはめったになかっ た。たとえば、Macintosh ファイルを Anarchie か Fetch でアップロード するとき、両方とも MacBinary をアップロードの初期設定としている。問 題の一部は、ファイルをアップロードする人の多くが MacBinary のファイ ル拡張子 .bin を反映してファイル名を変更すべきことを知らないことで はないかと思う。特に Fetch など、FTP アプリケーションの中には、自動 的に.bin 拡張子を付け加えようとするものもある。
アプリケーションのサポートは広範囲に渡っているが、深いとはいい難い。 たとえば、Anarchie と Fetch は MacBinary を正しく透過的に扱うが、Web ブラウザは一般に MacBinary ファイルを MacBinary ||+ または StuffIt Expander などのヘルパーアプリケーションに受け渡す。適切なヘルパーア プリケーションがなければ、このファイルをデコードできない。
さらに悪いことに、多くの Web サーバは MacBinary ファイルに対する適 切な MIME タイプを設定していない。このことは、古い Web ブラウザが MacBinary ファイルをテキストとして自分のウインドウ内に表示しようと する結果を招く。この場合、最新の Web ブラウザにアップデートすること は別にして、2 つの解決策がある。第一は、リンクをクリックしたままに すると多くのブラウザで現われるポップアップメニューから Download Link to Disk を選択する。ファイルをダウンロードしたら、StuffIt Expander にドロップする。第二は、問題の Web サイトの管理者に MacBinary ファ イルのための正しい MIME タイプを設定するように説得することだ。この ファイルは、バイナリモードでダウンロードされ、“bin”拡張子がつき、 MIME タイプに“application/x-macbinary”を使うように設定すべきだ （タイプとクリエータ欄には BINA と SITx に設定でき、こうすればファ イルのダブルクリックで StuffIt Expander が起動する）。
さらに混乱することに、Internet Config、したがって Internet Explorer は MacBinary MIME タイプを不正確に“application/macbinary”と設定す る。これは完了していない仕様提案なのである。また、古いバージョンの Netscape Navigator（少なくとも 2.x バージョンと恐らく 3.x バージョ ン）では MacBinary に対する MIME タイプがまったく何も設定されていな い。Web サーバと Web ブラウザ間の同意がなければ、ユーザーが MacBinary ファイルへのリンクをクリックしたときに、不測の事態が起こ る恐れはかなりある。理論上は、強制的にディスクにダウンロードして手 動で StuffIt Expander でデコードすればうまくいくはずだが、バリエー ションがありすぎて断言できない。私がお薦めするのは、MacBinary の MIME タイプが Internet Config、Web サーバ、古いバージョンの Netscape Navigator などでどうなっていても“application/x-macbinary”に設定す ることだ。たとえばファイル拡張子とファイルを扱うアプリケーションの ような他の MacBinary を処理するための設定は、先述のように Web サー バと同じものにする。
再度いうが、MacBinary はバイナリパッケージ用フォーマットであり、転 送エンコード用フォーマットではない。したがって MacBinary ファイルが 転送される時にはいつも完全な 8 ビット接続が要求されることになる。い まだにインターネットへの時代遅れの 7 ビット接続（これはいまだに存在 するが、インターネットの過去のもやの中に急速に消え去ろうとしている。 FTP と Web の HTTP は両方とも 8 ビット接続を使うからである）の過去 に留まっている人が MacBinary ファイルを転送しようとすれば、転送時に 障害を受けることになる。今日では極めて珍しいが、このような特殊な状 況では BinHex のような転送エンコード用フォーマットも必要だ。
AppleSingle -- MacBinary と同様に、AppleSingle は 8 ビットバイナ リパッケージ用フォーマットである。ほとんどの人は、Eudora または Emailer の添付書類の変換方式のポップアップメニューでしか AppleSingle のことを目にしたことはなく、Eudora のバルーンヘルプの説明はよくでき ているが、詳細を欠いている。AppleSingle と AppleDouble は Apple 版 の Unix である A/UX の時代に開発された。A/UX は 2 フォークの Macintosh ファイルをサポートしなかったので、Apple は A/UX と Mac OS 間でファイルを共有するための方法が必要だった。MacBinary は明白な選 択だったが、MacBinary はファイル内に最初にデータフォークを格納する ので、A/UX から MacBinary ファイルをその場で編集しようにもできなかっ た。そこで Apple は MacBinary ファイルに格納されるフォークの順序を 逆にして（これで毎回リソースフォークを動かすことなくデータを簡単に ファイルに追加したり削除したりできた）、将来の拡張に備えていくつか の（使われることのなかった）オプションを追加し、これを AppleSingle と呼称した。
その拡張性のおかげで、AppleSingle は MacBinary よりもよいフォーマッ トである（Mac OS 8.5 で現われる新しい Finder フラッグさえサポートす る）が、重大な問題を一つ抱えている。ファイル転送用にこれをサポート するものがほとんどないことだ。電子メールプログラムは AppleSingle の 添付書類をデコードできるものが多いし、Fetch は AppleSingle ファイル をアップロードもダウンロードも両方できる。しかし、Web ブラウザはこ れに関してまったく役に立たない。MacBinary III がもたらしたファイル フラッグ問題が最初に持ち上がったとき、即座に考えたのは AppleSingle を布教すべきだということだったが、ほとんどのアプリケーションの現行 のサポートがまだない状況で、デベロッパーたちは AppleSingle をサポー トし、Mac コミュニティに新しいファイル拡張子を放つために必要な作業 を行うことをいやがった。MacBinary III はささやかな反抗の道だった。
結果として、AppleSingle は Macintosh ユーザー間の時折の電子メール メッセージに限定されている（Apple は AppleSingle をディスクイメージ を格納するときにも使っているが）。クロスプラットフォーム用のフォー マットとして、AppleSingle は失敗した。それは、Macintosh ファイルの 2 つのフォークを簡単には分割できないような方法で一緒にまとめるから だ。AppleDouble が求められる理由はここにある（下記を参照）。要する に、他の Macintosh ユーザーに添付書類を送るのでない限り、 AppleSingle を使う現実的な利点はなく、その場合でさえ AppleDouble も 同等に働くのである。
AppleSingle は 8 ビットフォーマットなので、AppleSingle ファイルは、 電子メールを使って送るとき、転送エンコード用フォーマットで保護しな ければならない。SMTP のような電子メールプロトコルは 8 ビットファイ ルのために安全性を保証していないし、要求もしていないからだ。
AppleDouble -- AppleDouble は Macintosh ファイルの 2 つのフォーク を分割ファイルとして格納する（タイプやクリエータなどの Finder 情報 はリソースフォークにまとめる）。AppleDouble もまた A/UX のために作 られた。AppleSingle を使って Mac OS と A/UX 間でファイルを共有でき るのは、双方のプログラムが AppleSingle を理解する場合だ。しかし、NFS （Network Filing System）を使って他種の Unix とファイルを共有しよう とする場合、こういった他のマシン上のプログラムが AppleSingle を理解 することはありそうもなかった。しかし、Macintosh ファイルを 2 つの分 割ファイルとして格納する AppleDouble の技法は、そういった他の Unix ユーザーがリソースフォークや Finder 情報を乱すことなくファイルのデー タフォークのみを編集できるようにした。インターネットのファイルサイ トで AppleDouble フォーマットで格納されたファイルにお目にかかること はない。これはアップロードする各ファイルのために 2 つのファイルを格 納することがばかげいているからだ。
しかし、Macintosh ファイルを分割する AppleDouble のやり方は、電子 メールで極めて役立つことがわかった。ファイルの各パートを一つのメッ セージ内で別々の MIME パートにできるからだ。これで、受信する電子メー ルプログラムが自分の理解できるパートだけを取り出すことができるよう になる。Mac の電子メールプログラムが AppleDouble でエンコードされた 添付書類を受け取れば、両方のフォークを読み、一緒にして元に戻すこと を知っている。しかし、Macintosh 以外の電子メールプログラムが AppleDouble でエンコードされた添付書類を受け取れば、データフォーク だけを保存し、リソースフォークは捨て去る。
実際、Eudora の作者 Steve Dorner 氏によって書かれた the Macintosh extensions to MIME によれば、AppleDouble は Macintosh ファイルを送 るときの標準である。AppleSingle と同様に、AppleDouble は Mac OS 8.5 で登場する新ファイルフラッグを失わない。したがって、これが将来は電 子メールプログラムのための初期設定のエンコード用フォーマットとして AppleDouble を選択させるだろう。しかし、AppleSingle と AppleDouble は両方ともこれらの新ファイルフラッグを格納できるからといって、古い アプリケーションが適切に新フラッグを読め、再び書き出すことができる わけではないことは覚えておこう。したがって、これらの フォーマット には何の変更も必要ないが、 アプリケーション には依然として必要で あろう。
再度いうが、AppleDouble はバイナリパッケージ用フォーマットなので、 どんな AppleDouble 電子メール添付書類も転送エンコード用フォーマッ ト、一般的には Base64 によって保護されなければならない。
uuencode -- uuencode は最も古いインターネットの転送エンコード用 フォーマットの一つである。電子メールと Usenet ニュースを運ぶテキス トのみの UUCP プロトコル上でバイナリファイルを転送できるようにする ために何年もの昔に設計された uuencode は、8 ビットデータを取り上げ て 7 ビットテキストに変換する。多くの uuencode ツールがあるが、ファ イルは、すべてファイル名とファイルに対する Unix パーミッション（一 般に 644 だが、他の番号も可能）を規定した“begin“行で開始するので、 簡単に認識できる。
uuencode のような転送エンコード用フォーマットは、本質的に圧縮ソフト ウェアの逆を行く。8 ビットのバイトの一群を取り上げて、一連の 7 ビッ ト文字でこれを表わす。したがって、転送エンコード用フォーマットでエ ンコードされたファイルは、エンコード後常に 35 % まで大きくなる。
uuencode は Macintosh ファイルのフォークについて知らず、Mac ファイ ルのデータフォークのみをエンコードする。Mac ファイルのすべてがリソー スフォークを持つわけではないし、この中に必要な情報を格納するものば かりではない（たとえば、Microsoft Word ファイルはリソースフォークを 持つが、そこにファイルに必須の情報はなにも含まれない）ので、 uuencode は Windows ユーザーにファイルを転送するための条件にあった 方法だとわかった。uuencode のためのサポートは Windows プログラムで より一般的なので、私は Windows ユーザーに添付書類を送るとき AppleDouble が失敗した場合は（受信者の電子メールプログラムが MIME 対応でない場合に起こりうる）uuencode に立ち戻る。
Base64 -- uuencode と同様に、Base64 は 7 ビットリンクでの伝送また は 7 ビットプロトコルの使用に耐えられるように 8 ビットファイルを 7 ビット文字を使って表わす。Base64 転送エンコード用フォーマットは、本 来インターネットのために開発されたものではなく、コンピュータがバイ ナリデータをプリンタに送るための PostScript レベル 2 用のものだった。
エンコードとデコードのための多数のユーティリティを誇る uuencode と 違い、Base64 はほとんど完全にユーザーに対して透過的で、電子メールプ ログラムが背後で処理する。この透過性は、Base64 が現代的なプログラム によって扱われる現代的なフォーマットになった結果として生まれた。昔 は、コンピュータとプログラムの性能がそれほどよくなかったので、ユー ザーが今よりも熟練する傾向があった。だから、たとえば電子メールプロ グラム内部に転送エンコードのためのサポートを埋め込む必要はそれほど なかったのだ。
Quoted-Printable -- Quoted-printable は、Eudora 内の QP ボタンの で唯一間接的に知っている人がほとんどだが、これは上部 ASCII 文字（発 音記号つきの特殊文字など）を 7 ビット形式で表わすために考案された転 送エンコード用フォーマットである。quoted-printable と他の転送エン コード用フォーマットの重要な違いは、quoted-printable でエンコードさ れたテキストが人間の識別可能な状態をほぼ維持するということだ。 Quoted-printable はファイルをエンコードするためには使われず、電子 メールメッセージのテキストのためだけに使われる。
我々はみな、行末にたくさん等号の付いた電子メールメッセージを見たこ とがある。これが quoted-printable でエンコードされ、しかし受け取っ た方でデコードされなかったメッセージの印である。通常これは、メッセー ジが quoted-printable でエンコードされていることを特定する MIME ヘッ ダが削除されたためである。この問題は主としてメーリングリストのダイ ジェストで持ち上がる。それは、メーリングリストソフトウェアが各メッ セージを残りと結合する前に、それから最も本質的なヘッダ以外のすべて を除去するからである。この問題の解決策は MIME ダイジェストを作成す ることだ。これはダイジェスト内の個別のメッセージのためにヘッダを維 持する。その代わりメールボックス内にダイジェストを溢れさせ、転送用 エンコード法を特定する特殊ヘッダをそのまま残すことを助長する。
BinHex -- 私は最も混乱するフォーマットを最後に残しておいた。 BinHexは、バイナリパッケージ用フォーマット と 転送エンコード用 フォーマットの両方であり、1980 年代初期に Tim Mann 氏によって TRS-80 用に開発され、1984 年に Yves Lempereur 氏によって Macintosh 用に完 全に書き直された。また、Yves は MacBinary フォーマットを作成したチー ムの一員であり、これをサポートするために BinHex 5.0 プログラムを書 いた。このことが混乱を招く原因となった。というのは、彼の BinHex 4.0 プログラムは BinHex フォーマットを使い、方や BinHex 5.0 は MacBinary を使うからだ。
<http://www.research.digital.com/SRC/personal/mann/trs80.html#binhex>
BinHex はインターネット上で Macintosh ファイルを伝送するときの両問 題を解決する。ファイルを BinHex でエンコードすれば、エンコーダはま ずファイルのフォークをひとまとめにし、その後、8 ビットファイル全体 を 7 ビットファイルに変換する。この機能の組み合わせは、BinHexをイン ターネット上で Macintosh を扱うための最も人気のある方法とした。それ は、何をやったとしてもオリジナルのファイルは元に戻ると、かなり確信 できるからだ。
私は、もはや BinHex が常によいものだというつもりはない。7 ビットリ ンクが一般的であった昔は素晴しかったが、今日の世界では、BinHex 化し たときに 30 ないし 35 % までファイルが大きくなることは、容量とダウ ンロード時間の不必要な浪費である。また、BinHex は Mac OS 8.5 の新し いファイルフラッグを格納しないので、近い将来さらに役立たずとなるだ ろう。
いずれにしろ、BinHex はしばらくの間どこかで消えることはないだろう。 BinHex のためのサポートは極めて広範に渡っていて、誰でも .hqx を認識 し、それをどう扱うべきか知っている（StuffIt Expander にドロップす る）。BinHexファイルは 7 ビットテキストなので、ひどい仕様のアプリ ケーションを存続させることはもっとありそうだし、昔は、電子メールメッ セージやブラウザのウインドウからテキストファイルにコピーし、保存し、 デコードすることは日常的だった。もし、今日のソフトウェアに BinHex テキストがあれば、恐らくなにか悪い事態が起こるかもしれず、そのファ イルが損傷を被る恐れは十分にある。BinHex テキストファーマットの他の 小さな利点は、BinHex コードの上に人間に読める説明を持てることだ。
人々が BinHex を好む理由について私が耳にしている主な根拠は恐らくそ れが機能するということだろう。これは本当だ。そして私は、誰かにひど い動きをするものに切り替えることを決して奨励するつもりはない。 BinHex デコーダは巨大なエンコードファイルを MacBinary デコーダより もうまく扱うという状況を聞いているし、MacBinary に関する MIME タイ プの上述した大失敗もまたトラブルの原因となってきた。しかし、同時に、 我々の目標は、今日の現代的なフォーマットに作用する問題を特定して終 息させることであるはずで、DOS のように、これまで使ってきたものに拘 泥することではないはずだ。
非営利、非商用の出版物およびウェブサイトは、フルクレジットを明記すれば記事を転載またはウェブページにリンクすることが できます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありませ ん。書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017
｜ 
｜ 