[1] Webブラウザーには、文字コードの指定のためのメニューがあるのが普通でした。
[2] 文字コード指定メニューは、 文字コードを選択して再読込を実行するものです。
[11] 変更のためのメニューとしてはもちろん、 文書の文字符号化を利用者に提示するための欄としても機能していました。 は Webブラウザーの一般利用者も最低限の文字コードの知識が必要な時代でした。
[23] 現在では主要なWebブラウザーがこのメニューを廃止してしまいました。 そのため古くからある一部のWebページ (稀に近年作られたごく一部の Webページ) が文字コードを誤判定して文字化けして表示されても、 一般の利用者が修正することすらできなくなってしまいました。
[24] 明らかに Web非互換で有害な変更であるにも関わらず、 主要な Webブラウザー事業者らは廃止を強行し、 被害を無視しています。
[3] 実際の処理はどの仕様でも規定されていませんが、 HTML構文解析器における change the encoding による navigate に相当する操作 (当該ページ読み込みに使ったデータを使った読み込み、 またはそれができない場合同じ fetch 条件を使った読み込みを a known definite encoding 指定付きで実行) することが期待されていると思われます。
[10] 適用対象は文書だけであり、 XHR や JavaScript ファイルや CSS ファイルなどには適用されません。 (ただし明示されないとき既定値が文書の文字符号化になることで間接的に適用される場合はあります。)
[31] Chrome では、利用者が手動で文字コードを指定すると、 以後そのタブでは (著者による明示的な指定があっても無視して) その指定に従うようです。他のタブには伝播しません。 起源の違いにも左右されないように見えます。
[32] GUI 系の古典的な Webブラウザーの多くは、「表示」などのメニュー項目の下に、 対応している文字コードの一覧を提示してそこから選択させていました。
[33] 何に対応するか、そのうち何を表示するかは完全に Webブラウザー次第で、 動作する OS 等によっても異なることがありました。
[35] ただこの実装方法は利用者に文字コードの深い知識がなければ正しい選択が困難です。
[36] charset sniffing 等の知識によって候補となる文字コードを絞り込んで優先的に表示し、 それ以外も必要なら選択できるようにするのが好ましいでしょう。
[46] フレーム内の文書の場合は、フレーム外の文書とは独立して文字コードを修復したいことがあります。 Webブラウザーは、 右クリックの文脈メニューなどの手段でフレーム単位で文字コード指定メニューを提供する必要があります。
[47] フレーム外の文書の文字コード指定メニューは、必ずしもすべての子孫のフレームにその効果を波及させる必要はないと考えられますが、 環境符号化としての伝播があった場合はフレーム外の再読み込みによって自動的に子孫も指定された文字コードに変更されるのが適切な動作でしょう。
[44]
CLI のツールやプログラミング言語のライブラリーなどは、
呼び出し時のオプション等の方法で文字コードを指定できるようになっていることが多いです。
対話的ではないとしても、文字コード指定メニューと同等の機能を提供するものといえます。
[45] その他の種類の利用者エージェントやWebブラウザーも、それぞれの媒体に適した利用者インターフェイスにより、 同等の機能を提供する必要があります。
[6] 文字コードを誤認識することによる脆弱性を発生させることを意図した攻撃を防ぐため、 UTF-7 など危険性の高い文字コードを候補に含めることは望ましくないと考えられています。 また近年では文字コードの誤認識を利用者が修正せざるを得ない状況は減ってきており、 Webブラウザー上の文字コード指定メニューの扱いも小さくなっています。
[8] 歴史的には大量の文字コードの選択肢を並べるのが一般的でした。
[7] 現在では、 Encoding Standard で規定されている文字符号化 (replacement を除く。) を基礎に、 Encoding Standard が対応しきれていない地域の文字コードを若干補った程度のもののみを候補に挙げるのが好ましいと考えられます。
[9] 他に「自動判定」や「自動判定 (日本語)」や「自動判定 (ロシア語)」 が必要かもしれません。
[16]
その後時代が進み、サーバーが UTF-8 を機械的に
Content-Type: に指定することが増えたため、
古くからあるHTML文書やテキストファイルの実際の文字コードと食い違うケースが散見されるようになりました。
現代ではこれを無視させるために文字コード指定メニューの需要がむしろ高まっています。
[22] 平成時代後期から令和時代初期の頃になって、 主要な Webブラウザーは次々と文字コード指定メニューを廃止してしまいました。
[84] それによる被害報告が多くありますが、 Webブラウザー事業者らは黙殺しています。
[29] 今となっては文字化けする Webページの絶対数は少ないので、 無視し続ければ過去の遺産として無かったことにできると考えているのでしょう。
[85] 実事例はWebブラウザーによる文字コード判定の失敗事例集参照。
[60] いつのまにか Chrome の文字コード選択メニューがなくなって、 文字化けしているページを正しく表示する方法がなくなってしまった。。。
[81] No way to see UTF-8 file [41308220] - Chromium, https://issues.chromium.org/issues/41308220
[14] Firefox の文字コード指定メニューなくなっちゃった? Firefox の Chrome に対する数少ない優れた点を削ってどうすんのよ。。。
[17] Internet Archive で90年代東アジアのウェブサイトがまともに表示できないところが多くて辛い。。。 当時からブラウザーの文字コードメニューで文字化けを治すのが普通の操作みたいになってたようなあれだから、 ブラウザーにメニューがなくなって自動判定も働かない (or 間違った文字コード指定がついてる) ともうお手上げなんだよなあ。
[18] 近年のWebプラットフォーム開発の人達はWeb互換性を忘れてしまったみたいで、 これじゃあ百年後に昔のウェブサイトは見れなくなるんじゃないかと思っていたけど、 もう既に20年前のウェブページがまともに見れなくなってしまったんだよなあ。
[19] Internet Archive にしかないサイトはまあ仕方がないとしても、 現役サイトでも長年放置されてるところが表示できなくなってるのは困りもの。
[21] ちょっと前までは Chrome で見れなくても Firefox なら文字コードメニューで表示できたのに。 Firefox はただでさえシェアが減ってるのに存在意義を自ら削ってるのやばいだろ。
[25] こういう非互換変更を強行した Webブラウザー事業者の主要開発者らはほとんど欧米人で、 もう文字化けは遠い昔の記憶になってしまっているんですよねえ。 アジアではまだたまに遭遇する身近な事象だというのに。 こういうのも一種の欧米中心主義なのでしょうか。
[30] 欧米人にとっては文字化けが仮にあるとしても一部の文字だけで、 ほとんどの ASCII文字は読めてしまいますからね。 アジアのように言語の文字の大部分が関係ない文字に見えるという状況を体験していないのでしょう。
[26] まあそういう無意識的な偏見だけでなく、 古いものはとっとと捨ててしまえという IT業界の悪習から来てる所はありそうですよね。
[27] 古いページが残っていても新しいものはどんどん増えていき、 新しいものの方が参照されやすいという局所性と相まって、 古いページが見られる割合はどんどん下がっていく (が皆無になるわけではないし、希少性が上がるということは貴重になるということでもある) のに、 割合が低いから切り捨ててもいいという判断を Webブラウザー事業者が安易にしすぎるところがよろしくない。 近年の傾向だと特に Google の従業員はそういうところがあり、 Mozilla はそうでもないが何年かして結局最後に Google に追随する感がある。
[28] 文字コード変更メニューの場合あって困ることないんだから、 Firefox には残しておいた方が Firefox でないと正しく表示されないページがあります、って優位性のアピールに使えるのにねえ。 自分たちで必要な機能を削っておいて、 Firefox のシェアが減って困ってます、っていわれてもな。 自業自得やん。こっちはもっと困ってるんだよ。
charset=UTF-8 が一律で付与されているパターン。
HTML にはそれと矛盾している charset が明記されているケースもあるし、
されていないケースもある。当時は HTTP charset なしでも
meta ないし自動判定でうまくいっていたか、
万一誤判定されても容易に文字コード変更メニューで修復できた。
今はどうにもならない。
著者は古い頁を頻繁に見に来ているわけではないから気づいていないのだろうし、
場合によっては著者が死亡していてサーバー上の頁だけが残存していることだってある。
しかし Webブラウザー事業者には人の心がないのでそんなものは
Web 上の割合のごくわずかだからと切り捨ててしまうのである。charset=UTF-8 は無指定とみなしてほしい。
勝手に機械的にデフォルトで設定するなら意味がないのだから。それが嫌なら文字コード変更メニューくらい実装しろよ糞ブラウザー[48] Hong Kong IBM, , https://web.archive.org/web/19991110081712/http://www.hk.ibm.com/
[49] >>48 Big5。 Firefox は windows-874, Chrome は gbk と誤認。
[50] Sun Microsystems GmbH, , https://web.archive.org/web/19961227010530fw_/http://www.sun.de/tops/top.html
[51] >>50 UTF-8。 Firefox は windows-1252, Chrome は Shift_JIS (閲覧者のロケール既定値?) と誤認。
[12] 参照処理モデル確立以前の Webブラウザーはシステムの文字コードで表示するのが基本で、 優れた実装はそれ以外にも沢山の文字コードを変換して表示できるという世界でした。
[13] それすら不完全で、例えば日本語の Windows 版 Netscape Navigator の文字コード指定メニューには世界各地のいろいろな文字コードが示されてはいましたが、 ISO 8859-1 を選んでもシフトJISでビット組合せが同じ半角カナが表示されるという有様でした。
[52] 234628 - Disable View>Character Coding menu when it won't have effect / is unnecessary (e.g. XML), https://bugzilla.mozilla.org/show_bug.cgi?id=234628
[897] 943252 – Move nsCharsetMenu and charsetTitles.properties to comm-central ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=943252
[38] Character Encoding Menu in 2014, Henri Sivonen, , https://hsivonen.fi/encoding-menu/
[37] Text Encoding Menu in 2021, Henri Sivonen, , https://hsivonen.fi/encoding-menu-2021/
[39] The Text Encoding Submenu Is Gone, Henri Sivonen, , https://hsivonen.fi/no-encoding-menu/
[40] >>39 完全になくなったと思いきやかわりの機能が追加されてた。しかし隠されてて気づくはずがない。
If we removed the feature, we’d remove a reason for these users to stay with Firefox. Safari and Gnome Web still have more elaborate encoding override UI built in (the list of encodings in both is questionably curated but the lists satisfy the Japanese use cases), and there are extensions for Chrome.
これわかってるのに敢えて削除するんだからもう Firefox は顧客の需要を勘案する気がないってことだよね。そりゃあシェアが減る一方だよ。
[42] 計測したらあんまり使われていないし上手く使われていませんでした、って当たり前じゃんね。新しいサイトは問題ないんだから。 たまにしか遭遇しないんだから。 日常から使い慣れてるとしたらこの30年は何だったんだって話だよ。
[43] 【Google Chrome】文字化けで困った時は、テキストエンコーディングを使おう|かげさんの111から始まるHistory, https://kage3.cocolog-nifty.com/blog/2019/12/post-fb8610.html
[15] >>40 その代わりの「修復」機能、それが効くのは運が良いごく一部の場合だけで、
使えないことの方が多いです。ないよりましだけど、あるからといって元の問題の解決に全然なっていない、
対処しましたアピールにしかなっていない無駄開発。最初からメニューをなくさなければこんな問題にはならなかったのに。
[54] Firefox は「修復」した結果も再読込で忘れてしまうのでいちいち「修復」させないといけない (そして「修復」による再読込がいちいち発生する) という、 とことん使いづらい実装方法なんだよねえ。
[55] Web標準の世界では「利用者 > 著者 > ブラウザー事業者」という優先順位が決まっているのに、 Firefox (や Chrome) はこの分野ではブラウザー事業者の都合だけで物事が進められてるからこんなことになるのよねえ。