本Blogに掲載しているプログラムリストは、すべてapplescript:// URLリンクを埋め込んであり、リスト末尾にあるリンクをクリックするだけで、スクリプトエディタに内容を転送できるようにしています。

ところが、macOS 12.5RCにおいてSafariで表示した本Blog内のコンテンツで、applescript:// URLリンクをクリックしたところ、

・プログラムリストが短いと内容はスクリプトエディタに転送される
・プログラムリストが一定基準よりも長くなると、スクリプトエディタに内容は転送されなくなる

といった現象が確認されています。知り合いにいろいろ確認してみたところ、

・macOS 12.5以前のOSであっても、上記のような現象を確認していた

という話です（「じゃあ教えてよ！」と心の中でツッコミを入れていましたが）。

macOS 10.15のときに、PDFView上のURL Link（applescript://）が一律で無視されたときには、不服申し立てを行い、最終的には、

・macOS標準添付のPreview.app上のPDFはapplescript:// URL Linkは無視される
・サードパーティのアプリケーション上のPDFViewのapplescript:// URL Linkの妨害はやめる

ということになったようです。いつ状況が変わるかわからないので、未来永劫この状況が維持されるかどうかは不明です。自分だけがAppleに文句を言っていたわけではないと思いますが、基本的にAppleとの歴史は戦いの積み重ねです。Appleのやらかしを指摘して、事実関係のみ述べ、修正されるまで執念深く追求するという戦いの繰り返しです。

→ 本件は私のやらかしかもしれません、、、、

現状の確認

本BlogへのAppleScriptのプログラム掲載に使用しているAppleScript→HTML変換プログラム「AS Publisher v18」の内容を再確認してみましたが、Cocoaの機能を用いて文字列をURLエンコードしているだけです（そんなに複雑な処理をしていません）。部品単品でエンコード/デコードを行って検証してみたものの、呼び出している部品に問題は見つかりませんでした。

→ この部品でURLエンコードする方法を間違っていたもよう。ただし、過去のmacOSでは「間違ったURLエンコードが飛んでくることがあるので、対処しとくか」という処理になっていたところが、「厳密に正しいものしか処理しないようにしよう」という方針に変わったことが原因？

次に、Safariで何らかの妨害をしている可能性について検証してみました。

Safariではなく、CotEditor上でURLエンコードしたAppleScriptのプログラムのHTMLコンテンツをオープンし、CotEditorの最前面の書類からURL部分をURL Event的にオープン。これもSafari同様の問題が発生していることを確認しました。

コンテンツ中のURL部分をData Detectorを用いて抽出→Openさせた場合、URL内容が一定以上の長さを超えると途中で切られてしまうという動作を確認。macOS全体で「長いURL」への応答を殺しているという現状を確認。こういう話は一切WWDCでやらずに、コソコソ変更するんですよねー。

→ 事実関係を確認すると、本件についてはとくに悪意はない模様

本Blog側の対応

本問題の確認直後、すぐにAppleにバグレポートを行いました。この後は、PDFViewのときと同様に、Appleと２・３年あまりも不毛なやりとりを続けることになるのでしょう。事実上の牛歩戦術ともいえます。

そのやりとりをしている２・３年の間、ぼーっとしているわけにも行かないので対応策を考えておかなければなりません。

確実で安全な対策は、Script Debuggerでapplescript:// URLリンクを受信するように、Script Debugger側で設定することです。これなら、途中でApple側の妨害や嫌がらせに遭うことなく、プログラムリストの内容を転送できます。

ただし、「AppleScriptを今日はじめました」という人がScript Debuggerをダウンロードしているはずがないので、そこには対策しておく必要があります。

少ない労力で対処するのであれば、掲載リストのZipアーカイブをダウンロードできるようにしておくぐらいでしょう。

プラス、本Blogの過去記事アーカイブの英訳版を企画中ですが、日本語版も出してもいいような気もします。