enc=utf-8 環境下での utf-8 の読み込みロジックを改良する

[koron]

enc=utf-8 で utf-8 なファイルを読み込む時に、 fencs に ucs-2 などのエンコードがあるとほとんど正しく開けないという問題があります。本 issue はこの問題の解決を目指すものです。

関連: #370

原因

ucs-2 から utf-8 の変換はサイズが偶数である限り、原理的に決して失敗しません。そのため fencs を先頭から順番に試し成功したところでやめる、というVimの戦略では決して utf-8 を開けなくなります。

対策

utf-8 は本来制約が強いため valid かどうか判定することができます(今のVimは enc=utf-8 の時にしていませんが)。それを利用して ucs-2 よりも先にその判定を行なうことで utf-8 として正しく読み込めます。

思い付き

これを理由に guess 的なものを捩じ込めないだろうか。

[ynkdir]

fencs を先頭から順番に試し成功したところでやめる

enc=utf-8 fencs=utf-8 で読み込むときはバリデーションしてます

[koron]

@ynkdir コード的にどのあたりだか、教えてもらえます?

それが真なら順番だけ変えれば良いのかな。

[koron]

仮にバリデーションしてるとしても ucs-2 が utf-8 として valid になる可能性が高いと意味ないか。
でも改行とかで途中に 00 が出てくるから invalid 判定でないのはおかしいなぁ。
そこだけ直せばよいのかなぁ。

今はそんなところ。

[ynkdir]

どうなってたか中身はあんまり覚えてませんが fileio.c:readfile() 内を utf8 とか valid とかで検索するとそれっぽいとこがあると思います。

ちなみに私は fencs=ucs-bom,utf-8,euc-jp,cp932 と設定してます。

00 は utf-8 としては valid なので特に ascii のみのファイルとかははじけないですね。

[koron]

fileio.c:1922 あたりですかね。

となると

ucs-2 が utf-8 として valid になる可能性が高いと意味ない

これが効いてきますなぁ。

[koron]

日本語において ucs-2 が utf-8 として invalid になる という推測に基づく前提が誤りであるため、
本 issue で述べた対策は機能しません。
またこのことは原理的にも ucs-2 を utf-8 から分離することは不可能ということを示すため打つ手なしです。

本 issue は閉じます。

[k-takata]

既にクローズされちゃってますが、fencs=utf-8,ucs-2leというようにucs-2系を後ろにすれば、日本語であればある程度機能します。
例えば、ファイルという文字列をucs-2leで保存して、それを開いてみると確認できると思います。

[koron]

それはたまたまutf-8で解釈できないucs-2leができたというだけですよね?

[k-takata]

例えば0x80以上とそれ未満が交互に出てくるような場合は確実にはじけるはず（Vimのコードの確認していませんが）
。
コード表は見ていませんが、おそらくカタカナなどはそれに相当します。これをたまたまと見るかどうかですが…。

で、私の結論としては、Vim本体の対策は不要で、fencs の指定で utf-8 の後ろに ucs-2 系を加えればいいのではないかということになります。（少なくとも日本語を扱う場合は）

[koron]

Tony が 「ucs-2 じゃなくて utf-16 を使え」って言ってるけど、アレはどうだろう? 採用する価値あるかしら?

[k-takata]

あぁ、ucs-2 系よりも utf-16 系の方がいいでしょうね。
今更、サロゲートペアを扱えない ucs-2 を使うメリットが感じられません。

[koron]

utf-16 の読みは良いと思いますが、書きはどうなんですかね?
utf-16 で書いたものWindows はちゃんと(すべて)扱えるのかしら?

[koron]

http://ja.wikipedia.org/wiki/UTF-16#.E6.99.AE.E5.8F.8A

これを見る限り大丈夫そうね。一次情報(Microsoft)からの情報でないのがやや不満だけど。

[koron]

ちょっと毛色の違う問題を思いだした。

fencs=...,ucs-bom,utf-8,utf-16le,utf-16be

の時に、utf-8なんだけど壊れたバイトシーケンスを含みかつ全体のサイズが偶数の時って、
無理やり utf-16 になっちゃいそう。
これは理想を言えば utf-8 で開かれ 8g8 で不正シーケンスを探せる状態になると嬉しい。

結局のところ utf-16 (ucs-2) が貪欲すぎることが問題なんだろう。
ucs-bom がある以上、そっちが utf-16 ユーザをほぼ救ってくれるだろうから
ピュアな utf-16 ユーザには少し泣いてもらっても utf-8 の使い勝手を向上させるべきではなかろうか?

ちなみになんでこれを思い出したかっていうと、
2chのログは cp932 なんだけどたまに euc-jp や utf-8 で書き込まれてて泣きをみたからw

[koron]

@k-takata

ucs-bom がある以上、そっちが utf-16 ユーザをほぼ救ってくれるだろうから
ピュアな utf-16 ユーザには少し泣いてもらっても utf-8 の使い勝手を向上させるべきではなかろうか?

これについて検討&意見をお願いできますか?

[k-takata]

ピュアな utf-16 ユーザには少し泣いてもらっても utf-8 の使い勝手を向上させるべきではなかろうか?

確かにそうですね。
WindowsでUTF-16の場合、たいていはBOMがついていますし、BOM無しUTF-16よりも、壊れたバイトを含むUTF-8を扱える方が便利な気がします。

[koron]

fencs=...,ucs-bom,utf-8,utf-16le,utf-16be

の時に、utf-8なんだけど壊れたバイトシーケンスを含みかつ全体のサイズが偶数の時って、
無理やり utf-16 になっちゃいそう。

一応、あとでこれ本当にそうなるか確認する。なるならば現状のままとし、ならないなら utf-8 と utf-16 系追加する。

[koron]

utf-8なんだけど壊れたバイトシーケンスを含みかつ全体のサイズが偶数の時って、無理やり utf-16 になっちゃいそう。

試した。なった。

ただし壊し方によっては cp932 として valid になって引っかかるな。根深い問題だわw

とりあえずは utf-16le, utf-16be は外します。その他のutf-8にまつわる問題は別issueを立てて対応する方向で。

[koron]

fencs によるコード自動判定の精度を限界まで上げようという試みだった。
検討時点では成果は上げられなかったが、 wontfix ではなく backlog として将来に希望を繋ぐべきと判断した。