はじめまして。宜しくお願い致します。
当方以前はSerene Bach 2.19R（EUC-JP）を使用しておりましたが、WordPress 2.5への移行を検討中(テスト中)であります。
さて表題の件ですが、Serene Bachの記事をインポートすると全て文字化けしてしまいます。単純にエクスポートしたデータEUC-JPからUTF-8に変換すれば良いと思うのですが、ググってもそのやり方にたどり着けません。
お手数ですが、文字コードの変換方法をご教授頂けないでしょうか。
はじめまして。宜しくお願い致します。
当方以前はSerene Bach 2.19R（EUC-JP）を使用しておりましたが、WordPress 2.5への移行を検討中(テスト中)であります。
さて表題の件ですが、Serene Bachの記事をインポートすると全て文字化けしてしまいます。単純にエクスポートしたデータEUC-JPからUTF-8に変換すれば良いと思うのですが、ググってもそのやり方にたどり着けません。
お手数ですが、文字コードの変換方法をご教授頂けないでしょうか。
Serene Bach からエクスポートしたデータをテキストエディタで開き、
文字コードをUTF-8 にして保存すればOK です。
SBのデータが巨大なようであれば、サクラエディタをオススメします。
（と当初書いていましたが、安全性が担保できませんのでエディタの選別は自己責任でどうぞ）
名前をつけて保存→文字コードセット：UTF-8 という手順になります。
残念ながら、サクラエディタは、Shift_JIS なのに ISO-2022-JP と誤認した前科 (WPJ フォーラムのキャッシュ) があるので、今回は「紹介するべきではない」代物です。
単に「巨大なテキストを開けるエディター」として出すならいいんですが、今回は文字コード変換に使うため、「文字コードを誤認するエディター」を選ぶのは、よろしくありません。サクラエディタは内部文字コードが SJIS らしく、UTF-8 を扱うにはよいエディターとは言えません (「波ダッシュ」が化けたりするらしい)。
そういう面ではマトモなのは EmEditor ぐらいしかなさそうです (TeraPad, K2Editor など、Windows のエディタの多くは内部コードが Shift_JIS)。
あと、質問者が Windows を使っているかどうか不明なので、「Windows ならば○○○」という限定を入れてほしかったです。Mac ユーザーだとすると「サクラエディタがおすすめ」と言われても困りますので。(Linux ユーザーは文字コード変換で悩むことはないでしょうが)
yurikoさん、フォローありがとうございます。
Windowsの件については記載が足りなかったですね、すみません。
サクラエディタの誤認識の件については、
ひとつのファイル内に複数の文字コードが混在しているものを扱って、
認識がうまくいかないというものを誤認識と呼ぶのには疑問がありますね。
ポリシーの問題だとは思いますが。
EmEditorはフリー版だと巨大なファイルを開けなかった記憶があるので、
これも場合によっては×ですね。
お金がかかってもOKであれば、Pro版か秀丸でいいと思うのですが。
残念ながら Windows は常用環境じゃないので、EmEditor フリー版で開けるファイルサイズは分かりません。大事なウェブログアーカイブなので、シェアウェアフィーを払ってでも処理した方がいいとは思います。
で、「誤認識かどうか」という議論を抜きにしても、より「安全」なエディタを紹介する、という面において、サクラエディタは対象外である、というのは合意していただけますでしょうか。
なお、Ktai Style の以前の softbank.php は ISO-2022-JP に似たコード (ESC $ G など) があっただけで、ISO-2022-JP ではありません (複数のコードが混在したわけではない)。文字コード判別コードを正しく作ってあれば ISO-2022-JP と判別することはあり得ないのです (ISO-2022-JP の指示シーケンスは ESC $ @ とか ESC $ B とかなので)。したがって、サクラエディタが ISO-2022-JP と判定したことは、文字コード判定ルーチンがいい加減であることの証拠となります。
そうなると、EUC-JP の判定ルーチンも不安になるわけで、Shift_JIS と判定されたりしたら、目も当てられません。しかも、ISO-2022-JP の検出よりも EUC-JP の検出の方が難しいですし。
僕自身は常用していて、特段文字コードの判別に失敗したことがなく
判断がつきません…というわけで、サクラエディタの過去ログをgoogle cache経由で
見て見ましたが、文字コードを誤認識する、という申告があったようです。
（ログの内容までは確認できませんでした）
というわけで、オススメ部分は訂正しておきます。
（よくよく調べてみるとEm Editorでも秀丸でも文字コード誤認識の申告は
あるようでしたので、オススメそのものがよくないかもしれませんね。
当たり前ですが、自己責任でお願いします、ということで）
#むぅ、delとstrikeつかえないのかー
まあ、通常の利用では、どんなソフトでも文字コード自動判定に失敗することは少ないでしょう。Ktai Style の softbank.php は特殊なケースですから。ただ、質問者の sb アーカイブがその「特殊なケース」に合致してしまう可能性がないかと心配でした。
でも、EmEditor でも判別ミスがあったとなると、もはや自動判別を使うのは危険ということになりますね。EUC-JP → UTF-8 の変換は、どんなエディターを使うとしても「文字コードを EUC-JP と指定して開く (自動判別は使わない)」「文字コードを UTF-8 (BOM なし) として別名で保存する」という手順がよいでしょうか。これならば、サクラエディタでも問題なさそうです。
# del 使えないのは不便ですね。フォーラム管理者へ要望や〜〜。
返信有難うございました。
＞Serene Bach からエクスポートしたデータをテキストエディタで開き、
文字コードをUTF-8 にして保存すればOK です。
もっと高度な裏技で文字コードの変換を行なうものだとばかり思っていました。
お恥ずかしいです。。
無事解決いたしましたのでご報告いたします。
このトピックは閉じられたので返信できません。
