.textClippingファイルについて

＞これってどういうファイルなのでしょう？
リソースフォークだけのデータです。
正確にはTEXTリソース。
＞また、ブラウザなどからのクリップは正常にされますが、
＞編集中の文章は文字化けしてしまいます。
＞TextEdit,Mail,OmniWebなどで確認しましたが、
＞これはバグでしょうか、それとも私の環境固有の問題でしょうか？
どれだと化けて、どれだと化けないのでしょうか？　もう少し詳しく（個別に）書いてください。
ちなみに、うちではTextEditで編集中のテキストをクリップしても化けません。
OmniWebのフォームのテキストエリアから編集中のテキストをクリップしても化けません。
もしこれらの状況で化けるのなら、文字コードなども関係してくるのかも知れませんね。

経験的に文字コードは変換されずに扱ってると思います。
Netscape 6.2.2 から AppleWorks へコピーアンドペーストすると化けますから。一旦 TextEdit や Stickes を経由させると問題ないので、TextEdit や Stickes には文字コードを認識して変換する機能が付いているのだと思います。

お二方には毎度お世話になります。（ペコリ）
>経験的に文字コードは変換されずに扱ってると思います。
だと私も思います。少なくとも私の環境だとそのようです。
具体的な文字化けの例ですが、
当方OmniWeb(現在4.1beta2日本語）にて試していますが、
もださんやiBookさんの書き込みを選択し
デスクトップ（Finderのウィンドウ内でもいいのですが）へドラッグ＆ドロップ、
これで、デスクトップ上にクリップファイルが出来ますが、
これを開いても当然問題なく選択した内容が開かれます。
しかし、今現在私がこの書き込みを行っている、
replyの文章の編集エリア内の文字を選択（つまりこの編集中の文）、
同様にドラッグして出来たクリップファイルをダブルクリック、
すると、全部化けて読むことが出来ません。
ちょうど、WEBブラウザで文字コードが違っていたときのような状態で、
開かれます。
次にこの文字化けしているクリップとしていないクリップ二つを、
TextEditの編集中のウィンドウへドラッグ＆ドロップ。
すると、きちんと読める形でペーストされます。
さらにこのTextEdit内の編集中の文章を選択、デスクトップへドロップ、
そこで新たに出来たクリップをダブルクリックにて開くと…、
やはり化けて表示されます。
アプリ間同士のコピー＆ペーストでは、
iBookさんの言われる通りです。
ということで、クリップファイルの表示の問題だけのようですので、
編集中の文字列はクリップファイルで表示できないコーディングなのかな、
と思うわけですが、いかがでしょうか。
そもそも、様々な文字コードを扱わなくてはならない状況なので、
多少は止むを得ないのかな〜などと思ったりもしますし、
バグと言うよりは仕様と言えるのかもしれませんね。
しかし、全くの初心者がファイルを開いたら、
分けのわからない文字列の羅列で、どうしていいかわからない。
なんて状況もあるでしょうから、
とりあえず、何らかの解決策がほしいかなと思います。
（ん？私だけの問題ではないですよね？）

比較的閉じられた環境のMacOS時代はあまり感じることも少なかった、
文字コードや改行コードの違いですが、
UNIXベースになり旧環境と混在した状況で、さらには、
VrPCなんかも動かしてたりすると、もう…。
OMNIのbookmarkをWINのネットスケープに無理矢理持って行ったら、
もう、めちゃめちゃ。（当たり前？（笑））
少なくともMacOS内では（Xと９間でも）統一したコードに変換して、
（OS Xではユニコードと言うことになるのでしょうか）
OS側で出来るだけ吸収してくれるようになるといいかな。
＃＃
ちなみに、クリップファイルっていつから搭載されたんでしたっけ？
気がついたら、あったって感じで…。
漢字Talk時代（System7.5)の頃はなかったような…。
（私が気付かなかっただけ？）

>というのも、画像ファイルはそのままの形式でクリップされることから、
テキストも通常のテキストファイルとして保存された方が、便利なのでは？
と思ったからです。
と書きましたが、Webブラウザ等から画像をドラッグすると、
その画像形式のファイルが出来ることから、
OSXでは、画像は皆その画像形式でクリップされるんだと勘違いしました。
画像も画像編集アプリ等から選択した部分を引っ張って行けば、
.pictClippingという形式のクリップファイルが出来ますね。
考えてみれば、OS9以前でもそうでした。失礼しました。
＃＃＃
しかし比較的閉じられた環境で使うことの多かった
MacOS時代はあまり感じることも少なかった、
文字コードや改行コードの違いですが、
UNIXベースになり旧OSと新OSのルールが混在した状況で、さらには、
VrPCなんかも動かしてたりすると、もう大変です。
（OMNIのbookmarkをWINのネットスケープに無理矢理持って行ったら、
もう、めちゃめちゃ。当たり前？（笑））
少なくともMacOS内では（Xと９間でも）統一したコードに変換して、
（OS Xではユニコードと言うことになるのでしょうか）
OS側で出来るだけ吸収してくれるようになるといいかな。
それともアプリ側で対応すべき問題なのでしょうか…。
画像にしても、tiffが標準でpictの位置付けが曖昧な気がします…、
例えばこのpictリソースファイル（で良いのですよね？）の扱いとか…。
＃＃
ちなみに、クリップファイルっていつから搭載されたんだろう？
こんな機能が搭載されましたって紹介されてた記憶がない…。
気がついたらあったような。
漢字Talk7.5くらいの頃はなかった気もするけど…？。
（私が気付かなかっただけかな）

テキストや画像が複数のアプリケーション間を跨いでドラッグされるとき、
送信側(ドラッグを開始した方)のアプリケーションは、
受信側アプリケーションの特定のウインドウに、
ドロップできるかどうかを問い合わせなくてすむように、
ペーストボードと呼ばれるデータの一時的な保存場所へ
最初から複数の種類のデータを同時に格納します。
Finderのウインドウに何かがドロップされる時、
その瞬間ペーストボードがチェックされ、そこでIDが'TEXT'の
データが含まれているようなら.textClipingが作成されますが、
このファイルの中身はペーストボードのデータそのままです。
このため作成されたデータに何が含まれることになるかは
送信アプリケーション側がドラッグ開始時に、
ペーストボードに何を格納するかによって決まることになりますが、
IEのテキストエリアや他にもmiだとかcarbonのアプリのいくつかのうち、
ドラッグするものにフォントや字詰め、カラー、インライン画像が含まれなければ、
'TEXT'以外のものを含めることは容量の無駄ですのであまり行うべきでないものとされています。
対してStickiesやTextEditでは、文字ごとに個別にフォントを
設定したりできるので、可能な限り書式を維持するために
Cocoaで使いやすい'RTF 'と、classicで使いやすい'styl'(styled Clipboard text)、
さらに書式が無効な場所へのドロップも可能なように'TEXT'の、
少なくとも3種類のデータを格納します。
で、問題のFinderで文字化けするクリッピングファイルと言うのは
'TEXT'のみしか保存されていないものです。
Finderで開こうとしたとき、フォントの情報が一切含まれていないため、
誤って英語のフォントを適用してしまうために発生します。
　
これはFinderにクリッピングの中身の文字を解釈できる仕組みをつけるか、
自分で任意のフォントの利用を設定する仕組みをつけるかすれば解決できる問題ですので、
気が向いた読者はフィードバックしてあげて下さい。

ほう、文字コード判定は関係ないのですね。フォント情報を渡してるかどうかということですか...
日本語環境だと、フォント情報が無かったらとりあえず Osaka にでもしてくれれば回避できるのかな？　それだと単なる地域化（ローカライゼーション）なので日本語以外の文字を使ってると化けて真の国際化（インタナショナリゼーション）とは言えなくて敗北感を感じますが...

皆さん、お詳しい解説、情報ありがとうございます。
毎回大変勉強になります。
もう少し、自分でも勉強をすすめて皆様のお役にたてるように、
なりたいものです。
今後も宜しくお願いします。
さて、今回の件、大変良くわかりました。
やはり、クリップファイルを開いたら、
文字化けしていた、では何かと問題もあるかと思いますし。
OSとしての完成度を疑われてしまう可能性もありますので、
ここはやはりOS側で表示の際にファント情報がないテキストに対して
何らかの対処をして表示する機能が必要だと思います。
というわけで、フィードバックしてみようかと思います。