日本COBOL代碼：G文字和標識符的規則？

我們正在處理IBMEnterprise日本COBOL源代碼。日本COBOL代碼：G文字和標識符的規則？

準確描述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>是一個宏，是另一個正則表達式。推測他們被命名的不錯，所以你可以猜出它們包含的內容。

這裏是IBM Enterprise COBOL Reference。第3章「字符串」，子標題「DBCS文字」第32頁是相關閱讀。我希望通過提供確切的參考信息，有經驗的IBMer可以告訴我們如何誤讀它： - {我對DBCS字符「短語」意思是，當它說「」中的一個或多個字符時特別不清楚在範圍X'00 ... X'FF的任一字節「 DBCS-字符除8位字符代碼的對以外什麼都可以？如果您檢查它，現有的RE匹配3種類型的字符對。

下面的一個答案表明< squote> < squote>配對是錯誤的。好的，我可能會相信，但這意味着RE只會拒絕字符串包含單個< squote> s。我不認爲這是我們所遇到的問題，因爲我們似乎在G文字的每個實例上都會出現問題。

類似地，COBOL標識符可以明顯地由DBCS字符組成。準確地說，標識符允許什麼？正則表達式再次是理想的。

EDIT2：我開始認爲問題可能不是RE。我們正在閱讀Shift-JIS編碼文本。我們的讀者將該文本轉換爲Unicode。但是DBCS字符確實是而不是Shift-JIS;相反，它們是二進制編碼的數據。可能發生的情況是DBCS數據被翻譯爲，就好像它是Shift-JIS一樣，並且這會消耗將「兩個字節」識別爲DBCS元素的能力。例如，如果DBCS字符對是81：1F，則ShiftJIS讀取器會將此對轉換爲單個Unicode字符，然後其雙字節特性丟失。如果您不能計算對，則可以找到，但找不到結束引用。如果找不到結束語，您無法識別文字。所以問題會出現，因爲我們需要在lexing進程的中間中切換輸入編碼模式。育。

來源

2009-09-09 Ira Baxter

嘗試在你的規則添加一個單引號，看它是否經過此更改，

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

如果我沒有記錯的話，N和G文字之間的一個區別是，G允許將單引號。你的正則表達式不允許這樣做。

編輯：我以爲你得到所有其他的DBCS文字工作，只是有G字符串的問題，所以我只是指出了N和G之間的區別。現在我仔細看看你的RE。它有問題。在我使用的Cobol中，可以混合使用ASCII和日語，例如，

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

您只承認DBCS。我會放鬆這個限制，然後再試一次。

我不認爲有可能完全在正則表達式中處理G文字。只有有限的狀態機，沒有辦法跟蹤匹配的報價和SO/SI。你的可再生能源是如此複雜，因爲它試圖做不可能的事情。我只是簡化它並手動處理不匹配的令牌。

你也可能面對編碼問題。代碼可以是EBCDIC（片假名）或UTF-16，將其視爲ASCII將不起作用。在Windows上，SO/SI有時會轉換爲0x1E/0x1F。

我只是想幫助你在黑暗中拍攝，沒有看到實際的代碼:)

來源

2009-09-15 01:50:30

你的意思是作爲開頭或closng報價？ midstring中的squote對旨在表示中間字符串中的一個squote，而不是開頭或結尾處的一個。我會仔細檢查語法，但你確定嗎？ – 2009-09-15 02:51:40

根據我的記憶，你不需要在G字符串中轉義midstring引號。對於N字符串，您需要將其加倍，以便您的規則適用於N字符串。幾年前我把手冊扔掉了，所以我無法證實這一點。 – 2009-09-15 03:11:55

啊，光明即將來臨。爲了幫助你，我已經指出了手冊，以便你可以再次閱讀 grin;我也重組了RE，我必須讓它更容易理解，但沒有改變它。這些手冊在G文字中的引號非常安靜，但它顯然沒有說它們應該翻倍，所以我會承擔你的權利（剔！）。對我的修改文本有什麼進一步的意見？ – 2009-09-15 04:28:30

是否<NotLineOrParagraphSeparatorNorApostropheNorShiftInNorShiftOut>還包括單，雙引號，或只是撇號？這將是一個問題，因爲它會消耗文字結束字符序列>'...

我會檢查所有其他宏的定義以確保。我可以看到的唯一明顯的問題是您已經知道的<squote> <squote>。

來源

2009-09-15 15:29:27 lcv

這是〜[\ u000d \ u000a \ u0028 \ u2000 \ u000e \ u000f]。它不能消耗關閉< squote>。 – 2009-09-15 19:56:55

「這是否應該只匹配G型'< ... >'或G型」< ... >「的常量？ – lcv 2009-09-16 11:43:26

是的，對於G」<....>「有一個類似的問題，如果我得到一個正確的其他很容易修復 – 2009-09-17 07:28:23

日本COBOL代碼：G文字和標識符的規則？

回答

相關問題