Японский код COBOL: правила для букв G и идентификаторов?

Мы обрабатываем исходный код IBMOnterprise Japanese COBOL.

Правила, которые точно описывают то, что разрешено в литералах типа G, и то, что разрешено для идентификаторов, неясно.

В руководстве IBM указано, что буква G '...' должен иметь SHIFT-OUT в качестве первого символа внутри кавычек, и SHIFT-IN как последний символ перед заключительной цитатой. Наш COBOL lexer "знает" это, но указывает на 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, и его двухбайтовая природа затем теряется. Если вы не можете считать пары, вы не можете найти конечную цитату. Если вы не можете найти конечную цитату, вы не можете распознать литерал. Таким образом, проблема возникла бы что нам нужно переключать режимы ввода-кодирования в середине процесса лексики. Юк.

Ответ 1

Попробуйте добавить одну цитату в свое правило, чтобы узнать, проходит ли она, сделав это изменение,

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

Если я правильно помню это, одно отличие между литералами N и G заключается в том, что G допускает одиночную кавычку. Ваше регулярное выражение не позволяет этого.

EDIT: Я думал, что у вас есть все другие литераторы DBCS, и у меня есть проблемы с G-строкой, поэтому я просто указал на разницу между N и G. Теперь я подробно рассмотрел ваш RE. У этого есть проблемы. В Cobol я использовал, вы можете смешивать ASCII с японским, например,

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

Вы принимаете только DBCS. Я бы освободил это ограничение и повторил попытку.

Я не думаю, что можно полностью обрабатывать литералы G в регулярном выражении. Невозможно отслеживать соответствие котировок и SO/SI с помощью конечного конечного автомата. Ваш RE настолько сложный, что он пытается сделать невозможное. Я бы просто упростил его и позаботился о несовпадении токенов вручную.

Вы также можете столкнуться с проблемами с кодировкой. Код может быть в EBCDIC (Katakana) или UTF-16, рассматривая его как ASCII, не будет работать. SO/SI иногда преобразуются в 0x1E/0x1F в Windows.

Я просто пытаюсь помочь вам стрелять в темноте, не видя фактического кода:)

Ответ 2

Делает ли <NotLineOrParagraphSeparatorNorApostropheNorShiftInNorShiftOut> также включают одинарные и двойные кавычки или просто апострофы? Это будет проблемой, так как она будет потреблять буквальную последовательность символов символов > '...

Я бы проверял определение всех других макросов, чтобы убедиться. Единственная очевидная проблема, которую я вижу, - это & lt; squote > <squote> о котором вы, похоже, уже знаете.