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

Мы обрабатываем исходный код японского языка COBOL IBMEnterprise.

Правила, которые точно описывают, что разрешено в литералах типа 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>"

где <имя> - это макрос, который является другим регулярным выражением. Предположительно они названы достаточно хорошо, чтобы вы могли догадаться, что они содержат.

Вот справочник IBM Enterprise COBOL. Глава 3 "Символьные строки", подзаголовок "Литералы DBCS" на стр. 32 является подходящим прочтением. Я надеюсь, что, предоставив точную ссылку, опытный IBMer может рассказать нам, как мы ее неправильно истолковали:-{Мне особенно непонятно, что означает фраза "символы DBCS", когда она говорит "один или несколько символов в диапазоне". X'00...X'FF для любого байта "Как символы DBCS могут быть чем угодно, кроме пар 8-битных кодов символов? Существующий RE соответствует 3 типам пар символов, если вы изучите его.

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

Точно так же идентификаторы COBOL могут быть составлены из символов DBCS. Что конкретно разрешено для идентификатора? Опять же, регулярное выражение будет идеальным.

EDIT2: я начинаю думать, что проблема может быть не в RE. Мы читаем Shift-JIS кодированный текст. Наш читатель конвертирует этот текст в Unicode по мере необходимости. Но символы DBCS на самом деле не Shift-JIS; скорее это двоичные данные. Вероятно, происходит то, что данные DBCS переводятся так, как если бы это был Shift-JIS, и это испортило бы способность распознавать "два байта" как элемент DBCS. Например, если пара символов DBCS была:81:1F, считыватель ShiftJIS преобразует эту пару в один символ Unicode, и его двухбайтовая природа будет потеряна. Если вы не можете сосчитать пары, вы не можете найти конечную цитату. Если вы не можете найти конечную цитату, вы не можете распознать литерал. Таким образом, проблема может заключаться в том, что нам нужно переключать режимы кодирования ввода в середине процесса лексирования. ЮК.

Источник

2 ответа

Решение

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

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

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

РЕДАКТИРОВАТЬ: Я думал, что у вас все другие литералы DBCS работают и просто возникают проблемы с G-строкой, поэтому я просто указал на разницу между N и G. Теперь я более внимательно посмотрел на ваш RE. У него есть проблемы. В Коболе, который я использовал, вы можете смешать ASCII с японским, например,

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

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

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

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

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

Источник

Включает ли одинарные и двойные кавычки или только апострофы? Это было бы проблемой, так как оно потребляло бы буквальную последовательность закрывающих символов>' ...

Я бы проверил определение всех других макросов, чтобы убедиться. Единственная очевидная проблема, которую я вижу, это , о которой вы, похоже, уже знаете.

Источник
Другие вопросы по тегам