Parsing 确定Cobol编码风格

我正在开发一个解析Cobol程序的应用程序。在这些程序中，有些程序尊重第8列至第72列中的传统编码样式的程序文本，有些程序较新，不遵循这种样式

在我的应用程序中，我需要确定编码样式，以便知道是否应该解析第72列之后的内容

我已经能够确定程序是从第1列还是第8列开始，但是从第1列开始的prog也可以遵循第72列之后的注释规则

所以我试图找到一些规则，让我能够确定第72列之后的文本是注释还是有效代码

我已经找到了一些，但很难说它是否每次都有效：

点在第72列之后，确定句子的结尾，但我担心点也会出现在评论中

在第72列之后查找语句的结束字符：'}

在第71-72-73列中查找char，如果没有空格，则查找整个单词，并检查它是关键字还是变量。问题是，它可能是来自副本或替换的变量等

我想知道您对这些规则的看法，以及您是否有任何想法来帮助我确定Cobol程序的编码风格

---

我不需要API或其他我可以依赖的可靠规则。

我认为您需要了解每个程序的COBOL编译器。它的文档应该告诉您它使用什么约定/配置/开关来决定源代码是否在第72列结束

所以。。。。哪些编译器

---

如果您认为第72列的问题是一个难题，请等到您真正开始解析COBOL本身。如果您没有做好处理该语言词汇问题的准备，那么您可能在处理语法问题方面准备得很差。

我认为您需要了解每个程序的COBOL编译器。它的文档应该告诉您它使用什么约定/配置/开关来决定源代码是否在第72列结束

所以。。。。哪些编译器

---

如果您认为第72列的问题是一个难题，请等到您真正开始解析COBOL本身。如果您没有做好处理该语言词汇问题的准备，那么您可能在处理语法问题时准备得很差。

没有一种算法可以100%确定地做到这一点，因为如果注释可以是任何东西，它们也可以是可编译的COBOL代码。因此，从理论上讲，如果注释被忽略，您可以编写一个程序，这意味着一件事，如果注释被视为COBOL的一部分，则完全意味着另一件事

但这是极不可能的。最有可能发生的情况是，如果您试图按照错误的约定编译代码，它将失败。因此，唯一正确的方法是尝试以一种方式编译/解析程序，如果遇到不合理的情况，请切换到另一种方式。您还可以支持在样式已知时将参数传递给编译器

您可以尝试使用您所描述的启发法，但这永远不会完全准确。他们最多能给你的是一种可能性，即代码是一种或另一种样式，这将随着他们检查越来越多的代码行而增加。它们可以帮助您在开始编译之前猜测样式，或者帮助您找出问题实际上只是代码中的输入错误

编辑： 关于启发法的想法，很难说。如果有像//或其他语言中的标准注释符号，这会容易得多，但听起来您的代码似乎不遵循此约定。我能想到的唯一一件事就是检查每一行或可能99%的行，不计算空行或用*注释的行是否在位置72之前有一个句点

您不想做的一件事是对位置72后的零件应用任何启发式。也就是说，您不希望检查注释以查看它们是否是有效的COBOL。您想先检查一下您知道的是COBOL，看看它本身是否有效。这有几个原因：

用英语写的评论中可能会有句号和引号，所以你的第一个和第二个要点就出来了。 自然语言比COBOL更难解析。 这些注释中很容易包含COBOL，可能有人注释掉了该行的前一个版本。 评论的一条重要规则是，它们永远不应该影响程序的功能。如果更改注释可以更改程序的编译方式，则违反了这一点。 所有这些，我的意见是你根本不应该使用启发式。除非明确指定了一种约定，否则应始终尝试在这两种约定下编译程序。在这两种约定下，代码都有可能成功编译，然后您将有两个不同的程序，无法判断哪一个是正确的

如果发生这种情况，您需要比较

---

e两个结果，可能是一个散列或什么，看看他们是否是同一个程序。如果它们是相同的，很好，但如果不是，则需要强制用户显式地选择约定。

没有一种算法可以100%确定地做到这一点，因为如果注释可以是任何内容，它们也可以是可编译的COBOL代码。因此，从理论上讲，如果注释被忽略，您可以编写一个程序，这意味着一件事，如果注释被视为COBOL的一部分，则完全意味着另一件事

但这是极不可能的。最有可能发生的情况是，如果您试图按照错误的约定编译代码，它将失败。因此，唯一正确的方法是尝试以一种方式编译/解析程序，如果遇到不合理的情况，请切换到另一种方式。您还可以支持在样式已知时将参数传递给编译器

您可以尝试使用您所描述的启发法，但这永远不会完全准确。他们最多能给你的是一种可能性，即代码是一种或另一种样式，这将随着他们检查越来越多的代码行而增加。它们可以帮助您在开始编译之前猜测样式，或者帮助您找出问题实际上只是代码中的输入错误

编辑： 关于启发法的想法，很难说。如果有像//或其他语言中的标准注释符号，这会容易得多，但听起来您的代码似乎不遵循此约定。我能想到的唯一一件事就是检查每一行或可能99%的行，不计算空行或用*注释的行是否在位置72之前有一个句点

您不想做的一件事是对位置72后的零件应用任何启发式。也就是说，您不希望检查注释以查看它们是否是有效的COBOL。您想先检查一下您知道的是COBOL，看看它本身是否有效。这有几个原因：

用英语写的评论中可能会有句号和引号，所以你的第一个和第二个要点就出来了。 自然语言比COBOL更难解析。 这些注释中很容易包含COBOL，可能有人注释掉了该行的前一个版本。 评论的一条重要规则是，它们永远不应该影响程序的功能。如果更改注释可以更改程序的编译方式，则违反了这一点。 所有这些，我的意见是你根本不应该使用启发式。除非明确指定了一种约定，否则应始终尝试在这两种约定下编译程序。在这两种约定下，代码都有可能成功编译，然后您将有两个不同的程序，无法判断哪一个是正确的

---

如果发生这种情况，您需要比较这两个结果，可能需要使用散列或其他方法来查看它们是否是同一个程序。如果它们是相同的，很好，但如果不是，则需要强制用户显式地选择约定。

没有绝对可靠的方法来确定是否使用COBOL程序 仅基于源代码的固定格式或自由格式。见鬼，有时很难识别 仅基于源代码的编程语言。退房 这个经典-它在8种不同的语言编译器下有效。那个 说，你可以尝试一些可能会产生 答案往往是正确的

嵌入在源代码中的编译器指令

注意确定代码格式的某些编译器指令。 不幸的是，每个编译器供应商都使用自己的指令风格

例如，Microfocus COBOL使用 SOURCEFORMAT指令。此指令将出现在程序顶部附近，以便进行短时间的预扫描 可以用来找到它。另一方面，OpenCobol使用>>源代码格式是免费的 >>源格式是固定的，用于在同一程序的不同部分的自由格式和固定格式之间切换 可以用不同的格式

这里的底线是，您必须支持多个COBOL编译器的约定

编译开关

还可以使用编译器开关指定源代码格式。在这种情况下，没有混凝土 继续下去的线索。但是，您可以合理地确定，整个源程序将 固定或免费。你能做的只是猜测。除非程序员想搞乱 你的头和一些将，一个自由格式的程序将有关键字识别部门或ID部门，在第8列之前开始。 每个COBOL程序都将以这些关键字开始，因此您可以使用它们作为确定程序中代码格式的锚点 缺少嵌入的编译器指令

---

警告-这远非易事，但可能是一个良好的开端。

没有绝对可靠的方法来确定COBOL程序是否正确 仅基于源代码的固定格式或自由格式。见鬼，这是什么时候 很难识别 仅基于源代码的编程语言。退房 这个经典-它在8种不同的语言编译器下有效。那个 说，你可以尝试一些可能会产生 答案往往是正确的

嵌入在源代码中的编译器指令

注意确定代码格式的某些编译器指令。 不幸的是，每个编译器供应商都使用自己的指令风格

例如，Microfocus COBOL使用 SOURCEFORMAT指令。此指令将出现在程序顶部附近，以便进行短时间的预扫描 可以用来找到它。另一方面，OpenCobol使用>>源代码格式是免费的 >>源格式是固定的，用于在同一程序的不同部分的自由格式和固定格式之间切换 可以用不同的格式

这里的底线是，您必须支持多个COBOL编译器的约定

编译开关

还可以使用编译器开关指定源代码格式。在这种情况下，没有混凝土 继续下去的线索。但是，您可以合理地确定，整个源程序将 固定或免费。你能做的只是猜测。除非程序员想搞乱 你的头和一些将，一个自由格式的程序将有关键字识别部门或ID部门，在第8列之前开始。 每个COBOL程序都将以这些关键字开始，因此您可以使用它们作为确定程序中代码格式的锚点 缺少嵌入的编译器指令

---

警告-这远非易事，但可能是一个好的开始。

大多数COBOL编译器都允许您生成和分析后文本操作阶段

可以使用OpenCOBOL查看文本预处理器的输出

cobc -E program.cob

---

文本处理处理器处理任何副本。。。替换编译器指令以及将源格式转换为编译器词法分析器所需的实际自由格式是固定的，包括行连续、字符串文字连接、注释行删除等。许多OpenCOBOL工具包交叉引用器和动画制作器，仅举两个例子，在预处理器通过后使用源代码。如果解析器程序依赖于后处理源代码文件，我认为您不会失去任何街头信誉。

大多数COBOL编译器将允许您生成和分析后文本操作阶段

可以使用OpenCOBOL查看文本预处理器的输出

cobc -E program.cob

---

文本处理处理器处理任何副本。。。替换编译器指令以及将源格式转换为编译器词法分析器所需的实际自由格式是固定的，包括行连续、字符串文字连接、注释行删除等。许多OpenCOBOL工具包交叉引用器和动画制作器，仅举两个例子，在预处理器通过后使用源代码。我不认为如果你的解析器程序依赖于后期处理的源代码文件，你会失去任何街头信誉。

@JerryCoffin你这么说是因为没有任何Cobol程序看起来是一样的：？我必须解析Cobol，所有不同的格式都是非常痛苦的。。。顺便说一句，如果你有任何想法，欢迎他们，谢谢@JerryCoffin你这么说是因为没有任何Cobol程序看起来是一样的：？我必须解析Cobol，所有不同的格式都是非常痛苦的。。。顺便说一句，如果你有任何想法，欢迎他们，谢谢！事实上，所有的程序都不使用同一个编译器，这就是问题所在。我已经完成了Cobol解析，我需要它能够正确解析词汇和语义级别。从现在起，我将根据Cobol项目更改一个变量以修复列限制，但现在我希望能够确定它，而不必自己输入它；那么你就知道应该应用什么约定了？是的，这可能是一个解决方案，但我无法访问每个程序的编译器选项，问题是：！对于其中一些，我必须打开它，阅读它，猜猜使用了什么选项。。。我想限制人的行为，只使用解析器来解决我的问题。好吧，那你就卡住了。如果您想要一个可靠的解决方案，只需尝试双向解析文件。如果不确定是哪种编译器，则需要为每个编译器方言提供完整的解析器。你显然至少有两个。COBOL的变化超出人们的预期；那可能要做很多工作。我刚刚投票支持今年的低调陈述！事实上，所有的程序都不使用同一个编译器，这就是问题所在。我已经完成了Cobol解析，我需要它能够正确解析词汇和语义级别。从现在起，我将根据Cobol项目更改一个变量以修复列限制，但现在我希望能够确定它，而不必自己输入它；那你就知道是什么了

---

要应用的选项？是的，这可能是一个解决方案，但我无法访问每个程序的编译器选项，问题是：！对于其中一些，我必须打开它，阅读它，猜猜使用了什么选项。。。我想限制人的行为，只使用解析器来解决我的问题。好吧，那你就卡住了。如果您想要一个可靠的解决方案，只需尝试双向解析文件。如果不确定是哪种编译器，则需要为每个编译器方言提供完整的解析器。你显然至少有两个。COBOL的变化超出人们的预期；那可能要做很多工作。我刚刚投票支持今年的低调陈述！这也是我想象的解决方案。我想我将不得不以这个结束。你有没有更多的启发建议？谢谢你的回答@阿兰·贾尼姆——也许吧。我有一个想法，还有几个注意事项。请看我的编辑。好的，实际上我已经使用了注释规则，但是它帮助我知道左对齐方式，而不是右对齐方式。最后，我使用了上面的启发式方法，当然还有更多的条件——正如你所说的，例外是可能的，它会给出非常好的结果！PS：为了澄清，我没有修改代码，也没有试图编译或执行代码，我只是对代码进行解析，以便能够绘制程序图，并分析语义错误或可能导致奇怪行为的事情。这也是我想到的解决方案。我想我将不得不以这个结束。你有没有更多的启发建议？谢谢你的回答@阿兰·贾尼姆——也许吧。我有一个想法，还有几个注意事项。请看我的编辑。好的，实际上我已经使用了注释规则，但是它帮助我知道左对齐方式，而不是右对齐方式。最后，我使用了上面的启发式方法，当然还有更多的条件——正如你所说的，例外是可能的，它会给出非常好的结果！PS：为了澄清，我没有修改代码，也没有试图编译或执行代码，我只是对代码进行解析，以便能够绘制程序图，并分析语义错误或可能导致奇怪行为的事物。@alain.janinm其他编译器指令或注释可能会在标识或ID关键字之前出现，但这是每个有效的COBOL程序开始时第一个实际的COBOL关键字。如果他们在第8列之前开始，源格式很可能是免费的，在第8列和第12列之间很可能是固定格式；有了上面的3个启发法，另一个启发法和经过调整的权重，我已经能够为大多数程序确定正确的代码样式，有了你的线索，在某些情况下我可能能够更快更准确地完成。我知道除法，我已经做过了，但它不能告诉我正确的限制是72，我有从第8列开始的程序，但没有遵守正确的限制。关于编译器指令的事实更有趣；多语言语言的例子很有趣：我从来没有见过这样的东西！幸运的是，我的程序并没有那么复杂。@alain.janinm标识或ID关键字可能会被其他编译器指令或注释所取代，但这些是每个有效COBOL程序开始时第一个实际的COBOL关键字。如果他们在第8列之前开始，源格式很可能是免费的，在第8列和第12列之间很可能是固定格式；有了上面的3个启发法，另一个启发法和经过调整的权重，我已经能够为大多数程序确定正确的代码样式，有了你的线索，在某些情况下我可能能够更快更准确地完成。我知道除法，我已经做过了，但它不能告诉我正确的限制是72，我有从第8列开始的程序，但没有遵守正确的限制。关于编译器指令的事实更有趣；多语言语言的例子很有趣：我从来没有见过这样的东西！幸运的是，我的程序没有那么复杂。