11

IBMEnterpriseJapaneseCOBOLソースコードを処理しています。

Gタイプのリテラルで何が許可されているか、および識別子に何が許可されているかを正確に説明する規則は明確ではありません。

IBMのマニュアルによると、G'....'リテラルには、引用符内の最初の文字としてSHIFT-OUTが必要であり、終了引用符の前の最後の文字としてSHIFT-INが必要です。私たちのCOBOLレクサーはこれを「認識」していますが、実際のコードで見つかったGリテラルに反対しています。結論：IBMのマニュアルが間違っているか、誤解しています。お客様はコードを見せてくれないので、問題を診断するのはかなり難しいです。

編集：明確にするためにテキストの下で改訂/拡張：

Gリテラル形成の正確なルールと、それらがIBMリファレンスマニュアルの内容とどのように一致するか（一致しないか）を知っている人はいますか？理想的な答えは、Gリテラルの正規表現です。これは私たちが現在使用しているものです（別の作者、ため息によってコード化されています）：

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

ここで、<name>は別の正規表現であるマクロです。おそらくそれらは十分に名前が付けられているので、それらが何を含んでいるかを推測することができます。

これがIBMEnterpriseCOBOLリファレンスです。第3章「文字列」、32ページの「DBCSリテラル」の小見出しは関連する読み物です。正確なリファレンスを提供することで、経験豊富なIBM社員がそれをどのように誤解したかを教えてくれることを願っています：-{「範囲内の1つ以上の文字」と書かれている場合、「DBCS文字」というフレーズが何を意味するのか特にわかりません。 X'00 ... X'FF for which byte "DBCS文字は、8ビット文字コードのペア以外のどのようになりますか？既存のREは、調べてみると3種類の文字のペアに一致します。

以下の1つの答えは、<squote><squote>のペアリングが間違っていることを示しています。OK、私はそれを信じるかもしれませんが、それはREが単一の<squote>を含むリテラル文字列のみを拒否することを意味します。Gリテラルのすべてのインスタンスにつまずくように見えるので、それが私たちが抱えている問題だとは思いません。

同様に、COBOL識別子は明らかにDBCS文字で構成できます。正確には、識別子には何が許可されていますか？ここでも、正規表現が理想的です。

EDIT2：問題はREではないかもしれないと私は考え始めています。Shift-JISでエンコードされたテキストを読んでいます。私たちの読者は、そのテキストをUnicodeに変換します。ただし、DBCS文字は実際にはShift-JISではありません。むしろ、それらはバイナリコード化されたデータです。おそらく、DBCSデータがShift-JISであるかのように変換され、「2バイト」をDBCS要素として認識する機能が台無しになっている可能性があります。たとえば、DBCS文字ペアが：81：1Fの場合、ShiftJISリーダーはこのペアを単一のUnicode文字に変換し、その2バイトの性質は失われます。ペアを数えられない場合は、最終見積もりを見つけることができません。終了引用符が見つからない場合は、リテラルを認識できません。したがって、問題は、字句解析プロセスの途中で入力エンコーディングモードを切り替える必要があることであるように思われます。ユク。

4

2 に答える 2

2

ルールに一重引用符を追加して、この変更を行って合格するかどうかを確認してください。

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

私の記憶が正しければ、N リテラルと G リテラルの違いの 1 つは、G では一重引用符が使用できることです。あなたの正規表現はそれを許可していません。

編集: 他のすべての DBCS リテラルが機能していて、G 文字列に問題があるだけだと思ったので、N と G の違いを指摘しました。RE を詳しく調べました。問題があります。私が使用した Cobol では、たとえば、ASCII と日本語を混在させることができます。

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

RE は DBCS のみを想定しています。この制限を緩めて、もう一度やり直します。

G リテラルを完全に正規表現で処理することはできないと思います。有限ステート マシンだけでは、クオートと SO/SI の一致を追跡する方法はありません。あなたの RE は、不可能なことをしようとしているのでとても複雑です。単純化して、トークンの不一致を手動で処理します。

エンコーディングの問題に直面する可能性もあります。コードは EBCDIC (カタカナ) または UTF-16 である可能性があり、ASCII として扱うと機能しません。SO/SI は、Windows で 0x1E/0x1F に変換されることがあります。

私はあなたが実際のコードを見ずに暗闇で撮影するのを手伝おうとしています:)

于 2009-09-15T01:50:30.760 に答える