'99.7.17 ('04.8.25更新)
同じようで違うのがMacとWindows。その違いを知ればファイルのやり取りも難しくありません。データ交換に関連する違いとその注意点、解決方法をまとめました。
LAN、WAN、サーバ関連、エミュレータ、遠隔操作ソフト、プリンタの共有とそれらのセキュリティに関しては「MacとWindowsを繋ごう」として独立しました。
MacからWindowsへのファイル送信には幾つか注意点がありますが、一番問題なのはMacBinary (マックバイナリ) ですね。Macのファイルにはデータフォークとリソースフォークという２つのデータ保存領域があり、Mac同士でのファイル送信時にはその２つをまとめ、さらにクリエータとファイルタイプ、作成日、修正日等のファイル情報 (Finder情報) を入れたヘッダを付属させて送信します。そのパッケージ形式をMacBinaryといいます。これはファイル圧縮時にも使います。
一つのファイルでも、役割の違うデータがそれぞれ別の場所にあるので、一つに纏めないと送信や圧縮ができないからですね。
・Windowsの送信ファイルの構造
| データのみ |
・MacBinaryの構造
(Macのファイル構造ではなく、あくまで送信や圧縮時に使う形式)
| ヘッダ | データフォーク | リソースフォーク | コメント |
ファイルによって構成が変わります。
| ヘッダ | データフォーク | リソースフォーク |
| ヘッダ | データフォーク | コメント |
| ヘッダ | リソースフォーク | コメント |
| ヘッダ | データフォーク |
| ヘッダ | リソースフォーク |
リソースフォークには通常、カスタムアイコンやプレビュー画像や、ファイルを開いたときのウィンドウサイズ等のデータが含まれています。アプリケーションのファイルには、リソースフォーク部分にUI (ユーザインターフェース) にかかわる大部分のデータが入っていて、Macでは必要不可欠なデータ領域です。
リソースフォークの後ろにはGet Infoコメントが付加されることもあります。Finderの「情報を見る (Get Info)」で書き込めるファイルに添付するコメントで、記述があれば付加されます。(コメントの保存に対応してないアプリケーションも多いので注意。逆にコメントを消すならNoComment (フリーウェア))
しかし、Windowsとのデータ共有ができるテキストやGIFやJPEGなどでは、データフォーク部分だけがあれば良く、それ以外の部分を送っても邪魔になります。Windows側でファイルが開けなかったり、そうでなくとも余分なデータがくっついていることになります。Macでは送信や圧縮時にはリソースフォーク等も一緒にするのがデフォルトなので、データフォーク単独で送るようにする工夫が必要になってきます。
MacBinaryの詳細は「MacBinaryの規格」でどうぞ。
MacBinary以外のパッケージ形式もあります：
AppleSingle (ほとんど使われていない。MacBinaryと違ってリソースフォークが前)
AppleDouble (主にメールの添付ファイルに使われる)
BinHex (添付ファイルやWeb上のダウンロードファイル形式として使われてきたが、OS8.5以降のicon badgeやcustom routingのFinder情報の保存に対応していない。MacBinaryはIIIで対応済み)
■
OS Xでは従来との互換性のために、リソースフォークのあるファイルも扱えるようになっていますが、OS X専用のCocoaアプリケーションでは、拡張子の採用とともにファイルはデータフォークだけになります。
また、OS Xでは255文字までのファイル名を扱えますが、MacBinaryでは最長でも63バイトまでしか扱えません。
Macのアーカイブソフトでは、デフォルトはMacBinaryで保存するようになっています。Windowsへ送るためのファイルはMacBinaryで保存しないように指定します。Windowsで一般的なアーカイブ形式はLHa (.lha、.lzh) とZip (.zip) です。CompactPro (.cpt) 形式はもっぱらMac用なので使えません。自己解凍型のファイルは相手の環境では (基本的に) 解凍できないので気をつけましょう。
LHa形式の場合、MacLHA (フリーウェア) でアーカイブするならメニューで[View][Show Type]を選び、MacBinaryのチェックを外して保存します。Windowsな環境の人ならLHa形式の圧縮ファイルを解凍するツールは普通持っていますね (たとえばLhasa (フリーウェア) 。Zipも解凍)。
Zip形式のアーカイブはWindowsでは一般的ですね。MacならZipItやMacZip (フリーウェア) が有名です。これもMacBinaryを使わないで圧縮すればデータフォークのみになります。
StuffIt (.sit) 形式ならそのまま何もせずに圧縮保存しても、Windows側でAladdin Expander (StuffIt ExpanderのWin版) (フリーウェア) さえあればデータフォークだけの解凍が可能ですが、Windowsでの普及はいまいちのようです。Macでは標準とも言える形式なんですけどね。 (この場合余分なデータであるリソースフォークをあらかじめ取っておけば、ファイルサイズが小さくなります。ResCleaner (メールウェア) 等 )
Macで受け取った時はStuffIt Expander Mac版 (最新版はZipとLHaにも対応、フリーウェア) さえあれば何でも解凍できそうですが、LHa形式の解凍はまだすごく心許ないのでLHA Expander (フリーウェア)もあるといいです。これは.exeの自己解凍型まで扱えて便利です。
アーカイブした後にファイルを送る段階では、ファイルをそのまま送る場合と同じ点をご注意下さい。余分なヘッダがついていて解凍できないことにもなります。
・圧縮したファイルがMacBinaryで送られる場合1
(元のファイルはMacBinaryを使って圧縮)
| ヘッダ | データフォーク | リソースフォーク | ||
| ヘッダ | データフォーク | リソースフォーク | ||
・圧縮したファイルがMacBinaryで送られる場合2
(元のファイルはMacBinaryを使用せず圧縮)
| ヘッダ | データフォーク | リソースフォーク |
| データフォーク |
・圧縮したファイルがデータフォークのみで送られる場合1
(元のファイルはMacBinaryを使って圧縮)
| データフォーク | ||
| ヘッダ | データフォーク | リソースフォーク |
・圧縮したファイルがデータフォークのみで送られる場合2
(元のファイルはMacBinaryを使用せず圧縮)
| データフォーク |
| データフォーク |
てことは、Mac to Macだと
MacBinaryで圧縮したファイルならば、その圧縮ファイルがデータフォークのみで送られても受け手のMacで解凍でき、個々のファイルのリソースフォークやクリエータ情報等は失われないのです。メールソフト (PostPet2とか) でBinHexやAppleDoubleが使えなくても、事前に圧縮しておけばBase64で送っても大丈夫。
Windowsのファイル名にはファイルタイプを示す拡張子が必要で、それが無いと(ダブル)クリックしてもアプリケーションで開けません。最近はMac用のソフトでも拡張子を付けて保存するものも増えてきましたが、Windowsとのファイル交換を前提にするなら付け忘れないようにしましょう。
Windows側では、拡張子を表示しない設定にしていると見えないのですが、Macから送られたファイルが開かない場合に拡張子をつけることで解決することもあります。Mac側では、受け取ったファイルの拡張子からファイルタイプとクリエータを自動設定します (「File Exchange (PC Exchange)」コントロールパネルで対応アプリケーションとファイルタイプを変更できます)。
OS Xでは、専用のCocoaアプリケーションでは拡張子式になります。従来との互換のためMac式と拡張子式が混在しています。拡張子の表示、非表示はFinderで設定できますがファイルごとに切り替えもできます。
| ファイル形式 | 拡張子 | ファイル形式 | 拡張子 |
|---|---|---|---|
| テキスト | .txt | Illustrator | .ai |
| HTML文書 | .html、.htm | MS Excelブック | .xls |
| PDF文書 | CSV形式 | .csv | |
| JPEG画像 | .jpg、.jpeg | MS Word文書 | .doc |
| GIF画像 | .gif | リッチテキスト形式 | .rtf |
| PNG画像 | .png | LHa形式アーカイブ | .lzh、.lha |
| Photoshop形式 | .psd | Zip形式アーカイブ | .zip |
Mac OS 8以前は最長31文字(半角で数えて)まででしたが、OS XになってWindowsのロングファイル名に近くなり、255文字(Unicodeで。半角も全角も1文字)まで使るようになりました。まだ対応していないソフトも多いので気軽には使えませんけど。
OS 9のFinderは31文字までですが、OS内部では長いファイル名に対応しています。OS X上で付けた長いファイル名は、OS 9のFinderでは「abcdefghijklmnopqrst#012345.txt」と拡張子の前に#に続く6桁の16進数を付加し31文字に縮めて表示します。うっかりファイル名変更しなければ、長いファイル名が保持されます。
OS Xでは、HFS+使用時にはUTF-16で510バイトまで。サロゲートペアは4バイト、合成文字は4バイト以上使うので、それらを含むと255文字になりません。Terminal等のUNIX系アプリケーションで使う時にはUTF-8になります。
Windowsのロングファイル名は、パスとして260文字(半角で数えて)まで。たとえばDドライブなら「D:\<256文字>NUL」です。
OS 9以前で使えない文字は「:」だけ、OS Xでは「:/」が使えず、先頭にドット「.」のつくファイルはFinder上で見えないファイルになります。(HFS+なら/は使えますが、UFSやUNIX系のソフトで使う時に問題が出たりします)
Windowsは使えない名前が多いです。文字は「\/:*?"<>|」が使えません 。「,;」は他の使えない文字をファイル名にしようとした時のアラートに表示されますが使えます。が、CD書き込みソフトに拒否されたりします(Jolietで「;」が使えませんし)。さらに、次の予約名は使えません：CON、PRN、AUX、CLOCK$、NUL、
COM1、COM2、COM3、COM4、COM5、
COM6、COM7、COM8、COM9、LPT1、
LPT2、LPT3、LPT4、LPT5、LPT6、
LPT7、LPT8、LPT9
ドット「.」から始まるか、半角スペースおよびドットで終わるファイル名も使えません。(ドットから始まるファイルだけは、Macから持って行けばWindows上で存在できます)
半角英字の大文字と小文字を区別しないのはどちらも同じです(OS XのファイルシステムはHFS+とUFSとどちらも使用可能ですが、UFSにあるファイルはUNIX式に大文字小文字の区別があります)。
また、ファイル名にはなるべく記号を使わない方がいいでしょう。機種依存文字は使えませんし、従来のコードとUnicodeとの変換テーブルの違いから、MacとWinで一部の記号文字の割り振りが違い、文字化けすることもあります。
[濁点半濁点が化ける話]
OS Xのファイル名はUnicodeで記録されますが、Normalization (正規化) として、かなの濁点半濁点つきの文字等を合成文字として、基底文字と結合文字 (濁点半濁点) に分離して保持する方式です。Windows NT、2000、XPもファイル名はUnicodeですが分離したりしません。結合文字未対応のソフトで扱うと、Windows 95、98、MeのShift_JISのファイル名との変換時に問題が出ますし、2000やXPとのやりとりで失敗することもあります。
日本語対応のMacとWinのファイル交換ソフトならば、それらは考慮してあるはずですが。
ISO 9660(レベル1) のCDや、古いMac (OS 8.0まで) のPC Exchangeで読ませるDOSディスクでは8.3形式しか使えません。8.3形式は、ファイル名は半角8文字と区切りの「.」と3文字の拡張子。ディレクトリは8文字のみ。使える文字は、ISO 9660規格のCDなら英大文字と数字、アンダースコアのみです。DOSディスクなら英小文字 (大文字と区別されない) 全角文字 (8文字部分に4文字まで)、「!#$%&'-()@^_`{}~」の記号も使えます。「SP"*+,./:;<=>?[\]|」が使えません。(SP=半角スペース)
参考:
HFS Plus Volume Format (Mac)
Naming a File (win)
UAX #15: Unicode Normalization Forms
JIS記号の UCS BMP へのマッピングの問題および MS漢字とシフトJISの違い
MacからWinのフォーマットのメディアに書き込むと、Win側に、書き込んだ覚えの無いフォルダや隠しファイルが作られます。リソースフォークとファイル情報 (Finder情報) 、Macで使うときのディスク情報等です。Macで再利用しないなら消しても大丈夫ですが、「Desktop Folder」や「Trash」というフォルダならWinで使えるファイルが入っている可能性もあります。
OS 9以前：
(太字はフォルダ、グレーはWindowsでも隠しファイル。いつもすべてあるわけではありません。メディアやOS (PC Exchange) のバージョンによっても変わります。以下はOS9.1で書込み)
| TheVolumeSettingsFolder | Resource.frk | Deskto~1 |
| Openfo~1 | ||
| DesktopPrinters DB | - | |
| Finder.dat | - | |
| OpenFolderListDF_ | - | |
| TheFindByContentFolder | - | - |
| Desktop Folder | Macのデスクトップに引き出されたファイル | - |
| Trash | Macのゴミ箱に入れて消してないファイル | - |
| Resource.frk | Macからコピーしたファイルのリソースフォークがファイル毎にある | - |
| Desktop DB | 古いPC Exchangeだと「Desktop」ひとつ | - |
| Desktop DF | - | |
| Fileid.dat | - | - |
| Finder.dat | Finder情報 | - |
| !openfol.der | 古いPC Exchangeにだけある | - |
■
OS X：
SMBやWebDAVでWinとOS Xを繋ぐと、頭に「.」がついたOS Xから見て不可視のファイルがWin側に作られます。
また、Winから覗くとMac上の不可視ファイルも見えます。
OS Xなら、「TinkerTool」というシステム環境設定を入れると、すべての不可視ファイルがFinderで見えるようになります。
■
DAVE等の接続ソフト経由のデータ送信では、リソースフォークとファイル情報 (Finder情報) を保持するために、それぞれ少し違う形式で不可視ファイルをWin側に作ります。
JIS、Shift_JIS、EUC-JP、Unicode 等の規格で決められた文字だけ使っていればいいのですが、今程ネットが盛んでなかった昔の名残りで、特定の機種だけでしか読めない文字が存在します。テキストだけでなく、ファイル名、HTML文書、PDF文書、CSVデータ、Illustrator内の文字等、文字を使うあらゆるところに関係してきます (Photoshop等で画像化された文字は問題ありません。Illustratorならアウトライン化すれば大丈夫)。通常の日本語変換では現れなくとも、文字パレットや文字コード表を出して文字を直接記述する時は気をつけましょう。その旨指摘があるはずです。
代表的な機種依存文字は○の中に数字がある「丸付き数字」と「ローマ数字」と「ハートマーク」です。それらはMacで書いてもWindowsで読めないしWindowsで書いてもMacで読めません。記号は機種依存のものが多いので使う時には気をつけましょう。(ローマ数字は半角アルファベットのIVXで代替するのが一般的です。フォントを細明朝体か中ゴシック体にすればMacでもWinの記号文字が表示されますけど)
送信前に文字コード変換ソフト (ふみばこ (Mac、フリーウェア) 等) を使う手もあります。「Macの機種依存文字→Windowsの機種依存文字」になるのですが、Macの方が記号が多く完全に置き換えることはできないし、もとから機種依存文字を使わないのが合理的ですね。
Winからの文書の機種依存文字をMac用に変換するときは ふみづかい (Mac、フリーウェア) が使えます。Macのフォントにない文字は変換しようがないのでご注意ください。
漢字以外で使える全角文字 (JIS X 0208)
(1区〜8区、JISの2121〜2840、Shift_JISの8140〜84BEの範囲の文字. この範囲外に使えない同じ形の文字もあるので注意)
| 、。，．・：；？！゛゜´ ｀¨＾￣＿ヽヾゝゞ〃仝々〆〇ー ―‐／＼〜‖｜…‥‘’“”（） 〔〕［］｛｝〈〉《》「」『』 【】＋−±×÷＝≠＜＞≦≧∞∴ ♂♀°′″℃￥＄¢£％＃＆＊＠ §☆★○●◎◇◆□■△▲▽▼※ 〒→←↑↓〓 ∈∋⊆⊇⊂⊃∪∩∧∨¬⇒⇔ ∀∃∠⊥⌒∂∇≡≒≪≫√∽∝∵ ∫∬ʼn♯♭♪†‡¶◯ ０１２３４５６７８９ ＡＢＣＤＥＦＧＨＩＪＫＬＭ ＮＯＰＱＲＳＴＵＶＷＸＹＺ ａｂｃｄｅｆｇｈｉｊｋｌｍ ｎｏｐｑｒｓｔｕｖｗｘｙｚ ぁあぃいぅうぇえぉおかがき ぎくぐけげこごさざしじすずせぜ そぞただちぢっつづてでとどなに ぬねのはばぱひびぴふぶぷへべぺ ほぼぽまみむめもゃやゅゆょよら りるれろゎわゐゑをん ァアィイゥウェエォオカガキ ギクグケゲコゴサザシジスズセゼ ソゾタダチヂッツヅテデトドナニ ヌネノハバパヒビピフブプヘベペ ホボポマミムメモャヤュユョヨラ リルレロヮワヰヱヲンヴヵヶ ΑΒΓΔΕΖΗΘΙΚΛΜ ΝΞΟΠΡΣΤΥΦΧΨΩ αβγδεζηθικλμ νξοπρστυφχψω АБВГДЕЁЖЗИЙКЛ МНОПРСТУФХЦЧШЩЪ ЫЬЭЮЯ абвгдеёжзийкл мнопрстуфхцчшщъ ыьэюя ─│┌┐┘└├┬┤┴┼━┃ ┏┓┛┗┣┳┫┻╋┠┯┨┷┿┝ ┰┥┸╂ |
つぎに、JISの第3水準、第4水準の漢字もOS 9以前のMacでは読めません。以下のWindowsの文字です。
上記は、DTPの規格、Adobe-Japan1-4には含まれています。新JIS (X 0213、JIS2000ともいう) をShift_JISやEUC-JPで使う時には同時に使えない文字ですが、Unicodeなら同時使用できます。
新JISでは第3、第4水準の漢字と多くの記号が追加されましたが、WindowsやMacではShift_JISの拡張として取り入れられることはなく、Unicodeとして実装されます。となると、文字データをUnicodeで保存するソフトでないと新JISで追加された文字は使えないってことですね。
OS X 10.1ではUnicode 3.2に対応し、新JIS (X 0213) のすべての文字をサポートしていて、第3、第4水準の漢字を扱えます。また、Adobe-Japan1-4にJIS X 0213を追加したAPGS (Apple Publishing Glyph Set) なので、上記Windowsの拡張漢字とX 0212の文字も使えます (ヒラギノフォントが対応。APGSを含んだAdobe-Japan1-5対応のヒラギノは10.2.4から)。OS付属のTextEdit (テキストエディット) はUnicodeで記録できますが、古いフォントや古いアプリケーションでは使えないので注意しましょう。Windowsの方はXPの次で新JIS対応予定です。
■
OS 9以前やWin95、98、Meでも、第3、第4水準を表示する新JIS対応フォントを使えば、今すぐに表示も交換も可能になります(WinNT、2000、XPでは使えません)。メールの場合は、ISO-2022-JP-3に対応したメーラーが無い場合は添付ファイルとして送信します。
Mac用フォント：JIS X 0213 free font for Macintosh
Win用フォント：Kandata: JIS X 0213 conforming free TrueType font
関連情報：新JIS漢字実践情報
■
また、半角文字では、ドイツ語スペイン語等の西欧のアルファベットに表れる特殊文字 (ウムラウトやアクセント付き文字等) が8bitコード部分にありますが、Macは独自コードなのでWindowsのISO 8859-1規格 (とほぼ同じコード) と互換性がありません。欧文だけの文書ならISO 8859-1で保存できるソフトを使うか変換ソフトで変換します。(日本語は変換すると文字化けします。8bitコード部分はそのまま送ります)
変換ソフト：MacWinText(macwintext-10.hqx) (Mac、シェアウェア)
FTPソフトのFetch (Mac、シェアウェア)、NetFinder (Mac、シェアウェア) には変換機能 (ISOコード変換) があります。
日本語とそれらの文字が共存した文書の場合、Word形式かリッチテキスト形式で多言語の文字が保存できます。単なるUnicodeでは、フォント情報のないUnicodeの多言語テキストをちゃんと表示できるソフトがまだ多くありません。できるのはWWWブラウザとOS X付属のTextEdit (テキストエディット) くらいかも。MacのSimpleText等のエディタで、文字単位のフォント指定だけで特殊文字を表示した文書は、フォント情報がリソースフォークに保存されるのでWindowsへは伝えられません(コードも違うし)。TextEditはUnicodeのリッチテキスト・フォーマット (RTF) で保存できます。WindowsのWord等RTF対応ソフトで表示できます (Windowsのフォントにない文字に注意)。
OS 9以前のMacはCR、OS XはUNIXですからLFが標準、WindowsはCR LFです。最近はOS X付属のTextEditのようにWebに対応してどのコードでも正常に改行されるテキストエディタも多いですが、MacからWindowsへ送る場合、改行されないと酷いことになるのでCR LFにしておくと安心です。WindowsからMacの場合は余分なLFが□ (とーふ) に見えたりしますが、改行されないわけではないので目で読むだけならあまり支障ありません。
CSV (コンマ区切りのデータ) やタブ区切りのデータでは、改行部分が違うと認識されないので、各々の環境に合わせた改行コードに変換します。なぜかMacではタブ区切り、Winではコンマ区切りが多いようですから、相手のソフトによっては区切りの変換も必要になるかもしれませんね。
Macでは、mi (フリーウェア) やYooEdit (フリーウェア)、Jedit (シェアウェア) 等のテキストエディタかテキストコード変換ソフトの ふみばこ (フリーウェア) 等で改行コードの変換ができます。
Windows側でも、TeraPad (フリーウェア) や秀丸エディタ (シェアウェア) やEmEditor (シェアウェア) 等のエディタや変換ソフトのCoDesk (フリーウェア) 等で変換できます。
コンマとタブの変換も大抵のテキストエディタで可能です。
変換ソフトを使ってMac用フォントをWindowsで使ったり、その逆もできます。
TTConvert (PostCard ウェア) Mac上でMacのTrueType FontをWindowsのFontへ。
TrueKeys ($50) Mac上で双方向の変換ができます。2バイトFontにも対応。
TransType ($49.9) こちらも双方向。Mac版とWin版があります。
OS XではWindowsのフォントがそのまま使えます。OS X側のアプリケーションによっては使えないこともありますけど。MacIEでMSゴシックが使えなくて残念
MacのフォーマットはWindowsで読めませんが、WindowsのDOSフォーマット (FAT) は一部例外を除きMacで読むことができます。なので、フロッピーやMOで渡す場合には、基本的にDOSフォーマットしたディスクでやり取りします。
Macでファイルをコピーすると、データフォークとリソースフォーク、Finder情報等は別々のファイルに保存されます。Macからは通常のファイルにしか見えませんが、Winで読む時はデータフォークのみ利用できます。参照：不可視ファイル
Mac OS8.1 以降なら31文字 (半角で数えて) までのファイル名が使えます。
MOの640MB以上のDOSフォーマットはMac標準で読めません。後述のツールが必要です。(OS X 10.2.1で640MBが読めるようになったらしいです。1.3GBは未確認)
NTFSフォーマット のメディアはMacでは読めません。読み込みツールも無いようです。Virtual PCでもダメらしい。
Macのフォーマット：
Windowsのフォーマット：
フロッピードライブは、iMac以降なくなったので持ってない人もいます。あっても外付けの他社製になりますが、たいていDOSフォーマットも読めます。古いMac標準のフロッピードライブでは、720KBと1.44MBのDOSフォーマットが読めます (NEC PC98の1.25MBのフロッピーはMacで読めません。640KBならOS付属のDOS640K Driverという機能拡張書類を入れれば読めます。Mac側のドライブで720KBのDOSフォーマットすればPC98で読めます) 。
MacでフロッピーやMOをDOSフォーマットできると便利ですが、できないドライブ (ドライバが未対応の場合) もあります。だったらDOSフォーマットされたメディアを買ってくればいいんですね。
DOSフォーマットディスクを読むこともできないダメなMac用MOドライブ (ドライバ) も無くはありませんから、Windowsから送る時は確認した方が確実ですし、Macユーザなら買う前にちゃんと確認しましょう。
OS X 10.2未満のOS Xでは、DOSフォーマットのフロッピーやMOが読めないことが多いですね。マウントされないときはボリューム名を半角英数字にしてみましょう。それでだめなら、面倒ですがOS 9で起動し直せば読めます。OS 9にも専用ドライバを入れておけば安心ですね。
CD-R/RWで書き込む場合にはファイル名が問題になります。フォーマットを何にするかが重要です。Windows側で日本語のファイル名を使った場合、Joliet (ジョリエット) 形式で焼けばOS Xでも読むことができます。OS 9以前ならMacにJolietフォーマットのロングファイルネームを読めるようにする機能拡張 (後述) を入れる手が一番簡単です。(Mac側でJolietで焼けるソフトが少ないのが問題)
Macからは、Apple ISOで日本語ファイル名を使って書き込めばWindowsで読むことができますが、OS Xでは文字化けしてしまいます。Hybrid CD-ROMにして、“HFSかHFS+”と“Apple ISOかJoliet”を使えばOS 9以前とOS XとWindowsとで読めるCDにできます。(Windows側でHybridで焼くのが難しいのが問題)
Mac OS9.2から標準の書込みソフトDisc Burnerのフォーマットの「標準 (HFS+/ISO 9660)」はHybridですが、日本語ファイル名のファイルをWinで読めなかったりします。Mac以外で使うには信頼度がまだ足りません (ver.1.0.2で確認)。
そもそも、データ用CDの標準規格ISO 9660が古くファイル名の制限がきついため、MacもWinも独自の拡張をしたり独自の規格を作ったことがややこしさの始まりでした。現在はUDFという新たな標準規格ができましたが、まだまだ従来の規格に取って変わるまでは行きません。
参考：
オレンジフォーラム
OSTA Universal Disk Format Specifications (UDFの規格)
DVD-ROMの規格は統一されていますが、書き込み可能DVDの記録フォーマットは色々あります。容量はDVD-RAM以外は4.7GB。一方、ファイルフォーマットの基本はUDFかUDF Bridgeです。UDFならMacとWinの互換性はあまり気になりませんが、標準で未対応のOSではドライバのインストールが必要です。UDF Bridgeなら、UDFとして読めない環境ではISO 9660のディスクとして殆どのOSで読むことができます (ファイル名は8.3形式)。しかし、FAT32 (Win用) やHFS、HFS+ (Mac用) での記録もできてしまうので気をつけましょう。あとは送る相手の機器で再生できるかどうかが大問題ですね。
現在大きく分けて3種類の記録フォーマットがあります。
| ○ | フォーマット | 書込書換 | 利点 | 欠点 | 規格作成 |
|---|---|---|---|---|---|
| 1 | DVD-RAM | 書換10万回 | 書換回数が多い
家電のDVDレコーダとしてはトップシェア 9.4GB版やケース入りもある |
DVD-ROMドライブでは読めない | DVD Forum |
| 2 | DVD-RW | 書換千回 | DVD-ROMドライブで読みやすい | - | |
| DVD-R | 書込1回 | 多くのDVD-ROMドライブで読める | - | ||
| 3 | DVD+RW | 書換千回 | DVD-ROMドライブで読みやすい 追記しやすい |
- | DVD+RW Alliance |
| DVD+R | 書込1回 | 多くのDVD-ROMドライブで読める 追記しやすい |
- |
参考：
DVD技術解説
DVD Media Technical Report
スマートメディア、コンパクトフラッシュ、メモリースティック、USBメモリ等のフラッシュメモリ・メディアのフォーマットは独自のものですが、WinでもMacでもDOSフォーマットのリムーバブルディスクの扱いになります。メディアリーダーが対応していれば、WindowsでもMacでも扱えます。
Macで書き込み禁止にしないでマウントすると、デスクトップファイル等 (Macでは不可視) を構築して書き込んでしまいます。わずかですが、容量損した気分。
メールの添付ファイルとして送る場合には、エンコード方式に気をつけます。Base64がWindowsでは標準で、Macから送ればデータフォークだけ送ることができます。 (MacからMacの人に送ればちゃんとクリエータとファイルタイプだけは送れたりします)
MacからAppleDoubleで送れば、受け手がMacならリソースフォークを含んだ完全なファイルとして送れるだけでなく、Mac以外の環境ではデータフォーク部分だけ独立して利用できます。データフォークとそれ以外の部分の２つに分けてBase64でエンコードされるからです。相手がWindowsだと分かっているなら、要らないリソースフォークやファイル情報 (Finder情報) を送ることのない単なるBase64で送る方が親切ですけど、両方の環境へ一度に送る時には便利かもしれません。
・AppleDoubleの構造 (２つに分かれている)
| ファイル情報 | リソースフォーク |
| データフォーク |
AppleDoubleやBinHex (Mac専用) で送る場合の注意点として、GIFやJPEG等は圧縮済みとはいえ、カスタムアイコンやプレビュー画像がリソースフォークに含まれていると、本体のデータの数倍の大きさになることもあります。画像ソフトでそれらが付かない設定で保存するか、リソースフォーク削除ソフト (ResCleaner (メールウェア) 等) であらかじめシェイプアップしておくと良いでしょう。
以前はMac間通信ではBinHexがスタンダードでしたが、近ごろのメーラーだとAppleDoubleがデフォルトですね。受信側のメールソフトが対応していないと、Mac同士なのに不完全なデータになってしまいますが、最近のものなら大丈夫。 (PostPet2はBase64にしか対応してません)
OS X標準ソフトのMailで使われるのはAppleDoubleです。
メールのエンコードの解説は「エンコード・コレクション」にあります。
たとえば、画像のPICT (.pict、.pct) 形式はMacの標準ですが、Windowsでは読めないソフトが多いです。逆にWindows標準のBMP (.bmp) やIcon (.ico) 形式はMacで読めないソフトが多いです。Photoshop等Mac版Win版両方あるソフトを入れてあれば、そのソフトの形式で交換できますが (バージョンを合わせる必要があります。詳細は各ベンダーのサイトで)、そうでない場合汎用形式を使います。ここでは画像形式だけ取り上げてみます。送信効率の良いように圧縮する形式が多いですね。
| 画像形式 | 特徴 |
|---|---|
| JPEG(JFIF) | 写真画像の圧縮率がすばらしく高いが、非可逆圧縮なので加工を繰返すと画質が劣化する。(GIFに続いてライセンス問題が発生中。代替はPNG?) |
| GIF | 256色まで。ベタ塗の多い画像の圧縮向き。ライセンスの問題で扱えるフリーウェアは少ない (ライセンス料が必要なので)。 |
| PNG | フルカラーで可逆の圧縮ができる。可逆なだけに写真画像の圧縮率はJPEGには及ばない。GIFの後継。アニメーションができないのが玉に傷。 |
| TIFF | 圧縮無しと有りがある。JPEG圧縮タイプは非可逆。LZW圧縮タイプはGIFと同じくライセンスに触れるので、フリーウェアでは扱えないことが多い。幾通りもタイプがあって、ものによっては読めないソフトもあるので注意。YMCKで保存できるのが印刷データ向き。 TIFF-FはFAX用。 拡張子「.tif .tiff」 |
| EPS | (Encapsulated Post Script) プレビュー画像が付いたポストスクリプト形式。印刷向き。プレビュー画像の形式に注意。 拡張子「.eps」単純なポストスクリプトなら「.ps」 |
| JPEG2000 | まだ対応ソフトが出始めたばかり。驚異的な圧縮率 (同画質でも従来のJPEGの半分以下のサイズ)。可逆圧縮もサポート。 拡張子「.jp2」 |
| SVG | (Scalable Vector Graphics) XMLで記述される、ベクターで画像を記録するフォーマット。ポストスクリプトを元にしたテキストデータ。インタラクティブに画像を書き換えられるのが魅力。 拡張子「.svg」gzip圧縮したSVGの拡張子「.svgz」 AdobeからMac用とWin用のViewerが配付されています。 |
MacならGraphicConverter (シェアウェア) があればBMP (.bmp) やIcon (.ico) をはじめ大抵の画像形式は読み込めるし変換できます (日本語化パッチ)。国産画像形式を開くならPixelCat (フリーウェア) があります (アイコンが可愛い)。
OS Xではシステム付属のプレビュー (Preview) が多くの画像形式に対応しています。JPEG2000への変換もできます。
WindowsではGV (フリーウェア) でPICT (.pict、.pct) を開いてBMPに変換できます。
ポストスクリプトとIllustratorのファイル交換では、本体データには互換性があるのですが、プレビュー画像の形式の違いに注意しましょう。特にMac側で保存するときには「IBM PC」形式を指定します。
関連情報：Illustrator:Windows と Macintosh のデータ互換
Winの代表的ワープロソフトWordにはMac版もありますが、読むだけ専用ソフトもあります。icWord
コンバートスター (Windows用) はワープロ専用機のデータを変換するソフトですが、MacのワープロソフトのデータをWinで扱える形式に変換することもできます。
TIFF-Fという多ページ対応の画像形式で送る所 (サーバ) が殆どですね。Winでは Windows 95 OSR2 以降に標準で付いてくるImagingで見ることができます。XPでは代わりにWindows Picture and Fax Viewerが付属していて見ることができます。
MacはOS X 10.2以降のプレビューで見られるようになりましたが、それ以前では標準でサポートしていません (QuickTime5のViewerでも1ページ目だけなら見られますが)。
Macで見るには、フリーウェアならMacFlexに付属のMacFlex Viewerで、より綺麗に見たいならGraphicConverter (シェアウェア) がお薦めです。
このページのためにお世話になった方々です。2002年半ば以前は特に記述していませんが、ありがとうございます。
MacとWinを繋ぐことに関しては下記のページです。LAN、WAN、サーバ関連、エミュレータ、遠隔操作ソフト、プリンタの共有とそれらのセキュリティ等。
