OSとファイル名の関係に気をつけよう

プラットフォーム間の問題

InDesignはクロスプラットフォームを謳い文句にしているアプリケーションです。実際、操作性はWindows版とMacintosh版でほとんど同じ、出来上がるデータも同じでWindows版で作ったデータをMacintosh版で開いてもデータが変わってしまうことはありません。

さらにOpenTypeフォントだけを使っていれば、フォント環境の違いに悩まされることもありません。プラットフォームの違いが大きな壁となってきた従来のDTPを考えると大きな進歩と言えるでしょう。これも、OSに依存しないデータ管理を推進してきたAdobeやユーザーの努力のたまものと言えるのかもしれません。

ただし、OSの違いによって起きる問題が完全になくなったわけではありません。その違いを把握していないと大きなトラブルになる可能性もあるのです。中でも注意しなければならないのがファイル名の問題ではないでしょうか。

パソコンでは、データは基本的にハードディスクやSSDなどのストレージで保管・管理されます。データをどのように保管するか、その管理を司るのがファイルシステムです。Windowsでは一般にNTFS、macOSではHFS+やAPFSといったファイルシステムが使われています。

管理方法であるファイルシステムが変われば、ファイルの最大容量やファイル名の規則も違ってきます。Macintoshでこれまで長い間使われてきたHFS+では、ファイル名には最大255字までのユニコード文字が使えました。一方、Windowsで使われているNTFSは、ファイル名に255字までのユニコード文字が使えます。

こう比べてみると、MacとWindowsでそれほど大きな違いがないように思われるかもしれません。しかし、実際には重大なトラブルが起きかねない違いがありました。

ユニコードの正規化形式

文字コードは、文字セットとその実装方法を定めたものです。ユニコードの場合、実装方法がひとつではありません。エンコーディング（符号化）の方式だけでも、UTF-8、UTF-16、UTF-32などいくつもあるのです。UTF-8は8bitの文字列を複数使って文字を表す方式、UTF-16は、16bitの文字列を1個ないし2個使って表す方式です。NTFSやHFS+はUTF-16、APFSはUTF-8を採用しています。

エンコーディング方式以外にも違いがあります。それがユニコードの正規化形式です。

ユニコードでは、フランス語やドイツ語などで使われるアクセント付き文字のような、複数の文字を組み合わせてひとつの文字を表現する「結合文字」という仕組みが用意されています。たとえば、「が」という文字を表現することを考えてみましょう。ユニコードでは「が」という文字に「U+304C」という符号が割り当てられていますが、それ以外に「か」（U+304B）と濁点「゛」（U+3099）を合成することでも「が」を表現できるようになっているのです（「か」を基底文字、「゛」を結合文字と言います）。この場合、「U+304C」と「U+304b U+3099」は等価の文字であるとみなします（「等価」には、意味も見た目も同じである「正準」と見た目に違いがあるものも含む「互換」の2種類がある。「が」は正準等価）。

このように同じ文字に対して複数の表現があるため、ファイルを管理するシステムでは混乱が生じないように統一的な表現に変換する処理が必要になります。それがユニコード正規化という形でルール化されているわけです。ユニコード正規化形式は4種類あります。そのうち、正準等価性で分解する処理が正規化形式D（NFD）、正準等価性で分解してから合成する処理が正規化形式C（NFC）です。1つの文字の「が」は正規化形式C（NFC）、「か」＋「゛」のように分解されている文字は正規化形式D（NFD）の結果です。

Windowsをはじめとする多くのOSとファイルシステムでは、NFC正規化されたファイル名もNFD正規化されたファイル名もそのまま保存されます。ただし、OSでファイル名を入力する際には濁音や半濁音は1つの合成済みで入力されるため、結果としてファイルのほとんどはNFC正規化されたファイル名がついています。ところがMac OS Xの標準ファイルシステムだったHFS+ではNFD（正確にはNFDを部分的にカスタマイズしたもの）が使われており、しかもデータをHFS+のストレージに保存した段階でファイル名に含まれる濁点は結合文字に変換されることになります。

これが、アプリケーションによっては問題を引き起こすのです。たとえば、macOS上でInDesignに画像を貼り込む作業を考えてみましょう。HFS+でファイル名にはNFDが使われるため、画像のファイル名に濁音や半濁音が使われていた場合、基底文字＋濁点や半濁点という形で記述されています。InDesignはリンクとして画像を取り込む際にファイル名を記録しますが、それはこのNFDの形で記録されるわけです。

次に、InDesignファイルと画像ファイルをWindowsに持ってきて開いてみます。Windows環境ではNFDで正規化されたファイル名の濁音や半濁音が文字化けしてしまう可能性がありますが、文字コードの違いを吸収できるストレージや転送ツールなどを使えば変換することができます。

ところが、InDesignの内部に保持されているファイル名はNFDのままです。そのため、InDesign内部でリンク先ファイル名の濁音や半濁音付きの文字が基底文字＋結合文字の2文字として認識されてしまうのです。しかも、NFDの結合文字は文字化けする可能性があります。

実際、Mac上で画像を貼り込んだInDesignデータをWindowsで開くと、画像のファイル名によっては文字化けしたり、リンクが切れてしまうというトラブルが起きます。そうなると、あらためてリンクし直すしかありません（ファイル名だけが問題なので再リンクで正しくリンクし直せば大丈夫）。

なお、2016年、アップル社は新しいMac用ファイルシステムとしてAPFS（Apple File System）をリリースし、macOS 10.13以降のデフォルトのファイルシステムとなりました。

APFSは、それまで長い間MacのデファクトだったHFS+に比べてセキュリティとパフォーマンスが向上し、特にSSDなどフラッシュメモリに最適化されたシステムと言われています。ファイル名に関しては、HFS+と異なり、ファイルシステムでユニコード正規化が行われるわけではありません。ただし、ファイルシステムでは何もしなくてもFinderの作業でNFD正規化が行われてしまえば、同様の問題が起きる可能性があります。

この問題を根本的に解決するには、クロスプラットフォームで作業する場合は、ファイル名に濁音や半濁音など複数の表現が存在する文字を使わないというルールを守るしかないでしょう。なお、ファイル名によってトラブルが起きる可能性はOS以外のプログラムも含めるとほかにもあります。結局のところ、ファイル名は昔ながらの8.3形式（半角8字＋拡張子3字）で英数字だけを使うのが一番安全だということかもしれません。

（田村　2007.7.2初出）
（田村　2023.8.21更新）