Japoński kodeks COBOL: zasady G literałów i identyfikatorów?

Question

Przetwarzamy japoński kod źródłowy COBOL IBMEnterprise.

Zasady, które opisują dokładnie to, co jest dozwolone w literałach typu G, i co jest dozwolone dla identyfikatorów, są niejasne.

Instrukcja IBM wskazuje, że literka G '.... " musi mieć SHIFT-OUT jako pierwszy znak wewnątrz cudzysłowu, i SHIFT-IN jako ostatni znak przed cytatem zamykającym. Nasz lexer COBOL "wie" to, ale sprzeciwia się literałom G znalezionym w prawdziwym kodzie. Wniosek: instrukcja IBM jest błędna, lub błędnie ją odczytujemy. Klient nie pozwala nam zobaczyć kodu, , więc dość trudno jest zdiagnozować problem.

EDIT: Revised/rozszerzony poniżej tekście dla jasności:

Czy ktoś wie dokładnie zasady G formacji dosłownym, i jak (nie) pasujące jakie podręczniki referencyjne IBM powiedzieć? Idealna odpowiedź byłaby wyrażeniem regularnym dla literału G. to co używamy teraz (oznaczonych przez innego autora, westchnienie):

#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>" 

gdzie < nazwa> jest makro, które jest kolejnym wyrażenie regularne. Prawdopodobnie są one nazywane na tyle dobrze, aby można było odgadnąć, co zawierają.

Oto IBM Enterprise COBOL Reference. Rozdział 3 "Ciągi znaków", podpozycja "Literały DBCS" strona 32 jest odpowiednim odczytem. Mam nadzieję, że dzięki dokładnemu odnośnikowi doświadczony IBMer może nam powiedzieć, jak błędnie go odczytaliśmy: - {Jestem szczególnie niejasny, co to wyrażenie "znaki DBCS" oznacza , gdy mówi "co najmniej jeden znak w zakresie X'00 ... X'FF dla każdego bajtu " W jaki sposób znaki DBCS mogą być tylko numerami par z 8-bitowymi kodami znaków? Istniejące RE pasuje do 3 typów par znaków, jeśli je przeanalizujesz.

Jedna z poniższych odpowiedzi sugeruje, że squote < squote> < squote jest nieprawidłowe. OK, mogę w to uwierzyć, ale oznacza to, że RE odrzuci tylko literałowe ciągi zawierające pojedynczą odmianę <. Nie wierzę, że to problem, który mamy, gdy wydajemy się potknąć o każde wystąpienie literału G.

Podobnie, identyfikatory COBOL mogą wyglądać na kompozycje ze znakami DBCS. Co jest dozwolone dla identyfikatora? Znowu wyrażenie regularne byłoby idealne.

EDIT2: Zaczynam myśleć, że problem może nie być RE. Czytamy tekst zakodowany w Shift-JIS. Nasz czytelnik konwertuje tekst na Unicode w niezmieniony sposób. Ale znaki DBCS są naprawdę nie Shift-JIS; raczej są to dane zakodowane binarnie. Prawdopodobnie jest to, że dane DBCS są tłumaczone tak, jakby były Shift-JIS, a to zmiażdży zdolność , aby rozpoznać "dwa bajty" jako element DBCS.Na przykład: , jeśli para znaków DBCS to: 81: 1F, czytnik ShiftJIS przekształci tę parę w pojedynczy znak Unicode, , a jego dwubajtowa natura zostanie następnie utracona. Jeśli nie możesz zliczyć par, , nie możesz znaleźć końcowej oferty. Jeśli nie możesz znaleźć końcowej oferty, , nie możesz rozpoznać literału. Tak więc pojawi się problem polegający na tym, że musimy zmienić tryb kodowania wejściowego w środku procesu leksykowania. Yuk.

Answer 1

Spróbuj dodać pojedynczy cytat w regule, aby zobaczyć, czy przechodzi przez tę zmianę,

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

Jeśli dobrze pamiętam, jedna różnica pomiędzy N i G literałów jest to, że G pozwala apostrof. Twoje wyrażenie regularne na to nie pozwala.

EDYTOWANIE: Myślałem, że masz wszystkie inne literały DBCS działające i właśnie problemy z G-stringiem, więc właśnie wskazałem różnicę między N i G. Teraz przyjrzałem się bliżej twojemu RE. Ma problemy. W COBOL kiedyś, można mieszać z japońskim ASCII, na przykład,

G"ABC<ｦｧｨ>" <> are Shift-out/shift-in 

ponownie zakłada tylko DBCS. Utraciłbym to ograniczenie i spróbuję ponownie.

Nie sądzę, że można obsługiwać literały G w całości w wyrażeniu regularnym. Nie ma sposobu, aby śledzić pasujące oferty i SO/SI z samą skończoną maszyną stanów. Twoje RE jest tak skomplikowane, ponieważ próbuje zrobić to, co niemożliwe. Po prostu uprościłbym to i ręcznie zaadresowałem tokeny niedopasowania.

Można również napotkać problemy z kodowaniem. Kod może znajdować się w EBCDIC (Katakana) lub UTF-16, traktując go jako ASCII nie będzie działać. SO/SI czasami są konwertowane na 0x1E/0x1F w systemie Windows.

jestem po prostu staramy się pomóc strzelać w ciemno, nie widząc rzeczywisty kod :)

Answer 2

Czy <NotLineOrParagraphSeparatorNorApostropheNorShiftInNorShiftOut> zawierać także pojedyncze i podwójne cudzysłowy, lub po prostu apostrof? Byłby to problem, ponieważ pochłaniałby literalną sekwencję zamykającą> "...

Chciałbym sprawdzić definicję wszystkich innych makr, aby się upewnić. Jedyny oczywisty problem, który widzę, to to, że zdajesz się już być świadomy.