shibuyaの日記： cygwinのviでゴミ除去に悩んだムダ話 12
日記 by
shibuya
http://twitter.com/nsh1960/status/162578562782724096
@null cat -v で確認すると "M-oM-;M-?" だと申告された QT : 357 273 277 --- ゴミの正体は od -c で確認したらこんなものだった。
http://twitter.com/nsh1960/status/162585505068883969
@null なぜか先頭行にあってもvimで確認できなかった。set listは試していない。。。 QT : ed で先頭行の前に0aとして挿入後ファイル更新するとvimでは2行目行頭にがゴミの正体だとやっとわかる
http://twitter.com/nsh1960/status/162753342207045633
@null まちがい。使っているcygwinで常用のエディタviは/usr/bin/vim-nox.exeのsymlinkであって/usr/bin/gvim.exeと実体は別だった。一緒ではない。 QT : なぜか先頭行にあってもvimで確認できなかった。
テキストファイルにゴミが入ったのはキーボード他の環境が腐っている自分のせいだけど、ゴミがテキストファイル1行目行頭にあると認識できなくて行末以下でないと表示も何もしてくれない制限ってあったんだっけな?
CYGWIN_NT-5.1 mizuho 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
ホスト名はWindows PC用ゲーム「おとボク」のフルボイスDVD版をプレイ後買ったのがきっかけ。
(上記はわたし自身のアカウントでtweetしたものである)
どうやって作ったんでしょう？ (スコア:2)
おかしいですね
vim はデフォルトだと bomb オプションはオフなので
新規でファイルを作った場合、BOM はつかないはずなんですけど。
http://sites.google.com/site/vimdocja/options-html#'bomb [google.com]'
notepad で開いて保存し直したとかでしょうか？
vim で以下のように入力すると、現在の bomb の設定状況がわかります。
:set bomb?
同様に、以下のように入力すると、現在のエンコーディングの状況がわかります。
:set encoding?
多分、問題のファイルを開いた状態だと以下のような結果になっているはずです。
:set bomb?
bomb
:set encoding?
encoding=utf-8
bomb オプションをオフにするには以下のように入力します。
:set nobomb
nobomb にした状態で保存すれば、BOM なしの UTF-8 (= UTF-8n) で保存出来るはずです。
uxi
Re:どうやって作ったんでしょう？ (スコア:1)
ありがとうございます。
notepad で開いて保存し直したとかでしょうか？
cygterm上でviを使いながら別ファイルを見比べようとしたのが悪さしたしたとしたらxyzzyかな?UTF-8nでなくUTF-8で読み込みかつ自動セーブありの設定をしていたxyzzy.exe がそうしたのかくらいが思いつくこと。明示的にread-onlyで開かなかったのが悪かったのでしょう。NotepadはCRLFのLFが苦手だからcygwin用のファイルでは使うつもりはないのでした。wordpadも結果的にCRLFがわからなくなるから同様に忌避。
Re:どうやって作ったんでしょう？ (スコア:2)
xyzzy は常用してますが、少なくとも私のところでは、あまりその手のトラブルに遭遇したことはないです。
BOM なし UTF-8 を読んだのなら、
エンコーディングは utf8n になっているはずなんですけど、
もし utf8 になっているようなら
C-x C-k f utf8n
として修正してもらえばよいと思います。
uxi
Re:どうやって作ったんでしょう？ (スコア:1)
ありがとうございます。
xyzzyで開いたせいだという話を持ち出したのはわたしの「いいがかり」のような気が大いにしてきました。
viで最初に開いたファイルがasciiキャラクタだけだったのに日本語コメントを付け加えたうちに自分で変にしてしまったというviだけで全部自己完結というのがいちばん可能性が高いと思われます。
// cygtermの表示切替だとか、別のもののせいにするとさらに無辜のソフトウェアを非難することにつながるのでますますもって自爆テロ。
BOMについてはみなさん書いているので… (スコア:1)
cygwin なら od -c より hexdump -C の方が判りやすいですよ。
16進数より8進数の方が判りやすいなら別ですが。
fjの教祖様
Re:BOMについてはみなさん書いているので… (スコア:2)
hexdump は util-linux パッケージに入っているので、ひょっとするとインストールされてないかも？
今回の場合、vim はインストール済みなので、vim パッケージに入っている xxd のほうがオススメかと。
uxi
Re:BOMについてはみなさん書いているので… (スコア:1)
ありがとうございます。
digとかは一方のPCに入っていて他方では入れていないこともありますが、hexdumpもxxdも使っているPCでは使えるようになっています。
// でも hexdumpもxxdも今日はじめて使った。さらにいうとviは使うけどvimとして利用するのをずっと敬遠してきたという暗い過去を持つ。
Re:BOMについてはみなさん書いているので… (スコア:1)
ありがとうございます。
16進数より8進数の方が判りやすい
該当します。 "od -b/od -t o1"なのかよ、どうして"od -o"じゃダメなのさ、というくらい多国語対応していない頃のシステムでmanを読んだ古いところ1990年前後錆付いていて頭がついていっていません。だからhexdumpの方が向いているというのも逆説的に成り立つわけです。
// さらにいうとbashとkshのbuiltinコマンドの非互換なオプションに依存しないようにと最初に楽した報いで泣いている最中。
UTF-8のBOMですね (スコア:0)
357 273 277
11 101 111 10 111 011 10 111 111
1110 1111 1011 1011 1011 1111
EF BB BF (= UTF-8のBOM)
最近のvimはUTF-8のファイルの先頭にBOMがあると無視してくれるのか。
先頭以外のU+FEFFはZero Width No-break Spaceと解釈して、無視してはならないことになっています。
Re:UTF-8のBOMですね (スコア:1)
ありがとうございます。
次からはぼやく前にByte Order Mark (BOM) FAQ [unicode.org]を読んで修行し直すことを誓いました。
それって UTF-8 じゃないですか？ (スコア:0)
ゴミではなく UTF-8 の BOM (= 0xEF 0xBB 0xBF) を od -c すると
\357 \273 \277
になります。
BOM はエンコーディングの識別子なので
UTF-8 対応のテキストエディタでは表示されないのが仕様だと思います。
Re:それって UTF-8 じゃないですか？ (スコア:1)
ありがとうございます。UTF-8です。teratermでcygterm動かしています。cygwin 1.7は多国語環境の既定値がUTF-8ですよってに。
でも1行目の行頭に入れて欲しくないです。理由:
が使えなくなるじゃないですか!という目的に照らすとゴミなんです。