クリップボードの中身を考察してみる

どうも、個人的にいろいろあって落ち込んでいるわしです。



てことで、この間からちまちまやっている(というほどやっていないものの)、互換漢字〔正規化表現文字〕をコピー&ペーストしたときの挙動についてです。現在のエントリでいうと、こちらこちらのふたつ。
本エントリでは、以前のコメント欄で予告した通り、簡単ながら起こした図版を元に説明してみます。

もっとも、APIやアプリケーションの挙動そのものは推測が多分に混じってるので誤りの可能性もありますが、という前提をつけときます。あしからず。

ちなみに今回は、InDesignとは敢えて無関係にしてあります。
「Uncode(UTF-16)を含む情報をクリップボードを介した場合における、OSおよび一般的なアプリケーション間の挙動(としての推測)」に絞っているので、個々のアプリケーションまでは原則として関与してません。



まずはOS Xについて。
いきなり図版が3パターンありますが、Windowsと共通する部分であったり、小形さんのコメント等も参考にしたもの、そうでないもの入り交じってたりしますので、少々ややこしい内容になってますのであしからずご了承ください。
上から順に(a) (b) (c)として呼称します。

080723_クリップボード_OSX

まず(a)ですが、コピー&ペースト処理が単一アプリケーション内で完結する場合について。この場合は「アプリケーション固有情報」がそのままペーストされるため、特に変化はないと考えて差し支えないでしょうk。これは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)に相当するものでの図版は以下。

080723_クリップボード_WinXP

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でも検証しなければならないかもしれないということを痛感したわけで。
……いつごろ全てが終わるのかわからなくなってきた気がしないでもないです。

おがたです。
プログラマでもないので、ぼくもあまりよく分かっていないのですが……。

> この時、OS Xの場合は必ず「OS(カーネル)自身が認識できるように」という前提によって
> 変換が行われるため、自動的にUTF-8に変換され、かつ、Normalization Form Dによる
> 正規化処理(正規分解)が行われることになります。

この部分は、なにか典拠となるような資料があるのでしょうか。もともとUnicode正規化は文字列の照合を目的とした処理ですよね。たとえばUnicideでは「フォルダ」を表す符号の並びは、結合文字を使った合成列か、それとも合成ずみ文字かで変わってきます。しかし見た目は同じです。ファイル管理システムにおいてはそれでは困るので、正規化によってどちらかに揃える処理が必要になるわけですよね。
一方で、なぜ正規化がクリップボードで必要なのか、その部分がよくわかりません。「必ず」クリップボードで行われるというのは考えづらいように思うのですが、いかがでしょう。

Mac OS Xの挙動を見ていると、かならず合成列にするという訳でもないようです。たとえば、ことえりで「ダ」を入力すると、それはU+30C0、つまり合成ずみ文字の方です。ところがこの文字をコピーして、Finder上のフォルダ名なんかにペーストすると、とたんにU+304B/U+3099の合成列に変換されるわけです。
非公開コメント

最近の記事

はてブ数順傾向

プロフィール

あさうす

  • Author:あさうす
  • DTP業界を中心に主観だらけの毒を吐いてます。後ろ盾なし、保証なし。あくまでも独断と偏見に満ちているだけで、何かの圧力とかはありません。たぶん。いやないです。信じてください。

    なお、名無しコメント&煽り、勝手にトラックバックやリンクなどはご自由に。spam認定したもの以外は削除しません。ただしFC2の都合でTBは弾かれるかもしれません。

    当blogは、Firefoxを推奨します。

    何かお問い合わせございましたら [assause@gmail.com] までどうぞ。

月別アーカイブ