テキストエディタ: 問題なく使えるもの、使ってはいけないもの
-
lilyfanさんの書き込みを拝見してトピックを立ててみました。
みなさまからテキストエディタについての情報をいただけないでしょうか。# 「Windows のメモ帳は使用禁止」というのを、インストール説明のどこかに載せませんか?? ダブルクリックすると「メモ帳」で開いてしまうので、それはダメというのを書かないといけません。> ドキュメンテーション関係者さま
Codex には「テキストエディタ」が登場するページが結構あり、また、「用語集」にエディタの説明と英語版エディタの一覧が載っているので、日本語でも問題なく使えるエディタの一覧に改訂したいと考えておりました。
現在、インストール説明やドキュメント上でテキストエディタについて触れている箇所は次のとおりです。
- WordPress | 日本語 » インストール — 「WordPad などのテキストエディタで wp-config-sample.php を開き、~」
- Codex では、ほとんどのページは 用語集 にリンクを張っていますが、一部、具体的に書き添えられている箇所があります。↓
- インストールの前に — 「Windows ユーザであれば Notepad が使えます。」
- wp-config.php の編集 — 「Microsoft Word のようなワープロソフトは、WordPress ファイルの編集には 絶対に 使わないでください!」
Windows のメモ帳=Notepad ですよね。。orz
作業環境が日本語だと問題が出てしまうのでしょうか。。ここは直さないといけませんね。Codex はページ数が多い(これからも増える)ので用語集に集約するか、トラブルが多ければ、ダブルクリックで開けてしまう NotePad について注意書きを添える必要があるのかなと思います。
-
(A)について
最初に(A)用エディタの要件をはっきりさせればよかったのですが、
– 文字コードを指定でき、UTF-8 BOM なし(UTF-8N)で保存できること
– 改行コード指定 (FTP クライアントで指定できれば不要)今の日本語版 WP は wp-config.php に日本語が入っているため、一つめの条件も必須、ということでいいのでしょうか。。?
>ぼののさん(笑)
今の日本語版 WP は wp-config.php に日本語が入っているため、一つめの条件も必須、ということでいいのでしょうか。。?
そうですね。wp-config.phpをwindowsのメモ帳(notepad)で開いて、編集して保存すると、bomをつけてしまうので、エラーはいちゃいます。
ですので、一つ目の条件も必須ですね。日本語が入っていなければshift-jisの認識でも問題ないのですが。。。
# あれ、フォーラムの返信欄にquicktagってついてましたっけ?
>kentanjpさん、lilyfanさん、hiromasaさん
教えていただいたエディタを一覧に載せました。ありがとうございます。
リンクになっていないものは、開発・配布元の URI をご存知でしたら教えてください。Jedit (Mac OS X)
http://www.artman21.com/jp/これはシェアウェアですね。
#MACはここ2年くらい触ってないので詳細忘れました OTLWIki 見てみました。「エクスポートデータを編集する場合」の項目では、再度エディター一覧を掲載した方がいいですね。ここで、TeraPadl, UnEditor, NoEditor, サクラエディタ, PeggyPad が落ちます。(あ、PeggyPad はもともと入ってなかったか)。
細かい話ですが、UniEditor と NoEditor はまとめてしまって「UniEditor, NoEditor」と1行にした方がいいかもしれません。
エディター開発元のリンクはそれぞれ以下の通りです。
TextEdit: http://www.apple.com/jp/macosx/ (あえてリンクするとすれば)
SubEthaEdit: http://www.codingmonkeys.de/subethaedit/ (途中のバージョンからシェアウェアです。以前は無償バージョンのリンクがありましたが、もうなくなったのかな?)
Smultron: http://smultron.sourceforge.net/あと、非対応エディターの注意書きが厳密には正しくありません。「波ダッシュ」自体は Shift_JIS に存在します (0x8160)。Windows における Unicode の U+301C から Shift_JIS への変換が正しくなくて「未定義文字」になってしまうのが問題なのです。ですので、例示文字と挙げるには不適切になってしまっています。
非対応エディタでは、Unicode のみ存在して Shift_JIS に存在しない文字 (ハートマーク・温泉マーク等) が「?」になったり、波ダッシュ 〜 が正しく変換されず文字化けすることがあります。
あたりが適切でしょうか。Shift_JIS にはハートマークがないですが (拡張された規格にはあったかも)、CP932 には存在するならば、例示は温泉マークだけのがいいかもしれません。
波ダッシュは実体参照を使った方が安全でしょう。pswiki の該当場所は正しく U+301C の波ダッシュになっているようですけど、今後の編集で全角チルダに化けてしまうと、もったいないですから 😉SubEthaEdit の注意ですが、OS X 標準のテキストエディットや Smultron でもおそらく発生します (Mac OS X 自体の仕様です)。ただし、Jedit は円マークをバックスラッシュに強制変換する設定があるので、これをオンにすれば安全です。
しかし、Jedit は、UTF-8 の BOM あり/なしを環境設定で選ぶのでオフにしておくことと、全角チルダを波ダッシュに強制補正する機能があるので、オフにしておいた方が無難なことがあげられるでしょう。Windows では、波ダッシュが問題点の横綱で、Macintosh では、円マークがトラブルの筆頭だと思います。
(A)の用途向けとしては、「GreenPad」も良いかもしれません。
http://www.kmonos.net/lib/gp.ja.htmlあー、PeggyPad が抜けちゃってるのは、NGって書いたせいかな?
正確には、(B)に対してはNGってことで(A)には使えます。
開発元のURLは、 http://www.anchorsystems.jp/
製品についてのURLは、 http://www.anchorsystems.jp/anchor/ashp/peggy/pegindex.html
となります。(B)向け一覧はまだ作っていないのですが、Vim はきっとそれ用にくださった情報ですよね。。?
そうですね、(B)で検証するときに設定しておく必要があるかと思います。
文字コード変換に関する問題点の詳しい説明はWikipediaをリンクしてみてはどうでしょう?
文字コードに関してのWikipediaのURL
文字コード変換に関わる問題についてのURL
HTMLの改行ってCRLFじゃないといけないという記述をどこかで見たような気がしたので、調べてみました。
MIME テキストのすべてのサブタイプと同じく、text/html の正規の形式では、改行をつねに CR (0x0D) のバイト値に LF (0x0A) のバイト値が後続するシーケンスとして表現しなければならない。 同様に、text/html の中にそうした CRLF シーケンスがあれば、それは改行を表現していなければならない。 改行シーケンス以外で CR バイト値や LF バイト値を使用することも禁止されている。 この規則は、使用されている文字符号化法 (charset) に関わりなく適用される。
# HTML自体ではなく、MIMEの方で定義されているとわ… 通りで見つからないと。
XHTMLに対しては、以下のRFCがあります、
LFを改行として使う場合は、Content-Type: application/xhtml+xmlとし、
Content-Type: text/html の場合は、CRLFを使うのがRFC的には正しいようです。# HTML自体ではなく、MIMEの方で定義されているとわ… 通りで見つからないと。
おおお、今やきちんとした定義があるんですね。しかし WordPress 自体もきちんと準拠してない気がします。まず、テンプレートファイルの改行コードは CRLF で作らないといけないし、テンプレートタグが改行を出すときも CRLF にしないといけないので、かなり変更が必要そう……。
# 個人的には、テキストファイルの CRLF 改行は大嫌いなのでテーマファイルを CRLF にしたくない 😉
LFを改行として使う場合は、Content-Type: application/xhtml+xmlとし、
これは、「改行コードの規定がないから LF でもよい」という理解でいいんでしょうか。
これは、「改行コードの規定がないから LF でもよい」という理解でいいんでしょうか。
W3CによるXML1.0勧告の2.11 End-of-Line Handling
(和訳 2.11 行末の取扱い)に下記のように定められています。XMLの構文解析対象実体は,通常コンピュータのファイル内に保存され,編集の便宜のために複数の行に分けることが多い。これらの行は,普通は,CR (#xD)コード及び LF (#xA)コードの何らかの組合せによって分けられる。
アプリケーションの処理を簡単にするため,外部解析対象実体又は内部解析対象実体のリテラル実体値が,”#xD#xA” の2文字の連続とするリテラル又は#xDの単独のリテラルを含む場合に,XMLプロセサは,アプリケーションに単一の文字#xAだけを渡さなければならない(この処理は,入力内に存在する改行コードを構文解析の前に正規化することによって,容易に実現できる。)。
RFC 3023 (XML Media Types)(和訳みつらず)
では、特に改行コードの規定はされていないようです。さらに、RFC 3236 では application/xhtml+xml は applicatino/xmlに従うということなので、xmlの派生であるxhtmlにはCR/LF/CRLFがそれぞれ現れてよいということです。
と、いうことで、xhtmlでLFのみを使うのであれば、application/xhtml+xmlがよいということになります。
私が使ってるエディタはmi http://www.mimikaki.net/ ですが、
モード設定の文字コードの項目で、
・unicodeで保存するときに\マークをバックスラッシュで保存/コピーする
・UTF-8保存時BOMをつける
のチェックをはずす必要があります。Windows、 MK-Editor http://www.mk-square.com/
RCバージョンのまま数年間アップデートされていませんが、非常に使いやすいため、ずっと使い続けています。どちらも、\とバックスラッシュ、並線と全角チルダの混在文書が扱えません。
Linux、KDEのKATE、日本語環境wnn+cannaでは全角チルダが空白で表示されますが、混在文書を適切に扱えます。
wp-config.phpのように、英数記号しか含まれないファイルなら、Shift_JISで保存すればメモ帳でも問題ないです。
むしろShift_JISにした方が、BOMだの何だのという変な問題が出てきません。PHPファイルの改行コードは、FTPでアップロードするときにアスキーモードか自動選択にすれば、エディタで保存するときに何であれ、関係ないと思います。
でもPHPではPerlや他の言語と違い、何でも良いみたいですね。XMLやHTMLの改行コードについて言及がありますが、
HTTPと、HTML/XHTML/XMLは異なります。
http://www.rfc-editor.org/rfc/rfc2046.txt
text/*のHTTPヘッダはCRLFでなければなりませんが、それ以外は何でも良いです。(HTML本文については言及していません)Perlでは
print “Content-Type: text/html;charset=utf-8\n”;
print “X-MY-HELLO: Hello, my name is Dab.\n”;
print “\n”;
などと書きますが、\nはウェブサーバーやモジュール(mod_perlやmod_cgi)により、CRLFに変換されます。
Classic Macで”\n”と書けば通常はCRが書き出されますが、ヘッダ部分はウェブサーバーによりCRLFに変換されます。PHPではheader()を使うので、
header(“Content-Type: application/xhtml+xml”);
header(“X-MY-HELLO: Hello, my name is Dab.”);
WordpressではHTTPヘッダの改行を書くことはないと思います。本文中の改行コードはなんでもいいです。
というか、Content-Type: image/jpgだったら、改行もなにもありませんし、0x00が連続で続いたり、0x0dが連続で続くこともあります。text/*以外のヘッダをLinux ApacheのCGIとasisで試してみると、
やはりどんなMIME-TypeでもLFはCRLFに変換され、CRはエラーとなるようです。XHTMLを使うときはapplication/xhtml+xmlが良いですが、IE6で表示できないことがあります。
(WindowsXP SP3などのアップデートで表示できる様になっているかも知れません)
昔のXHTML1.1の文法ではapplication/xhtml+xmlかapplication/xmlしかダメでしたが、現在はtext/htmlも認めています。今、気がつきました。
>wiki
Vim もマルチプラットフォームですね。
本家は、 http://www.vim.org
日本語Windows向けパッチ+バイナリが http://www.kaoriya.net/ です。ものすごーーく間が空いてしまってすみません。
jyoshidaさんの投稿(#post-872)までを Wiki に反映してあったものを、用語集の記述にマージさせていただきました。WordPress Codex 日本語版 » 用語集 – テキストエディタ
間違いや直したほうがいい箇所など、お気づきの点がありましたらご指摘ください。
テキストエディタの一覧は、通常用とコンテンツデータの編集用に分けたほうがいいか迷ったのですが、1つのリストにして、印を付けてみました。
投稿してくださった内容の転載の仕方など、失礼なところがあったら大変申し訳ありません。後ほど見直しておきたいと思います。
また、このトピックの続きも拝読した上で、後日反映させていただきたいと考えています。(体調不良のためまた間があいてしまったらごめんなさい。。)
Notepad(英語名)でショートカット名がメモ帳(日本語名)なので同一のテキストエディタを示しています
英語圏WindowsOSやヨーロッパなどはNotepadが問題ないから英語Codex説明にはNotepadが推奨されている?
プログラムコードが1バイト圏で済む地域はコード流用されていて”UTF-8”がUTF-8N形式かも
日本は漢字と言う厄介なコードを使っていてNotepad(メモ帳)とはいっても別のソースから作られているかも知れないので保存文字コードを”UTF-8”がUTF-8BOMでUTF-8Nにするオプションがない?
多バイト圏、韓国、中国、シガンポール、アラビヤ、ヘブライ等は日本語sourceを使っていれば同じ現象が発生しているかもNotepadとWordpad
Win95にさかのぼります
Notepadはテキストエディタで32KBsizeまでしか編集出来ない、36KB位を境にフリーズ
WordpadはワープロのWord体験版のようなものでテキスト(32KBsize以上も可)、Doc(リッチテキスト形式、簡単に言うとWord95の基本書式まで編集できる)
Win2000かXPでNotepadは500MBでも開けるようになったので編集できるかは別だけど、よってWordpadはDocビュアー位しか使われない?Windows98、95系のメモ帳はS-JISまでしか取り扱えないので(UTF-8不可)編集できません、Win2000は編集できるか?だたマルチバイト正式はXPからだから不可かも
私は以前のWP、wp-config.php がS-JISエンコードで保存してよいか参加していないので判りません
そしてWP2.5からwp-config.php UTF-8で保存するのが必須になった
重要なのが
テキストエディタを使わなくてはいけないのかです、標準やBlog閲覧環境で代替できる方法がある場合それで良いかと言う事です
代替案
ie6,ie7でUTF-8BOMで保存されているテキストを開き、ファイル->名前をつけて保存でUTF-8で保存すればUTF-8Nになります(バイナリ比較でok)
ただし
Firefox3.0.4では同じようにUTF-8で保存してもUTF-8BOMになるためこちらはng
頻繁に更新してくれるし東京WPで公演依頼できる仲?なので依頼?
Safariはインストールしていないので不明ここでieがUTF-8Nを採用しているから英語圏NotepadもUTF-8Nじゃないのかな?
後は日本だけ?の問題と言う事でwpのinstall.php(admin.php)でコードチェックして”Winメモ帳など非推奨でwp-config.phpを作成していませんか、”とか表示かな?
- トピック「テキストエディタ: 問題なく使えるもの、使ってはいけないもの」には新たに返信することはできません。