なんかデタラメばかり書かれているので、げんなりです。three-eye さんが、文字エンコーディングや PHP などをどれだけ勉強されているのか知りませんが、正直なところ、かなり間違った知識をお持ちなのではないでしょうか。まず「UTF-8N」という不正確な用語を使うのをやめましょう。(一部の Windows テキストエディターだけが使っている「方言」です)
phpデーモンがUTF-8 BOM でもUTF-8Nでもエラーにならず実行出来るように要望する
まず、 BOM 自体はエラーになっているのではなく、「そのまま画面出力される」という動作になっています。ところが、そのあとで header() 命令などが実行されると「すでに画面出力が行なわれている」というエラーが出てしまうのです。
で、これは WordPress の開発チームではどうしようもなく、PHP の開発チームに要望しなければなりません。しかし、PHP は「HTML/XHTML ファイルに PHP の命令を埋め込む」というスタイルの言語である以上、BOM を無視させるのは、なかなか難しいものがあるでしょう。(BOM は <?php ... ?> の外側にあるものだから)
そして、もしそういう機能が装備されたとしても、PHP 5.3 ないし PHP 6 からしか取り込まれないため、あまり意味がありません。PHP4 → PHP5 への切り替えもなかなか進んでいない現状で、PHP のアップグレードを伴うような対応方法を提案するのは、かなり無理があります。
というか、PHP が、コードを <?php ... ?> で囲む必要があるという仕様であること自体がダメなんですよね 😉 php タグなしに PHP のコードであると解釈されるべきだと思います。
Windowsテキストeditorではなくホームページ編集Softを使う
まともなテキストエディターであれば、UTF-8 の BOM なしで保存できます。Windows の「メモ帳」が変なだけですよ。これを書くならば、いっそのこと「Windows を使わない」と言う方がよいです 😉
FTP転送プログラムがUTF-8N変換を備える
すでに対応している FTP/SFTP ツールがあるかもしれませんが、その場合でも、テキスト転送モードを使うことになるでしょう。当然ながら、バイナリー転送モードだと BOM の変換はできません (してはいけない)。
しかし、テキスト転送モードは、いろいろとトラブルの元なので、あまり使わないことが推奨されています。となると、せっかくの BOM 変換機能も使えないことになります。
結局のところ、FTP/SFTP ツールで解決するのは困難です。
RFC にASCII TextがCR,CR+LF規定を提案する[これは現状を規定するのだからすぐ承認]
では RFC を書いて提案してください (言いだしっぺの法則)。ASCII を変更するような RFC を作るとなると、相当困難が予想されると思います。個人的には、「やめとけ」と言っておきます 😉
ちなみに、ASCII には CR も LF も規定されていますが、「改行コードとしてどの文字を使うか」はシステムに依存していて、ASCII コードとはあまり関係ありません。
マルチバイトTEXTはUTF-8N変換を要望する－－＞そうすればFTPがバイナリ、ASCIIの他にマルチtextが増えるだろう
FTPで変換するならローカルではUTF-8 BOM でもいいし、PHPはUTF-8Nだから正常、FTP開発者には苦労してもらうのが最小限の修正で済むのでは
なんで Microsoft の変な実装を FTP ソフト開発者が尻ぬぐいしなければならないんでしょう?? 諸悪の根源は「メモ帳」が UTF-8 の BOM つきを強制していることです。なので、「メモ帳」を使わないこと、ないし「メモ帳」の実装を直すことが、正しく、かつ、素直な解決方法です。
Microsoft が「メモ帳」を修正して、デフォルトで UTF-8 の BOM なしで保存するようにするのがスマートな解決方法でしょう。Windows Update, Microsoft Update で配布すれば、強制的にアップデートできるわけで、スムーズに解決できますよね。もちろん、ある程度の混乱が予想されますが、事前にアナウンスして、慎重に準備すればなんとかなるでしょう。
