ある意味どうでもいいことや、役立つかどうかもわからないような中身を、日々脳内から適当に垂れ流しまくりつつ、今日をなんとか生き存えることを思案してます。
まずはOS Xについて。
いきなり図版が3パターンありますが、Windowsと共通する部分であったり、小形さんのコメント等も参考にしたもの、そうでないもの入り交じってたりしますので、少々ややこしい内容になってますのであしからずご了承ください。
上から順に(a) (b) (c)として呼称します。
まず(a)ですが、コピー＆ペースト処理が単一アプリケーション内で完結する場合について。この場合は「アプリケーション固有情報」がそのままペーストされるため、特に変化はないと考えて差し支えないでしょうｋ。これはWindowsも同様の処理です。
次に(b)と(c)。この場合はクリップボードを経由して異なるアプリケーションにペーストされる場合です。
こちらでは、メインプロセスが一度コピー元のアプリケーション（Application A）から異なるプロセス（Application BやFinder/Explorerなど）に移った際の処理が働きます。クリップボードの情報は、OSの処理によって「OS自身や他のアプリケーションが認識可能な情報」と「Application Aが認識できる固有の情報」に分離処理されます。ここまでだけで言うとWindowsもまったく同じ。
この時、OS Xの場合は必ず「OS（カーネル）自身が認識できるように」という前提によって変換が行われるため、自動的にUTF-8に変換され、かつ、Normalization Form Dによる正規化処理（正規分解）が行われることになります。
ここからは(b)(c)別々の処理です。
まずは(b)ですが、Application Bにペーストする場合、Application B自身がOS XのAPIを叩いて「UTF-16へのコード再変換」「Normalization Form C（正規化合成）」を行ってから取り込んだ場合を示しています。この場合は、クリップボード内で前出の処理が行われていることを前提に（決めつけして）、オリジナルと同じ情報を保とうとするために行おうとしているものです。その結果として、復号された文字コードは正常に認識ができることになります（ただ、NFCが本当に行われているかどうかがよくわからないので「?」を付けています。もしかしたらされていないかも）。
一方、(c)については、Application B自身は「必要に応じて、OSのAPIによってUTF-16へのコード再変換」のみ処理させる（なのでペースト先によってはUTF-16変換はされない）状態で取り込むパターン。この場合は分解された情報、かつ、Application B自身が認識出来る情報のみ取り込むので、結果として文字コードそのものが変化してしまう（オリジナルと異なる情報になる）という結果。
一方、Windowsの場合。内容的には(b)(c)に相当するものでの図版は以下。
Windowsでは、OS Xと同様に「OS自身や他のアプリケーションが認識可能な情報」と「Application Aが認識できる固有の情報」という分離処理こそ行いますが、UTF-8への変換は行いません。
Windowsの場合は、内部で認識できるコードはUnicode(UTF-16)であるため、それ自体は必要性がない、ということになります。また、InDesignの結果を見る限りですが、正規化処理等も含まれていないように見えるので、クリップボード内部では特別な処理などは行っていないように見える、というわけです。
上記のように考えたものの、実際にはNAOIさん・小形さん両名のコメントからもわかる通り、単純にそうではないみたいです。
なぜそうなるのか、というのは、アプリケーション固有の処理が絡んでいるためになるわけですが、それを説明するためには現状では情報が足りません。
なので、それを確認するためにはまだまだ続いて、別の確認を行わなければならないということに。
……てことでまた時間のあるときに書きます、ええ。
コメント
えーと、最初にも断ってはおりますが、かなり仮定や推測が混じってます。
一部実体験も含みますが。
ところで、よくよく考えてみると、OS XのTerminalには「pbcopy」「pbpaste」なる、クリップボードの中身を確認するためのありがたいコマンドがありました。
http://journal.mycom.co.jp/column/osx/106/index.html
このあたりを利用して、クリップボードの中身を確認しつつ、OS Xでも検証しなければならないかもしれないということを痛感したわけで。
……いつごろ全てが終わるのかわからなくなってきた気がしないでもないです。
2008/07/28 22:42 by あさうす URL 編集
プログラマでもないので、ぼくもあまりよく分かっていないのですが……。
> この時、OS Xの場合は必ず「OS（カーネル）自身が認識できるように」という前提によって
> 変換が行われるため、自動的にUTF-8に変換され、かつ、Normalization Form Dによる
> 正規化処理（正規分解）が行われることになります。
この部分は、なにか典拠となるような資料があるのでしょうか。もともとUnicode正規化は文字列の照合を目的とした処理ですよね。たとえばUnicideでは「フォルダ」を表す符号の並びは、結合文字を使った合成列か、それとも合成ずみ文字かで変わってきます。しかし見た目は同じです。ファイル管理システムにおいてはそれでは困るので、正規化によってどちらかに揃える処理が必要になるわけですよね。
一方で、なぜ正規化がクリップボードで必要なのか、その部分がよくわかりません。「必ず」クリップボードで行われるというのは考えづらいように思うのですが、いかがでしょう。
Mac OS Xの挙動を見ていると、かならず合成列にするという訳でもないようです。たとえば、ことえりで「ダ」を入力すると、それはU+30C0、つまり合成ずみ文字の方です。ところがこの文字をコピーして、Finder上のフォルダ名なんかにペーストすると、とたんにU+304B／U+3099の合成列に変換されるわけです。
2008/07/28 00:50 by おがたかつひろ URL 編集