文字コード指定メニュー

文字コード指定メニュー (Web)

[1] Webブラウザーには、文字コードの指定のためのメニューがあるのが普通でした。

[2] これは文字コードを選択して再読込を実行するものです。

[4] HTTPヘッダーHTML文書内の文字コードの指定は、無視されます。

[11] 変更のためのメニューとしてはもちろん、 文書の文字符号化利用者に提示するための欄としても機能していました。 Webブラウザーの一般利用者も最低限の文字コードの知識が必要な時代でした。

[23] 現在では主要なWebブラウザーがこのメニューを廃止してしまいました。 そのため古くからある一部のWebページ (稀に近年作られたごく一部の Webページ) が文字コードを誤判定して文字化けして表示されても、 一般の利用者が修正することすらできなくなってしまいました。

[24] 明らかに Web非互換で有害な変更であるにも関わらず、 主要な Webブラウザー事業者らは廃止を強行し、 被害を無視しています。

挙動

[3] 実際の処理はどの仕様でも規定されていませんが、 HTML構文解析器における change the encoding による navigate に相当する操作 (当該ページ読み込みに使ったデータを使った読み込み、 またはそれができない場合同じ fetch 条件を使った読み込みを a known definite encoding 指定付きで実行) することが期待されていると思われます。

[5] HTML文書に限らず、XML文書テキストファイルにも適用されます。

[10] 適用対象は文書だけであり、 XHRJavaScript ファイルや CSS ファイルなどには適用されません。 (ただし明示されないとき既定値が文書の文字符号化になることで間接的に適用される場合はあります。)

選択肢

[6] 文字コードを誤認識することによる脆弱性を発生させることを意図した攻撃を防ぐため、 UTF-7 など危険性の高い文字コードを候補に含めることは望ましくないと考えられています。 また近年では文字コードの誤認識を利用者が修正せざるを得ない状況は減ってきており、 Webブラウザー上の文字コード指定メニューの扱いも小さくなっています。

[8] 歴史的には大量の文字コードの選択肢を並べるのが一般的でした。

[7] 現在では、 Encoding Standard で規定されている文字符号化 (replacement を除く。) のみを候補に挙げるのが好ましいと考えられます。

[9] 他に「自動判定」や「自動判定 (日本語)」や「自動判定 (ロシア語)」 が必要かもしれません。

メニュー廃止の被害

[14] Firefox の文字コード指定メニューなくなっちゃった? FirefoxChrome に対する数少ない優れた点を削ってどうすんのよ。。。

[15] もみじばしさんはTwitterを使っています: 「つちぶた本舗の全駅訪問の旅が文字化けして困っています https://t.co/8jxWB9YJFm」 / Twitter, , https://twitter.com/momiji_3015/status/1567919885443026946

[16] ひめ@女体化したい人生だったさんはTwitterを使っています: 「ウチのサイトも見事に文字化けしてたとの報告をいただきました(気づいてなかった…) いい加減shift_jisなのも悪いのか。いま外出中なので対応できないけど、UTF-8にする方向で検討中です。」 / Twitter, , https://twitter.com/sarasvati635/status/1576429367999143937

[17] Internet Archive90年代東アジアのウェブサイトがまともに表示できないところが多くて辛い。。。 当時からブラウザーの文字コードメニューで文字化けを治すのが普通の操作みたいになってたようなあれだから、 ブラウザーにメニューがなくなって自動判定も働かない (or 間違った文字コード指定がついてる) ともうお手上げなんだよなあ。

[18] 近年のWebプラットフォーム開発の人達はWeb互換性を忘れてしまったみたいで、 これじゃあ百年後に昔のウェブサイトは見れなくなるんじゃないかと思っていたけど、 もう既に20年前のウェブページがまともに見れなくなってしまったんだよなあ。

[19] Internet Archive にしかないサイトはまあ仕方がないとしても、 現役サイトでも長年放置されてるところが表示できなくなってるのは困りもの。

[20] 意外とGoogle検索ではちゃんと文字コード判定できてて、 Google検索に出てくるのにChromeで表示できないとかいう地獄。

[21] ちょっと前までは Chrome で見れなくても Firefox なら文字コードメニューで表示できたのに。 Firefox はただでさえシェアが減ってるのに存在意義を自ら削ってるのやばいだろ。

[22] 他の事例は HTML documents misinterpreted by charset sniffer 参照。


[25] こういう非互換変更を強行した Webブラウザー事業者の主要開発者らはほとんど欧米人で、 もう文字化けは遠い昔の記憶になってしまっているんですよねえ。 アジアではまだたまに遭遇する身近な事象だというのに。 こういうのも一種の欧米中心主義なのでしょうか。

[26] まあそういう無意識的な偏見だけでなく、 古いものはとっとと捨ててしまえという IT業界の悪習から来てる所はありそうですよね。

[27] 古いページが残っていても新しいものはどんどん増えていき、 新しいものの方が参照されやすいという局所性と相まって、 古いページが見られる割合はどんどん下がっていく (が皆無になるわけではないし、希少性が上がるということは貴重になるということでもある) のに、 割合が低いから切り捨ててもいいという判断を Webブラウザー事業者が安易にしすぎるところがよろしくない。 近年の傾向だと特に Google の従業員はそういうところがあり、 Mozilla はそうでもないが何年かして結局最後に Google に追随する感がある。

[28] 文字コード変更メニューの場合あって困ることないんだから、 Firefox には残しておいた方が Firefox でないと正しく表示されないページがあります、って優位性のアピールに使えるのにねえ。 自分たちで必要な機能を削っておいて、 Firefox のシェアが減って困ってます、っていわれてもな。 自業自得やん。こっちはもっと困ってるんだよ。

歴史

[12] 参照処理モデル確立以前の Webブラウザーはシステムの文字コードで表示するのが基本で、 優れた実装はそれ以外にも沢山の文字コードを変換して表示できるという世界でした。

[13] それすら不完全で、例えば日本語WindowsNetscape Navigator文字コード指定メニューには世界各地のいろいろな文字コードが示されてはいましたが、 ISO 8859-1 を選んでもシフトJISビット組合せが同じ半角カナ表示されるという有様でした。

[897] 943252 – Move nsCharsetMenu and charsetTitles.properties to comm-central ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=943252