Code COBOL japonais: règles pour les littéraux et les identifiants G?

Question

Nous traitons le code source COBOL japonais IBMEnterprise.

Les règles qui décrivent exactement ce qui est autorisé dans les littéraux de type G, et ce qui est autorisé pour les identificateurs ne sont pas claires.

Le manuel IBM indique que G « .... » littérale doit avoir une SHIFT-OUT comme le premier caractère à l'intérieur des guillemets, et SHIFT-IN comme le dernier caractère avant la citation de clôture. Notre lexer COBOL "sait" cela, mais les objets aux littéraux G trouvés en code réel. Conclusion: le manuel IBM est faux, ou nous le lisons mal. Le client ne nous laissera pas voir le code, donc il est assez difficile de diagnostiquer le problème.

EDIT: Révision/étendue ci-dessous pour plus de clarté du texte:

Est-ce que quelqu'un sait les règles exactes de G formation littérale, et comment ils (ne) correspondent à ce que disent les manuels de référence IBM? La réponse idéale serait une expression régulière pour le littéral G. C'est ce que nous utilisons maintenant (codé par un autre auteur, soupir):

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

où < name> est une macro qui est une autre expression régulière. Vraisemblablement, ils sont nommés assez bien pour que vous puissiez deviner ce qu'ils contiennent. Il s'agit du IBM Enterprise COBOL Reference. Chapitre 3 "Chaînes de caractères", sous-titre "Littéraux DBCS" page 32 est une lecture pertinente. J'espère que, en fournissant la référence exacte, un IBMer expérimenté peut nous dire comment nous l'avons mal interprété: - {Je ne suis pas très clair sur ce que l'expression "DBCS-caractères" signifie quand il est écrit "un ou plusieurs caractères dans la plage X'00 ... X'FF pour l'un des octets " Comment les caractères DBCS peuvent-ils être tout sauf paires de codes de caractères de 8 bits? Le RE existant correspond à 3 types de paires de caractères si vous l'examinez. Une réponse ci-dessous suggère que l'appariement < squote> < squote> est incorrect. OK, je pourrais le croire, mais cela signifie que le RE ne rejettera que chaînes littérales contenant < squote> s. Je ne crois pas que ce soit le problème que nous avons car nous semblons trébucher sur chaque instance d'un littéral en G. De même, les identifiants COBOL peuvent être composés avec des caractères DBCS. Qu'est-ce qui est autorisé pour un identifiant, exactement? Encore une fois, une expression régulière serait idéale.

EDIT2: Je commence à penser que le problème ne pourrait pas être le RE. Nous lisons le texte codé Shift-JIS. Notre lecteur convertit ce texte en Unicode. Mais les caractères DBCS sont vraiment et non Shift-JIS; il s'agit plutôt de données codées en binaire. Probablement ce qui se passe est que les données DBCS sont traduites comme si c'était Shift-JIS, et que cela muck up la capacité pour reconnaître "deux octets" comme un élément DBCS.Par exemple, si une paire de caractères DBCS était: 81: 1F, un lecteur ShiftJIS convertirait cette paire en un seul caractère Unicode, et sa nature à deux octets serait alors perdue. Si vous ne pouvez pas compter les paires, vous ne pouvez pas trouver la citation de fin. Si vous ne trouvez pas la citation de fin, vous ne pouvez pas reconnaître le littéral. Donc, le problème semble être que nous devons changer les modes de codage d'entrée dans le milieu du processus de lexage. Yuk.

Answer 1

Essayez d'ajouter une offre unique dans la règle pour voir si elle passe en faisant ce changement,

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

Si je me souviens bien, une différence entre N et G littéraux est que G permet guillemet simple. Votre expression régulière ne le permet pas. EDIT: Je pensais que vous aviez tous les autres littéraux DBCS fonctionnant et juste avoir des problèmes avec G-string, alors je viens de souligner la différence entre N et G. Maintenant, j'ai regardé de plus près votre RE. Il a des problèmes. Dans le Cobol je, vous pouvez mélanger ASCII avec le japonais, par exemple,

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

Vous RE prend la DBCS uniquement. Je perdrais cette restriction et j'essayerais à nouveau.

Je ne pense pas qu'il soit possible de gérer les littéraux G entièrement en expression régulière. Il n'y a aucun moyen de garder la trace des devis correspondants et SO/SI avec une machine à états finis seul. Votre ER est si compliqué parce qu'il essaie de faire l'impossible. Je voudrais juste le simplifier et prendre soin de mésappariement des jetons manuellement.

Vous pourriez également rencontrer des problèmes d'encodage. Le code pourrait être en EBCDIC (Katakana) ou UTF-16, le traiter comme ASCII ne fonctionnera pas. SO/SI sont parfois convertis en 0x1E/0x1F sous Windows.

J'essaie simplement de vous aider à tirer dans l'obscurité sans voir le code réel :)

Answer 2

Est-ce que <NotLineOrParagraphSeparatorNorApostropheNorShiftInNorShiftOut> comprennent également des guillemets simples et doubles, ou tout simplement apostrophes? Ce serait un problème, car il consommerait la séquence de caractères de fermeture littérale> '...

Je vérifierais la définition de toutes les autres macros pour m'assurer. Le seul problème évident que je peux voir est le <squote> <squote> que vous semblez déjà être au courant.