Macintosh（MacOS）のファイルをネットワークや他のOSで扱う際の 注意事項は、比較的よく知られていると思います。即ち、
当然ながら、Macintosh以外の環境で「転送するためのファイル形式」から 「本来のデータ」を抽出するユーティリティは多数作られています。 電子メールを取扱うソフトにも組込まれていることが多いようです。 ところが、その多くは、「本来のデータ」以外の「Macintosh固有情報」を 単なる「邪魔もの」として捨ててしまっているようです。
この状況は勿体無いと思ったので、 「Macintosh固有情報」を読み出す、 あるいは「本来のデータ」を抽出しながら 「Macintosh固有情報」も別ファイルで残す （具体的には、AppleDouble形式に変換することになる） という形のユーティリティを自作しました。 後者については、逆変換も作成しています。 自分自身が必要に迫られる度に必要な分だけ作っていたので、 最初に思い立ってから一通り揃うまでに３年余り掛かってしまいましたが、 とりあえず揃ったので公開することにしました。
各形式のファイルに含まれている「各種情報の並びを管理する情報」や 「Macintosh固有情報」から必要と思われる情報を適宜選り出して、 その内容を表示します。 どの情報を選り出すかは、作者が「作ったときの気分」で判断していますが、 変更は容易でしょう。 どの形式でも管理情報はファイルの冒頭（ヘッダ）にあり、 「Macintosh固有情報」もヘッダに含まれていることが多いので、 メッセージ等では全て「ヘッダ」と呼んでいます。
コマンド名は、MacBinaryを取扱う「macbinhead」、 Apple Single/Doubleを取扱う「applehead」、 BinHex4.0を取扱う「hqxhead」です。
元々は「データフォークを抽出して、他の部分も別ファイルで残す」 というユーティリティが欲しいという開発動機で作ったのですが、 現実的には、その「別ファイル」の規格として確立したものが 「AppleDouble」しか無かったので、 結果的には、「AppleDoubleへの変換」を行うツールになりました。
となると、逆変換（AppleDoubleからの変換）を一通り揃えれば、 「AppleDouble」を軸（ハブ）として経由することによって、 最小限のユーティリティ数で全ての変換ができる形になるので、 そのように揃えました。
実は「AppleDouble」を経由することによって、 プログラミングが楽になるという側面もあります。 情報を並べる順序が異なるファイル形式同志で変換しようとすると、 ファイルの中を前に行ったり後に行ったりせねばならないのですが、 「AppleDouble」はデータフォークが別ファイルになっているので、 後戻りせずに「一方のファイルの読み書きを保留する」だけで済む場合が多いのです。
「AppleDouble」に向けて変換する （結果のうち「ヘッダ＝Macintosh固有情報」のファイルを 単に無視すれば、「本来のデータ」を抽出したことになる）ユーティリティは、 MacBinaryから変換する「macbindiv」、 AppleSingleから変換する「applediv」、 BinHex4.0から変換する「hqxcnv」です。 当初、標準入力に変換元データを与えることができるようにするため、 オペランドを省略した場合には後ろから割り当てる仕様にしていたのですが、 誤操作の元になるので、2003年11月25日版で前からの割り当てに変更し、 標準入力に変換元データを与える仕様を取りやめました。 標準入力は変換先ファイルが既存の場合の上書き確認に用います。
「AppleDouble」から変換するユーティリティは、 MacBinaryに変換する「apple2bin」、 AppleSingleに変換する「applemerge」、 BinHex4.0に変換する「makehqx」です。
変換元のデータ内容が異常な場合の処理は、以下の考え方に基づいています。
プログラムは全て、unixのキャラクタインタフェースの環境（cshとか）で 使う前提で書いてあります。NEWS-OS Rel.6で動作確認しています。
MS-DOS上でも動作するように書いてあります （Quick C Ver.2で一通り確認済）が、 バイナリ入出力をリダイレクトで行うと正常動作しないので注意してください （標準入出力のモードを切り替える必要があり、厄介なので対応していません）。 MS-DOSではファイル名が8文字以内という制限があるので、 作者自身は以下のように名前を変更しています。 従う必要はありませんが、御参考まで。
「applehead→applehed」「macbinhead→macbinhd」 「applemerge→applemrg」「macbindiv→mcbindiv」 「apple2bin→appl2bin」、
なお、詳しくは動作確認していませんが、 Windows上のVisual C++ Ver.6でコンパイルすれば、 MS-DOSウィンドウ（MS-DOSプロンプト／コマンドプロンプト）で動作する Win32アプリケーションとして使えそうだということが判りました。 但し、MS-DOSとunixとで動作を変えてある部分は 基本的にMS-DOSの流儀に従わねばならないのですが、 一部（しばらく修正していないもの）のソースは そのまま使うとunixの流儀で作ってしまうので、 その部分だけ修正（冒頭の「MSDOS」という文字列を「WIN32」に変える）が必要です。 既に「WIN32」の場合の動作が冒頭に記述してあるものと、 元々「MSDOS」云々の記述が無いものは、変更不要です。
ちなみに、各ファイル形式の固有情報の納め方を表現する構造体の メンバーの命名にミススペルがあります。 注釈は概ね正しいスペルに直っていると思いますが、 プログラム本体の方は新たなバグの元になるので修正していません。 まあ、そこは御愛嬌ということで^_^;
Macintosh（MacOS）のファイルをネットワークや他のOSを介して 転送するためのファイル形式には、代表的なものが３系列あります。 いずれも、同じような目的に使われるものですが、 必要な情報をどのように配列してどう識別するかという 具体的な流儀は根本的に異なります。
なお、種々の流儀が生じるようになった歴史的な事情は、 A.C.Engst氏の解説をTidBITS翻訳チームが和訳したものにまとまっているので、 参考にしてください。
MacBinaryは、古くから最も一般的に用いられている形式でしょう。 ただ、古いゆえに、MacOSの新しいバージョンで 追加された一部の固有情報が表現できず、 それに対応するべく改訂版規格が２回出されているようです。 初版を「MacBinary I」、１次改訂版を「MacBinary II」、 ２次改訂版を「MacBinary III」と呼びます。
また、「MacBinary I」では、そのファイルがMacBinaryであるかどうかを 確実に判断する仕掛けが提供されていないという弱点 （ヘッダの特定部分がゼロかどうか確認するという、 大いに不安の残る方法しか無い）がありました。 「MacBinary II」以降では、ヘッダのCRC情報 （所定の計算式に当てはめることで、データが化けていないことを 一定の確率で保証するための「鍵」となる情報）を ヘッダ自身に埋め込むことで、この問題に対処しています。 このことも「MacBinary II」開発の動機の１つだったと推測されます。
MacBinaryの規格書は、例えば こちらで公開されています。 なお、MacBinary形式のファイルをunixやDOS/Windowsで管理する場合には、 拡張子を「.bin」とする習慣があります。
「AppleSingle」と「AppleDouble」は、 将来の拡張が無理無く収まることを意識しており、 MacOS以外のファイル形式も表現できることも目指している という意味でMacBinaryより優れた面がある形式です。 しかし、MacBinaryより後発であるゆえに普及の程度は低いようで、 unixやDOS/Windowsで管理する場合の拡張子に関する習慣も無いようです。
この規格系列の顕著な特徴として、 Macintoshファイルの全体を１つのファイルで表現する 「AppleSingle」フォーマットの他に、 「データフォーク」と「データフォーク以外の部分＝Macintosh固有情報」を 各々１個のファイルとして、 合わせて２つのファイルで１個のMacintoshファイルを表現する 「AppleDouble」フォーマットを規格化していることがあります。
この「AppleDouble」フォーマットは、 Macintosh以外のOSにおける使い勝手を考慮したものでしょう。 通常の利用方法では、「Macintosh固有情報」を除いた 「データフォーク」が「本来のデータ」であると考えることができます。 この「本来のデータ」だけにアクセスしたいと思い立った時に、 特に「変換」を施す必要が無く、 単に一方を「無視」すれば良いという状況にしているわけです。 そこで、Windowsの普及率の高さが確定した最近では、 電子メールにMacintoshファイルを添付する場合には 「AppleDouble」フォーマットを利用する流儀が推奨されています。
このページで公開するユーティリティでも、 データフォークを抽出する際には、残る「Macintosh固有情報」を 「AppleDouble」フォーマットでファイル化しています。
Apple Single/Doubleの規格書は、例えば こちらで公開されています。
付記： この話題について解説しているWWWページを検索してみると、 「MacintoshではAppleDoubleとBase64が同義に使われている」などと 混乱した説明をしている例が多々見受けられるようです。 これは、Macintosh用のメールソフトで、 「AppleDouble形式に変換して、さらにBase64でエンコードする」 （「エンコード」については、 次のBinHexの説明を参照してください）という動作を、 BinHexとの比較上、単に「AppleDouble」と呼んでいる例が多いからのようです。 また、Base64ではAppleDouble形式をエンコードし、 uuencodeではデータフォークだけを抽出してエンコードするという、 単なる習慣（おそらくは、各々の規格が普及したタイミングの問題） という以上の理由の全く無い使い分けが一般化していることも、 誤解に拍車をかけているようです。
BinHexは、unixやDOS/Windowsで管理する場合に 拡張子を「.hqx」とすることになっていることから、 そのまんま「HQX形式」と呼ばれる場合もあります。
この形式が他と根本的に異なるのは、 「アスキー形式へのエンコード」を前提とした規格であることです。 「アスキー（ASCII）」というのは米国における文字コード規格のことで、 そのまま国際規格である「ISO文字コード」の基礎になっており、 JIS規格の「7ビットローマ字」もASCIIを微修正したものです。 そのため、このような文脈で「アスキー形式」と言えば、 「英数字など、コンピュータにとって基本的な文字情報だけで、 内容が構成されたデータ形式」のことを指し示します。
一般に通信によってデータを交換する場合には、 「基本的な文字情報」以外の情報が正しく転送される保証が無い ということが頻繁に起こります。 最近でこそ、TCP/IP環境が普及して、 どんなデータでも正しく転送される状況が増えましたが、 それでも、電子メールなど文字情報を取扱うのが本来の目的である媒体では、 文字以外の情報が保証されない状況が残っています。
そこで、任意のデータを一定の規則に従って 文字情報（アスキー形式）に変換（エンコード＝符号化）してから転送し、 それを受け手側で元のデータに復元（デコード＝復号）する という方法が考え出されました。
アスキー形式へのエンコードを行う流儀としては、 他に「uuencode」「ISH」「Base64」などがあります。 これらは、単にデータをエンコードするだけであり、 デコード後の取扱いは、デコード結果を見て考える、 あるいはエンコードされたデータに付随して送られてきたデータに従う、 ということになっています （但し、「ISH」には、データ内容がMacBinaryであるという情報を 含めてエンコードできる仕掛けが用意されている）。
それに対して、BinHexは、「Macintosh固有情報」を含む Macintoshファイルに関する情報を一定の規則で並べながら、 同時にエンコードも行うという、 両方の機能が一体化した規格になっています。 （実は、「BinHexをデコードしただけのファイル」というのも、 原理的にはMacBinaryやAppleSingleと対等な規格として 成立し得るのですが、現実には使われていません。）
おそらくインターネットブームの影響でBase64がエンコード方式の 事実標準の地位を確立してしまったためだと思われるのですが、 最近ではMacBinaryやAppleDoubleをBase64でエンコードするのが主流であり、 BinHexが使われることは無くなってきたようです。 そのため、BinHexの規格自体が改訂されず、 MacOSの新しいバージョンに対応できなくなっており、 益々BinHexが使われなくなるという循環構造になっているようです。
なお、BinHexにはBinHex4.0とBinHex5.0があるようなのですが、 この２つは「Macintosh固有情報」の並べ方が根本的に異なり、 全く別の規格であると考えた方が良い状況になっているようです。 現実問題として、BinHexといえば多くの場合BinHex4.0のようで、 BinHex5.0にはお目にかかったことがありません。 このページで公開するユーティリティも、 BinHex4.0のみに対応しています。
BinHex4.0の規格書は、例えば こちらで公開されています。
伝統的にはファイルには ハードウェアの都合に応じた構造があるのが普通でした。 しかし、その考え方を崩して、 どのファイルもOSのレベルでは単なる「バイト列」であり、 構造はアプリケーションの都合に応じて アプリケーションが設定するという考え方を徹底したのが、 unixの画期的な特徴の１つです。 この特徴ゆえに、unixは新しい技術にも容易に対応することができ、 拡張性の高い柔軟なOSになることができたと考えられます。 そして、この特徴は、MS-DOSやWindowsにも引き継がれました。
Macintosh（MacOS）も、根本的なところでは、この考え方を継承しています。 しかし、Macintoshのファイルには、最小限の「構造」があります。 それが「データフォーク」「リソースフォーク」と呼ばれるものです。 このうち「データフォーク」は全くの「バイト列」であり、 unixやMS-DOS/Windowsと同様に考えれば良いものです。 一方の「リソースフォーク」には、システムのレベルで制御する構造があり、 その一部はシステムがどのように利用するか決まっています。 つまり、MacOSは構造のある部分と構造の無い部分を併用することによって、 システムが高度な操作を行えるようにしつつ、 拡張性も確保しようとしているわけです。 そして、この「リソースフォーク」は 必然的に「Macintoshに固有の構造」になりますから、 その内容は「Macintosh固有情報」であるということになります。
そして、Macintoshのファイルには、 リソースフォークの他にも「固有情報」と呼ぶべきものがあります。 それは「ファイル管理情報」に分類される内容の情報です。 Macintoshの管理情報は他のOSと較べて矢鱈と内容が多く、 他のOSには存在しない情報が多く含まれているのです。 ここで「ファイル管理情報」と呼んでいるのは、 ファイルに関する情報のうち、ファイル本体の中に埋め込まれる形ではなく、 全く別に管理されているもののことです。 ファイル管理情報のうち、 おそらくほとんどのOSが備えているであろうと思われるのは「ファイル名」です。 OSが「ファイル」というものを扱う限り、 各々のファイルを他のファイルから識別する手段が必要ですが、 その識別をファイルに「名前」をつけることで実現するために 管理しているのが「ファイル名」です。 また、多くのOSには、ファイルの更新日付を 「ファイル管理情報」として管理する仕組があります。
Macintoshに固有の「ファイル管理情報」として有名なのが
「タイプ情報」「クリエータ情報」です。
これは、機能的にはunixやMS-DOS/Windowsの「拡張子」に対応します。
「拡張子」とは、ファイル名の末尾の部分のことで、
unixでは、これをファイルの種類を区別する目的で使う習慣があります。
MS-DOSでは、この習慣を「OSの動作に関わる規則」にまで昇格し、
実行ファイルは特定の拡張子を有さねばならないことになりました。
Windowsは、この規則を更に発展させ、
全ての拡張子はファイルの種類を規定するものであり、
各拡張子に対して、その種類のファイルを取扱う標準アプリケーションを登録し、
ファイルを「開く」ことをユーザが指示すると、
OSが対応する標準アプリケーションを自動的に起動することになりました。
「拡張子」に対するWindowsの考え方は、
実はMacintoshの流儀を模倣したものです。
しかし、MacintoshがWindowsと根本的に違うのは、
Windowsの「拡張子」が「ファイル名の一部」であるのに対し、
Macintoshの「タイプ情報」「クリエータ情報」は
ファイル名とは別に管理されているということです。
ちなみに、２種類あるのは、同じ種類の形式で記録されているファイルでも、
起動するアプリケーションをファイル毎に変えることができるようにするためです。
また、Macintoshは当初からGUI（Graphic User Interface ＝文字情報ではなく画像情報で示された操作対象に対して 操作を指示する方式）ベースで設計されているため、 画面上でファイルを示す「アイコン」を 画面のどの位置にどのように表示するか規定する情報も、 「ファイル管理情報」として管理しています （「アイコン」にどのような画像を用いるかは、 「リソースフォーク」で指定します）。
さらに、Macintoshは他のOSで「ファイル名」の付け方に強い制限 （例えばMS-DOSなら8文字＋拡張子3文字の計11文字で、 使える文字も限定）があった時代から、 長いファイル名を、比較的自由に命名できるようになっていました。 従って、このような自由な命名ができないOSでファイルを管理するには、 そのための短いファイル名を別途命名する必要がありました。 そこで「Macintoshのファイルを転送するためのファイル形式」では、 「Macintosh上でのファイル名」（通常“Real Name”と呼ばれる）も 「固有情報」の１つとして取扱われています。
一般に、Macintoshのファイルを他のOSで使う必要がある場合、 そのファイルは「どちらのOSでも使えるという建前で設計されている」 ファイル形式（テキスト・JPEG・GIF・TIFF・PNG・DVI・PDFなど、 あるいは開発者がデータの移行を保証しているソフトウェアのデータ形式）に なっていることが多いでしょう。 そして、そのようなデータはMacintosh上では 「データフォーク」に収録することになっています。 それゆえ、Macintoshのファイルから「データフォーク」のみを抽出して、 他は見もせずに捨ててしまうという流儀が一般化しています。
しかし「データフォーク」以外の所謂「ヘッダ部分」には、 「リソースフォーク」の他、「タイプ情報」「クリエータ情報」 「Macintosh上でのファイル名」といったような 多様な情報が収録されているのです。 これを利用しない手は無いと思うのですが、どうでしょう？
補足： 「MacOS X」では、Macintosh固有情報を廃していこうという方針になりましたが、 旧来のデータやアプリケーションを捨ててしまうわけには行かないので、 従来のMacintosh固有情報を有するHFS（Hierarchical File System）も 使えるようになっています。