フォーラム

テキストエディタ: 問題なく使えるもの、使ってはいけないもの (57 件の投稿)

  1. bonops
    メンバー
    3 years前の投稿 #

    今までいただいた情報を Wiki にまとめてみました。
    おかしなところとかありましたら教えてください。

    ここでいくつか返信を。。

    katze さん

    このトピックとしては、OSを問わず
    「wp-config.phpの編集に用いてもよいテキストエディタ」
    を列挙することに専念したほうがよいのではないでしょうか。

    「DBをエクスポートしたファイルの編集に用いてもよいエディタ」
    については、別トピックを立てて議論した方が良いと思います。

    と、せっかく書いてくださったのにすみません、仕切り下手で。。
    既に(B)情報のボリュームも多かったので、どうしようかと思ってしまって。。(・;)

    (A)(B)のどちらについての情報か、投稿の冒頭に書いていただくのではどうでしょう。。
    >みなさま

    lilyfanさん
    確かに対応 OS の詳細まで載っていると親切ですね。
    ただ、バージョンアップに伴って変わってくる可能性などもあり、正直なところ、WordPress ドキュメントをメンテする立場として考えると、各エディタの情報を最新に保つのはキビシイかな、と。。(^-^; もちろん、参加者が増えてそれぞれに更新していってもらえるのならばいいのですけれども。。

    詳しいシステム要件はエディタの配布元を確認してもらうのだと、まずいでしょうか。私もまだチェックできていないので、現時点では、注釈で「動作対象 OS の詳細は、各配布元にてご確認ください。」としておきました。

    おでさん
    補足情報ありがとうございました。 :-)
    読み込める容量はバージョンアップで進化していきそうなので、とりあえず各エディタについて述べずに、ここに注釈として書いてみました。そして参考情報としておでさんの投稿にリンクしてみました。

    >kentanjpさん、lilyfanさん、hiromasaさん
    教えていただいたエディタを一覧に載せました。ありがとうございます。
    リンクになっていないものは、開発・配布元の URI をご存知でしたら教えてください。

    jyoshidaさん
    「どうかとは思いますが。」と言われながらも載せてみました。(^^;
    (B)向け一覧はまだ作っていないのですが、Vim はきっとそれ用にくださった情報ですよね。。?

    Itsukiさん
    lilyfanさんも書いてくださっていますが、.htaccess の改行コードは LF になるかと思います。FTPクライアントで、転送時に改行コードを直してくれるものもあるので(Win の FFFTP とか)、それだとファイルの改行コードが LF になっていなくても大丈夫かもしれません。

    大昔に「改行コードはサーバに合わせる」と覚えていたのですけど、最近はたくさんサーバがあるので、.htaccess は Apache だから LF なのか、Unix 系だけ LF なのかは分からないです。。

    参考情報:
    Unicode の改行コード
    .htaccess は ASCII モードでアップするし、LF じゃないと Apache くんに改行だと認識してもらえないのかも。。?(←これは怪しい想像)
    改行コード -- lilyfanさんの「もはや CR のみ、というのは時代遅れ、CRLF にする必要はあまりないです」というのは、CR=昔の Mac、CR/LF=Win、ということかと思います。

    とかいう半端な情報を書き込みつつ、改行コードは LF でオッケーということで、Smultron も一覧に載せさせていただきました。
    開発・配布元の URI をご存知でしたら教えてください。

  2. bonops
    メンバー
    3 years前の投稿 #

    (A)について

    最初に(A)用エディタの要件をはっきりさせればよかったのですが、

    - 文字コードを指定でき、UTF-8 BOM なし(UTF-8N)で保存できること
    - 改行コード指定 (FTP クライアントで指定できれば不要)

    今の日本語版 WP は wp-config.php に日本語が入っているため、一つめの条件も必須、ということでいいのでしょうか。。?

  3. odyssey
    管理者
    3 years前の投稿 #

    >ぼののさん(笑)

    今の日本語版 WP は wp-config.php に日本語が入っているため、一つめの条件も必須、ということでいいのでしょうか。。?

    そうですね。wp-config.phpをwindowsのメモ帳(notepad)で開いて、編集して保存すると、bomをつけてしまうので、エラーはいちゃいます。
    ですので、一つ目の条件も必須ですね。

    日本語が入っていなければshift-jisの認識でも問題ないのですが。。。

    # あれ、フォーラムの返信欄にquicktagってついてましたっけ?

  4. kentanjp
    メンバー
    3 years前の投稿 #

    >kentanjpさん、lilyfanさん、hiromasaさん
    教えていただいたエディタを一覧に載せました。ありがとうございます。
    リンクになっていないものは、開発・配布元の URI をご存知でしたら教えてください。

    Jedit (Mac OS X)
    http://www.artman21.com/jp/

    これはシェアウェアですね。
    #MACはここ2年くらい触ってないので詳細忘れました OTL

  5. IKEDA Yuriko
    常連回答者
    3 years前の投稿 #

    WIki 見てみました。「エクスポートデータを編集する場合」の項目では、再度エディター一覧を掲載した方がいいですね。ここで、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 では、円マークがトラブルの筆頭だと思います。

  6. katze
    メンバー
    3 years前の投稿 #

    (A)の用途向けとしては、「GreenPad」も良いかもしれません。
    http://www.kmonos.net/lib/gp.ja.html

  7. katze
    メンバー
    3 years前の投稿 #

    (すみません、重複書きこみしてしまいました……)

  8. jyoshida
    メンバー
    3 years前の投稿 #

    あー、PeggyPad が抜けちゃってるのは、NGって書いたせいかな?
    正確には、(B)に対してはNGってことで(A)には使えます。
    開発元のURLは、 http://www.anchorsystems.jp/
    製品についてのURLは、 http://www.anchorsystems.jp/anchor/ashp/peggy/pegindex.html
    となります。

    (B)向け一覧はまだ作っていないのですが、Vim はきっとそれ用にくださった情報ですよね。。?

    そうですね、(B)で検証するときに設定しておく必要があるかと思います。

  9. jyoshida
    メンバー
    3 years前の投稿 #

    文字コード変換に関する問題点の詳しい説明はWikipediaをリンクしてみてはどうでしょう?

    文字コードに関してのWikipediaのURL

    文字コード変換に関わる問題についてのURL

  10. jyoshida
    メンバー
    3 years前の投稿 #

    HTMLの改行ってCRLFじゃないといけないという記述をどこかで見たような気がしたので、調べてみました。

    RFC 2854 (和訳)

    MIME テキストのすべてのサブタイプと同じく、text/html の正規の形式では、改行をつねに CR (0x0D) のバイト値に LF (0x0A) のバイト値が後続するシーケンスとして表現しなければならない。 同様に、text/html の中にそうした CRLF シーケンスがあれば、それは改行を表現していなければならない。 改行シーケンス以外で CR バイト値や LF バイト値を使用することも禁止されている。 この規則は、使用されている文字符号化法 (charset) に関わりなく適用される。

    # HTML自体ではなく、MIMEの方で定義されているとわ… 通りで見つからないと。

    XHTMLに対しては、以下のRFCがあります、

    RFC 3236 (和訳)

    LFを改行として使う場合は、Content-Type: application/xhtml+xmlとし、
    Content-Type: text/html の場合は、CRLFを使うのがRFC的には正しいようです。

  11. IKEDA Yuriko
    常連回答者
    3 years前の投稿 #

    # HTML自体ではなく、MIMEの方で定義されているとわ… 通りで見つからないと。

    おおお、今やきちんとした定義があるんですね。しかし WordPress 自体もきちんと準拠してない気がします。まず、テンプレートファイルの改行コードは CRLF で作らないといけないし、テンプレートタグが改行を出すときも CRLF にしないといけないので、かなり変更が必要そう……。

    # 個人的には、テキストファイルの CRLF 改行は大嫌いなのでテーマファイルを CRLF にしたくない ;-)

    LFを改行として使う場合は、Content-Type: application/xhtml+xmlとし、

    これは、「改行コードの規定がないから LF でもよい」という理解でいいんでしょうか。

  12. jyoshida
    メンバー
    3 years前の投稿 #

    これは、「改行コードの規定がないから 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がよいということになります。

  13. dab
    メンバー
    3 years前の投稿 #

    私が使ってるエディタは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も認めています。

  14. jyoshida
    メンバー
    3 years前の投稿 #

    今、気がつきました。
    >wiki
    Vim もマルチプラットフォームですね。
    本家は、 http://www.vim.org
    日本語Windows向けパッチ+バイナリが http://www.kaoriya.net/ です。

  15. bonops
    メンバー
    3 years前の投稿 #

    ものすごーーく間が空いてしまってすみません。
    jyoshidaさんの投稿(#post-872)までを Wiki に反映してあったものを、用語集の記述にマージさせていただきました。

    WordPress Codex 日本語版 » 用語集 - テキストエディタ

    間違いや直したほうがいい箇所など、お気づきの点がありましたらご指摘ください。

    テキストエディタの一覧は、通常用とコンテンツデータの編集用に分けたほうがいいか迷ったのですが、1つのリストにして、印を付けてみました。

    投稿してくださった内容の転載の仕方など、失礼なところがあったら大変申し訳ありません。後ほど見直しておきたいと思います。

    また、このトピックの続きも拝読した上で、後日反映させていただきたいと考えています。(体調不良のためまた間があいてしまったらごめんなさい。。)

  16. three-eye
    メンバー
    3 years前の投稿 #

    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を作成していませんか、”とか表示かな?

  17. IKEDA Yuriko
    常連回答者
    3 years前の投稿 #

    プログラムコードが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 を動かしてのテストはあまり十分ではないようです ;-) リソース自体のチェックは慎重に行なわれているんですが。

  18. three-eye
    メンバー
    3 years前の投稿 #

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

    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開発者には苦労してもらうのが最小限の修正で済むのでは

  19. IKEDA Yuriko
    常連回答者
    3 years前の投稿 #

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

  20. three-eye
    メンバー
    3 years前の投稿 #

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

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

  21. IKEDA Yuriko
    常連回答者
    3 years前の投稿 #

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

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

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

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

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

  22. bonops
    メンバー
    3 years前の投稿 #

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

    >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)
    にしたほうがよかったかな。。

  23. jyoshida
    メンバー
    3 years前の投稿 #

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

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

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

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

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

  24. Hypnotherapy
    メンバー
    2 years前の投稿 #

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

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

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

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

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

  25. bonops
    メンバー
    2 years前の投稿 #

    >Hypnotherapyさん

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

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

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

  26. Hypnotherapy
    メンバー
    2 years前の投稿 #

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

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

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

  27. xiaorui
    メンバー
    2 years前の投稿 #

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

返信

ログイン しなければ投稿できません。

About this Topic