2

私はRegexKitLiteを使用しています。RegexKitLiteはエンジンとしてICUを使用しています。ドキュメントにもかかわらず、「xxxxxxxxxxx」に対して検索するときの/ x*/のような正規表現は空の文字列と一致します。/ x *？/のように動作します。このバグが存在する場合は回避したいと思います。正規表現の一致で長さが0の結果が返される場合は、エスケープされていない*を+として書き直すことを検討しています。私の素朴な推測では、*sの代わりに+sを使用した正規表現は、常に正しい結果のサブセットを返します。これの予期しない結果は何ですか？私は正しい方向に進んでいますか？

FWIW、ICUは* +演算子も提供しますが、どちらも機能しません。

編集：もっと明確にすべきでした：これはインタラクティブアプリの検索フィールド用です。ユーザーが入力する正規表現を制御することはできません。壊れた*サポートはICUのバグのようです。そのPOSをコードに含める必要がなかったらいいのにと思いますが、町で唯一のゲームです。

4

4 に答える 4

1

*すべての数量詞を単にに変更する+と、正規表現は、がゼロオカレンスに一致する* はずのインスタンスでは機能しなくなります。言い換えれば、問題は常にゼロと一致するものから、ゼロと一致しないものへと変化します。あなたが私に尋ねるなら、それはどちらにしても役に立たない。

ただし、ネガティブな先読みで、発生ゼロのケースを個別に処理できる場合があります。たとえば、x*として書き直すことができます(?:(?!x)|x+)。それは私が知っている恐ろしいことですが、それは私が現時点で想像できる最も自己完結型の修正です。所有格の星（*+）に対してもこれを行う必要がありますが、嫌がる星（*?）に対してはこれを行う必要はありません。

ここにそれは表形式です： 

ビフォアーアフター
x *（？:( ?! x）| x +）
x * +（？:( ?! x）| x ++）
バツ*？バツ*？
より複雑な原子は、独自の括弧を保持する必要があります。 
（？：xyz）*（？：（？！（?: xyz））|（?: xyz）+）
あなたはおそらくそれらを先読みの中に落とすことができますが、それらは読みやすさ以外は何も傷つけません、そしてそれはとにかく失われた原因です。：D{min,}および{min,max}フォームも影響を受ける場合、それらは同じ扱いを受けます（所有格のバリアントに対して同じ変更が加えられます）。

x {0、}         x * 
x {0、n }と同じ（？:( ?! x）| x {1、n }）

条件(?(condition)yes-pattern|no-pattern)文がここにぴったりだと思います。残念ながら、ICUはそれらをサポートしていないようです。

于 2011-02-13T00:31:46.447 に答える
1

問題のコードのどこで問題が発生したかはわかりませんが、この特定のバグはICUライブラリにはないことを確信できます。（私はICU正規表現パッケージの作成者です。）

私は上記の感情に同意します。やるべきことは、正規表現パターンを微調整して問題をハックしようとするのではなく、根本的な問題が何であるかを理解することです。提起された元の質問からは明らかではない、いくつかの単純な間違いが行われている可能性があります。

于 2011-02-24T00:46:39.700 に答える
0

\*とは両方とも[*]文字通りのアスタリスクであるため、単純な置換は機能しない可能性があります。

実際、動的な書き換えは行わないでください。複雑すぎます。最初に正規表現を静的に微調整してみてください。

x*x{0,}およびと同等(?:x+)?です。

于 2011-02-12T22:32:41.557 に答える
0

ええ、その戦略を使用してください:(
擬似コード）

if（$ str =〜/ x * / && $ str =〜/（x +）/）{print "'$ 1'\ n"; }

しかし、本当の問題はあなたが言うようにバグです。なぜ地球上で数量詞の基本的な構成が台無しになっているのですか？これは、コードに含める必要のあるモジュールではありません。

于 2011-02-12T23:48:43.017 に答える