サポート » WordPress への貢献と参加 » テキストエディタ: 問題なく使えるもの、使ってはいけないもの

  • lilyfanさんの書き込みを拝見してトピックを立ててみました。
    みなさまからテキストエディタについての情報をいただけないでしょうか。

    # 「Windows のメモ帳は使用禁止」というのを、インストール説明のどこかに載せませんか?? ダブルクリックすると「メモ帳」で開いてしまうので、それはダメというのを書かないといけません。> ドキュメンテーション関係者さま

    Codex には「テキストエディタ」が登場するページが結構あり、また、「用語集」にエディタの説明と英語版エディタの一覧が載っているので、日本語でも問題なく使えるエディタの一覧に改訂したいと考えておりました。

    現在、インストール説明やドキュメント上でテキストエディタについて触れている箇所は次のとおりです。

    • WordPress | 日本語 » インストール — 「WordPad などのテキストエディタで wp-config-sample.php を開き、~」
    • Codex では、ほとんどのページは 用語集 にリンクを張っていますが、一部、具体的に書き添えられている箇所があります。↓
    • インストールの前に — 「Windows ユーザであれば Notepad が使えます。」
    • wp-config.php の編集 — 「Microsoft Word のようなワープロソフトは、WordPress ファイルの編集には 絶対に 使わないでください!」

    Windows のメモ帳=Notepad ですよね。。orz
    作業環境が日本語だと問題が出てしまうのでしょうか。。ここは直さないといけませんね。

    Codex はページ数が多い(これからも増える)ので用語集に集約するか、トラブルが多ければ、ダブルクリックで開けてしまう NotePad について注意書きを添える必要があるのかなと思います。

11件の返信を表示中 - 46 - 56件目 (全56件中)
  • モデレーター IKEDA Yuriko

    (@lilyfan)

    プログラムコードが1バイト圏で済む地域はコード流用されていて”UTF-8”がUTF-8N形式かも
    日本は漢字と言う厄介なコードを使っていてNotepad(メモ帳)とはいっても別のソースから作られているかも知れないので保存文字コードを”UTF-8”がUTF-8BOMでUTF-8Nにするオプションがない?

    「メモ帳」が UTF-8 の BOM ありでしか保存できないのは、漢字の使用有無とは無関係です。未確認ですが、おそらく英語版 Windows でも同様だと思われます。

    ここでieがUTF-8Nを採用しているから英語圏NotepadもUTF-8Nじゃないのかな?

    BOM のあり/なしは OS の違いよりもアプリケーションの違い (ie と notepad) に依存した挙動でしょうから、英語版 Windows の notepad.exe も BOM つき UTF-8 で保存するのだと予想されます。英語版 Windows は持っていないので完全にあてずっぽうですが 😉

    私は以前のWP、wp-config.php がS-JISエンコードで保存してよいか参加していないので判りません

    WordPress 日本語版での wp-config.php (ないし wp-config-sample.php) のソースを見てみると分かりますが、日本語コードを使っているのは PHP のコメント部分だけなので、Shift_JIS でも一向に問題ありません。コメント部分のため、不正な文字コードを入れ込んでセキュリティホールを発生させることも、まず無理でしょう。

    ということで、「wp-config.php の日本語コメントを Shift_JIS にする」というのは、解決方法の1つとしてはアリです。

    ただ、wp-config.php は、WordPress 本体ないしプラグイン等から include されるものなので、文字コードをまぜてしまうのは、あまり好ましくありません。

    後は日本だけ?の問題と言う事でwpのinstall.php(admin.php)でコードチェックして”Winメモ帳など非推奨でwp-config.phpを作成していませんか、”とか表示かな?

    wp-config.php はインストール時にウィザードで自動生成できるので、そうすることを推奨すればよく、手作業で wp-config.php を編集するのは特殊な事例です。このため、「メモ帳を使ってはいけません」と書くだけで十分だと思われます。

    あと、WordPress 日本語版は、ME と違って、本体のロジックには手を入れない方針のはずなので、そういう改造は困難でしょう。ロジックを変更してしまうと慎重なテストが必要になってしまいます。現状の、日本語リソースの追加だけならば、そのリソースがきちんと機能しているかチェックするだけでよい (*) ので、比較的迅速なリリースができていますが、独自改造を入れるとそれが無理になってしまいます。

    (*) 残念ながら、実際に WordPress を動かしてのテストはあまり十分ではないようです 😉 リソース自体のチェックは慎重に行なわれているんですが。

    three-eye

    (@three-eye)

    もう一度初めから投稿読み直していて、追加

    phpデーモンがUTF-8 BOM でもUTF-8Nでもエラーにならず実行出来るように要望する

    Windowsテキストeditorではなくホームページ編集Softを使う
    サーバ転送を考慮し開発されているはずだからUTF-8N扱えるはず

    FTP転送プログラムがUTF-8N変換を備える

    jyoshida氏が発言されましたがRFC 2854 等しかなくASCII TextのCR,CR+LF規定が無い
    だとすれば規定がないからおかしくなっているとすれば
    RFC にASCII TextがCR,CR+LF規定を提案する[これは現状を規定するのだからすぐ承認]
    マルチバイトTEXTはUTF-8N変換を要望する-->そうすればFTPがバイナリ、ASCIIの他にマルチtextが増えるだろう
    FTPで変換するならローカルではUTF-8 BOM でもいいし、PHPはUTF-8Nだから正常、FTP開発者には苦労してもらうのが最小限の修正で済むのでは

    モデレーター IKEDA Yuriko

    (@lilyfan)

    なんかデタラメばかり書かれているので、げんなりです。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 で配布すれば、強制的にアップデートできるわけで、スムーズに解決できますよね。もちろん、ある程度の混乱が予想されますが、事前にアナウンスして、慎重に準備すればなんとかなるでしょう。

    three-eye

    (@three-eye)

    「メモ帳」を使わないこと、ないし「メモ帳」の実装を直すことが、正しく、かつ、素直な解決方法です。

    なるほどこの考えぬけていました、実装が間違っているプログラムを排除するのが先ですよね、提案を破棄しlilyfan氏のメモ帳をデフォルトで UTF-8 の BOM なしで保存するようにするのがスマートな解決方法でしょう。にします

    モデレーター IKEDA Yuriko

    (@lilyfan)

    なるほどこの考えぬけていました

    返答を修正している間に返事がついてしまいました 😉

    thee-eye さんが、どんな OS/システムをお使いかのか知りませんが、いろんな OS やシステムを使ってみると、「いかに Windows がデタラメか」というのがよく分かりますよ (*) 😉 もちろん、Linux や Mac OS X にもダメな部分はいっぱいある (**) んですが……。

    (*) 波ダッシュ問題や円マーク問題は、その際たる例でしょうか。IE の「独自実装多すぎ」というものありますね。
    (**) Mac OS X はバックスラッシュと円マークを区別しようとして、かえって問題が起きることがあります。Linux は GUI 周りがダメすぎでしょう。

    wp-config.php の UTF-8 BOM 問題は、なかなか根が深くて解決するのが大変です。いろいろ提案して頂けるのはありがたいのですが、今回はちょっと的が外れていたということで、納得頂けると幸いです。

    改行コードに関する部分がまだ理解できてないので(す、すみません。。><)、先にテキストエディタのリストだけ更新させていただきました。

    >dabさん

    情報ありがとうございます。書き込んでくださってから時間が経ってしまいすみません。
    ・mi
    ・MK-Editor (正式版が出ましたね。 :-))
    ・Kate
    を Codex に反映させていただきました。

    どちらも、\とバックスラッシュ、並線と全角チルダの混在文書が扱えません。

    「波線」は他と揃えて「波ダッシュ」とさせていただきました。
    バックスラッシュの前に書いてくださった記号は、私の PC ではバックスラッシュに見えてしまうのですが、円記号と解釈して載せてあります。
    いずれも間違ってたら教えてください。

    Linux、KDEのKATE、日本語環境wnn+cannaでは全角チルダが空白で表示されますが、混在文書を適切に扱えます。

    これは、「Kate」 と 「wnn+canna」 というのを同時使用、という意味でしょうか。別のエディタとして載せていいですか?(先に Kate だけ載せてしまったのですが。。全然理解できてなくてすみません)
    「wnn+canna」は、WnnCanna それぞれはあったのですが「wnn+canna」という名前のアプリが見つけられず、Codex に書けてないです。
    wnn+canna の公式サイトとプラットフォーム、フリーウェア/シェアウェアの区別を教えていただけたらありがたいです。

    >jyoshidaさん

    いつもありがとうございます。助かります。
    お使いになっている Vim は Kaoriya.netさん版とのことでしたが、本家の Vim も ◆マークをつけていいかお分かりになりましたら教えてください。

    あと、Vim を Kaoriya.netさん版ごとクロスプラットフォームに移動しちゃったのですが、

    ・Windows:
      ・Vim (日本語Windows向けパッチ+バイナリ)
    ・クロスプラットフォーム:
      ・Vim  ←本家の

    のように分けた方が製品としては正しいでしょうか。。

    リストの書き方を
    * アプリ名 (OS)
    にしたほうがよかったかな。。

    >bonopsさん
    すいません、気がつかなくって遅くなりました。

    Kaoriya.netさんのは日本語/Windows向けバイナリの他にソース差分も配布されていますのである意味クロスプラットフォームとも言えます。
    また、本家はソースとWindows向けバイナリを配布していますが、設定ファイルをちゃんと書かないと日本語の扱いはNotepad以下になるので(笑)、おすすめはできませんね。
    カテゴリ訳は難しいですが、

    ・Windows
    ・Vim(日本語Windows向けパッチ+バイナリ)

    ・クラスプラットフォーム
    ・Vim(本家)
    Vim(日本語パッチ)

    という感じでしょうかねぇ~

    さてこのスレッドがまだ生きているのかどうかですが…
    うちがいつも使用しているテキストエディタを挙げときます。

    それは、TheTextっていうフリーテキストエディタ。
    (有償版もあるらしいけどそっちは使ったことがないのでパス :p)

    文字コード指定での保存が可能(S-JIS、EUC-JP、JIS、UTF-8に対応)なので
    比較的使用に耐えうるエディタかなと。

    文字コード云々の件はこちらではわからないのでお任せします(ぉ
    (チェックしてほしい文字/記号一覧があれば見てみますが)
    とりあえず、橋ゲタ高は出ますが並ダッシュは表示されませんでした。

    なので(A)の使い方としては○、(B)としては△ないしは×でしょうかね。

    >Hypnotherapyさん

    スレ生きてます。(^-^; 情報ありがとうございますー。

    TheText は UTF-8 BOMなし保存できますか?

    OK でしたら、直接 Codex に書き込んでいただく(私が書き込むのは間があいてしまいそうなので)か、
    プラットフォームや URL を教えていただければ私の方で書き込んでおきます。 🙂

    投げたままで見てませんでした;

    さて、BOMの件なのですが…調べ方がわかりませんでしたorz
    ファイルの保存形式にはBOMに関する記載がありません。

    ソフト自体はベクターにありますので実際に見ていただいた方が
    確実だと思います…。

    ソフト自体はベクターにありますので実際に見ていただいた方が
    確実だと思います…。

11件の返信を表示中 - 46 - 56件目 (全56件中)
  • トピック「テキストエディタ: 問題なく使えるもの、使ってはいけないもの」には新たに返信することはできません。