ディスクイメージをダウンロードすると展開されてデスクトップにマウントされる。お約束の動作ではあるものの、アプリケーションであればとっととディスクイメージの内容をアプリケーションフォルダに突っ込むし、プログラムのソースであればソースのフォルダに突っ込むことになる。
ディスクイメージをそのままフォルダに突っ込むと、ディスクイメージへのエイリアスが作られるだけで内容はコピーされない。Classic Mac OSから変更された挙動のうち、最も納得の行かないのがこれだ。
毎度毎度手作業で「フォルダ作成」→「ファイルコピー」とやっていたのだが、あまりにいろいろとダウンロードしてくるため、その頻度もただごとではない回数になっている。
これは、やるしかないだろう。
少し気合いを入れて、選択したディスクイメージの内容をすべてアプリケーションフォルダに（ディスクイメージの名前でフォルダを掘って）コピーするAppleScriptを作ろうとした。
ところが、ここで大きな落とし穴があった。FinderとAppleScriptの間でUnicodeの解釈に違いがあるのだ。実は相棒に相談するまで知らなかったのだが、Unicodeの実装に２通りあって、「文字＋濁点」で表現する方式と、通常方式に分かれているとのこと。
Finder側は「バナナ」を「ハ/゛/ナ/ナ」と文字と濁点を分離して保持しているようだ。
えっ！？ と思って、AppleScriptで、
set a to "バナナ" as Unicode text
set aList to characters of a
と書いて実行してみたら、いつも通りに「バ/ナ/ナ」が得られた。AppleScript側は、基本的にはこのように「バ/ナ/ナ」と保持する。
だが、Finderから「バナナ」というディスクイメージの名称を取得して、as Unicode textでUnicodeにキャストしてから文字ごとにバラバラに切り離すと「ハ/゛/ナ/ナ」となってしまう。
この状況を見ると、AppleScript側では「文字＋濁点」も「通常方式」も両方ともイケるのだろう。ただ、どちらの方式でデータを保持しているかは、ちょっと見ただけでは分からない。
「日本語の文字が入ってると困るから、とりあえずファイル名をUnicode textにしとくかぁ」
と、やってしまうとトンでもない目に遭うというわけだ。しかも、一度「文字＋濁点」になってしまうといろいろ不都合……いや、不具合と言ってもいいかもしれないレベルの問題が発生する。
この問題は「そんなバナナ？！」と言われたかどうかは定かではないが、たまたま「バナナ」という文字列が入ったディスクイメージをサンプルに使っていたために発見されることとなった。
仕方がないので、as Unicode Text でキャストせず、一度as stringでキャストしてから処理した。こうすればただの文字列だ。
30分ぐらいドタバタしていたのだが、結局はこれで解決できた。そもそも、なんでまたディスクイメージの名称を文字ごとにバラバラにしなくてはならなかったかといえば、パスの最後に付く「:」を削りたかっただけの話だ。
結局、ディスクイメージのコピー自体、dittoコマンドをdo shell scriptで呼び出して済ませたたため、「:」の削除処理自体は不要になるというオチがついた。
それでも、問題をさっさと解決できたことは評価すべきなのだろう。ものすごく納得が行かないのだが、そう思うべきなのだろう。責任者出てこい……（ーー；；＞Apple
その後、dittoコマンドでなぜかアプリケーションのパッケージングが解除されてしまうとか（解決ずみ）、スクリプト単体では動作するもののScript Menuに入れると挙動が変わってしまうとか（未解決） また気が向いたら完成させることに。