Notepad(メモ帳)を使うべきではない理由 その17~20


17: CR+LFのみを改行として認識する

わかりやすく言えば、改行がなくなって読めたもんじゃなくなることがある。

テキストファイルで使われる改行コードには、Windowsで標準的なCR+LF(0x0d0a)のほかに、Unixに多いLine Feed (LF, 0x0a)やMacで多かったCR (Carriage Return, 0x0d)があるんだけど、Notepadが改行と認めるのはCR+LFだけ。マイクロソフトがそう言うのならしょうがない。

18: UTF-8で保存するとBOMが付く

わかりやすく言えば、ファイルに余計なデータが付加されて、それを削除できない。

BOM (Byte Order Mark)とはUTF-16の形式(little endianあるいはbig endian)を識別するために先頭に書かれる文字(Zero Width No-break Space, ZWNBS, U+feff)のこと。UTF-8では必要ないのだが、UTF-8のファイルの先頭にも、メモ帳はZWNBSを付けてくれる(0xefbbbf)。このせいでファイルが不正とされることも多いんだけど、マイクロソフトがそう言うのならしょうがない。

19: 文字エンコードの判定が変

わかりやすく言えば、文字化けから逃れられないことがある。

次のような内容のファイルを作り、保存して開くと文字化け。

this app can break

文字エンコード自動認識の失敗。この例ではUTF-16LEだと誤解している。それだけならほかのソフトでも、とくにファイルが小さいとよくあることだからいい。でも、BOMの無いこのファイルを、BOMが無ければ読めないはずのUTF-16と解釈するのは変。最悪なのは、文字コードを指定して開き直すことができないこと。そもそも、先に言ったように、NotepadのルールではUnicode (UTF-8, UTF-16)のファイルには必ずBOMを付けることになっているのだし。でも、マイクロソフトがそう言うのならしょうがない。

Behind ‘How to break Windows Notepad’

20: 文字エンコード名が変

わかりやすく言えば、よそでは通じない用語になじんでしまう。

Notepadで名前を付けて保存しようとすると、文字コードを指定できる。そこで選択できるのは、ANSI, Unicode, Unicode big endian, UTF-8。UnicodeはUTF-16LE、Unicode big endianはUTF-16BE、UTF-8はUTF-8(BOM付)でいいとして(UTF-8にBOMは要らないが)、ANSIってなんだよ!!! ここは正しくはCP932かMS932, Windows-31Jとすべきところ(実際、CP932で保存される)。妥協して、Shift_JISでもまあいいだろう。
でも、ANSIはないだろ、そりゃないぜ、マイクロソフト! ASCIIの別名ANSI_X3.4-1968を縮めてANSI? でも、ASCIIじゃなくてCP932なんだけど、マイクロソフトがそう言うのならしょうがない。

以上の問題は、Windows Vista Beta 2のNotepad 6.0でも残っている。

まあ、このブログを読んでいて、メモ帳を使ってる人なんてほとんどいないと思うけど。

追記:結局のところ、おすすめのエディタは何なの?(2006.08.09)

Notepad(メモ帳)を使うべきではない理由 その17~20” への4件のコメント

  1. ピンバック: Tweets that mention Notepad(メモ帳)を使うべきではない理由 その17~20 | inquisitor -- Topsy.com

    • aさん

      コメントありがとうございます。
      認識していませんでしたが、そういうこともあるんですね。

  2. ほんと、ショボいですよね。がっかりです。なんでこういったバグ?が報告されまくってるのに、改善しないのでしょうね?
    殿様商売っていやですね

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です