unflagged/エンコーデッドな変数。flagged/デコーデッドと見なされる。この1と2の扱いの違いが混乱の原因のひとつ。記述を追加すると今まで動いていたコードも動作がヘンになる。■■print文のUTF8文字列の扱いは少々複雑である。1print文の引数が単独文字列であれば、フラグありなしに関わらず正しく表示する。unflagged/エンコーデッドな文字列が文字化けする。3print文の文字列に英文字の埋め込み文字定数を含む場合、フラグの有無に関わらず文字化けは生じない。4print文の文字列に日本語などUTF8の埋め込み文字定数を含む場合、フラグなしのunflagged/エンコーデッドな文字列が文字化けする。1から4までの現象から、次のことが導き出せる。指定でコードを書く際、フラグありのflagged/デコーデッドな文字列(変数)では文字化けしない。unflagged/エンコーデッドな文字列である。関数でフラグありのflagged変数に変換する。なければ文字化けの原因となる。UTF8文字列の処理前提で書かれているコードであるが故、大量の文字化けが生じる可能性が高い。上述の文字化けが生じる際の文字コードの条件は、本ページの終部に付加したサンプルコードを実際に試していただければ検証可能。上述の1から4の現象から、任意の文字列変数に格納されている文字コードのUTF8のフラグの有無は「あ」のような全角文字1文字を混在させることで簡単に判別できる。UTF8フラグの有無と無関係で正常表示される。文字列であれば、必ず文字化けする。外部ファイルのデータは全て、フラグなしのunflagged/エンコーデッドデータでなけばならない。ないと、テキストファイルでは文字化けだらけのデータであったり、データベースであれば外部からアクセス不能なキーを有するDBとしたりして、問題をさらに厄介にする。指定のないプレーンなコードでは全てがフラグなしのコードとして扱われるからこの外部ファイルデータ的な問題は一切生じない。指定しないことが推奨されるべきである。コードのフラグ有り内部処理用途のUTF8文字列はテキストファイル化すると文字化けるから、必ずencode_utf8変換してから出力すること。逆に、外部ファイルから読み込まれるUTF8文字データはフラグ無しなので、早期にdecode_utf8関数でフラグ付けをすること。(フラグ無しUTF8文字列もフラグ有りUTF8の文字列と混在させなければ正常表示する。これによって問題がさらに厄介に見えることがある。けするUTF8文字列はフラグ無しのundecoded/encodedなUTF文字列だけ!なのである。文字化けは外部ファイルやURLなどで受け取った文字列に含まれるデータなど、外部由来のUTF8文字列だけなのである。内部処理的には、文字化けしない、decode_utf8でデコードされたフラグ有りのUTF8で統一しなければならない。UTF8のままでよい。以下のように、URL埋め込みのUTF8(全角)文字列はエンコード不要である。いうか、ブラウザ画面上で文字化けしなければ正常。出力全てがフラグなしであればそれはそれで正常なリンクURLを構成する。使用する場合、文字列変数は全てフラグありUTF8とすること。decode_utf8を用いてUTF8の内部フラグ付けを徹底して行うこと。使用する場合、外部ファイル、DBへ出力する場合は、encode_utf8でフラグ外しを行うこと。使用する場合、文字列を画面表示する場合は、フラグ付けされた文字列のみを用いること。使用する場合、文字列変数のフラグの有無が分からなくなったら、全角文字1文字を付加して表示させてみる。文字化けすれば、その文字列変数はフラグ無し。Ascii記号で区切り解除する場合が多いので、フラグのありなしとは無縁のまま正常動作することが普通。使わないと面倒だろう。ファイル毎にそれぞれ別途、指定しなければならない。この点を失念していると埋め込み文字列のフラグの様態がファイル毎に異なることで文字化けする。