การกำเนิดของโครงการนี้ถือได้ว่าเป็นแนวคิดเล็ก ๆ ที่มาหาฉันที่ไหนสักแห่งในปลายปี 2007 ซึ่งถูกกำหนดให้พบรูปแบบสุดท้ายในอีก 12 ปีต่อมา ( ณ จุดนี้ - แน่นอนแม้ว่าการดำเนินการในปัจจุบันก็ตาม ผู้เขียนก็พอใจมาก)
ทุกอย่างเริ่มต้นเมื่อในกระบวนการปฏิบัติหน้าที่อย่างเป็นทางการของฉันในห้องสมุดฉันดึงความสนใจไปที่ความจริงที่ว่ากระบวนการป้อนข้อมูลจากข้อความที่สแกนของสารบัญของสิ่งพิมพ์หนังสือ (และเพลง) ลงในฐานข้อมูลที่มีอยู่ เห็นได้ชัดว่าสามารถทำให้ง่ายขึ้นและทำให้เป็นอัตโนมัติได้อย่างมาก โดยใช้ประโยชน์จากคุณสมบัติของความเป็นระเบียบและการทำซ้ำของข้อมูลทั้งหมดที่จำเป็นสำหรับการป้อนข้อมูล เช่น ชื่อผู้เขียนบทความ (หากเรากำลังพูดถึงชุดบทความ) ชื่อของ บทความ (หรือคำบรรยายที่แสดงในสารบัญ) และหมายเลขหน้าของรายการสารบัญปัจจุบัน ในตอนแรกฉันเชื่อมั่นในทางปฏิบัติว่าระบบที่เหมาะสมสำหรับการดำเนินงานนี้สามารถพบได้ง่ายบนอินเทอร์เน็ต เมื่อความประหลาดใจเกิดจากการที่ฉันไม่สามารถหาโครงการดังกล่าวได้ ฉันจึงตัดสินใจลองดำเนินการด้วยตนเอง
หลังจากผ่านไปได้ไม่นาน ต้นแบบแรกก็เริ่มทำงาน ซึ่งฉันเริ่มใช้ในกิจกรรมประจำวันทันที โดยแก้ไขจุดบกพร่องในตัวอย่างทั้งหมดที่อยู่ในมือของฉันไปพร้อมๆ กัน โชคดีที่ที่ทำงานปกติของฉันซึ่งฉันไม่ได้เป็นโปรแกรมเมอร์เลย ฉันยังคงรอดพ้นจาก "การหยุดทำงาน" ที่มองเห็นได้ในการทำงานของฉัน ในระหว่างนั้นฉันกำลังแก้ไขข้อบกพร่องผลิตผลทางสมองอย่างเข้มข้น ซึ่งเป็นสิ่งที่แทบจะคิดไม่ถึงในความเป็นจริงปัจจุบัน ซึ่งบอกเป็นนัย รายงานรายวันเกี่ยวกับงานที่ทำในระหว่างวัน กระบวนการขัดเกลาโปรแกรมใช้เวลาทั้งหมดไม่น้อยกว่าประมาณหนึ่งปี แต่หลังจากนั้นผลลัพธ์ก็แทบจะเรียกได้ว่าประสบความสำเร็จไม่ได้เลย - มีแนวคิดที่แตกต่างกันมากเกินไปที่ไม่เข้าใจสำหรับการนำไปปฏิบัติ: องค์ประกอบเสริมที่สามารถข้ามได้ ; การดูองค์ประกอบล่วงหน้า (เพื่อวัตถุประสงค์ในการทดแทนองค์ประกอบก่อนหน้าในผลการค้นหา) แม้แต่ความพยายามของเราเองในการนำนิพจน์ทั่วไปไปใช้ (ซึ่งมีไวยากรณ์เฉพาะ) ฉันต้องบอกว่าก่อนหน้านี้ฉันเลิกเขียนโปรแกรมไปบ้างแล้ว (ประมาณ 8 ปีถ้าไม่มากกว่านั้น) ดังนั้นโอกาสใหม่ที่จะนำทักษะของฉันไปใช้กับงานที่น่าสนใจและจำเป็นจึงดึงดูดความสนใจของฉันไปโดยสิ้นเชิง ไม่น่าแปลกใจเลยที่ซอร์สโค้ดที่เป็นผลลัพธ์ - เนื่องจากไม่มีแนวทางที่ชัดเจนในการออกแบบในส่วนของฉัน - กลายเป็นสิ่งที่ผิดพลาดอย่างรวดเร็วที่ไม่อาจจินตนาการได้ของชิ้นส่วนที่แตกต่างกันในภาษา C ด้วยองค์ประกอบบางอย่างของ C ++ และแง่มุมต่าง ๆ ของการเขียนโปรแกรมด้วยภาพ (ในขั้นต้น ตัดสินใจใช้ระบบการออกแบบเช่น Borland C++ Builder - "เกือบ Delphi แต่เป็นภาษา C") อย่างไรก็ตาม ทั้งหมดนี้ทำให้เกิดผลในการทำให้กิจกรรมประจำวันของห้องสมุดของเราเป็นแบบอัตโนมัติ
ในเวลาเดียวกัน ฉันก็ตัดสินใจเข้าร่วมหลักสูตรเพื่อฝึกอบรมนักพัฒนาซอฟต์แวร์มืออาชีพในกรณีฉุกเฉิน ฉันไม่รู้ว่าเป็นไปได้จริงหรือไม่ที่จะเรียนรู้ "การเป็นโปรแกรมเมอร์" ตั้งแต่เริ่มต้นที่นั่น แต่เมื่อคำนึงถึงทักษะที่ฉันมีอยู่แล้วในขณะนั้น ฉันสามารถเชี่ยวชาญเทคโนโลยีที่มีความเกี่ยวข้องมากขึ้นในเวลานั้นได้ เช่น เช่น C#, Visual Studio สำหรับการพัฒนาภายใต้ .NET รวมถึงเทคโนโลยีบางอย่างที่เกี่ยวข้องกับ Java, HTML และ SQL การฝึกอบรมทั้งหมดใช้เวลาทั้งหมดสองปี และทำหน้าที่เป็นจุดเริ่มต้นของโครงการอื่นของฉัน ซึ่งท้ายที่สุดก็กินเวลานานหลายปี แต่นี่เป็นหัวข้อสำหรับการตีพิมพ์แยกต่างหาก ในที่นี้ เป็นการเหมาะสมที่จะทราบว่าฉันพยายามปรับการพัฒนาที่ฉันมีอยู่แล้วในโครงการที่อธิบายไว้ เพื่อสร้างแอปพลิเคชันหน้าต่างที่มีคุณสมบัติครบถ้วนใน C# และ WinForms ที่ใช้ฟังก์ชันการทำงานที่จำเป็น และใช้เป็นพื้นฐานสำหรับ โครงการประกาศนียบัตรที่กำลังจะมีขึ้น
เมื่อเวลาผ่านไป ความคิดนี้เริ่มสำหรับฉันที่สมควรถูกเปล่งออกมาในการประชุมประจำปีดังกล่าว โดยมีตัวแทนของห้องสมุดต่างๆ เช่น "LIBKOM" และ "CRIMEA" เข้าร่วม แนวคิดนี้ใช่ แต่ไม่ใช่การนำไปปฏิบัติของฉันในขณะนั้น จากนั้นฉันก็หวังว่าจะมีคนเขียนมันใหม่โดยใช้แนวทางที่มีความสามารถมากกว่านี้ ไม่ทางใดก็ทางหนึ่งภายในปี 2013 ฉันตัดสินใจเขียนรายงานเกี่ยวกับงานเบื้องต้นของฉันและส่งไปยังคณะกรรมการจัดงานประชุมพร้อมใบสมัครขอรับทุนเข้าร่วมการประชุม ฉันค่อนข้างแปลกใจที่ใบสมัครของฉันได้รับการอนุมัติ และฉันเริ่มปรับปรุงโครงการบางส่วนเพื่อเตรียมนำเสนอในการประชุมใหญ่
เมื่อถึงเวลานั้น โครงการได้รับชื่อใหม่ BIRMA แล้ว ได้รับความสามารถเพิ่มเติมต่างๆ (ที่ยังไม่ได้นำไปใช้อย่างเต็มที่ แต่ถือว่าค่อนข้างถูกสันนิษฐาน) - .
พูดตามตรง เป็นเรื่องยากที่จะเรียกงาน BIRMA 2013 ว่าเป็นงานที่สมบูรณ์ พูดตามตรง มันเป็นงานฝีมือแฮ็กเกอร์ที่ทำด้วยความเร่งรีบมาก ในแง่ของโค้ดแทบไม่มีนวัตกรรมพิเศษเลย ยกเว้นความพยายามที่ค่อนข้างช่วยไม่ได้ในการสร้างไวยากรณ์แบบรวมบางประเภทสำหรับ parser ในลักษณะที่ชวนให้นึกถึงภาษาการจัดรูปแบบ IRBIS 64 (และในความเป็นจริงก็คือระบบ ISIS ด้วย - โดยมีวงเล็บเป็นโครงสร้างแบบวงกลม ทำไมตอนนั้น ฉันคิดว่ามันดูเจ๋งดี) โปรแกรมแยกวิเคราะห์สะดุดกับวงกลมของวงเล็บประเภทที่เหมาะสมอย่างสิ้นหวัง (เนื่องจากวงเล็บยังมีบทบาทอื่นด้วย กล่าวคือ พวกเขาทำเครื่องหมายโครงสร้างที่เป็นทางเลือกในระหว่างการแยกวิเคราะห์ที่สามารถข้ามได้) ฉันแนะนำทุกคนอีกครั้งที่ต้องการทำความคุ้นเคยกับไวยากรณ์ที่ไม่สมเหตุสมผลและยากที่จะจินตนาการของ BIRMA โดยละเอียดเพิ่มเติมในรายงานของฉันในเวลานั้น
โดยทั่วไป นอกเหนือจากการดิ้นรนกับ parser ของตัวเองแล้ว ฉันไม่มีอะไรจะพูดเพิ่มเติมเกี่ยวกับโค้ดของเวอร์ชันนี้ - ยกเว้นการแปลงย้อนกลับของแหล่งข้อมูลที่มีอยู่เป็น C++ ในขณะที่ยังคงรักษาคุณสมบัติทั่วไปบางอย่างของโค้ด .NET (พูดตามตรง มันเป็น ยากที่จะเข้าใจ สิ่งที่กระตุ้นให้ฉันย้ายทุกอย่างกลับ - อาจเป็นความกลัวโง่ ๆ ที่จะเก็บซอร์สโค้ดของฉันไว้เป็นความลับราวกับว่ามันเป็นสิ่งที่เทียบเท่ากับสูตรลับของ Coca-Cola)
บางทีการตัดสินใจที่โง่เขลานี้อาจเป็นสาเหตุของความยากลำบากในการจับคู่ไลบรารี DLL ที่เป็นผลลัพธ์กับอินเทอร์เฟซที่มีอยู่ของเวิร์กสเตชันแบบโฮมเมดสำหรับการป้อนข้อมูลลงในแคตตาล็อกอิเล็กทรอนิกส์ (ใช่ฉันไม่ได้พูดถึงข้อเท็จจริงที่สำคัญอีกประการหนึ่ง: จากนี้ไปทั้งหมด รหัสของ “เครื่องยนต์” BIRMA เป็นไปตามที่คาดไว้ โดยแยกออกจากส่วนอินเทอร์เฟซและบรรจุใน DLL ที่เหมาะสม) เหตุใดจึงจำเป็นต้องเขียนเวิร์กสเตชันแยกต่างหากเพื่อจุดประสงค์เหล่านี้ ซึ่งในลักษณะและวิธีการโต้ตอบกับผู้ใช้ได้คัดลอกเวิร์กสเตชัน "Catalogizer" เดียวกันของระบบ IRBIS 64 อย่างไร้ยางอาย - นี่เป็นคำถามแยกต่างหาก กล่าวโดยย่อ: มันให้ความแข็งแกร่งที่จำเป็นแก่การพัฒนาของฉันสำหรับโครงการสำเร็จการศึกษาของฉัน (ไม่เช่นนั้นเครื่องมือแยกวิเคราะห์ที่ย่อยไม่ได้เพียงอย่างเดียวก็ไม่เพียงพอ) นอกจากนี้ ฉันพบปัญหาบางประการในการใช้งานอินเทอร์เฟซของเวิร์กสเตชัน Cataloger กับโมดูลของฉันเอง ซึ่งใช้งานทั้งใน C++ และ C# และเข้าถึงกลไกของฉันโดยตรง
โดยทั่วไปแล้ว น่าแปลกที่นี่คือต้นแบบที่ค่อนข้างงุ่มง่ามของ BIRMA.NET ในอนาคตซึ่งถูกกำหนดให้เป็น "ม้าทำงาน" ของฉันในอีกสี่ปีข้างหน้า ไม่สามารถพูดได้ว่าในช่วงเวลานี้ อย่างน้อยฉันก็ไม่ได้พยายามหาวิธีในการนำแนวคิดที่มีมายาวนานไปปฏิบัติให้สมบูรณ์ยิ่งขึ้น ในบรรดานวัตกรรมอื่น ๆ ควรมีลำดับวงจรที่ซ้อนกันซึ่งอาจรวมองค์ประกอบเสริมไว้ด้วย - นี่คือวิธีที่ฉันจะทำให้แนวคิดของเทมเพลตสากลสำหรับคำอธิบายบรรณานุกรมของสิ่งพิมพ์และสิ่งที่น่าสนใจอื่น ๆ มีชีวิตขึ้นมา อย่างไรก็ตาม ในกิจกรรมภาคปฏิบัติของฉันในเวลานั้น ทั้งหมดนี้เป็นเพียงความต้องการเพียงเล็กน้อย และการนำไปปฏิบัติที่ฉันมีในเวลานั้นก็เพียงพอแล้วสำหรับการเข้าสู่สารบัญ นอกจากนี้ ทิศทางการพัฒนาห้องสมุดของเราเริ่มเบี่ยงเบนไปสู่การแปลงเอกสารสำคัญของพิพิธภัณฑ์ การรายงาน และกิจกรรมอื่น ๆ ที่ฉันไม่ค่อยสนใจมากนัก ซึ่งท้ายที่สุดฉันก็ต้องละทิ้งมันไปในที่สุด โดยให้ทางแก่ผู้ที่จะ จงยินดีกับสิ่งทั้งหมดนี้มากขึ้น
ในทางตรงกันข้าม หลังจากเหตุการณ์อันน่าทึ่งเหล่านี้เองที่โครงการ BIRMA ซึ่งในขณะนั้นมีคุณสมบัติเฉพาะทั้งหมดของโครงการก่อสร้างระยะยาวทั่วไป ดูเหมือนจะเริ่มดำเนินชีวิตใหม่ที่รอคอยมานาน! ฉันมีเวลาว่างมากขึ้นสำหรับความคิดที่ไม่ได้ใช้งานฉันเริ่มค้นหาเวิลด์ไวด์เว็บอีกครั้งเพื่อค้นหาสิ่งที่คล้ายกัน (โชคดีที่ตอนนี้ฉันเดาได้แล้วว่าจะมองหาทั้งหมดนี้ไม่ใช่แค่ที่ใดก็ได้ แต่บน GitHub) และที่ไหนสักแห่งใน At the เมื่อต้นปีนี้ ในที่สุดฉันก็ได้พบกับผลิตภัณฑ์ที่เกี่ยวข้องจากบริษัท Salesforce ชื่อดังภายใต้ชื่อที่ไม่สำคัญ . ด้วยตัวมันเอง มันสามารถทำเกือบทุกอย่างที่ฉันต้องการจากกลไกแยกวิเคราะห์ดังกล่าว กล่าวคือ แยกส่วนย่อยแต่ละส่วนออกจากข้อความที่มีโครงสร้างชัดเจน แต่มีโครงสร้างที่ชัดเจนอย่างชาญฉลาด ในขณะที่มีส่วนต่อประสานที่ใช้งานง่ายสำหรับผู้ใช้ปลายทาง รวมถึงสาระสำคัญที่เข้าใจได้ เช่น รูปแบบ เทมเพลต และเหตุการณ์ที่เกิดขึ้น และในเวลาเดียวกันก็ใช้ไวยากรณ์ที่คุ้นเคยของนิพจน์ทั่วไป ซึ่งสามารถอ่านได้ง่ายขึ้นอย่างไม่มีใครเทียบได้เนื่องจากการแบ่งออกเป็นกลุ่มความหมายที่กำหนดสำหรับการแยกวิเคราะห์
โดยทั่วไปฉันตัดสินใจว่านี่คืออันหนึ่ง กอร์ป (ฉันสงสัยว่าชื่อนี้หมายถึงอะไร? บางทีอาจเป็น “ตัวแยกวิเคราะห์ทั่วไปทั่วไป” บางชนิด?) – ตรงกับสิ่งที่ฉันมองหามานานแล้ว จริงอยู่ การนำไปใช้ตามความต้องการของฉันในทันทีมีปัญหามากจนกลไกนี้จำเป็นต้องยึดลำดับโครงสร้างของข้อความต้นฉบับอย่างเข้มงวดเกินไป สำหรับรายงานบางประเภท เช่น ไฟล์บันทึก (กล่าวคือ นักพัฒนาวางไว้เป็นตัวอย่างที่ชัดเจนของการใช้โครงการ) นี่ค่อนข้างเหมาะสม แต่สำหรับข้อความเดียวกันของสารบัญที่สแกน ก็ไม่น่าจะเป็นไปได้ ท้ายที่สุดแล้ว หน้าเดียวกันกับสารบัญสามารถขึ้นต้นด้วยคำว่า "สารบัญ", "เนื้อหา" และคำอธิบายเบื้องต้นอื่น ๆ ที่เราไม่จำเป็นต้องวางไว้ในผลลัพธ์ของการวิเคราะห์ที่ต้องการ (และตัดออกด้วยตนเอง แต่ละครั้งก็ไม่สะดวกเช่นกัน) นอกจากนี้ ระหว่างองค์ประกอบที่ซ้ำกันแต่ละรายการ เช่น ชื่อผู้เขียน ชื่อเรื่อง และหมายเลขหน้า หน้าเว็บอาจมีขยะจำนวนหนึ่ง (เช่น ภาพวาด และเพียงอักขระแบบสุ่ม) ซึ่งคงจะดีเช่นกันหากสามารถ ตัดออก อย่างไรก็ตาม แง่มุมสุดท้ายยังไม่มีความสำคัญมากนัก แต่เนื่องจากประการแรก การใช้งานที่มีอยู่จึงไม่สามารถเริ่มมองหาโครงสร้างที่จำเป็นในข้อความจากที่ใดที่หนึ่งได้ แต่เพียงประมวลผลมันตั้งแต่เริ่มต้นแทน ไม่พบ กำหนดรูปแบบไว้ตรงนั้น และ... จบงานของฉัน แน่นอนว่าจำเป็นต้องมีการปรับแต่งบางอย่างเพื่อให้มีช่องว่างระหว่างโครงสร้างที่ทำซ้ำ และนั่นทำให้ฉันกลับมาทำงานได้อีกครั้ง
ปัญหาอีกประการหนึ่งคือตัวโครงการเองถูกนำไปใช้ใน Java และหากในอนาคตฉันวางแผนที่จะใช้วิธีการบางอย่างในการเชื่อมต่อเทคโนโลยีนี้กับแอปพลิเคชันที่คุ้นเคยสำหรับการป้อนข้อมูลลงในฐานข้อมูลที่มีอยู่ (เช่น "Cataloguer" ของ Irbis อย่างน้อยที่สุด ทำสิ่งนี้ใน C# และ .NET ไม่ใช่ว่า Java เองเป็นภาษาที่ไม่ดี – ฉันเคยใช้มันเพื่อใช้งานแอปพลิเคชันหน้าต่างที่น่าสนใจซึ่งใช้ฟังก์ชันการทำงานของเครื่องคิดเลขแบบตั้งโปรแกรมได้ในประเทศ (เป็นส่วนหนึ่งของโครงการหลักสูตร) และในแง่ของไวยากรณ์ มันคล้ายกับ C-sharp ตัวเดียวกันมาก นี่เป็นเพียงข้อดี: ยิ่งฉันจบโครงการที่มีอยู่ได้ง่ายขึ้นเท่านั้น อย่างไรก็ตามฉันไม่ต้องการที่จะกระโดดเข้าสู่โลกของเทคโนโลยี Java แบบหน้าต่าง (หรือมากกว่าเดสก์ท็อป) ที่ค่อนข้างแปลกตาอีกต่อไป - ท้ายที่สุดแล้วภาษานั้นไม่ได้ "ปรับแต่ง" สำหรับการใช้งานดังกล่าวและฉันก็ไม่อยากทำซ้ำเลย ประสบการณ์ก่อนหน้านี้ บางทีอาจเป็นเพราะว่า C# ร่วมกับ WinForms นั้นใกล้เคียงกับ Delphi มาก ซึ่งพวกเราหลายคนเคยเริ่มต้นมาแล้ว โชคดีที่พบวิธีแก้ปัญหาที่จำเป็นได้ค่อนข้างรวดเร็ว - ในรูปแบบของโครงการ ซึ่งทำให้ง่ายต่อการแปลโปรแกรม Java ที่มีอยู่เป็นโค้ด .NET ที่ได้รับการจัดการ จริงอยู่ที่ผู้เขียนละทิ้งโครงการไปแล้วในเวลานั้น แต่การใช้งานครั้งล่าสุดทำให้ฉันสามารถดำเนินการที่จำเป็นสำหรับข้อความต้นฉบับได้ค่อนข้างสำเร็จ กอร์ป.
ดังนั้นฉันจึงทำการเปลี่ยนแปลงที่จำเป็นทั้งหมดและรวมทั้งหมดไว้ใน DLL ประเภทที่เหมาะสม ซึ่งสามารถ "รับ" ได้อย่างง่ายดายโดยโปรเจ็กต์ใดๆ สำหรับ .NET Framework ที่สร้างขึ้นใน Visual Studio ในระหว่างนี้ ฉันได้สร้างอีกเลเยอร์หนึ่งเพื่อความสะดวกในการนำเสนอผลลัพธ์ที่ส่งคืน กอร์ปในรูปแบบของโครงสร้างข้อมูลที่สอดคล้องกันซึ่งจะสะดวกต่อการประมวลผลในมุมมองตาราง (โดยยึดทั้งแถวและคอลัมน์เป็นพื้นฐาน ทั้งคีย์พจนานุกรมและดัชนีตัวเลข) ยูทิลิตี้ที่จำเป็นสำหรับการประมวลผลและแสดงผลลัพธ์นั้นเขียนได้ค่อนข้างเร็ว
นอกจากนี้ กระบวนการปรับใช้เทมเพลตสำหรับกลไกใหม่เพื่อสอนให้แยกวิเคราะห์ตัวอย่างข้อความสารบัญที่สแกนที่มีอยู่ไม่ได้ทำให้เกิดความยุ่งยากพิเศษใดๆ อันที่จริง ฉันไม่จำเป็นต้องอ้างถึงเทมเพลตก่อนหน้านี้เลยด้วยซ้ำ: ฉันเพียงแค่สร้างเทมเพลตที่จำเป็นทั้งหมดตั้งแต่เริ่มต้น ยิ่งไปกว่านั้น หากเทมเพลตที่ออกแบบมาเพื่อทำงานกับระบบเวอร์ชันก่อนหน้าได้กำหนดกรอบงานที่ค่อนข้างแคบสำหรับข้อความที่สามารถแยกวิเคราะห์ได้อย่างถูกต้องด้วยความช่วยเหลือ เอ็นจิ้นใหม่ได้ทำให้สามารถพัฒนาเทมเพลตที่เป็นสากลพอสมควรซึ่งเหมาะสำหรับมาร์กอัปหลายประเภทที่ ครั้งหนึ่ง. ฉันพยายามเขียนเทมเพลตที่ครอบคลุมบางประเภทสำหรับข้อความสารบัญใด ๆ ก็ตามแม้ว่าแน่นอนว่าถึงแม้จะมีความเป็นไปได้ใหม่ ๆ ที่เปิดให้ฉันรวมถึงโดยเฉพาะอย่างยิ่งความสามารถที่ จำกัด ในการใช้ลำดับการทำซ้ำที่ซ้อนกันแบบเดียวกัน ( เช่นนามสกุลและชื่อย่อของผู้เขียนหลายคนติดต่อกัน) สิ่งนี้กลายเป็นยูโทเปีย
บางทีในอนาคตอาจเป็นไปได้ที่จะใช้แนวคิดบางอย่างของเมตาเทมเพลตซึ่งจะสามารถตรวจสอบข้อความต้นฉบับเพื่อให้สอดคล้องกับเทมเพลตที่มีอยู่หลายเทมเพลตพร้อมกัน จากนั้นตามผลลัพธ์ที่ได้รับ ให้เลือก ที่เหมาะสมที่สุดโดยใช้อัลกอริธึมอัจฉริยะบางประเภท แต่ตอนนี้ฉันกังวลกับคำถามอื่นมากขึ้น นักแยกวิเคราะห์เช่น กอร์ปแม้จะมีความสามารถรอบด้านและการปรับเปลี่ยนที่ฉันทำ แต่ก็ยังไม่สามารถทำสิ่งที่ดูเหมือนเรียบง่ายโดยธรรมชาติซึ่งโปรแกรมแยกวิเคราะห์ที่ฉันเขียนเองสามารถทำได้ตั้งแต่เวอร์ชันแรก กล่าวคือ: เขามีความสามารถในการค้นหาและแยกส่วนทั้งหมดที่ตรงกับมาสก์ที่ระบุในเทมเพลตที่ใช้ในตำแหน่งที่ถูกต้องจากข้อความต้นฉบับ โดยไม่สนใจเลยในสิ่งที่ข้อความที่ให้ไว้ในช่องว่างระหว่างส่วนเหล่านี้ จนถึงตอนนี้ ฉันได้ปรับปรุงกลไกใหม่เพียงเล็กน้อยเท่านั้น ทำให้สามารถค้นหาการทำซ้ำใหม่ที่เป็นไปได้ทั้งหมดของลำดับที่กำหนดของมาสก์จากตำแหน่งปัจจุบัน เหลือความเป็นไปได้ที่จะปรากฏอยู่ในข้อความของชุดอักขระที่กำหนดเองซึ่งสมบูรณ์ ไม่มีการระบุในการแยกวิเคราะห์ ซึ่งอยู่ระหว่างโครงสร้างการทำซ้ำที่ตรวจพบ อย่างไรก็ตาม สิ่งนี้ไม่ได้ทำให้สามารถตั้งค่ามาสก์ถัดไปได้โดยไม่คำนึงถึงผลลัพธ์ของการค้นหาส่วนก่อนหน้าโดยใช้มาสก์ที่เกี่ยวข้อง: ความเข้มงวดของโครงสร้างข้อความที่อธิบายยังคงไม่มีที่ว่างสำหรับการรวมอักขระที่ผิดปกติโดยพลการ
และหากตัวอย่างสารบัญที่ฉันเจอปัญหานี้ดูเหมือนจะไม่ร้ายแรงนัก ดังนั้นเมื่อพยายามใช้กลไกการแยกวิเคราะห์ใหม่กับงานที่คล้ายกันในการแยกวิเคราะห์เนื้อหาของเว็บไซต์ (เช่น การแยกวิเคราะห์แบบเดียวกัน) ข้อจำกัดอยู่ที่นี่ซึ่งปรากฏให้เห็นชัดเจนทั้งหมด ท้ายที่สุดแล้วมันค่อนข้างง่ายในการตั้งค่ามาสก์ที่จำเป็นสำหรับส่วนของมาร์กอัปเว็บซึ่งควรระบุตำแหน่งข้อมูลที่เรากำลังมองหา (ซึ่งจำเป็นต้องแยกออก) แต่เราจะบังคับให้ parser ไปยังข้อมูลถัดไปในทันทีได้อย่างไร ส่วนที่คล้ายกันแม้จะมีแท็กและแอตทริบิวต์ HTML ที่เป็นไปได้ทั้งหมดที่สามารถวางไว้ในช่องว่างระหว่างแท็กเหล่านั้นได้
หลังจากคิดสักนิด ฉันจึงตัดสินใจแนะนำรูปแบบการบริการสองสามแบบ (%ทั้งหมด_ก่อน) и (%ทั้งหมด_หลัง)ซึ่งให้บริการตามวัตถุประสงค์ที่ชัดเจนเพื่อให้แน่ใจว่าทุกสิ่งที่อาจมีอยู่ในข้อความต้นฉบับจะถูกข้ามไปก่อนรูปแบบ (มาสก์) ที่ตามมา นอกจากนี้หาก (%ทั้งหมด_ก่อน) เพียงเพิกเฉยต่อการรวมโดยพลการเหล่านี้ทั้งหมด (%ทั้งหมด_หลัง)ในทางตรงกันข้าม อนุญาตให้เพิ่มเข้าไปในแฟรกเมนต์ที่ต้องการหลังจากย้ายจากแฟรกเมนต์ก่อนหน้า ฟังดูค่อนข้างง่าย แต่ในการนำแนวคิดนี้ไปใช้ ฉันต้องรวมแหล่งที่มาของ gorp อีกครั้งเพื่อทำการแก้ไขที่จำเป็น เพื่อไม่ให้ทำลายตรรกะที่นำไปใช้แล้ว ในท้ายที่สุดเราก็สามารถทำเช่นนี้ได้ (แม้ว่าจะเป็นขั้นตอนแรกสุดแม้ว่าจะมีปัญหามากก็ตาม แต่การใช้งาน parser ของฉันก็เขียนขึ้นและเร็วกว่านั้นอีกในสองสามสัปดาห์) จากนี้ไป ระบบจะมีรูปแบบที่เป็นสากลอย่างแท้จริง - ไม่น้อยกว่า 12 ปีหลังจากความพยายามครั้งแรกที่จะทำให้มันใช้งานได้
แน่นอนว่านี่ไม่ใช่จุดสิ้นสุดของความฝันของเรา คุณยังสามารถเขียนตัวแยกวิเคราะห์เทมเพลต gorp ใหม่ใน C# ได้อย่างสมบูรณ์ โดยใช้ไลบรารีใดๆ ที่มีอยู่สำหรับการนำไวยากรณ์ฟรีไปใช้ ฉันคิดว่าโค้ดควรจะเรียบง่ายอย่างมาก และสิ่งนี้จะช่วยให้เราสามารถกำจัดสิ่งเดิมในรูปแบบของซอร์ส Java ที่มีอยู่ได้ แต่ด้วยเอ็นจิ้นประเภทที่มีอยู่ ค่อนข้างเป็นไปได้ที่จะทำสิ่งที่น่าสนใจต่าง ๆ รวมถึงความพยายามในการใช้เมตาเทมเพลตที่ฉันได้กล่าวไปแล้ว ไม่ต้องพูดถึงการแยกวิเคราะห์ข้อมูลต่าง ๆ จากเว็บไซต์ต่าง ๆ (แต่ฉันไม่ปฏิเสธ เครื่องมือซอฟต์แวร์เฉพาะทางที่มีอยู่เหมาะสมกว่าสำหรับสิ่งนี้ – ฉันแค่ยังไม่มีประสบการณ์ที่เหมาะสมในการใช้งาน)
อย่างไรก็ตาม ฤดูร้อนนี้ ฉันได้รับคำเชิญทางอีเมลจากบริษัทที่ใช้เทคโนโลยี Salesforce (ผู้พัฒนาเวอร์ชันดั้งเดิม) กอร์ป) ผ่านการสัมภาษณ์งานครั้งต่อไปในริกา น่าเสียดายที่ในขณะนี้ฉันยังไม่พร้อมสำหรับการปรับใช้ใหม่ดังกล่าว
หากเนื้อหานี้กระตุ้นความสนใจในส่วนที่สองฉันจะพยายามอธิบายรายละเอียดเพิ่มเติมเกี่ยวกับเทคโนโลยีสำหรับการรวบรวมและแยกวิเคราะห์เทมเพลตในภายหลังโดยใช้ตัวอย่างการใช้งานที่ใช้ใน Salesforce กอร์ป (การเพิ่มเติมของฉันเอง ยกเว้นคำฟังก์ชันสองสามคำที่อธิบายไว้แล้ว แทบไม่มีการเปลี่ยนแปลงไวยากรณ์ของเทมเพลตเลย ดังนั้นเอกสารประกอบเกือบทั้งหมดสำหรับระบบดั้งเดิม กอร์ป เหมาะสำหรับรุ่นของฉันด้วย)
ที่มา: will.com