文字が疑問符や見慣れない記号になるのは、エンコーディングがずれているからです。文字化けの仕組み、ユニコードが解決したこと、文字数とバイト数、原因を調べる手順をまとめました。
計算機は文字を絵としてではなく数として保存します。どの数がどの文字かを定めた表が必要で、この表を決めた取り決めが文字符号化です。初期には英語圏で作られた小さな表しかなく、各国が自国の文字を入れた表を別々に作ったことで、表がいくつにも分かれました。最も古い表の一つであるアスキーは7ビットで128文字だけを定め、英字の大文字と小文字、数字、基本的な記号、制御文字がすべてでした。日本語の環境ではシフトJISが、韓国語の環境ではEUC-KRとそれを広げたCP949が長く使われてきました。
ファイルを保存したときの表と開いたときの表が違えば、同じ数を別の文字として読むことになります。そのため文字が見慣れない記号や疑問符に見えます。中身が壊れたのではなく解釈を誤っただけなので、正しい符号化で開き直せばたいてい元どおりに見えます。逆に、化けた状態のまま保存し直すと、誤って読まれた文字がそのまま固まって戻しにくくなるので、化けたファイルは直す前に元のファイルを複製しておくのが安全です。
ユニコードは世界の文字それぞれに固有の番号を与えた一つの表です。表が一つなら、国ごとに違う表を使う問題はなくなります。その番号を実際のファイルに何バイトで書くかはまた別の問題で、それを定めた方式のうち最も広く使われているのがUTF-8です。日本語の漢字や仮名も、ハングルの完成形音節11,172字もすべてユニコードに収められているので、地域ごとの表では書けなかった文字も表せます。
UTF-8では文字ごとに占めるバイトが違うので、文字数とバイト数は一致しません。日本語10文字はおよそ30バイトになります。文字数の制限がある入力欄で、英数字より早く上限に達する場合、その制限がバイト基準である可能性が高いです。どちらの基準か分からないなら、短く書くほうが安全です。同じ日本語の文字でもシフトJISでは2バイト、UTF-8ではふつう3バイトなので、どの符号化を使うかで同じ文章のファイルの大きさが変わります。
ウェブの住所には、本来は英数字と一部の記号しか使えません。そのため、それ以外の文字や空白はパーセント記号と2桁の16進数に置き換えて書かれます。住所を複製したら見慣れない文字列が付いてくるのがこれで、壊れたのではなく規則どおりに変換された状態です。たとえば「あ」はUTF-8でE3 81 82の3バイトで、アドレスでは%E3%81%82と書かれます。空白は%20に変わります。
文字が化けたとき、やみくもに設定をあれこれ変えるより、次の順に確かめるほうが原因を早く見つけられます。ほとんどの場合、保存した側と開く側の符号化を合わせるだけで解決します。
ファイル名の「が」が「か」と濁点に分かれて見えることがあります。これは符号化ではなく正規化の違いです。ユニコードでは「が」を1文字で書くことも、「か」と結合用の濁点の2文字で書くこともでき、オペレーティングシステムによってファイル名の保存の仕方が違います。マックで作ったファイルを別のシステムへ移したときによく見られ、見た目は同じでも検索や比較では別の文字列として扱われることがあります。
UTF-8のファイルの先頭にEF BB BFという3バイトが付いていることがあり、これをバイト順マークと呼びます。一部のプログラムはこの印があって初めてUTF-8と認識し、逆に一部のプログラムはこの印を文字として読んで、最初の行の前に妙な記号を表示します。表計算ソフトでUTF-8のファイルの日本語が化けるとき、この印を付けて保存すると直ることがあり、プログラム用の設定ファイルでは逆に外しておくほうが安全です。