2

まず、私の意図を述べます。難読化されている可能性のある10桁の電話番号の解析ルールを作成しようとしています。だから、次のようなケースを想像してみてください"callmeNOW...555___555____5555!"

私が始めようと思った場所は、ウィキペディアの有効な市外局番のリストです。次に、これらをパイプ区切りの文字列に変換します。私が探している解析ルールとして使用しTOます。

その後、次の10桁を読んでみようと思いました。しかし、私が機能すると期待していた概念実証は機能しませんでした。

>> digit: charset "0123456789"
== make bitset! #{000000000000FFC0}

>> parse "callmeNOW...555___555____5555!" [10 [thru digit] to end]
== false

私が望んでいたことを実行できなかった、より単純なテストに私を導きます：

>> parse "5" [thru digit]
== false

THRUで使用しない場合は、期待どおりの動作をします。

>> parse "5" [digit]
== true

トークンとして使用した場合にビットセットがサポートされるのに、TOまたはではサポートされないのはなぜTHRUですか？

PS誰かがそれを望むなら、ここにRebolブロックとしての市外局番のリストがあります...

valid-area-codes: [
    205 251 256 334 659 938 907 250 480 520 602 623 928 327 479 501 870
    209 213 310 323 341 369 408 415 424 442 510 530 559 562 619 626 627
    628 650 657 661 669 707 714 747 760 764 805 818 831 858 909 916 925
    935 949 951 303 719 720 970 203 475 860 959 302 202 239 305 321 352
    386 407 561 689 727 754 772 786 813 850 863 904 941 954 229 404 470
    478 678 706 762 770 912 808 208 217 224 309 312 331 447 464 618 630
    708 730 773 779 815 847 872 219 260 317 574 765 812 319 515 563 641
    712 316 620 785 913 270 364 502 606 859 225 318 337 504 985 207 227
    240 301 410 443 667 339 351 413 508 617 774 781 857 978 231 248 269
    313 517 586 616 679 734 810 906 947 989 218 320 507 612 651 763 952
    228 601 662 769 314 417 557 573 636 660 816 975 406 308 402 531 702
    775 603 201 551 609 732 848 856 862 908 973 505 575 212 315 347 516
    518 585 607 631 646 716 718 845 914 917 929 252 336 704 828 910 919
    980 984 701 216 234 283 330 380 419 440 513 567 614 740 937 405 539
    580 918 458 503 541 971 215 267 272 412 445 484 570 582 610 717 724
    814 835 878 401 803 843 864 605 423 615 731 865 901 931 210 214 254
    281 325 361 409 430 432 469 512 682 713 737 806 817 830 832 903 915
    936 940 956 972 979 385 435 801 802 276 434 540 571 703 757 804 206
    253 360 425 509 564 304 681 262 274 414 534 608 715 920 307
]
4

3 に答える 3

1

もちろん、R3はparseビットに沿って移動しますが、通常のパターンは、補完的なビットセットを作成して、目的のセットでコンテンツをスキップすることです。

filler: complement digit: charset "0123456789"
parse/all stream [any [copy n some digit (append out: [] n) | some filler]]
probe out   ; all the digit chunks in the stream
于 2012-11-19T12:30:07.030 に答える
1

本当の答えは、TOとTHRUはパターンマッチング演算子ではなく、検索演算子であるということです。

文字セットは特にパターンマッチングに使用されるため、ビットマスクであるため、検索できず、ストリームに存在せず、一度に1バイトずつフィルタリングして比較します。これは、それらが将来TO / THRUに使用されるように作られないことを意味するのではなく、これまでそのように使用されることを意図されていなかった理由です。

「パイプルール」の例が機能する理由（実際には、OR（ "|"）操作を使用した選択肢のリスト）は、TO / THRUが、1つが一致するまで、指定された順序で各選択肢を検索するためです（したがって、順序は選択肢の長いリストで、速度を変更します）。

次のルールは、比較的整形式の電話番号をすべて抽出し、フォーム（R2およびR3）で「小刻みに動く部屋」を可能にします。

digit: charset "0123456789"
!digit: complement digit

parse/all text [   
    any [ 
        copy phone [ opt "(" 3 digit    1 3 !digit   3 digit    1 3 !digit    4 digit] (print phone)  
        |  skip 
    ] 
]

上記は、北米の電話用の迅速で汚い番号抽出装置であることに注意してください。テキスト全体をスキャンし、見つかった番号を印刷します。

于 2012-11-21T21:53:25.597 に答える
0

簡潔ではありませんが、数字セットをビットセットとして作成しない場合は！むしろパイプルールを使用すると、正常に機能します。

>> digit: ["0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"]
== ["0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"]

>> parse "callmeNOW...555___555____5555!" [10 [thru digit] to end]
== true
于 2012-11-19T10:57:30.897 に答える