Filezillaとnotepad++を使えば問題ないのでお試しあれ。
takuyaさん
ご回答ありがとうございます
せっかく答えてくださったのに、お礼が遅くなってすみません
別問題が発生しまして、まだ試せていませんので
（お礼が遅い上に申し訳ないのですが・・）まだ未解決のままにさせてください
サーバーも今週末あたりにかわるので、新サーバーになってからもう一度チャレンジしてみます
php/cssファイルに書いた日本語がHTMLで文字化けします
ちょっと理解不足で申し訳ないのですが、この意味はindex.phpなどのファイル名で作成した”テキスト”ファイルの文字がファイルを開きなおした場合などに文字化けを起こすのか、それともそのファイルをIEなどでhtmlファイルとして表示した場合に文字化けを起こすのか、後者の場合サーバにアップロードすると化けるのか、ローカルでも化けるのか、どのような状況なのでしょう。
例えば、style.cssにコメントなどで日本語を記述しterapadでUTF-8保存したファイルをテンプレートフォルダにアップロードし、wordpressの外観→編集で該当ファイルを開いた場合でも日本語が文字化けしていますか？
※ちなみに、一度文字化け状態で開いたファイルをそのまま保存してしまうと文字化けの復旧は難しいかもしれません。（コードが変わったまま保存されてしまうため）
shokun0803さん
こんにちは
ちょっと理解不足で申し訳ないのですが、この意味はindex.phpなどのファイル名で作成した”テキスト”ファイルの文字がファイルを開きなおした場合などに文字化けを起こすのか、
それともそのファイルをIEなどでhtmlファイルとして表示した場合に文字化けを起こすのか、
いえ、すみません、わたしの説明不足です
しくみがよくわかってないので、ただ現状をつらつら書く形になりますが…
わたしのいう「文字化け」は、後者です
（＝テキストファイル内では文字化けなしで、ＩＥなどで見たら文字化け）
なのですが、
同じ以下の手順で、ＵＴＦ－８にコード変換？したら
日本語で書いてたところが、一度だけ、テキスト内で化けました…
それ以来起こりません
（こんな状況把握と説明ですみません・・）
そのファイルはstyle.cssで、アップロードしてその文字化けしたものがどうなったかは確認できませんでした（ＣＳＳって、見れないんですよね？）
で、たいしたコメントでもないしとおもってcssファイル内から消してしまいました。
＜手順＞
１．ＰＨＰやＣＳＳファイルをテキストエディタ（わたしはマイフェス6）で開く
２．Ctrl+Aで、そのファイルに書いてる文字を全選択
３．（保存時の）ポストプロセッサ設定という画面を開く
４．ＵＴＦ８に設定
５．保存
６．アップロード
あと、気になる点なのですが、
なにも触ってないphpファイル（要するにデフォルト状態のままのファイル）をテキストエディタで開くと改行マークが↓なんですが、わたしが触ったところは下を向いて左を向く矢印（伝わりますか？）なんです
で、ＵＴＦ-8に変換してもその矢印は変わりません
その他の書かれている文字の見た目についても変化なしです（＝テキスト内で文字化けしない）
変わるのは唯一 そのテキストファイルの文字コードを表す記載が「UTF-8」になるだけです
後者の場合サーバにアップロードすると化けるのか、ローカルでも化けるのか、どのような状況なのでしょう。
サーバーにアップロードすると化けます
でも、すみません、ローカルでも化けるというのがわかりません
どうしたら、しらべられますか？教えていただけると助かります
TeraPad の場合は UTF-8N で保存してください。
サーバーにアップロードすると化けます
でも、すみません、ローカルでも化けるというのがわかりません
どうしたら、しらべられますか？教えていただけると助かります
大体の状況は分かりました。おそらくファイルをUTF-8で保存することは間違っていないのでしょう。
terapadの方しか使用していないのでこちらでの説明になりますが、terapadの場合でUTF-8のBOMなしで保存しても、日本語の使用されていないphpソースを開くとshift-jisとして開く場合があります。これはデフォルトでshift-jisが設定されていて、かつBOMがなく、コードを自動判断できる日本語などの文字列が使用されていない場合に起こっているようで、オプションの設定では発生しないかもしれません。
また、私の使用しているバージョン（0.91）では編集モードにphpはなく、phpで記述されたソース上のコード設定は自動判断の対象にはならないようです。（htmlのコードかつ拡張子がhtmlなどの場合はMETAタグなどで判断するようですが。）
上記terapadの仕様に関しては頭の隅においておいてもらって、、、
予測の範囲を出ませんが、
日本語で書いてたところが、一度だけ、テキスト内で化けました…
それ以来起こりません
なんらかのタイミングで違うコードとして開いたcssファイルが文字化けを起こし、文字化けのままコード変換を行い保存してしまった。（この場合文字化けはコードを戻しても直らないと思います。）
ソフトによると思いますが、ファイルを開いたときの自動判断でコードを間違って開くことは多々ありえます。BOMありのUTF-8ならばBOMで自動判断を行うので間違うこともないのでしょうが、wordpressなどphpファイルを作成するときにBOMは致命的です。
それ以来起こらないのは偶然が重なったのではないのでしょうか。
そのファイルはstyle.cssで、アップロードしてその文字化けしたものがどうなったかは確認できませんでした（ＣＳＳって、見れないんですよね？）
wordpressのテンプレートとしてフォルダにまとめてアップロードされているならcssファイルも見れます。外観の編集でご自身の作成されたテンプレートを選択し、コードが表示されたら右側にスタイルシートが選べるはずですので試してみてください。
また、改行についてですが、マイフェスを使用していないのでこれまた予測ですが、改行コードの違いではないでしょうか。UNIX系で作成されたファイルはLFで保存されているかもしれません。windowsで改行するとCR+LFになるので改行マークも変わるのでしょう。（混在できるのかどうかは分かりません。保存して開きなおすとどちらかに統一されていませんかね？）文字コードが変わっても改行コードは変わりません。
ローカルでのテストについてですが、一番簡単な方法はhtmlファイルを作成しIEなどで開くことです。METAタグなどで指定した文字コードと実際に保存されている文字コードが違えば文字化けします。phpで試すにはローカルサーバを準備しなければならないので、試すだけならhtmlファイルでも試せるはずです。
えーっと、つまり、アップロードされたテンプレートファイルに記述された日本語が、現状wordpress上で文字化けを起こしたりしていなければUTF-8でのファイル保存には成功しているのであり、悩むこともないのではないかと・・・。
もし現状でも文字化けを起こしているのであれば、UTF-8に変換したあとのファイルに日本語を打ち込み、保存しなおしたものを再度アップロードして試してみましょう、ということです。UTF-8に変換後のファイルでテキストエディタ上で文字化けを起こしていないならアップロードしても文字化けはしない”はず”なので、それでも文字化けを起こしているならエディタの問題ではないかもしれません。
shokun0803さん mizubeさん
おはようございます
今、UTF-8「N」で保存してアップしたら文字化けしてません！！
よかったです！ありがとうございます！！
しかし結局なんだったのか・・
shokun0803さん
すみません、回答抜けしていました
大変いまさらながらなんですが…
例えば、style.cssにコメントなどで日本語を記述しterapadでUTF-8保存したファイルをテンプレートフォルダにアップロードし、wordpressの外観→編集で該当ファイルを開いた場合でも日本語が文字化けしていますか？
これは、文字化けしてませんでした
ここで文字化けしてるのとしてないので、どう違いがあったのでしょうか？？
不思議です
mizubeさん
先に述べたとおり、８Nで保存したら解決しました
ありがとうございました
これは、文字化けしてませんでした
ここで文字化けしてるのとしてないので、どう違いがあったのでしょうか？？
不思議です
つまりBOMがついていたために文字化けが発生していたということですね。
wordpress上の編集画面はphpでhtmlを書き出して作成しているためページのソースコードはUTF-8になります。もちろんそのページを表示しているブラウザもUTF-8として表示するため、textareaに読み込まれたファイルがUTF-8でなければ文字化けします。
つまりUTF-8でファイル作成、及びアップロードが失敗していなければ画面上で文字化けするはずもないというわけで。
で、UTF-8Nですが、terapadでのBOMなしの設定です。BOMはファイルの先頭にUTF-8であるという”しるし”をつけてしまうわけで、phpではエラーの原因にもなり、文字化けの原因にもなるわけですね。（識者のみなさまこんな説明で大丈夫ですかね、、、）
shokun0803さん
おはようございます
説明してくださってありがとうございます！
解決済みにしてるのですが、もしよかったら教えてくださいませんか
文字化けしなくて解決しましたが、次はなにに気をつければいいの・・と心配なので・・
理解してみれば（ぼんやりですが・・）、
・わたしがいつも使ってるmifesは、wordpressのためにファイルをコード変換するには不向き（本来はできるのかもしれませんが使い方がわかりませんので放置します）
・編集はmifesでしてもいいが、最後のコード変換はterapadでしないとだめ
ということに行き着いたのですが、あってますでしょうか？
わたしが理解したことは、
１．UTF-8には UTF-8とUTF-8Nがあるということ
２．UTF-8にはBOMがあって、UTF-8NにはBOMがない
３．BOMとは、UTF-8の頭につく”しるし”
４．terapadだとコード変更の際、BOMなしかありかを選択できる
５．おそらくマイフェスだとできない？（UTF-8しかないから）
６．わたしは、とりあえず「UTF-8」で保存＆アップ成功していたということ
７．それでもIEなどで文字化けてたのは、UTF－8にBOMがついていたということ（マイフェス＆テラパッドのUTF-8で設定してたから）
８．ダッシュボードで文字化けてなかったのは、ダッシュボードがBOMがついていても読んでくれる設定だから？
このような感じですか？
５はともかく（できないってことないんでしょうが、よくわかりません・・）、８は合ってますか？
wordpressから随分ずれてしまってすみません
#mifesでしらべてたら 7.0の広告にutf-8nの識別ができます！と書いてました
わたしが使っている6.0（2002年発売）で、こちらは広告がないのでなんともいえませんが、
7.0でそんなことを謳ってるなら、たぶんできないっぽいですね（わかりませんけども）
えっと、間違った情報を与えてしまうといけませんので、エディタに関する情報は以下を参考にするといいでしょう。
WordPress Codex 日本語版 用語集 テキストエディタ
mifesについてはCodexでも表記がないので分かりかねますが、おおむね理解はあっていると思います。
ちなみに、「wordpressでテンプレートを作成（自作？）していてぶち当たった壁」ということでよいのでしょうか？だとすれば「８．ダッシュボードで文字化けてなかったのは、ダッシュボードがBOMがついていても読んでくれる設定だから？」に関しては「ダッシュボードはテンプレートを読み込んでいないので直接関係しない」になるかと思います。
テンプレートを読み込んで表示している（文字化けに関係する）のは記事を表示したときですね。もし「wordpressの投稿で記事を投稿したら文字化けした」という現象が発生したらそれはテンプレートの問題ではなく、インストールの問題になります。今のところこの問題は発生していないのですよね？
自作のテンプレートを作り始めるとはまります^^; だって楽しいもの・・・
shokun0803さん
こんにちは、ご教示くださったCodeX読みました
なるほどです（ここに書いてあったのですねスミマセン・・）
mifesはずっと会社で使っていて、「有料ソフトだしもちろんできるんだろう？」と勝手に思い込んでたので今回すっかりだまされました。（自分が悪いんですが）
ちなみに、「wordpressでテンプレートを作成（自作？）していてぶち当たった壁」ですが、
テンプレート（の定義がいまだよくわからないんですが・・申し訳ないです）というより、わたしは「テーマ」をカスタマイズしていると思っていました。（ここで質問させてもらってばっかりですが、これもとても楽しいです、CSSよりうんと楽しいです）
header.phpやpage.phpなどで、wordpressのタグ？を使って分岐して「このばあいは、こうしろああしろ」と追加しています
そしてそこにコメントを<!– watch out! ここはこういう理由でこうしてます –>みたいに書いていて
アップロードして、サイトのソース表示をすると <!– watch out! ????????? –>
みたいになっていたのです
wordpressの投稿で記事を投稿したら化けた（ダッシュボードから投稿した記事が化けた？）は、大丈夫です。正常に表示されています。
別問題なのですね。実は、これも混乱していました。
ところで、解決してるのにとても長くなってしまいましたが
お付き合いいただいてありがとうございました！
すっきりしました！感謝いたします！ ==(:X)
１．UTF-8には UTF-8とUTF-8Nがあるということ
２．UTF-8にはBOMがあって、UTF-8NにはBOMがない
少なくとも、これは正しくありません。「UTF-8N」というのは、日本の Windows 向けテキストエディター *だけ* が使用している造語であり、正しい用語ではないです。Unicode 系エンコーディングである UTF-16 などには、バイト列の並びを判断するための BOM がありますが、UTF-8 では BOM はオプションです。原則として「UTF-8 には BOM がない」のが基本です。
他の OS 向けテキストエディターや、海外製のテキストエディターでは、文字コードとしての選択肢は「UTF-8」となっていて、その他に「BOM をつけるかどうか」のチェックボックスがあるのが普通です。
しかし、Windows NT 以降の「メモ帳」は UTF-8 に対応しているものの、なぜか BOM を強制的に付けてしまいます。その影響か、サードパーティーのテキストエディターでは BOM なしの UTF-8 を使えるようにしていますが、なぜか、日本製のテキストエディターは「UTF-8N」なる文字コード名称を勝手に作ってしまいました。
もし何か名称を付けるならば、BOM ありの UTF-8 に対して「UTF-8B」とかを付けるのが自然だったはずです。「UTF-8N」という名前を考えた人は文字コードについて間違った理解をしていたと思われます。
まあ、諸悪の根源は、BOM あり UTF-8 を強制する「メモ帳」であり、それを製作した Microsoft ですね 😉
lilyfanさん
こんにちは
原則として「UTF-8 には BOM がない」のが基本
「UTF-8N」というのは、日本の Windows 向けテキストエディター *だけ* が使用している造語であり、正しい用語ではない
他の OS 向けテキストエディターや、海外製のテキストエディターでは、文字コードとしての選択肢は「UTF-8」となっていて、その他に「BOM をつけるかどうか」のチェックボックスがあるのが普通
ご説明ありがとうございます
随分わかってきました（つもりかもしれませんが・・）
今気づいたんですけど、ＮってnoneとかnoとかのＮなのですね
もともとNoneなのに、なんでＢＯＭありのほうにＢをつけずにオリジナルのなしのほうにＮをつけるのよということですね
というかもうそうとう既出ですよね
みなさんすみません・・
暖かいご回答ありがとうございます
goodtimesさん、みなさん、こんにちは。
#mifesでしらべてたら 7.0の広告にutf-8nの識別ができます！と書いてました
わたしが使っている6.0（2002年発売）で、こちらは広告がないのでなんともいえませんが、
7.0でそんなことを謳ってるなら、たぶんできないっぽいですね（わかりませんけども）
これは、ファイルを開くときの自動判定の話かもしれませんね。（上の方で shokun0803さんが説明してくださっているもの）
お使いになっている MIFES は
http://www.megasoft.co.jp/mifes/
で合ってますか？マイナーバージョンは何でしょう。
サイト内検索をしてみたところ、ver.6.05 のところに
http://www.megasoft.co.jp/update/mifes/miw6modify.html
外部プリポストプロセッサ「MIWUTF8.PPP」を変更して、保存時にファイルの先頭にＢＯＭ（0EFH,0BBH,0BFH）を書き込まないようにしました。ＢＯＭとはByte Order Markの略で、Unicodeファイルの判定に使われているマークのことです。
という記述がありました。
外部プリポストプロセッサというのの役割が分かっていませんが、6.05 以降なら UTF-8 BOM なしで保存されるのかもしれません。
（BOM有無は選べないみたいなので）BOM ありで保存したいケースがないとか、このページにあるその他の更新が入っても差し支えないのであれば、アップデートしてみるのも手かと思います。
# 私は MIFES ユーザではないので、公式サイトや設定・ヘルプをご自身でよく確認するか、サポートに問い合わせるのがよいかと思います。 🙂
なお、6.0系はファイルを開くときに一旦 Shift_JIS に変換するっぽいので、
たぶん PHP や CSS ファイルの編集は大丈夫ですが、今後、投稿やコメント等のコンテンツデータを扱うことがあればご注意ください。
http://www.megasoft.co.jp/mifes8/product/hikaku_miw6.html
http://ja.wikipedia.org/wiki/Mifes
ちなみに、
テンプレート（の定義がいまだよくわからないんですが・・申し訳ないです）というより、わたしは「テーマ」をカスタマイズしていると思っていました。
については、
WordPress Codex 日本語版 » テーマの作成 – テーマの構造 が分かりやすいかもです。 🙂
