[[TAG index/URLエンコード・デコードフォーム]]

W3C勧告では、アンカー名(A要素のname属性、id属性)はASCII文字に限ることになってます。
非ASCII文字(不正なURI)が用いられていた場合にブラウザは、与えられた文字をUTF-8で表現し、そのバイトをURIエスケープする。という規則が推奨されています。
要するに、仮名漢字で指定されたアンカーやファイル名に飛べないものだと思ってかかれということです。

> アンカー名(A要素のname属性、id属性)はASCII文字に限る
> 要するに、仮名漢字で指定されたアンカーやファイル名に飛べないものだと思ってかかれということ

ああ、やはり、そんな感じでありましたか。
おかげさまで、疑問氷解。すっきりしたでありますです。(´▽｀)

> ブラウザは、与えられた文字をUTF-8で表現し、そのバイトをURIエスケープする

ということは、今のブラウザはそういった動作をしてるから、
非ASCII文字を使っても結構イケちゃうときがある、ということですかな。

このあたり、HTMLページ作成ツールの類で
サポートしておくべき内容なんだろうなぁ。
アンカー名に非ASCII文字が使われていたら警告を表示するとか。
いや、一通り出来てからチェックするツール・ページもありますけど。
http://openlab.ring.gr.jp/k16/htmllint/htmllint.cgi
とか。

う。日記ページをチェックしたら凄い事になった… orz

補足です。
>> 要するに、仮名漢字で指定されたアンカーやファイル名に飛べないものだと思ってかかれということ
「文字コード」が異なる場合、仮名漢字で指定されたアンカーやファイル名に飛べないと思ってかかれ です。

IEだと仮名漢字で指定されたアンカーに大抵飛べるのは
1.ページ読み込み
2.文字コードを認識し、内部的におそらくUTF-8へ変換
3.アンカーへジャンプ
という手順をとっているからだと思われます。
そして、Mozillaなどが文字コードが一致していない場合に指定したアンカーへ飛べないことがあるのは、おそらくW3C勧告で推奨されている手順をそのまま使っているため、同じ文字であっても文字コードが異なればURIエスケープした結果が違うものになってしまうことによるものでしょう。

> IEだと仮名漢字で指定されたアンカーに大抵飛べるのは〜

> おそらくW3C勧告で推奨されている手順をそのまま使っているため〜

なるほど。すると、W3C勧告の手順のほうが、
穴がありそうということですかね…。
さすが、腐っても(?)IE、というところでしょうか＜なんか違う気が…