コンピュータで，日本語をはじめとした多言語，多種類の文字を扱う時は，英数字で数文字分に相当するデータで１文字を表すことが多い。ただ，その形式が多種多様。「エンコード形式（または文字コード）」などと呼ばれるが，当然，文章作成時と表示のエンコード形式が合っていないと「文字化け」が起こる。とはいえ，ウェブ記事の標準的な記述規格である HTML では，その記事が何のエンコード形式で書かれているのかを内部に記載する規定があり，「文字化け」することはまずない。
　 HTML は他にも画像挿入や複雑なレイアウトなどの様々な機能を持つが，視覚障害者などが「音読ソフト」に読ませて聞く時，それら機能はむしろ邪魔なようで，HTML ではなく，ほぼ「本文の文字のみ」データである「プレーンテキスト形式」で読みたいとの要望が出る。ただこの形式は「文字コード」を明記する規定がないため，文字化けし易い。
　ここでは「プレーンテキスト形式」で記事を読む時（ブラウザ）と，提供する（サーバ）側の双方での「文字化け」対策を考察してみる。

　コンピュータは欧米で発達してきたこともあり，アルファベット程度の文字種に都合のいいデータ単位で扱われる。そのため，日本語を含め英語圏以外の種類の多い文字を扱う時には，英数字で何文字分かに相当するデータを組み合わせて１文字を表すことが多い。その組み合わせ方には様々な形式があり，それらは「エンコード」とか「文字コード」と呼ばれる。当然，記事の作成時に使ったエンコード形式と，表示の形式が違っていると正しく表示しない。それで「文字化け」が起こる。
　ただ，ウェブ記事の記述で標準的に使われる規格である HTML では，エンコード形式が何なのかを記事内に記載する規定があるためか，一般的なウェブ記事で「文字化け」することはあまりない。

　一方，時として HTML ではなく，「プレーンテキストで読みたい」という要望が出る。この形式は，「エンコード」が何であるかなどの記載規定が一切ない，ほぼ「本文の文字だけ」の形式。文字エンコードが何であるか，つまり，日本語がどう表現されているかの情報を記事データ内に含んでいないため，ブラウザが「エンコード形式」を判別できないことがあり，扱いを間違ってしまい，正しく表示されない「文字化け」を起こし易い。正しく読みたいなら，断然 HTML のほうが確実だ。
　ところが，HTML という形式は，文字の他にも画像の挿入やら凝ったレイアウトやら，あるいは閲覧者がクリックすると何か動きがあるなどの様々な機能が付加できるのだが，時としてそれが「余計なこと」になるらしい。企業の宣伝に利用されるようなウェブサイトでは，そうした機能を駆使して，「見た目」を華やかにして，便利な機能が付加されて作られたものが多くなる。一方，視覚障害者などには，「音読ソフト」を使ってウェブ記事を「聞く」人がいる。そうした人は，画像はあまり意味がないし，本文の前や途中に関連記事の一覧や広告が配置されるようなレイアウトだと，そこも「音読ソフト」で読まれる時間がもったいないし，クリックすると詳しい説明が出てくる（逆に言えば，クリックしないと説明を表示しない）ような仕組みがあると，かえって聞きにくくなるというわけだ。

　筆者サイトでは「バリアフリー」の観点もあり，独自開発のシステムで，ここ最近の記事は「プレーンテキスト形式」でも提供できるようにしている。もしこの記事を筆者サイトで読んでいるなら，URL の末尾に“.txt”を付加して読み直すと，プレーンテキスト形式で読めるはず。当サイトの「プレーンテキスト」のエンコードの多くは UTF-8 を使っているが，エンコード情報自体は記事内に記載してはいない。UTF-8 はほぼ国際標準エンコード方式だと思っていたから，最近のブラウザならたいてい読めるだろうと思っていたら，「文字化けして読めなかった」という報告があった。国際標準が標準ではないブラウザもあるらしい。
　とは言っても，「プレーンテキスト形式」では，本文に「エンコード形式」を記載する規定はない。つまり，ブラウザが「エンコード形式」を判断する規定がないから，たとえ本文中に「エンコード形式が何か」を記載し，人が見て分かるようにしておいたとしても，ブラウザがそれを人と同じように解釈して正しく表示してくれることは期待できない。ブラウザへの対策をデータ内でするのはほぼ無理だ。
　しかも，エンコード形式を記載すると，「音読ソフト」はそこも読んでしまうことになるが，たいていは「文字コードが何か」なんて本文の内容と関係ないから，聞く側も分かりづらくなるだろう。あまりそうしたことは本文に記述しないほうがいいような気もするところ。
　だから，本来はブラウザに「エンコード」を指定して表示し直す機能があっていいはずで，実際筆者が使っているブラウザはそれができるのだが，どういうわけか最近のブラウザの中にはその機能が働かないものがあるらしい。
　何？ その「バリアフリー」のご時世に逆行するようなブラウザは？
　というわけで，対応できるブラウザと対応できないブラウザ，また，提供する（サーバ）側での対処方法などを考察してみたい。

◆ Chrome と IE は使わないほうがいいかも

　「本来はブラウザ側でエンコード設定を変更して表示する機能があっていい」と書いたが，実際，筆者が普段使用するブラウザには全てその機能が付加されている。その機能が働くブラウザの設定は次々節参照。
　ところが，前章で「文字化けで読めない，UTF-8 の設定もできない」と知らせてくれた方が使っていたのが，Chrome（クローム）と呼ばれるブラウザ。調べたところ，少なくとも Chrome の最近のバージョンには「エンコードの設定機能」は元からは備わっておらず，設定したい時は「アドイン」と呼ばれる拡張機能を組み入れる必要があるらしい。筆者が所有するパソコンにはインストールしないブラウザなので詳細は分からないが，もしその「アドイン」の組み入れ方が分からなければ，後述する IE 以外の他のブラウザに乗り換えたほうがいいと思われる。
　また IE（インターネットエクスプローラ）と呼ばれる MS（マイクロソフト）社製のブラウザにはその「エンコードの設定機能」があるが，少なくとも筆者が借用した PC で試した一部のバージョンでは，設定を正しく指定しても表示に反映せず文字化けしたままだった。これでは，もしプレーンテキストで文字化けが起きたら，IE で読むのはあきらめざるを得ないことになる。バージョンにも依るのかも知れないが，これも筆者は普段使わないブラウザなので，どのバージョンなら正しく機能する……といった詳しいことまでは分からない。後継の Edge も同じく詳細不明。やはり前述の Chrome を除いた，「エンコード変更機能」が確実に機能する別のブラウザを使ったほうが，無難じゃないかと思う。

◆ ブラウザ以外のソフトで読む方法

　Chrome や IE で文字化けしてしまい，他のブラウザが使えない時のとりあえずの方法としては，一旦保存をしてから，そのファイルを別のソフトで開くと読める場合がある。たとえばメモ帳や，エディタ，ワープロなどなら，たいていは「文字コード」を指定して開く機能がある。MS 社のブラウザで「エンコードの設定がまともに機能せず表示できなかった」と述べたが，同じパソコンの「メモ帳」で開いたら，UTF-8 もちゃんと読めたりした。この会社の開発方針はよく分からん。
　ただこの方法でも，ブラウザの表示がまともではないので，保存した時に元のデータの通りに保存されず，データの制度が落ち，別のソフトで開いた時に，やはり文字化けしてしまう可能性が残る。

　いずれにせよ，「ブラウザでエンコード指定をして読めない」場合，「プレーンテキスト形式」で文字化けしたら，そのままでは読む方法がないということ。そんな「バリアフリー」のご時世にも逆行するようなブラウザなど，お薦めできない。

◆ その他のブラウザでの設定

　筆者が主に使っているブラウザは FireFox（ファイヤーフォックス）と呼ばれるもの。とりあえずは確実に「エンコード変更機能」が働く。
　筆者サイトのテキストデータのエンコードは，ほぼ UTF-8 なので，「表示」メニュー→テキストエンコード→UNICODE あるいは UTF-8 を選択することで正しく表示されるはずだ。

▼ FireFox でのエンコード指定

　なお，メニューが表示されていない時は，[F10] または [Alt] キーを押すと現れるほか，[Alt]+[V] と押すと「表示メニュー」が現れる。

　いずれも，前述した２つを除く他のブラウザでもたいてい同様な設定の方法で対処できると思われるので，試してほしい。

　この章はデータを提供する側……つまり「サーバ側」の技術的な記事のため，ウェブ記事を「読むだけ」の側の人にとって関係性は薄いので必死に読まなくても大丈夫。

　プレーンテキストでもデータを提供するようにしてから，しばらくは「特に問題無し」と思っていたのに，ある方から「文字化けして見れない」と聞き，いつも自分でやっているように「エンコードを UTF-8 に設定してください」と言って対応したら，前述のとおり「Chrome では設定できないんです」と言われて，そんなアホなと……。
　視覚障害のある人は音読ソフトなどでウェブ記事を「聞く」人がいることは知っていたから，画像や広告，関連記事などのリンクを含まない「プレーンテキスト」で読めるようにしておくことは「バリアフリー」の観点で有効な手段だと思っていた。一方で「プレーンテキスト」は，HTML と違って「エンコード形式」の記載規定がないため，たとえ記載しても，ブラウザが認識してくれるとは限らない。だから，「プレーンテキスト」を扱う可能性もあるであろうブラウザであれば，エンコードを指定して表示する機能もあるだろうと思っていたから，そうではないブラウザがあると知り，むしろビックリ。

　世界標準となりつつある UTF-8 で文字化け起こして直せないとか，だからと言って，読む人が使うブラウザの「デフォルトのテキストエンコード」が何かをサーバ側で検知し，それに合わせてデータを送るなんてこともまず無理……となれば，ほぼ打つ手なしか，と思われた。
　とりあえずサーバソフトの Apache について調べてみたら，どうやらデフォルトのエンコード形式を指定するディレクティブがあるよう。

    AddDefaultCharset   On  |  Off  |  <encode>

　これを On に指定すると，レスポンスの content-type ヘッダ情報に charset=…… が付加されるようになるらしい。
　ただ，検索結果の記事の中には「これが原因で文字化けした」ようなものもあった。HTML 記事内での指定と，サーバ設定のデフォルトエンコードが衝突したらしい。そこで，このディレクティブで Off を指定したら文字化けしなくなったとか。当サイトでも，初期のころの HTML 記事は「シフト JIS」のものもあるので，衝突は避けたいところ。
　今回，エンコードの指定をしたいのは「プレーンテキスト」だけだ。そこで，<Files>……</Files> ディレクティブと組み合わせてみた。

    <Files ~ "\.txt$">
    AddDefaultCharset  UTF-8
    </Files>

　上記を .htaccess 内に記述。これでプレーンテキスト形式の拡張子「.txt」を持つファイル送信の時だけ，以下のレスポンスヘッダが送出されるようになった……はず。

    content-type: text/plain; charset=UTF-8

　「はず」というのは……なにぶん，使っているブラウザがことごとく文字化け「しない」ものばかりで，改善されたかどうか確認しづらい。手元の FireFox では，別に上記指定前でも文字化けなく表示していたが，当サイトから読んだテキストファイルは「エンコードの指定がありません」という警告が出ていた。上記指定後，警告は消え，ログを確認すると上記ヘッダも付加されていたから，他も大丈夫な「はず」だと。
　いちおう上記対策後，「Chrome で文字化けして読めない」と報告をくれた方に再度同じテキストデータを読んでもらったところ「読めた」という報告は受けた。また，「エンコード指定をしても文字化けした」IE でも確認したが，やはり文字化けは起きなかった。

　しかし，データは何も変えてないんだわ。だいたい，手元に保存したテキストファイルを読む時は「レスポンスヘッダ」なんか付加されないから，「エンコード指定」もないわけで。それって Chrome ではウェブ上のテキストデータは読めても，一旦保存したファイルを開くと，文字化けして読めなくなったりするということか。スゴい設計だ。使わないから分からんけど……まぁ，そうした「バリアフリー」を無視するような業者が作ったブラウザは，今後も使わないに越したことはないと思っている。