Japonca COBOL Kodu: G değişmezleri ve tanımlayıcıları için kurallar?

Question

IBMEnterprise Japonca COBOL kaynak kodunu işliyoruz.

G tipi değişmezlerde izin verilen neleri açıklayan kurallar, ve tanımlayıcılara neyin izin verildiği açık değildir.

IBM manuel G '....' literal tırnak içine ilk karakter, ve SHIFT-IN kapama tırnağına önceki son karakteri olarak bir SHIFT-OUT sahip olması gerektiğini belirtir. COBOL lexer'ımız bunu "bilir", ancak gerçek kodda bulunan G literals 'a nesneler. Sonuç: IBM kullanım kılavuzu yanlıştır, veya yanlış yorumluyoruz. Müşteri kodu görmemize izin vermeyecek, bu yüzden sorunu teşhis etmek oldukça zordur. Revize/netlik için metninin altında uzatıldı: DÜZENLEME

kimse G değişmez oluşumu, kesin kurallar biliyor mu ve nasıl IBM referans kılavuzları söylediklerine maç (yok)? İdeal cevap, G literal için düzenli bir ifade olur. Bu, biz (başka yazar tarafından kodlanmış, iç çekiyorum) artık kullanıyorsunuz budur: < adı> başka düzenli ifade olan bir makro olduğunu

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

. Muhtemelen , yeterince iyi adlandırıldıkları için neyi içerdiğini tahmin edebilirsiniz.

İşte IBM Enterprise COBOL Reference. Bölüm 3 "Karakter Dizeleri", "DBCS hazırlıkları" alt başlığı "Sayfa 32" ilgili okumadır. Tam referansı sağlayarak, deneyimli bir IBM firmasının bize nasıl yanlış bir şekilde yol açtığımızı söyleyebilirim: - {"DBCS-karakterleri" ifadesinin " " ifadesinin ne zaman olduğunu söylerken özellikle "bir veya daha fazla karakter belirsizdir" X'00 ... X'FF aralığında her iki bayt için " DBCS karakterleri, 8 bit karakter kodlarının çiftleri dışında nasıl olabilir? Mevcut RE, incelediğinizde 3 karakter çiftiyle eşleşir.

Aşağıdaki yanıtlardan biri < squote> < squote> eşleşmesinin yanlış olduğunu göstermektedir. Tamam, buna inanabilirim, fakat bu, RE'nin sadece squote> s içeren literal dizeleri reddedeceği anlamına gelir. Ben bir G literalinin her bir örneğini gezdiğimiz gibi, 'un sahip olduğumuz problem olduğuna inanmıyorum.

Benzer şekilde, COBOL tanımlayıcıları DBCS karakterleri ile 'dan bağımsız olarak oluşturulabilir. Bir tanımlayıcı için tam olarak ne izin verilir? Yine düzenli bir ifade ideal olurdu.

EDIT2: Sorunun RE olmayabileceğini düşünüyorum. Shift-JIS kodlanmış metni okuyoruz. Okuyucumuz, metninin Unicode'a giderken dönüştürdüğünü. Ancak DBCS karakterleri, Shift-JIS değil, ; daha ziyade, ikili kodlanmış verilerdir. Muhtemelen olup bitenler, DBCS verilerinin Shift-JIS olduğu gibi çevrilir ve bu, DBCS elemanı olarak "iki bayt" tanımak için yeteneğini bozar.Örneğin, bir DBCS karakter çifti olsaydı, : 81: 1F, bir ShiftJIS okuyucusu bu çifti tek bir Unicode karakterine dönüştürür, ve iki bayt doğası kaybolur. Çiftleri sayamazsanız, son teklifini bulamazsınız. Son alıntıyı bulamadıysanız, , literalini tanıyamazsınız. Yani sorun, görünecektir ki, kodlama işlemlerinin orta giriş kodlama modlarını değiştirmemiz gerekir. Yuk.

Answer 1

Ben doğru hatırlıyorsam, N ve G değişmezleri arasında bir fark G tek tırnak olanak sağlamasıdır

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

, bu değişiklik yaparak geçerse görmek için kural tek tırnağı eklemeyi deneyin. Normal ifaden buna izin vermiyor.

DÜZENLEME: Diğer tüm DBCS editörlerinin çalıştığını ve sadece G-string ile ilgili sorunlar yaşadığınızı sanıyorum, bu yüzden N ve G arasındaki farkı belirttim. Şimdi RE'nize daha yakından baktım. Sorunları var. Ben kullanılan Cobol olarak,

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

Sen RE sadece DBCS varsayar, örneğin, Japonlarla ASCII karıştırabilirsiniz. Bu kısıtlamayı kaybederim ve tekrar deneyeceğim.

G edebi bilgilerinin tamamen düzenli ifadeyle ele alınmasının mümkün olduğunu düşünmüyorum. Tek başına sonlu durum makinesiyle eşleşen tırnakları ve SO/SI'yı takip etmenin bir yolu yoktur. RE'niz çok karmaşık çünkü imkansızı yapmaya çalışıyor. Sadece basitleştiririm ve eşleşmeyen belirteçleri el ile ele alırdım.

Ayrıca, kodlama sorunlarıyla da karşılaşabilirsiniz. Kod, ASCII'nin çalışmadığı gibi davranarak EBCDIC (Katakana) veya UTF-16'da olabilir. SO/SI bazen Windows'ta 0x1E/0x1F'ye dönüştürülür.

Sadece gerçek kod :)

Answer 2

> NotLineOrParagraphSeparatorNorApostropheNorShiftInNorShiftOut < da sadece kesme işareti tek ve çift tırnak işareti veya içeriyor mu görmeden karanlıkta ateş yardımcı olmaya çalışıyorum? Bu bir sorun olur, çünkü bu, '' literal kapanış karakter dizisini ''

Kullanacağından emin olmak için diğer tüm makroların tanımını kontrol ederdim. Görebildiğim en belirgin sorun, zaten farkında olduğunuz <squote> <squote> şudur.