MacOSX,MacOS9,Windows３者共用できるCDRのISOイメージを作りたい

質問

皆様こんにちわ。

http://okweb.jp/kotaeru.php3?q=1611360
↑こちらのスレッドで一旦投稿したのですが、私の投稿に問題があった様子で
結論が確認できませんでしたので、再度投稿内容を改善してこちらにスレッド
を立てさせていただきました。

MacOSX,MacOS9,Windows３者で同じように日本語ファイル名、フォルダ名が
読めるようなCDR共用ISOイメージを作りたいのですが、どのようにしたら良いで
しょうか？

http://okweb.jp/kotaeru.php3?q=1611360
の元スレッドでいただいている解説の意味が、どうも私はとんちんかんで飲み込
めず混乱気味でいます。
どなたか篤志の方がいらしてましたら、かみくだいて教えていただけませんでし
ょうか。

回答No.5

kai123 · ベストアンサー

回答占領者kai123です。（おぃ

さて、補足・お礼欄についてです。

提示していただいた引数、オプションですが・・・
調べてくと？？？なところが・・・。
もう調べて把握されているかもしれませんが・・・。
「-J」は通常の ISO9660 ファイル名に加え、Joliet ディレクトリレコードを生成します。
「-U」はファイル名の変換をすべて無効にする
複数のドット (‘.’) がもてたり、英大小文字が混在可能等へ拡張する
「-r」はアクセス権等の適正化（これが2個ある）
「-L」はドットファイルの許可
「-l」は31文字までファイル名の拡張
「-D 」は深層ディレクトリの移動をしない
「-T」はCDROM の各ディレクトリ内に変換テーブルファイル TRANS.TBL を生成
「-hide-joliet-trans-tbl」はJoliet ツリーから TRANS.TBL ファイルを隠蔽する(あまり意味ない)
「-o」は出力先指定
「-national」はわかりませんでした。ググッてもでてこないのはナゼ？

という感じになっており、怪しいものは「-national」のみ
だけど、もっと「-J」というのが気になります。
GUIのほうではJolietは指定していないのですよね？
でもこれは、Joliet指定。・・・？
このオプションでISOファイルを生成すると、ISO9660 Jolietになりますよね・・・
GUIフロントエンドでなにをしているのかわかりませんが、チョット変ですね。

＞なぜ面倒なmkisofsで実行して・・・略

OSXのシステムにはたぶん、mkisofsは実装されてないと思います。確証なしですが。
ただ、mkisofsをもとにappleが作ったものが入っているかもしれませんが。
実際、UnixのコマンドのFindをかけてもシステム関係からは検出できませんでした。
そのかわり自分が集めたフリーのDVDオーサーリングソフト（イメージファイルを生成する）に
mkisofsが実装されていました。
mkisofsはかなりイイものだと言う事がわかりますね。
ただ、フリーでの話。商用OSではそうはいかないのでは？
ま、MacOSのPGじゃないのでよくわかりませんが。（逃

クラシック環境はのせていないので残念ながら検証不可能です。
OSXの上にクラシックを乗せているのだから、コアはOSXですよね。
という事はCDの認識はOSXでやってますよね。
OSXはドライブを/Volumes内にマウントしています。
そのファイル構成情報をクラシックでどう受け取っているかですね。
どうなんでしょ？

＞Macカテゴリーを代表する第一人者のharawoさんがUDFの言及をされているの
がよくわからないままなのですが、ここでharawoさんが言わんとされていることと
いうのはどのようなことになりますでしょうか？

さぁ・・・。
ただUDFはISO9660ではないです。
UDFとはUniversal Disk Format。
たしか、UDFはISO9660に書き込み規定を加えたISO13346の規格を
元にしたフォーマット。
UDFが読めなくても、ISO9660として読めるようになっています。
ISO13346についてくわしいことはわかりません。
この規格の仕様書自体が有料で一般には公開されていませんので。

なんか、自分の応用許容範囲を超えているかも（汗

お礼

> OSXはドライブを/Volumes内にマウントしています。
> そのファイル構成情報をクラシックでどう受け取っているかですね。
> どうなんでしょ？
これ、誰かクラシック載せている方に助太刀もらえると嬉しいですね。
ファイルI/Oは低レベルで実行させるという一般OS概論で行けばアウトな可能性が高そうですが、
http://okweb.jp/kotaeru.php3?q=1611360
の元投稿＃１で寄せられたリンクの中に、「責任持てないけど多分出来るはずです、」的な「不正レベル2」配布業者の発言記述もあるんですよ。
何事にも超絶技術のAppleMacintoshですから、ホントに低レベルI/Oの常識をくつがえしてくれている可能性も充分ありそうに思いますし。悶々です。
私自分で、OSX動くマシンを早く買わないといけませんね・・・
・・・とはいえ、先立つ物を考えると当分無理な現実が痛いです。

> ISO13346についてくわしいことはわかりません。
> この規格の仕様書自体が有料で一般には公開されていませんので。
なるほど、この書類を手にすることが出来る限られた技術者の人しか本当のところはなかなか知られていない訳ですね。
納得できました。

本当に本当にありがとうございます！！
凄く充実したスレになって嬉しいです。
しばらく締め切らず置いときますので、また何かお気づきになりましたら小さなことでもすごく嬉しいですので、コメント下さい＾＾！！

補足

またして制限オーバーで分割ですが、すみません^^;

> 回答占領者kai123です。（おぃ
いえいえ、本当にこんなご親切はOKWEBならではのありがたきしあわせです^^;
どうぞよろしくおねがいします。

> なんか、自分の応用許容範囲を超えているかも（汗
いえいえ、公開知識データベースのOKWEBの理念ではこれでいいんですよ^^
すごく真剣にご尽力いただいて感謝感激です！
他のもっと知ってる誰かが一生懸命なこのやり取りにほだされて、助太刀してくれたらそれでまた私達にも更なる飛躍になれますもんね。

> という感じになっており、怪しいものは「-national」のみ
> だけど、もっと「-J」というのが気になります。
> GUIのほうではJolietは指定していないのですよね？
> でもこれは、Joliet指定。・・・？
> このオプションでISOファイルを生成すると、ISO9660 Jolietになりますよね・・・
> GUIフロントエンドでなにをしているのかわかりませんが、チョット変ですね
そうなんです、これは「？？？」のままで納得いかない謎なんです。
GUIでJoliet指定に「レ点」をチェックすると明白に完全Windows規格Joliet盤が出来あがります（つまり、MacOSで読めなくなるんです)。
オペランドで「-J」を指定しながら「-hide-joliet-trans-tbl」＋GUIでJoiet解除
の組合せで、この不正な多国語レベル2が出来るという、一種のバグに偶然便乗できているのかもしれないですね。

> 「-national」はわかりませんでした。ググッてもでてこないのはナゼ？
これは多国語を許すスイッチですので、恐らく、オレンジブック等正規のISO規格からスピンオフしたバージョンだけにあるスイッチのはずです。
kai123さんから、本来レベル２でDBCSは許されていない、と教わって気付きました。

ちょっと後日、「-J」は矛盾して異常ですから、これを外した状態（なら納得ですもんね）で「もうちょっとマシな不正レベル2」が出来るかどうか、色々組合せ実験してみたいと思います。

回答No.4

kai123

またまたすみません。No.3です。
お礼、補足内容についてです。

＞ハイブリッドにせずに、容量一枚丸ごと汎用に供したい、という大前提でいましたので
-hfs　の指定はしていません。
（これも、マックではない本家のunix系OSで-hfs指定することでイメージが作れてしま
う、という事は、事実なら違反の犯罪になるわけですよね？？）

unixのmkisofsのデータをのぞいてみたところHFS用のライブラリがあるようなので
問題なくできると思いますよ。
ハイブリットはHFSボリュームのファイルシステムさえあればWinでも
作成可能ですから。ただWinで標準認識しないのと手に入らないというだけです。

やはりmkisofs+GUIフロントエンドですか。
そうすると、なかでなにをしてるのかわからない以上、これ以上の
詮索等やめときます。

＞元投稿で、・・・

あれその時に読みました。
読んだ時に感じたのは、明確に表記してないけど
ISO9660拡張 アップル拡張(Apple ISO)のことだなということですね。
（ていうかサポートだったら明確に表記しろよ！っというツッコミを・・・）

前の回答でも述べているこの仕様、所謂、互換性の問題でしょう。
この仕様で作成するとMacOSXではうまく認識しない場合があります。
この質問のNo.1の方の回答URL先にも書いてありました。

OS Xではボリューム名に日本語を使うとマウントされないし、
日本語ファイル名も表示できません。

って。まぁ、そういうことです。前回の質問のことは。
これは上で述べた互換性の問題、しょうがないですね。

＞mkisofs以外の市販ライティングソフトでも同じことが出来ている可能性が高そう
に思うんです。

上のとおり、互換性の問題。その市販のものでいくらアップル拡張で焼いても
この問題により、不具合がでますよ。そんなもんです。

なんか、私の不十分な知識のせいで逆に混乱させてしまったでしょうか？
すみません。
（実は逆にそちらの方が詳しかったりして）
自分、趣味でソフト等作成している者で、最近もUnix系アプリケーションの
OSX用GUIフロントエンドを作成していたので、そのせいか、ついつい
深追いしてしまいました。反省。

まっ、なんかわからずに認識してしまってるのなら、それもOKなのかも。
ただ、世間不特定多数に配布する場合はちょっと考えた方が良いかもしれませんね。
所謂、臨機応変ってやつですよ。
ということで今回の相手の方には純MacCDかJolietで焼いてあげてください。

MacやMS-DOSの存在を知らないWinOnlyのかたにはわからない悩みですね・・・。
今では、日本語ロングファイル名が普通になってきて、しかもそれに合わせて
CDを焼くのにJolietを普通に使用してます。「Joliet？なにそれ？」と言う人が
多くなっていますから。

お礼

> OSX用GUIフロントエンドを作成していたので、そのせいか、ついつい
> 深追いしてしまいました。反省。

いえいえ、okwebはその点、持ちつ持たれつお互い様の精神で運営されている訳です
から是非よろしくおねがいします。
いつか私の得意分野でご恩返しができればと思っています＾＾。

なぜ面倒なmkisofsで実行して、この件を質問しているかというと、その根底はOSX
にもBSDフルセットが標準装備されているなら当然mkisofsが実装されているだろう
と思っているからなんです。
もしかしたらcdrtoolsがOSXのライティングのエンジンになってるのでは？などと
思っているのですが、どうでしょうか？

あと、この「不正レベル2」CDRは、OSXのクラシック環境なら、うまく日本語が
見えるものでしょうか？
クラシックでもOSX上にあればそもそも低レベル段階でアウトなのでダメ、という
ことになりますか？

あと、若干話題が逆戻りしてしまうのですが、
http://okweb.jp/kotaeru.php3?q=1611360
で、Macカテゴリーを代表する第一人者のharawoさんがUDFの言及をされているの
がよくわからないままなのですが、ここでharawoさんが言わんとされていることと
いうのはどのようなことになりますでしょうか？

補足

度々本当に有り難うございます。
また分割になりますが、どうかよろしくお願いします。

＞ISO9660拡張 アップル拡張(Apple ISO)のことだなということですね。
私も当初そう思いこんでいたのですが（単に漢字Talk7以後うまく読めたというだけ
の理由で）、他OSで作成したリソースフォークが全く格納されていないことと、教え
ていただいた内容から、レベル2に勝手なシフトJISのDBCSファイル名やボリュームラ
ベルをつけたイメージファイル、だということがわかりました。

多分、MacOSで自由に読めてしまったのは、漢字トークに由来するMacOSがシフトJIS
をシステム漢字コードとして持っていたからたまたま読めてしまった、という事に
なるのではないかと考えてみましたが、いかがでしょうか？
（OSXを持っていなくて分からないのですが、多分OSXだと上層レイヤーで漢字コード
を処理されてるだろうと思うんです）
またこのような規格外の不正に対しては、アップル社の社是通りならば弾いてしまう
処置を施すところを、偶然か故意か永年放置されていた結果もありそうですね。

フロントエンドが渡している引数とオプションが、わかりました！
引数は、私のパソコン構成のプライバシーの部分がありますので、問題になっている
オプション命令だけペーストしますね。
-------------------------------------------------------------------------------
"mkisofs.exe"-national -U -r -L -l -J -D -r -T -hide-joliet-trans-tbl -o
-------------------------------------------------------------------------------
これが「不正なレベル2」生成に成功しているオプションスイッチ群です。

＞前の回答でも述べているこの仕様、所謂、互換性の問題でしょう。

その核心部分が、「-national」スイッチだと思うんです。
mkisofsで非英語圏のユーザー向けのnationalが有効に出来るバージョンは限られて
いるので、これは間違いない犯人だと思います。

その他でオプションの組合せにお気づきの問題がありましたら是非教えてください。

回答No.3

kai123

No.2です。

これは推測なので軽く聞き流してください。
（mkisofs使っていないので）

mkisofsを使用するとき、オプションはどのようにしていますか？
31文字拡張という事なのでまず、-lを指定していると思います。
他に-hfsや-appleを指定していませんか？
もし指定していれば、OS9でもしっかり日本語表示されます。
指定していなければ、「あってはならない事」ですね。

ネットで検索して見つけたman page [日本語]によると
-hfsはハイブリット用みたいですね。
つまり、これを指定する事によってHFS ハイブリッドボリュームを作るので
リソースフォークが保持されOS9上で日本語表示されます。
で、-appleは下の回答で述べた「ISO9660拡張 アップル拡張(Apple ISO)」では
ないでしょうか。この仕様はレベル2の拡張ですが、リソースフォークを記録できる
のでOS9上で日本語表示されます。

ところでその焼いたCDはWinでも日本語表示されるのでしょうか？
焼いたフォーマットがハイブリットやレベル1、レベル2であれば
Win上では文字化けを起こすような気がしますが、どうでしょう？
結局、下の回答で述べたようにISO9660では日本語不可のため
どうしてもJolietが必要になると思うのですが・・・。
（AppleISOはちょっとかわっていてWinでも日本語表示できるらしい。未確認）

お礼

> ところでその焼いたCDはWinでも日本語表示されるのでしょうか？
もちろんです。Windows95/98/2000/xp、OS/2、MacOS７～９で同一表示になるので、
すっかり安心しきっていました。

自分が使うパソコンが将来どんな機種になっても手持ちのデータが困らないように、と
いう発想が最初の動機でこういうイメージを作っていました。
ですので、他人にデータをあげる時にも用いたところ、OSXだけで問題が起きる、という
ことに初めて気付いた次第です。
MacOSX以外のUNIX系はまだ調べていないのですが、中途半端な日本語化しかできていな
い私の学習実験中のSlackWareでは、当然のごとく？日本語だけアウトで半角英数のみ
OKというMacOSXと同様の結果になりました。

> 焼いたフォーマットがハイブリットやレベル1、レベル2であれば
> Win上では文字化けを起こすような気がしますが、どうでしょう？

わたしのイメージファイルが、isoの決めた規格から外れて、偶然勝手に都合よく
日本語を表示してくれていることになるようですが、そこで腑に落ちないのが、
http://okweb.jp/kotaeru.php3?q=1611360
の最初の投稿で寄せていただいた他の例なんですよね・・・
mkisofs以外の市販ライティングソフトでも同じことが出来ている可能性が高そう
に思うんです。

※御礼の文字数制限にひっかかってしまい、お見苦しい二分割になってしまいましたが、私の主旨はご理解いただけていると信じていますので、どうかお許し下さいませ。

補足

どうもありがとうございます！

> 結局、下の回答で述べたようにISO9660では日本語不可のため
> どうしてもJolietが必要になると思うのですが・・・。

現実は、変なことが起きてしまっているんですよ。
私もこの問題は、非常に関心持っているんです。
ですので、イデオロギー等は完全に抜きにして、パソコンの中で一体何が起きている
のか、という真実が是非知りたい、と思って投稿しました。

mkisofsは、膨大なオペランドを入れるのが大変なソフトですから、私はフロントエン
ドを手前に噛ませて使っています。

そのため、生のmkisofsが受け取っている膨大なオペランド群がどうなっているかとい
うのは、runしてみて画面に流れ去る文字列を何かの方法でキャッチしないと「自分が
命令した内容」を自分で答えられない状況なのですが、これは後で奮闘努力してみて
うまく捕まえることが出来ましたら再度お礼補足欄にプラスしておきますね！

ご回答者様の皆様のご好意を決して踏みにじることがないように私も能力の限り努力し
ますので、フロントエンドのような際物を使うことから間違っている、という精神論
はこのスレッドではどうか抜きでよろしくお願いします。

＞31文字拡張という事なのでまず、-lを指定していると思います。

はいそうです、これに加えて、このようにして私はイメージ指定しました。

手書きスイッチ指定として「　-national -U -r -L　」
メニュー等選択項目として「31文字」の選択
同じく選択項目として、「joliet形式」を非選択
jolietを選択すると、MS系OSでもIBMOS/2などで読めなくなるのと、特殊な
拡張書類を装備しないごく一般ユーザーのMacOSで読めないために外してました。

さらにdisable name translation codepageという私にはわからない選択肢があ
るのですが、これは意味がわからないまま、非選択だとうまく成功してくれます。

mkisofsフロントエンドの説明によると、さらに「-graft-point」というスイッチ指定
が必要、と書いてあるのですが、どういう訳かその通りにすると必ず失敗するので、
このスイッチ指定は半信半疑のまま敢えて無指定にして長期連続安定作動してくれてい
ます。

ハイブリッドにせずに、容量一枚丸ごと汎用に供したい、という大前提でいましたので
-hfs　の指定はしていません。
（これも、マックではない本家のunix系OSで-hfs指定することでイメージが作れてしま
う、という事は、事実なら違反の犯罪になるわけですよね？？）

元投稿で、「私の作ったイメージはアップル拡張レベル２だと思ってます」等と投稿し
てしまいましたが、その心は単にMacOSで無事自在に読めたから、というだけの理由です。
-apple　を指定して本当にアップル拡張になっている訳ではありませんでした。
すみませんでした。
つまり、リソースフォークなしのMacOS読みこみ自在、という状態です。
レベル2の31文字、という規定がマックを前提に決められたから、この指定にすれば
国際汎用規格であるISO機構で決定された規格なのだから他機種でマックの読めるCDが
作れて当然なのだろう、程度の認識しかありませんでした。

回答No.2

kai123

もう少し勉強されてしっかり理解できるようになるまで
素直に半角英数の非ロングネームでファイル名付けて焼いた方が良いように思いますが。

前回の質問で仰っていたレベル2は
OS9では正常に読めたということから、「ISO9660拡張 アップル拡張(Apple ISO)」だと
思われます。これは、MacOS(OS9)からでも、正常に読めるようにしたもので
それ以外のOSではレベル2として認識されます。しかし、MacOSXでは日本語のファイル名は
正常に表示されません。
（多分、純レベル2はMacでもWinでも日本語使えません。）
ので、この場合、ISO9660 Jolietを使えば読めると思います。

前回の質問時に投稿できなかったので、ISO9660のファイル名解決について説明させてください。

ISO 9660 レベル 1：
オリジナルの ISO ネーミングフォーマットで、制限が厳しく設定されています。
(ほとんどのシステムで、純粋な ISO 基準を必要としません)
名前の要件：
長さ：8.3 文字
文字：半角英大文字 A-Z、半角数字 0-9、アンダースコア _ 。それ以外の文字は使用できません。
ISO Level 1では、ディレクトリ構造が8階層に制限されています。

ISO 9660 レベル 2：
ISO9660レベル1から、31文字のファイル名まで使えるようにしたものです。
そのほかの制限はISO9660レベル1と同様です。

Joliet：
マイクロソフトによるISO9660拡張フォーマット。
ISO9660レベル1との互換性を保持したまま、64文字までのファイル名と日本語が使えます。

アップル拡張(Apple ISO)：
Apple ComputerによるISO9660拡張フォーマット。
ファイルタイプ・クリエータというMacintosh独自の属性を記録できます。
ファイル名の制限などはISO9660レベル2と同様です。

自分はMacOSXでJolietを指定して焼いています。大抵はこれでOKです。
焼くのにToastを使用していますが、そのヘルプによると

Joliet (MS-DOS + Windows)：Windows 95 以降と Windows NT以降で使用する CD 用に、長いファイル名をそのまま CD に残します。
これらの OS よりも古いバージョンの DOS や Windows とも、完全に互換性があります。
Windows 95, 98、Me、NT 4.0、および XP が Joliet に対応しています。

Joliet 形式の CD には、2つのファイル形式が含まれます：

MS-DOSの名称規則を使用するISO 9660準拠のファイルシステム。
Unicode名称規則の長いファイル名を使用するJoliet準拠のファイルシステム。

両ファイルシステムとも、同じデータファイルを示します。長いファイル名にアクセスできるのは、
Mac OS X、Windows 95、98、2000、Me、NT 4.0、および XP システムのみです。
MS-DOS や UNIX などの ISO 9660 準拠のシステムは、ISO 9660 ファイルシステムしか認識することができません。
Joliet 名称で作成されたクロスプラットフォームの ISO 9660 CD には、実際、Mac OS (標準または拡張)、ISO 9660、
そして Joliet の、3つの異なるファイルシステムが含まれます。
名前の要件：
●長さ：最大 64文字
●文字：*/:;?＼ の文字は使用できません。
●例：1998 Report to Shareholders

となっています。

つまり、簡単にいうとJolietではそれぞれのOSに対応させるための
ファイル名を保持する事ができ、特定のOSで開いた時にそのOS用のファイル名で
表示するっということ。
例えば、Joliet(MS-DOS + Windows)を指定してあげれば、

「Joliet 名称で作成されたクロスプラットフォームの ISO 9660 CD には実際、Mac OS (標準または拡張)、
ISO 9660、そして Joliet の、3つの異なるファイルシステムが含まれます」

とのことなので、
MacOSX、Windowsで開けばJolietにより日本語のロングファイル名でも表示され
MS-DOSやUNIXで開けばISO9660によりISO9660基準のファイル名で表示されます。
（つまり8.3文字の半角英数ファイル名）
で、肝心のOS9で開くとMac OS (標準または拡張)により日本語のロングファイル名でも表示
されるようになるのです。

でも、これはMacOSXで焼いた場合・・・。
実はWin側で焼く場合はこうはいかないのです。

今、WinのB'sGoldをみたり、ネット検索してみたところ、Win側でJolietを指定しても
そのJolietの中には「Mac OS (標準または拡張)」のファイルシステムが含まれていないため、OS9では
文字化けをしてしまいうまく表示できないみたいです。MacOSXでは読めるけど。

今回の場合、相手はOSXなのでJolietで焼けば、読めるとおもいますがOS9の場合文字化けします。
OS9で文字化けせずに表示するには「Joliet Volume Access」という機能拡張を使います。
http://www.amy.hi-ho.ne.jp/fujisawa/mac/tips/Joliet/joliet.html

あなたが使用している「mkisofs」はUnix系のソフトですね。それをWin用にコンパイルしたやつですね。
これ自体は使用した事ないのでわからないのですか、たぶんこれでのJolietは「Joliet Volume Access」を
使うことでOS9でも認識しますよっということだと思います。（ネットで調べた結果）

昔からWin&Mac対応のCDを作る場合、Macからでしか作れないとされてきました。
これは、上で述べたことがあるからですね。
何でもそうです。win側からは対応されていない。Macのほうで対応させる・・・。

ちなみにMacOSX10.3.9のヘルプの
「MS-DOS（Windows）フォーマットの CD を作成する」の項目にこんな記述があります。

ディスクには HFS+、ISO-9660（Rock Ridge 拡張付き）、
および Joliet（Rock Ridge 拡張付き）の各ファイルシステムが含まれます。

やっぱり。MacがMS-DOS（Windows）フォーマットの CDを作成する際、
Macで正確に表示するようにHFS+、MS-DOSで正確に表示するようにISO9660、
unix系で正確に表示するようにRock Ridge、Windowsで正確に表示するようにJolietの
ファイルシステムを含めているんですね。

と、長くなりましたがこんな感じです。

本当は、相手側で読めないのならば、無理して日本語ファイル名を使うのではなく
半角英数8.3文字にする等、相手の環境に合わせる事が大切なんですけどね。

書いている間に下の方へのお礼が書かれていましたので
そのお礼について・・・。

＞それにしても、なぜMacOSXだけ変な規格に決めたのか・・・
それさえなければISO9660レベル２で万事解決だったのに・・・と憤懣やるかたありません。

それは違います。それがなくてもISO9660レベル２では日本語ファイル名の表示ができません。
WinでもMacでも。JolietっていうものがあるからWinで日本語表示できるんです。
上の各種概要参照。
ISO9660レベル1、レベル2はほんとシンプルなもので、半角英数等しか使えません。
ということは、レベル1でもレベル2でもwinで作ったJolietでも半角英数等を規定通りに
使えばMacでもちゃんと表示されますよ。
大元はMacで認識できるISO9660ですから。

お礼

大変ご親切にツボを押えたご指導をいただき、ありがとうございます！
おかげさまで今まで煙に巻かれていたような気味の悪いわだかまりが晴れました！

＞それは違います。それがなくてもISO9660レベル２では日本語ファイル名の表示ができません。
＞WinでもMacでも。JolietっていうものがあるからWinで日本語表示できるんです。

なるほど、OS9までのマックは「いい意味での欠陥？」のおかげで不正なISO9660レベル２（日本語）が偶然読み書きできてしまっていた、というのが原因だった訳ですね？

実はmkisofsでの不正な日本語入りレベル２イメージの作成中も、non-supportのエラーが表示されるんですが、これで謎が解けた気がします。

いつの世でもMacが一番正しい道を示しているわけですが、旧MacOSでは、いつものアップルの姿勢ならば断固として排除していたところですが、いわば一種のお目こぼしをしてくれていたがゆえに、日本国内で本来あってはならないはずの不正な日本語入りISO9660レベル２が多数流通してしまった、という理解でよさそうですね。

パソコンに詳しい人でないとわからない特別な機能拡張はない、ごく一般の人を対象にした場合で考えますと、
そうすると結論は、

・日本語レベル２はそもそもあってはならない規格外で使用すべきでない、
・１つのフォーマットで全対応ならレベル１、
・日本語を入れる場合はjolietとHFSのハイブリッド、

ということになりそうですね！
この理解でよろしいでしょうか？

補足

すみません、お礼欄を送信したあとで、大きな認識の隔たりに気付きました！

> あなたが使用している「mkisofs」はUnix系のソフトですね。それをWin用にコンパイルしたやつですね。
> これ自体は使用した事ないのでわからないのですか、たぶんこれでのJolietは「Joliet Volume Access」を
> 使うことでOS9でも認識しますよっということだと思います。（ネットで調べた結果）

これが、どういう訳で非MacでMacOS9に読める（本来有ってはならない）日本語ファイル
イメージが作れるのか、謎が深まるのですが、実はそうではないのですよ。
mkisofsでイメージ作成する際に、明示的にjolietにしない、という指定をしてイメージ
作成するんです。
３１文字拡張、というオペランドを指定しつつ、非jolietにすると、MacOS9で読める
あってはならない日本語レベル２イメージが出来てしまう仕組みです。

OSの理論的にあってはならない椿事ということになりそうですね＾＾；
なぜこんなことが許されたのか、また新しくとても興味深々です！
mkisofsのバージョンは1.14a04というものですが、それ以降に新しくなったときに幾つか試用して、
日本語の問題以外にも色々不都合があったので、その後は新版を追わずに、安定して不正な日本語イメ
ージが作れてしまうこのバージョンでずっと愛用してしまっていました。

私の作ったイメージファイルが反社会的だったのかもしれませんが、同様のイメージフ
ァイルをあちこちの人々が知らずに作成して、かなりの量が流通してしまっていたこと
は、前回マッキントッシュのカテゴリーで投稿したときに寄せていただいていた回答か
らも伺えますので、mkisofsのバージョンは1.14a04以外にも、多数のライティングソフ
トでこのようなことが出来てしまっていたのではないでしょうか・・・
（ルール違反の困った問題だったんですね・・・）

回答No.1

qO_op

Web&Mail&Mac講座
http://homepage1.nifty.com/glass/tom_neko/web/web_02.html#CD

参考URL：

http://homepage1.nifty.com/glass/tom_neko/web/web_02.html#CD

お礼

ありがとうございます、
なるほど、やはりjolietとAppleISOのハイブリッドでイメージファイルを作る以外には、「標準状態の誰のパソコンでも読める」CDにはならないんですね。

ちょっとこの文章を読んでも飲み込めないところが一つあるんですが、是非教えてもらえませんでしょうか？
前のスレッドでの回答者様がUDFを使う、というのは、UDFで焼かれたCDというものが今では多数流通しているんでしょうか？

パソコンにあまり興味のない人や、予算やリプレースの暇がない事業所などでは、いまだにWindows95を平気で使っているのをよく見ますが、９５ではUDFアウトですもんね。

それにしても、なぜMacOSXだけ変な規格に決めたのか・・・
それさえなければISO9660レベル２で万事解決だったのに・・・と憤懣やるかたありません。
私個人の感想としては、こう言う事をすることが「クリエイティブ」とか「イノベーティブ」だの「偉業」だとは全く思えませんなあ・・・。

まったくエライ人のすること、というのは愚民には理解できないものですね。
（ー＿－；）