そうそう。だから期待していたんだけどねぇ。

まぁ、そのとおりかな。並行して存在して、機器のリプレースと共に移っていくという。

「移行」が進まないよりも、移行しようとする先が提供されていないとエンドユーザー的には動きようがない。
非フレッツな旧USEN系は何時になることやら...。

こういうときだからこそ、可能な方には参加して欲しい。

ローカルに保存したファイルは、HTTP応答ヘッダーの情報が亡くなって、さらに不利な状況になる可能性もありそう。

Apacheで許可されてれば各ディレクトリの .htaccess で適切に何とかできるでしょう。この辺かな: addcharset.

iso-2022-jp以外でもcharsetなしだと同様なこと起きないのか、ちょっと気になりますな。

乱暴に言えば、HTTP応答ヘッダーがしっかりしてれば、<meta>なんてどうでも良いこと。
もちろん、わざわざ文字エンコーディングと一致してないcharsetを<meta>で指定するのはよろしうない。

自己フォロー。

もっとも、jpnicやjprsのサイトでさえ、きっちりとしたHTTP応答ヘッダーにcharset付けてないので絶望的とも言えるな。

ISO_2022_JP は論外だが、基本的にコンテンツに合ったHTTP応答ヘッダーのContent-Typeフィールドのcharsetを指定していないのがいけない。HTTP 1.1辺りではcharsetパラメータはtext/htmlとかに必須でなかったかな?

* 今までいい加減に済ませていたHTTP応答ヘッダーのツケが出てきた。
* 今まで勝手に中身を判断する悪しき挙動に身を染めていたIEがまっとうになろうとして失敗した。

と、いうあたりだろうな。

それはリポジトリ自体がアクセスされてしまった場合であって、.svnやCVSに過去の失敗は
含まれていないと思いますが?

まぁ、.svnなら修正前のオリジナルはあるでしょうけど。

そうそう。

一度上書きすれば十分。