4

たとえば、改行が混在するソースファイルをカウントできるアルゴリズムには、特定の説明 (正規表現などで難読化されすぎていない説明) が必要です。

'\r', '\n', '\r\n', '\n\r'

現在、次のアルゴリズムがあります。大丈夫ですか？：

  1. 最初の改行タイプの文字の「境界」に常にいるようにします。

  2. そのイベントで、現在のバイト文字を比較します。

3.1. '\n' の場合は、現在の行を終了して新しい行を開始するものとしてカウントします。

3.2. '\r' の場合、次の文字を読み取り (テキスト バッファーの制限を超えていない場合)、それが '\n' かどうかを確認します。そうであれば、'\r\n' 改行として数えます。

3.3. それが '\r' で、次の文字が '\n' でない場合、'\r' によって生成された改行として数えます。現在の行を終了としてマークし、それを新しい行の開始としてカウントします。

有用な場合は、Web ブラウザー間でコピー/貼り付けされたソース ファイル、および/またはさまざまな種類の改行を含む複数のファイルから追加されたソース ファイルの "移植性" を高める必要があり、必要な解析ツールがあります。すべてのケースで正しく堅牢な動作をするようにします。

4

1 に答える 1

2

そのアルゴリズムは、すべてのケースの 99.999% をカバーする必要があります。

ソースをテキスト モードではなくバイナリ モードで読み取って、これらの一部を'\n'.

作業している言語を指定しませんでした。C および C++ では、'\n'特定の値を持つことが保証されていないという点で、他のエスケープ文字とは異なることに注意してください。ほとんどの実装で ASCII 改行にマップされるのは事実ですが'\x0A'、コードの移植性を維持するために何かを使用する方が安全で明示的です。

改行には他にもいくつかのスキームがありましたが、それらは非常にまれです。Unicode には、もともと EBCDIC にあったファイルとの往復互換性のためのNEL文字があります (私が思うに)。Unicode ではLINE SEPARATORとPARAGRAPH SEPARATORも導入されましたが、これも改行文字として扱いたい場合があります。ただし、これらは非常にまれであり、ASCII の範囲外であるため、処理が複雑になる可能性があります。そのため、エンコーディングを知り、これらの問題に対処する準備ができている必要があります。

于 2012-04-12T00:08:55.360 に答える