Japanischer COBOL-Code: Regeln für G-Literale und Bezeichner?

Question

Wir verarbeiten IBMEnterprise japanischen COBOL-Quellcode.

Die Regeln, die genau beschreiben, was in G-Typ-Literalen erlaubt ist, und was für Bezeichner erlaubt sind, sind unklar.

Das IBM Handbuch gibt an, dass ein G ‚....‘ wörtliche ein SHIFT-OUT als erstes Zeichen innerhalb der Anführungszeichen haben muss, und ein SHIFT-IN als das letzte Zeichen vor dem letzten Zitat. Unser COBOL-Lexer "weiß" dies, aber Objekte zu G-Literalen gefunden in realem Code. Fazit: Das IBM Handbuch ist falsch, oder wir lesen es falsch. Der Kunde wird uns den Code nicht sehen lassen, so dass es ziemlich schwierig ist, das Problem zu diagnostizieren.

EDIT: Überarbeitete/erweitert unten Text für Klarheit:

Kennt jemand die genauen Regeln von G wörtlichen Bildung, und wie sie (nicht) entsprechen, was die IBM-Referenzhandbücher sagen? Die ideale Antwort wäre ein regulärer Ausdruck für das G-Literal. Dies ist, was wir jetzt verwenden (von einem anderen Autor codiert, seufz):

#token non_numeric_literal_quote_g [STRING] 
    "<G><squote><ShiftOut> ( 
    (<NotLineOrParagraphSeparatorNorShiftInNorShiftOut>|<squote><squote>|<ShiftOut>) 
    (<NotLineOrParagraphSeparator>|<squote><squote>) 

    | <ShiftIn> (<NotLineOrParagraphSeparatorNorApostropheNorShiftInNorShiftOut>| 
        <ShiftIn>|<ShiftOut>) 

    | <squote><squote> 

)* <ShiftIn><squote>" 

wo < name> ist ein Makro, das ein anderer regulärer Ausdruck ist. Vermutlich sind sie gut genug benannt, so dass Sie raten können, was sie enthalten.

Hier ist die IBM Enterprise COBOL Reference. Kapitel 3 "Zeichenketten", Zwischenüberschrift "DBCS-Literale" Seite 32 ist relevant. Ich hoffe, dass ein erfahrener IBMer uns durch die genaue Referenz sagt, wie wir ihn falsch gelesen haben: - {Ich bin besonders unklar, was der Ausdruck "DBCS-Zeichen" bedeutet, wenn "ein oder mehrere Zeichen" steht im Bereich X'00 ... X'FF für jedes Byte " Wie können DBCS-Zeichen alles andere als Paare von 8-Bit-Zeichencodes sein? Das vorhandene RE stimmt mit drei Typen von Zeichenpaaren überein, wenn Sie es untersuchen.

Eine Antwort unten schlägt vor, dass die < squote> < squote> Paarung falsch ist. OK, ich könnte das glauben, aber das bedeutet, die RE würde nur Literalstrings zurückweisen, die einzelne < Squote> s enthalten. Ich glaube nicht, dass das das Problem ist, das wir haben, wie wir scheinen, über jede Instanz eines G-Literals zu stolpern.

In ähnlicher Weise können COBOL-IDs mit mit DBCS-Zeichen zusammengesetzt werden. Was genau ist für eine Kennung erlaubt? Wieder wäre ein regulärer Ausdruck ideal.

EDIT2: Ich fange an zu denken, dass das Problem nicht der RE sein könnte. Wir lesen Shift-JIS-kodierten Text. Unser Leser konvertiert diesen Text in Unicode, wie es geht. Aber DBCS-Zeichen sind wirklich nicht Shift-JIS; Sie sind vielmehr binär codierte Daten. Wahrscheinlich ist was passiert, ist, dass DBCS-Daten übersetzt werden, als ob es Shift-JIS wäre, und das würde die Fähigkeit "zwei Bytes" als ein DBCS-Element erkennen mist.Wenn zum Beispiel ein DBCS-Zeichenpaar wäre: 81: 1F würde ein ShiftJIS-Leser dieses Paar in ein einzelnes Unicode-Zeichen umwandeln, , und seine Zwei-Byte-Natur ist dann verloren. Wenn Sie Paare nicht zählen können, können Sie das Endzitat nicht finden. Wenn Sie das Endzitat nicht finden können, können Sie das Literal nicht erkennen. So würde das Problem erscheinen zu sein, dass wir die Eingabecodierungsmodi in der Mitte des Lexing-Prozesses wechseln müssen. Yuk.

Answer 1

Versuchen Sie, ein Apostroph in Ihrer Regel hinzufügen, um zu sehen, wenn sie durch diese Änderung geht,

<squote><squote> => <squote>{1,2} 

Wenn ich mich erinnere ist ein Unterschied zwischen N und G Literale richtig, dass G Apostroph erlaubt. Dein regulärer Ausdruck erlaubt das nicht.

EDIT: Ich dachte, Sie haben alle anderen DBCS-Literale arbeiten und nur Probleme mit G-String, so habe ich nur den Unterschied zwischen N und G hingewiesen. Jetzt habe ich genauer auf Ihre RE. Es hat Probleme. Im Cobol, das ich benutzte, können Sie ASCII mit Japaner mischen, zum Beispiel

Ihr RE übernimmt nur das DBCS. Ich würde diese Einschränkung verlieren und es erneut versuchen.

Ich glaube nicht, dass es möglich ist, G-Literale vollständig im regulären Ausdruck zu behandeln. Es gibt keine Möglichkeit, übereinstimmende Anführungszeichen und SO/SI mit einer endlichen Zustandsmaschine allein zu verfolgen. Dein RE ist so kompliziert, weil es versucht, das Unmögliche möglich zu machen. Ich würde es einfach vereinfachen und manuell auf fehlende Übereinstimmungen achten.

Sie könnten auch Probleme mit der Codierung haben. Der Code könnte in EBCDIC (Katakana) oder UTF-16 sein, wenn man ihn als ASCII behandelt, funktioniert das nicht. SO/SI werden manchmal unter Windows in 0x1E/0x1F konvertiert.

Ich versuche nur, Ihnen im Dunkeln schießen zu helfen, ohne den eigentlichen Code zu sehen :)

Answer 2

Hat <NotLineOrParagraphSeparatorNorApostropheNorShiftInNorShiftOut> auch Einzel- und Doppel Anführungszeichen oder Apostrophe nur? Das wäre ein Problem, da es die wörtliche schließende Zeichenfolge> '...

verbrauchen würde Ich würde die Definition aller anderen Makros überprüfen, um sicherzustellen. Das einzige offensichtliche Problem, das ich sehen kann, ist die <squote> <squote>, die Sie bereits zu wissen scheinen.