Código COBOL japonés: reglas para literales e identificadores G?

Question

Estamos procesando el código fuente IBMEnterprise japonés COBOL.

Las reglas que describen exactamente lo que está permitido en los literales de tipo G, y lo que está permitido para los identificadores no están claros.

El manual IBM indica que un G '....' literal debe tener un desplazamiento a como el primer carácter dentro de las comillas, y un cambio -IN como el último carácter antes de la cotización de cierre. Nuestra lexer COBOL "sabe", pero se opone a los literales G se encuentran en código real. Conclusión: el manual de IBM está equivocado, o lo estamos malinterpretando. El cliente no nos deja ver el código, , por lo que es bastante difícil diagnosticar el problema.

EDIT: Revisado/extendida por debajo de texto para mayor claridad:

¿Alguien sabe las reglas exactas de la formación literal G, y cómo (no) coincide con lo que dicen los manuales de referencia de IBM? La respuesta ideal sería una expresión regular para el literal G. Esto es lo que estamos usando ahora (codificado por otro autor, suspiro):

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

donde < nombre> es una macro que es otra expresión regular. Es de suponer que tienen un nombre lo suficientemente bueno para que pueda adivinar lo que contienen.

Aquí es el IBM Enterprise COBOL Reference. El capítulo 3 "Cadenas de caracteres", subtítulo "literales DBCS" página 32 es una lectura relevante. Espero que al proporcionar la referencia exacta, un IBMer experimentado puede decirnos cómo lo leímos mal: - {No estoy particularmente claro sobre qué significa la frase "DBCS-characters" cuando dice "uno o más caracteres" en el rango X'00 ... X'FF, ya sea para byte"¿Cómo puede DBCS caracteres ser otra cosa que pares de códigos de caracteres de 8 bits? El RE existente concuerda con 3 tipos de pares de caracteres si lo examina.

Una respuesta a continuación sugiere que el < squote> < squote> el emparejamiento es incorrecto. bien, yo podría creer eso, pero eso significa que el RE sólo se rechazaría cadenas literales que contienen solo < squote> s. No creo que sea el problema que estamos teniendo ya que parece que tropezamos con cada instancia de un literal G.

Del mismo modo, los identificadores de COBOL aparentemente pueden estar compuestos con caracteres DBCS. ¿Qué se permite para un identificador, exactamente? Una vez más, una expresión regular sería ideal.

EDIT2: Estoy empezando a pensar que el problema podría no ser el RE. Estamos leyendo el texto codificado Shift-JIS. Nuestro lector convierte ese texto en Unicode como va. Pero los caracteres DBCS son realmente no Shift-JIS; más bien, son datos codificados en binario. probable que lo que está sucediendo es que los datos DBCS se está traducido como si fuera Shift-JIS, y que podría arruinar definitivamente la capacidad de reconocer "dos bytes" como elemento DBCS.Por ejemplo, si un par de caracteres DBCS fuera: 81: 1F, un lector ShiftJIS convertiría este par en un único carácter Unicode, y su naturaleza de dos bytes se perderá. Si no puede contar pares, no puede encontrar la cotización final. Si no puede encontrar la cotización final, , no puede reconocer el literal. Por lo tanto, el problema sería al ser que necesitamos cambiar los modos de codificación de entrada en el medio del proceso de lexing. Yuk.

Answer 1

intenta agregar una comilla simple en su estado para ver si se pasa al hacer este cambio,

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

Si recuerdo correctamente, una diferencia entre N y G literales es que G permite comilla simple. Su expresión regular no permite eso.

EDIT: Pensé que tenías todos los otros literales DBCS funcionando y solo tenía problemas con G-string, así que solo señalé la diferencia entre N y G. Ahora eché un vistazo más de cerca a tu RE. Tiene problemas. En el Cobol he usado, se puede mezclar con el japonés ASCII, por ejemplo,

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

Usted RE supone sólo el DBCS. Perdería esta restricción e intentaría de nuevo.

No creo que sea posible manejar literales G completamente en expresiones regulares. No hay forma de realizar un seguimiento de las cotizaciones coincidentes y de SO/SI con una máquina de estados finitos. Tu RE es tan complicado porque está tratando de hacer lo imposible. Simplemente lo simplificaría y cuidaría los tokens que no coinciden manualmente.

También podría enfrentar problemas de codificación. El código podría estar en EBCDIC (Katakana) o UTF-16, tratándolo como ASCII no funcionará. SO/SI a veces se convierten a 0x1E/0x1F en Windows.

estoy tratando de ayudarle a disparar en la oscuridad sin ver el código real :)

Answer 2

¿Se <NotLineOrParagraphSeparatorNorApostropheNorShiftInNorShiftOut> incluyen también entre comillas simples y dobles, o simplemente apóstrofes? Eso sería un problema, ya que consumiría la secuencia de caracteres de cierre literal> '...

Verificaría la definición de todas las otras macros para estar seguro. El único problema obvio que puedo ver es el <squote> <squote> del que ya pareces estar consciente.