Safari 3.1.1 (5525.18) であるサイトの画面を PDF 保存しようとして、「印刷」から「PDF」→「PDF 保存」を選ぶと、保存先を指定するダイアログボックスの「保存」のボタンがグレーのままで保存できません。他のサイトでは大丈夫です。ちなみに、そのページは「Web アーカイブ」でも「ページのソース」でもやはり保存はできません。何かサイトの方でファイルの保存や PDF 化ができないようにする設定のようなものが存在するのでしょうか？ しかし、普通に印刷する場合には「印刷」ボタンはちゃんとアクティブになっています。
試しに Adobe GoLive 9 で「サーバ」→「サイトをダウンロード」でファイルをダウンロードしてみましたが、画像はダウンロードされず、しかもやはり画面の PDF化はできませんでした...。
これは、どういう仕様、ないし現象なのでしょうか？
>Finder 251文字（全角文字は1文字、濁音・撥音は2文字カウント）
正確には、拡張子を含め全体でUTF-16（NFD）255文字まで。これはHFS+のファイルシステムの制限です。
>Safari 251バイト（全角文字は3bite、濁音・発音は6biteカウント）
これも拡張子を含め全体で255バイトですね。Safariというより、ファイル保存ダイアログの制限のようです。これはちょっとバグっぽいな。せめて上記のHFS+の制限である510バイトまではOKにすべきと思うが・・。ASCIIなら255バイト＝UTF-16 255文字だから矛盾がないし、やはり他言語がちゃんと考慮されてない感じ。
> 画面ダンプでファイルに出来ないウェブページというのは考えにくいです。
私の言葉が足りなかったみたいです。
メールで保存し、そのファイルを少し編集すると、印刷やPDF保存が出来る様になることを言いたかったのです。
> UTF-8 でコードすると、１文字が１ー４バイトになります。
> 今の場合、保存できたとおっしゃっている文字列は249バイトあります。
おや、Mac OS X は UTF-8 だったのですか？ UTF-16 ではなく？
> 255バイトじゃなく256文字のようです。
Unicode だと255文字もバイト数が色々になるようですが、OS的にはバイト数ではなく、文字数で規定されているのですかね...？
> Mac OS X は UTF-8 だったのですか？ UTF-16 ではなく？
UTF-8とUTF16の違いは？
こちらのページによると
--------------------------------------------------------
UTF-16の場合、2バイトで表現できる文字（0x0000〜0xD7FF、0xE000〜0xFFFF）はそのまま2バイトで表し、それ以降（0x00000000〜0x0010FFFF）の文字は4バイトで表します。このため英数も日本語も全て2バイトで表現されます。しかし、UTF-8は英数は1バイトで表現し、日本語は3バイトで表現するようになっています。
--------------------------------------------------------
だそうです。
ということは、FinderはUTF-16、アプリケーションの保存ダイアログはUTF-8で処理されているということ（で合ってます？）でしょうか。
Y. Kawabeさんのおっしゃるように、保存ダイアログでもUTF-16で処理されるべきなのになされていないのはバグってことなんでしょうね。
# 10.4のときはどうだったんでしょう・・・？
> ファイル名は日付だけにしてSpotlightで検索するのが楽なように思います。
Spotlight って実用的なんでしょうか？ 私の環境ではやたらと検索に時間が掛かるし、だいたい見つけたいものはまずヒットしないので、使い物にならないというのが実感なのですが...。むしろ以前のように単純にファイル名で検索できただけの方が便利だったような...。（Spotlight ではファイル名を検索しても、明らかに目の前に見えているファイルすらヒットしないことがよくあります...。）
> ということは、FinderはUTF-16、アプリケーションの保存ダイアログはUTF-8で
> 処理されているということ（で合ってます？）でしょうか。
MacWiki - UTF-8-MAC によれば、全部 UTF-8 のようにも読めますが...。日本語などをメインに使うユーザーには UTF-16 の方が保存容量効率が良く、日常的にラテン文字などをメインに使うユーザーには UTF-8 の方が効率が良いということなんでしょうね。UTF-8 だと通常の ASCII コードは互換性があるようですし...。そこで多くの外国製アプリケーションは UTF-8 対応になっているのかと...？ ブラウザも UTF-8 は選択できますが、UTF-16 はできないようですね...。
しかし、Unicode って色々な規格があって、「これって、文字コードなの？」とつい、思いたくなってしまいます (^^;)。かつての ASCII や Shift JIS、Latin-2 等のように、それを選択すれば、パッとその文字コードに変わるというわけではないようで。
ちなみに私は Unicode 支持者なのですが（問題が山積みなのは理解していますが、Unicode に色々欠点があるとは言え、では、Shift JIS 等のままの方がいいのかと言えば、Unicode の方が断然表現力が増えたわけですからね）、Mac OS が Unicode になってからは、昔のファイル等が文字化けした時にしばしば修正する方法がなくて困っています。以前は単に文字コードを偏向してやれば直ったのですけれどもね。過去に EndNote Plus で作成した書籍データベースを EndNote X で読み込むと文字化けの嵐で、修正する方法がなくて困り果てております...
> 私の環境ではやたらと検索に時間が掛かるし、だいたい見つけたいものはまずヒットしない
当環境では特に問題ないです。
PDFやテキストの内容で検索がかけられるので、思いつくキーワードを2、3入力すれば大抵目的のファイルにたどり着くし分類分けしたフォルダの階層を下るより速いので重宝しています。
# 昔はフォルダ分けとか名前の付け方とかきっちりとしていたものですが最近だんだんと杜撰になってきているのはいいのか悪いのか・・・ (^^;
> むしろ以前のように単純にファイル名で検索できただけの方が便利だったような...。
私は内容で検索したいときはSpotlight、ファイル名で検索したい時はEasyFindと使い分けています。
> 私は内容で検索したいときはSpotlight、
> ファイル名で検索したい時はEasyFindと使い分けています。
EasyFind もいまいちで...。もちろん、私の場合ですが...。
OSXの文字コードはUTF-8ですが、HFS＋のファイル名がUTF-16になっています。
Finderを含めすべてのアプリはUTF-8で処理しますので、日本語など3バイト以上になる文字を考えると、処理のバッファとしては510バイトでも不足ということになります。文字列からすぐに全体のバイト長が求まらないというUTF-8の欠点がここで表面化しますね。おまけに、HFS+のUTF-16はNFDなので、ファイル名に関してはUTF-8-MACで扱わねばならず、いっそうややこしい。SMBやAFPなどのネットワークファイルシステムでは、Macのファイル名は鬼門になってるようですね。
>10.4のときはどうだったんでしょう・・・？
同じです。（私の環境は10.4ですので。）
> OSXの文字コードはUTF-8ですが、HFS＋のファイル名がUTF-16になっています。
ここら辺、“言葉”としては理解できるんですが、実際の所となると「??」となってしまいます (^^;)。
Mac OS X は内部処理に UTF-8 を使っているわけですよね？ で、HFS+ のファイル名は UTF-16 だと...。すると、アプリケーション上からダイアログボックス経由で Finder にファイルを保存する場合に、まず、ダイアログボックスの「名前」欄に表示される自分が入力したファイル名は UTF-8 で表示されているわけですね？ で、実際に保存されたファイルを Finder 上で見ると、そのファイル名も（Finder はアプリケーションですから）UTF-8 で表示されているということなんですね？ しかし、ハードディスク上では実際には UTF-16 で保存されていて、Finder は UTF-8 に翻訳して表示しているということなんでしょうか？ 実際に HFS+ で UTF-16 で保存されているということはどうやったら確認できるのでしょうか？
今回、皆さん、「○○の部分は UTF-8 で保存されているようなので ○○バイトになりますが、○○の部分は UTF-16 で保存されているようなので、○○バイトになります」等と書かれていらっしゃいますが、マック上で今自分の目の前の文字列がどういうコードなのか、どうやったら判断できるのでしょうか？ Jedit X のようなエディタ上や Safari や Apple Mail 上でしたら、今の文字コードが何かを確認する方法はわかっているのですが...。
> 文字列からすぐに全体のバイト長が求まらないというUTF-8の欠点が
> ここで表面化しますね。おまけに、HFS+のUTF-16はNFDなので、
> ファイル名に関してはUTF-8-MACで扱わねばならず、いっそうややこしい。
要するに UTF-8 は ASCII との互換性とラテン文字を使っているユーザーの容量使用の効率性に配慮したために可変長の文字コードになってしまっているので、そのことがファイル名管理を複雑にしているということですね？ 私は色々な言語を使用しますが、それでも日本語が圧倒的に多いわけで、そういう場合には、つまり日本語をメインに使用するユーザーの場合は、エディタなどのデフォルト文字コードは UTF-16 にしておいた方がいいということですね？ しかし、アップル自体はテキストファイル等のデフォルト文字コードは UTF-8 を想定しているのでしょうか？
> SMBやAFPなどのネットワークファイルシステムでは、
> Macのファイル名は鬼門になってるようですね。
しばしばネットワークでハードディスクなどを共有したりすると、文字化けを起こしたり、使用できるファイル名の長さが極端に制限されるというのはこのためだったんでしょうか？
>ハードディスク上では実際には UTF-16 で保存されていて、Finder は UTF-8 に翻訳して表示しているということなんでしょうか？
詳しくは知りませんが、ファイルシステムをアクセスするAPIがやっているはずです。ファイルシステムによって使用している文字コードは異なります。例えばFATならSJIS、NTFSならUTF-16（NFC）、UFSならUTF-8など。これらがマウントされると、アプリからのその中のファイルへのアクセスはUTF-8のパス名で行われるので、その部分のAPIで変換されていることになります。
>実際に HFS+ で UTF-16 で保存されているということはどうやったら確認できるのでしょうか？
簡単な方法は無いでしょうね。HDDをrawデバイスでアクセスして、直接B-Treeの中を見ないとだめじゃないでしょうか。
でも、UTF-16なのはAppleの文書にも書かれている周知の事実なので、あえて確認する意味はないでしょう。
>マック上で今自分の目の前の文字列がどういうコードなのか、どうやったら判断できるのでしょうか？>
ですから、これはOSX上では常にUTF-8です。他の文字コードになっているのは、あくまで何らかの媒体の中に保存されているデータの話です。
>UTF-8 は ASCII との互換性とラテン文字を使っているユーザーの容量使用の効率性に配慮したために可変長の文字コードになってしまっている
どのOSでもそうですが、ASCIIと互換の無い文字コードを使うとなれば、OS全体を書き換えないとだめでしょうから、OS内部の文字コードとしてUTF-16やUTF-32を使うことはまず考えられませんので。
>日本語をメインに使用するユーザーの場合は、エディタなどのデフォルト文字コードは UTF-16 にしておいた方がいいということですね？
サイズにこだわるならそうなりますが、OSが使用していない文字コードを使うなら、当然その文字コードに対応しているアプリでしか使えません。一概にどちらが良いとはいえないでしょう。
>しばしばネットワークでハードディスクなどを共有したりすると、文字化けを起こしたり、使用できるファイル名の長さが極端に制限されるというのはこのためだったんでしょうか？
それはまた別の問題（HFSとHFS+の違いなど）です。NFDは他のOSでは全く使われていない上に、Appleの方言のようなものもあるらしくて、完全対応が面倒だということだと思います。
Safari で PDF で保存できないサイトがある
