Ctags: ユニバーサルctagsは、特定のファイルに無効な `utf-8`文字を挿入します

私には＃1275のように聞こえます。新しいpattern-length-limitオプションは、文字シーケンスの途中にある任意のバイト位置で切断されます。 ＃163、＃640、および＃1018を参照してください。

これを修正するには、 https： //github.com/universal-ctags/ctags/issues/1275#issuecomment-274489859のようなものを実装する必要があります。

@ alphaCTzo7Gは＃1807を参照してください、それはあなたのためにそれを適切に修正しますか？

@ b4n 、迅速な対応に感謝します...

ここに投稿したファイル_identifier.pyで、＃1805コミットを使用して、 ctagsが任意の場所に無効な文字/カットを挿入しなくなりました。

今後数日間、このPRを実際のシステムで試して、リポジトリ全体で機能するか、他のエラーが発生するかを確認します。

ctrlpとctrlp-py-matcherは非常に人気のあるプラグインなので、＃1807をマージして、 vimや他のテキストエディタユーザーがctrlpとこの問題を心配することなくctrlp-py-matcher 。

vim.evalで問題を引き起こしていることがわかった別のファイルがあり、 grep -axv '.*' misc.html （https：/のmisc.htmlによって決定される無効なutf-8文字が含まれていました/github.com/alphaCTzo7G/test）。 私が気付いたのは、 ctagsが無効なutf-8文字をmisc.htmlからタグファイルに挿入することです。

ctagsがファイル内の無効な文字を検出し、代わりに@tonymecがここで提案したようなものに置き換えることは意味がありますか？ （無効なシーケンスを、まさにその目的を意図した文字 （U + FFFD REPLACEMENT CHARACTER）の1つ以上のインスタンスに置き換えます。）： https ：

IIUC、ctags（あふれんばかりのctags、つまり、利用可能なctagsプログラムの1つにすぎません）は、Vimとは別に配布されます（作成者がBramを知っていても、Vimとctagsの連携を改善するために時折連携している場合でも）。

ctagsの観点からは、プログラムテキストを単なるバイト文字列として扱うことは正当です。UTF-8、Latin1、Latin9、またはその他のISO 8859文字セットであるかどうかに関係なく、スペースは0x20、ハードタブは0x09、改行は0x0Aであり、その前に0x0Dなどが続く可能性があります。 また、0x00になるヌルバイトはテキストファイルに表示されません。 Ctagsは、どのASCII互換エンコーディングで記​​述されているかに関係なく、すべてのプログラムを同じように扱うため、どれがどれであるかを気にする必要はありません。 EBCDICのような一部の風変わりな文字セットの場合のみ、テキストを完全に非ASCIIとして扱う必要があります（EBCDIC、IIRC、AIは0xC1-0xC9、JRは0xD1-0xD9、SZは0xE2-0xE9、0-9は0xF0-0xF9） 、およびスペース、タブ、改行、ダッシュ、アンダースコアなどのコードが何であるかは覚えていませんが、ASCIIの観点からは本当に風変わりであることがわかります）。

IMHO、ctagの場合、古き良き原則が適用されます：ガベージイン、ガベージアウト。

よろしくお願いします、
トニー。

@tonymec ..理にかなっています..他のタグ生成プログラムがあるかもしれないとuniversal-ctagsが最も人気があり、 universal-ctagsを使用している人々の間では大部分がvimユーザーです。

それで、これらの2つが機能するのではないか、または不正なutf-8文字を含むファイルを処理する方法について他のアイデアがあるかどうか疑問に思います。

1. また、 ctagsは+iconvこのオプションがあり、 libiconv使用が可能になっていることにも気づきました。 コマンドラインで使用すると、 iconvは不正なutf8文字を削除できます。 したがって、 --input-enconding=utf-8と--output-encoding=utf-8を渡すと、すべての不正なutf-8文字が有効なutf-8文字に変更されるのではないかと思います。

これはhttps://media.readthedocs.org/pdf/ctags/latest/ctags.pdfのセクション1.3.4で説明されてい

Two new options have been introduced (--input-encoding=IN and --output-encoding=OUT). Using the encoding specified with these options ctags converts input from IN to OUT. ctags uses the converted strings when writing the pattern parts of each tag line. As a result the tags output is encoded in OUT encoding. In addition OUT is specified at the top the tags file as the value for the TAG_FILE_ENCODING pseudo tag. The default value of OUT is UTF-8. NOTE: Converted input is NOT passed to language parsers. The parsers still deal with input as a byte sequence. With --input-encoding-<LANG>=IN, you can specify a specific input encoding for LANG. It overrides the global default value given with --input-encoding

1. 不正なutf8文字を処理するのは、エディターに任せてください。 その場合、 vim.evalを修正するか、 vim.evalに渡す前に不正なutf-8文字を解析して削除できるvimL関数が必要です。 vim.eval ..

alphaCTzo7G I @tonymecと彼の結論に同意します。

残念ながら、適切なエンコーディングを認識するのは非常に困難です-そして私は適切であると主張します。なぜなら、入力が技術的に有効であるエンコーディングを見つけるのは簡単だからです。すべてではないにしてもほとんどの8ビットエンコーディングはそうですが、それが正しいかどうかはわかっています。 1つはトリッキーまたは不可能です。たとえば、ISO 8859-1と8859-15の間でどのように確認できますか？ ソリューションには、使用頻度とコンテキストに関する複雑なヒューリスティックが含まれます。 または、HTMLなどの一部の言語に適用できるより単純なアイデアは、ファイル内のエンコーディングステートメントを抽出することですが、それも同様に正しくない可能性があります。

また、 ctagsはここでは難しい位置にあります。ほとんどではないにしても、多くのコンシューマーはエンコードを処理せず、生成されたタグはバイトレベルで一致する必要があります。 たとえば、タグパターンや名前をgrepしてもエンコーディングは変換されないため、タグはバイトレベルでファイルと一致する必要があります。 ASCIIだけを気にする必要があったときは簡単でしたが、もうそれほど幸運ではありません…UTF-8は十分に早く採用されませんでした。
これは、プレースホルダー文字に置き換えるという考えにも当てはまります。消費者は、そのような置換文字で何ができるでしょうか。 少なくとも特定の方法で処理する必要があります。

ただし、無効なUTF-8をU + FFFDに置き換えたり、削除したりすることに満足している場合は、ctagsの出力を後処理するだけでよいでしょうか。

@ b4n 、コメントutf-8エンコードされたファイルを扱い、作成したファイル用にutf-8エンコードしています。 残念ながら、あなたが言ったように、私は時々任意のエンコーディングを持つ傾向があるライブラリを使用します。

私はvim-gutentagsを使用していますが、後処理機能を提供します。 タグファイルを手動で後処理してすべてのファイルをutf-8文字にすることはできましたが、 vim-gutentagsでpost-processing機能を使用しようとすると、機能しませんでした。 。 ですから、もっと堅牢な解決策を見つけたほうがいいのではないかと思いました。しかし、それが存在しない場合は、もう一度調査する必要があります。

ファイルのエンコーディングを検出するには、次のいずれかのオプションの背後にある基盤となるライブラリを使用できません： https ：

enca 、 file 、 uchardet 、 enguess ？ これらはすべてコマンドラインユーティリティです。しかし、おそらくctags内部で使用できるライブラリがどこかにあるはずです。 私の推測では、エンコーディングの数が原因で、おっしゃるように、エンコーディングを完全に予測することは不可能かもしれませんが、そのほとんどをカバーする単純なソリューションの方が、何もないよりはましかもしれません。

--input-encoding (and/or --input-encoding-<LANG>) and --output-encoding optionsを試してみます.. ctags理解しない限り、特定のファイルが同じリポジトリ内で異なるエンコーディングを持つ可能性が非常に高いため、常に機能するかどうか--input-encoding (and/or --input-encoding-<LANG>) and --output-encoding optionsわかりません。エンコードを個別に修正し、目的の形式で吐き出します。