PhotoshopとかIllustratorの文字化けについて

とっても疲れました。何が疲れたかって、常日頃からリリースされてくるアプリケーションの挙動を確認しフィードバックを返すという作業をやっていますが、今回リリースされたmacOSにおいて日本語対応を失敗しているものが複数出てしまったのをしらみつぶしにチェックしていくのが結構大変だった事なんですね。
やっとこさ、状況を把握した状態なのですが、発生した事象が複雑でどうしたものかと今をもって悩み中です。
大雑把に言うと、各アプリケーション共にUnicodeで各種表記を統一しようと作業を進めたけど、macOSの方は古いバージョンでもあつかえるように残してあった「古い文字コードを扱う部分を取っ払ったよ(ｷﾘｯ」という事みたいです。Unicodeで書いてるから大丈夫やろ？　って思った？？？　それ、うまくいってませんから……(^-^;

という事で、詳細をまとめておきます。

まず、Photoshopさんです。最近Senseiがご活躍でいい感じに選択してくれたり空を置き換えちゃったりしてますが、基本的にマルチバイトに関する経験値が低いです。今回の不具合のクリティカルな奴は大半がファイルを特定の形式で書き出すときに発生します。

Photoshop 22.4.2

不具合の存在する書き出し形式／EPS DCS
書き出し時にDocumentCustomColorsとCMYKCustomColor、及びPlateFile（特色プレート名）のマルチバイト部分が0x3Fにフォールバックします。おそらく、この挙動はマルチバイトコード（恐らくShift JIS）をそのままMacRomanに通すことで生じているのではないかと考えています。同様にPhotoshop Image Resources（8BIM）の識別子0x03EE（Alpha Channel Name）も同様にマルチバイト部分が0x3Fにフォールバックします。しかし識別子0x0415（Unicode Alpha Names）は正常にUnicodeで記述されています。その為、当該ファイルをPhotoshop自身で再読み込みした際には、このUnicodeで記述された部分を読み込む為にカスタムカラー名が文字化けすることはありません。問題は他のアプリケーションが読み込む場合で、DocumentCustomColor等の情報を参照する為にカスタムカラー名が文字化けします。

不具合の存在する書き出し形式／EPS、JPG
これらのファイル形式においてはクリッピングパス名が正常に記述されません。クリッピングパスはPhotoshop Image Resouces内に0x7D0と0x0BB7の２箇所の関連識別子が存在します。従来、これらの識別子はShiftJISで記述されていた部分ですが、マルチバイト部分は0x3Fにフォールバックされます。結果として２種類の識別子は同一の文字列に化けてしまいますからクリッピングパスの指定は維持されます。これはPhotoshop自身も文字化けを生じた状態になります。

不具合の存在する書き出し形式／TIFF
クリッピングパス名
TIFFもEPSやJPGと同様に識別子0x07D0と0xBB7においてマルチバイト部分はは0x3Fにフォールバックします。そして、この２種類の識別子は同様の化け方をしますから表示上は文字化けしていますが、クリッピングパスとしては有効な状態で保持されます。（追記）PhotoshopではpathUnicodeNameTEXTを参照しますので表示上は化けません。
レイヤー名
レイヤー名に関してはImage Resources内に２つの関連識別子が存在します。normは従来ShiftJISで記述されていたもので、これも0x3Fにフォールバックします。一方、luniはUnicodeで記述される部分でPhotoshop自身はこちらの情報を利用してレイヤー名を認識します。この不具合は実用上影響のないものです。

不具合の存在する書き出し形式／PSD
クリッピングパス名
クリッピングパスに関しては重大な不具合となります。まず、他のアプリケーションと同様にImage Resources内の0x7D0と0xBB7の２種類の識別子のマルチバイト部分が0x3Fにフォールバックします。しかし、Photoshop自身はこの部分をパス名称表記には利用せずpathUnicodeNameTEXTを参照します。こちらはUnicodeで正常に記述されるので、Photoshopのパスパネルの表示は正常となります。ここが、大きな問題で、クリッピングパス指定は0xBB7識別子に記述された情報を参照します。これはクリッピングパスを認識するアプリケーション全てがこの挙動で、Photoshop自身も例外ではありません。その結果、パス名とクリッピングパス名の間に齟齬が生じます。結果として、再度Photoshopにて当該ファイルを開いたときにクリッピングパス指定が外れた状態で開かれてしまいます。しかし、0x07D0及び0x0BB7識別子が同様の文字化けを起こしているために他のアプリケーションに配置した際にはクリッピングパスを認識できてしまいます。

レイヤー名（誤記を訂正しました）
normのマルチバイト部分が0x3Fにフォールバックしますが、luniはUnicodeで正常に記述されるのでPhotoshopはこちらを参照し正しくレイヤー名を認識します。

アルファチャンネル名（追記分）
0x03EE識別子のマルチバイト部分が0x3Fにフォールバックするが、0x0415識別子が正常に記述されているのでPhotohshopは正常に表示します。

Photoshopに関しては以上です。しかし、0x7D0及び0xBB7識別子の問題は別の問題を生じます。例えばパス名を「三角形」とすると３文字とも0x3Fになりますから「???」となります。Photoshopでは複数のパスを保存可能ですから「四角形」という別のパスを持っていた場合に同じ「???」となってしまいます。このような状態となるとパスを正常に認識不能となりますので挙動が予測できません。こういった特殊な状況の検証はもう少し用心深く進めたいと思います。

追記分

このポストをまとめた時点では検証できてません（Aiは自宅でMacを貸してくれません^-^;）でしたので「こうなるだろうなぁ……」と思っていたのですが、先程試すと予想通りの挙動で……
まずはこちら、

この様に複数のパスがデータに含められている状態で

• パス名の文字数が同じ
• パス名に使われている文字が全てマルチバイト

である場合、このファイルを配置しようとするアプリケーションは、パス名が文字化けを起こすことにより一番最初のパスをクリッピングパスとして認識してしまいます。

これは２番目以降のパスがクリッピング指定されていた場合、意図しないパスが切り抜きに使われるということです。

何が起きているかと言うとパス名称はPhotoshop Image Resourcesの0x07D0から0x0BB6までの範囲に複数記述可能な仕様になっています。上に挙げた例では0x07D0に三角形が0x07D1に四角形が保存されるべきですが、いずれも0x3Fにフォールバックするために???になります。

クリッピングパスの指定自体は0x0BB7を参照しますが、これも???に化けていますから一番最初に引っかかる0x07D0がクリッピングパスとして選択されるのです。

Illustrator 25.3.1

不具合内容／TIFF書き出し時のレイヤー名称
Photoshopと関連するように見えますが、全く別の性質の問題も混ざっています。
norm識別子はShiftJISで記述されていましたがマルチバイト部分が0x3Fにフォールバックします。IllustratorからTIFFを書き出す際においてもluni識別子が含められますがUnicodeLTで記述されるべき部分がわけのわからない化け方をします。詳細にトレースしてみましたが予測もつかない……

不具合内容／PSD書き出し時のレイヤー名称
PSD形式を書き出す際においてもnorm識別子のマルチバイト部分が0x3Fにフォールバックします。しかし、Photoshopで開く場合luniが参照されるために影響は出ません。

とりあえず以上なのですが、まだまだありそうで恐ろしいｗ
マルチバイト関連のライブラリに手をいれて失敗しているのか、Unicodeにシフトしようとしてわざとやった結果なのかがはっきりしないのですが確信犯かもしれないｗｗｗ

2021.8.18追記

こちらの記事の不具合に関しては2021年8月リリースのPhotoshop ver.22.5.0、IIlustrator.ver.25.4.1で解消されています。
なにはともあれ、Maxリリース前に改善していただいたことに感謝したいと思います。