มีอันตรายในการเขียนข้อมูลดิบไปยังไฟล์หรือไม่? [ปิด]

ฉันกำลังทำงานกับปัญหาในการเขียนโปรแกรม Pearls - โดยเฉพาะการใช้งานโปรแกรมที่เรียงลำดับไฟล์ที่มีอย่างน้อย 10,000,000 จำนวนเต็ม (คอลัมน์ 1 ปัญหา 3) เนื่องจากหนังสือไม่ได้ระบุวิธีการจัดเก็บข้อมูลในไฟล์ฉันจึงพิจารณาจัดเก็บจำนวนเต็มเป็นไบต์ดิบ (มีข้อ จำกัด อื่น ๆ ที่ทำให้ตัวเลือกดิบเป็นตัวเลือกที่ดี) ฉันไม่เคยทำงานที่ระดับต่ำนี้มาก่อนดังนั้นฉันต้องการทราบว่ามีสิ่งใดที่อันตรายที่ฉันควรระวัง ฉันต้องกังวลเกี่ยวกับการใช้ลำดับจุดสิ้นสุดของไฟล์โดยไม่ตั้งใจเมื่อฉันเขียนไบต์ดิบไปยังไฟล์หรือไม่?

แก้ไข:

ตอนนี้ฉันรู้แล้วว่าคำถามของฉันกว้างแค่ไหน ฉันหมายถึงปัญหาของความหายนะมากขึ้นเช่นเขียนทับไฟล์อื่น ๆ บนดิสก์โดยไม่ตั้งใจ ขออภัยฉันไม่ชัดเจนในตอนแรก

อันตรายเพียงอย่างเดียวที่คุณจะพบเจอคือความสิ้นหวังน้อยและใหญ่ (ไม่ว่าจะเป็นไบต์ที่สำคัญที่สุด อย่างไรก็ตามหากคุณยังคงอยู่ในสภาพแวดล้อมเดียวกันจะไม่มีปัญหา นอกเหนือจากทั่วไปเพื่อให้มั่นใจว่าการเขียน / การแยกวิเคราะห์ไปกลับ

ระบบไฟล์ถูกออกแบบมาเพื่อจัดการกับลำดับของไบต์ใด ๆ

ไม่ความจริงแล้วนี่เป็นรูปแบบไฟล์ที่ใช้งานได้หลายรูปแบบ ตัวอย่างทั่วไปของไฟล์ไบนารีเช่นนี้รวมถึงรูปภาพและไฟล์เพลง / เสียง

ในการรักษาความสมบูรณ์ของไฟล์และข้อมูลที่อ่านจากไฟล์โปรดปฏิบัติตามแนวทางเหล่านี้:

• เปิดไฟล์ (อ่านหรือเขียน) เสมอโดยใช้โหมดเดียวกัน: ข้อความหรือไบนารี ความแตกต่างหลักคือโหมดข้อความใส่ใจเกี่ยวกับการขึ้นบรรทัดใหม่และอาจ "chomp" ปิดอักขระบรรทัดใหม่เมื่ออ่านไฟล์ (ขึ้นอยู่กับไลบรารีเฉพาะที่ใช้) โหมดข้อความอาจทำการแปล Unicode ที่มีโอกาสสำลักข้อมูลที่ไม่ใช่ Unicode
• เมื่ออ่านข้อมูลที่ไม่ใช่สตริงโปรดอ่านโดยใช้ชนิดข้อมูลเดียวกันกับที่คุณเขียน ตัวอย่างเช่นหากสี่ไบต์แรกของไฟล์เป็นจำนวนเต็มอธิบายให้แน่ใจว่าได้อ่านและเขียนโดยใช้วิธีการที่ / ให้จำนวนเต็มเพื่อให้แน่ใจว่าได้รับการปฏิบัติอย่างสม่ำเสมอ ประเภทข้อมูลเดียวกันอาจมีขนาดแตกต่างกันในเครื่องที่แตกต่างกันและการผสมข้อมูลในเครื่องเดียวกันยังสามารถเปลี่ยนความหมายของข้อมูล (เช่นการตีความบิตในช่วงกลางของจำนวนเต็มอีกต่อไปเป็นบิตบิต)
• Endianness: หากไลบรารีที่คุณใช้ไม่สามารถจัดการสิ่งนี้ได้อย่างสม่ำเสมอคุณอาจต้องจัดการด้วยตนเอง ตัวอย่างเช่น Java ใช้คำสั่งไบต์เครือข่าย (big endian) เสมอสำหรับประเภทหลายไบต์ C และ C ++ ใช้สิ่งที่ผู้ใช้ไลบรารีตัดสินใจโดยทั่วไปเหมือนกับโปรเซสเซอร์ (endian เล็ก ๆ น้อย ๆ ใน Intel, big endian กับคนอื่น ๆ ส่วนใหญ่) หากนี่คือการฝึกหัดอย่างรวดเร็วในระบบใดระบบหนึ่งมันไม่สำคัญ แต่มันก็ยังเป็นนิสัยที่ดีที่จะให้ความสนใจกับเรื่องนี้และใช้รหัสหากจำเป็น

รายละเอียดเฉพาะจะแตกต่างกันไปตามกรอบแพลตฟอร์มและภาษา แต่สิ่งนี้ควรครอบคลุม "gotchas" พื้นฐานด้วยไฟล์ I / O

นอกเหนือจาก gotchas ทั้งหมดที่กล่าวถึงแล้วหากคุณกำลังสร้างรูปแบบไฟล์ไบนารีใหม่แทนที่จะอ่านและเขียนข้อมูลในรูปแบบที่มีอยู่เป็นสิ่งสำคัญอย่างยิ่งที่คุณต้องรวมส่วนหัวของไฟล์ไว้ : บล็อกของข้อมูลที่จุดเริ่มต้น ของไฟล์ที่ระบุรูปแบบไฟล์อย่างไม่น่าสงสัยและบันทึกข้อมูลเมตาใด ๆ ที่อาจจำเป็นต้องใช้

ส่วนหัวไฟล์ที่ดีมีอย่างน้อยสามสิ่ง:

• " หมายเลขเวทมนต์ " อย่างน้อยสี่ไบต์ หมายเลข^{อาถรรพ์}ต้อง^rfc2119เป็น N ไบต์แรกในไฟล์ต้องไม่เคยถูกใช้สำหรับรูปแบบไฟล์อื่น ๆ ที่คุณสามารถขุดขึ้นมาและต้องมีอย่างน้อยหนึ่งไบต์ที่ไม่ใช่อักขระ ASCII ที่พิมพ์ได้ ดูข้อกำหนด PNGสำหรับวิธีการออกแบบหมายเลขเวทย์มนตร์ที่ละเอียดถี่ถ้วน ดูซอร์สโค้ดของfile(1)คำสั่งสำหรับฐานข้อมูลของตัวเลขเวทย์มนตร์ที่มีอยู่ซึ่งมีความครอบคลุมเท่าที่คุณจะหาได้

  จุดของเลขอาถรรพ์คือการกำหนดเลเบลไฟล์ในแบนด์ด้วยรูปแบบของมันอย่างไม่น่าสงสัย หากคุณไม่ได้ใส่หมายเลขเวทย์มนตร์หรือไม่ใช่สิ่งแรกสุดในไฟล์คุณจะเสี่ยงต่อการที่โปรแกรมระบุไฟล์ของคุณผิดประเภทไฟล์ประเภทอื่นซึ่งนำไปสู่การสูญเสียข้อมูลการตรวจจับไวรัสและอื่น ๆ หายนะ

• ข้อบ่งชี้ของเวอร์ชันของรูปแบบไฟล์ แม้ว่าคุณคิดว่าคุณจะไม่ต้องแก้ไขรูปแบบไฟล์ของคุณให้ทำสองไบต์ถัดไปหลังจากเลขอาถรรพ์00 00แล้วเอกสารว่านี่เป็นหมายเลขเวอร์ชัน 16 บิตใน endianness ที่แน่นอน (แล้วแต่จำนวนใดก็ตามที่คุณต้องการ แต่เลือก หนึ่งและติดกับมันตลอดทั้งไฟล์ ) และจะเพิ่มขึ้นหากความหมายของข้อมูลที่ตามมามีการเปลี่ยนแปลงอย่างรุนแรง ตัวคุณในอนาคตจะขอบคุณ

  (สเปค PNG ใช้เส้นทางที่แตกต่างกันที่นี่ระบุว่ารูปแบบของชิ้นข้อมูลจะถูกแช่แข็งและการเปลี่ยนแปลงรูปแบบในอนาคตทั้งหมดจะอยู่ในรูปแบบของชิ้นส่วนแบบใหม่นั้นใช้ได้เช่นกัน แต่ฉันขอแนะนำให้ใช้ ผู้เริ่มต้นจนถึงการประมวลผลข้อมูลแบบไบนารีผู้ที่ออกแบบ PNG นั้นได้รับการรวบรวมจากประสบการณ์ที่สั่งสมมานานหลายทศวรรษด้วยรูปแบบภาพ)

• กลไกบางอย่างสำหรับการฝังข้อมูลเมตาโดยพลการในไฟล์ สิ่งนี้สามารถทำได้ง่ายเหมือนกับการมีสองไบต์ถัดไปเป็นออฟเซ็ต 16 บิตจากจุดสิ้นสุดของส่วนหัวไปยังจุดเริ่มต้นของข้อมูลจริงโดยทุกสิ่งในระหว่างนั้นจะถูกตีความเป็นคู่ค่าคีย์ UTF-8 a la RFC 822 (นั่นคือ " Tag: value\n" - ถ้าคุณไปเส้นทางนี้ฉันไม่แนะนำให้อนุญาตให้พับเส้นยาว) อีกครั้ง PNG นั้นฉลาดกว่ามาก

สถาปัตยกรรมที่แตกต่างมีการแสดงที่แตกต่างกันสำหรับจำนวนเต็ม ความเสี่ยงหลักที่นี่คือการบันทึกการแสดงจำนวนเต็มในเครื่อง A แล้วพยายามอ่านกลับและตีความเนื้อหาเป็นจำนวนเต็มในเครื่อง B หากเครื่อง A และ B มีขนาดแตกต่างกันสำหรับจำนวนเต็มและ / หรือendianness ที่แตกต่างกันคุณ ' จะทำให้เกิดพฤติกรรมที่ไม่ได้กำหนด (เช่นใน C) หรือข้อยกเว้น

เนื่องจากนี่เป็นเพียงตัวอย่างการเขียนโปรแกรมและไม่ใช่โปรแกรม "ของจริง" จึงไม่ใช่ปัญหา หากนี่เป็นโปรแกรมจริงการหมุนรูปแบบไบนารีเฉพาะแอปพลิเคชันของคุณเองนั้นไม่ใช่ความคิดที่ดี มีวิธีแก้ปัญหาที่ดีกว่าเช่น SQLite หรือรูปแบบการทำให้เป็นสตริงแบบสตริงเช่น JSON, YAML, XML เป็นต้นสำหรับค่าเดียวที่เปลี่ยนเป็นสตริงจะเพียงพอ สำหรับรายการง่าย ๆ คุณสามารถบันทึกหนึ่งสายต่อบรรทัดและแยกอินพุตในบรรทัดใหม่เมื่อคุณอ่านกลับมา