Zwei Dinge machen die Beantwortung dieser scheinbar einfache Frage kompliziert:
Der Begriff "EBNF" hat eine große Vielfalt von Erscheinungsformen. Es gibt den ISO-Standard ISO/IEC 14977:1996 für "Extended BNF", aber soweit ich weiß, wird er selten in der Praxis verwendet. (Hinweis: Es gibt einen kostenlosen Download-Link auf dieser Seite; Kauf ist nicht erforderlich.) Viele Internetprotokolle verwenden "Augmented BNF" wie von RFC 5234 definiert, die wahrscheinlich besser für Ihr spezielles Problem passt. Und es gibt viele Parser-Generatoren, die BNF auf verschiedene Arten erweitern, im Allgemeinen durch Hinzufügen von regulären Ausdruck-ähnlichen Wiederholungs- und Optionsoperatoren, ohne in irgendeiner Weise standardisiert zu sein. (Tatsächlich war es dieses Chaos der möglichen Definitionen, das die ISO dazu veranlasste, einen Standard zu erstellen, aber wie es oft bei ISO-Standards der Fall ist, fehlender kostenloser Textzugang - bis zu einem Jahrzehnt nach seiner Veröffentlichung - und frei verfügbar Werkzeuge behindern Annahme.)
reguläre Ausdrücke nicht notwendigerweise eindeutige Grammatiken erzeugen, und der reguläre Ausdruck Sie ist nicht eindeutig liefern, da $ erlaubt ist, als ein gewöhnliches Zeichen verwendet werden. Die Implikation (und, ich bin mir sicher, die Absicht) ist, dass ein $ nicht als ein reguläres Zeichen behandelt werden kann, wenn es von einem anderen $ oder einer von geschweiften Klammern umgebenen Zahl gefolgt wird, aber der reguläre Ausdruck selbst nicht (und muss nicht) diese Unterscheidung machen. Weniger offensichtlich ist, was die Absicht wie für eine Zeichenfolge sein könnte:
${42 looks like an error to me but it would be accepted by the regex.
Wie auch immer, hier ist ein ISO-EBNF für etwas ähnliches wie Ihre Sprache. Beachten Sie, dass es nicht akzeptiert die obige Zeichenfolge.
(* EBNF does not have wildcard characters and there is no way to
enumerate all possible characters, so I use the exception mechanism
to describe the set
*)
any character
= ? Any character representable by the source character encoding ? ;
decimal digit
= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9';
literal sequence
= {any character} -
({any character}, ('$$' | '${'), {any character}) ;
escaped dollar
= '$$' ;
parameter
= '${', decimal digit, {decimal digit}, '}';
thingamajig
= {literal sequence | escaped dollar | parameter}
Im Großen und Ganzen, da man für die Flucht Dollar-Zeichen einen Mechanismus bereitstellen, wäre es wahrscheinlich einfacher sein, die Verwendung von losen Dollar-Zeichen nur zu verbieten. Das macht die Spezifikation und den Parser einfacher und vermeidet das Problem von nicht-kanonischen Darstellungen.(Nicht-kanonische Repräsentationen können ein Sicherheitsproblem darstellen, weil das Ausrunden einer Zeichenfolge in eine interne Repräsentation und zurück dann die Überprüfung der Fingerabdrücke nicht mehr möglich macht und Informationslecks ermöglichen. Diese sind in diesem Fall möglicherweise nicht signifikant, aber im Allgemeinen die beste Praxis Bei Datenaustauschprotokollen sollten möglichst nicht-kanonische Repräsentationen vermieden werden.)
Haben Sie vor, das '.' in dieser Regex einem' $ 'zuzuordnen? (Damit ist die Zeichenkette '$ a $ 42 'akzeptabel?) (Wenn ja, ist das * lexikalisch *. *') – rici
@rici könnte ich das tun, oder ich könnte einen Fehler machen. Für diesen speziellen Anwendungsfall sollte '.'' .' sein, nicht '[^ $]'. – SoniEx2
Wenn Sie wirklich '.' meinen, dann wird die Syntax (aber nicht die semantische Struktur) genau durch'. * 'Beschrieben, was in EBNF etwas wie' {beliebiges Zeichen} 'wäre. Aber wahrscheinlich wollen Sie das semantische Parsing wirklich beschreiben. In diesem Fall müssen Sie durch einige Ringe springen, um eine eindeutige Grammatik zu erstellen. Oder du könntest einfach lose Dollarzeichen als Fehler ablehnen :) – rici