^ @ ^ @ ^ @ หมายถึงอะไรในไฟล์ข้อความ?

บางครั้งผมก็มีปัญหาเกี่ยวกับการเปิดไฟล์โดยใช้โปรแกรมแก้ไขข้อความกราฟิก - geanyฉันใช้ ไฟล์สามารถอ่านได้โดยvimไม่มีปัญหา ฉันตรวจสอบไฟล์และไม่มีอะไรผิดปกติยกเว้นบางบรรทัด นี่เป็น.bash_historyไฟล์ตัวอย่าง:

 776 reboot
 777 ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^     @^@^@^@^@^@^@geany /etc/fstab
....
....
 823 reboot 
 824 ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@exit

ผมไม่ทราบว่าสิ่งที่^@เป็น geanyแต่หลังจากที่ถอดแต่ละบรรทัดเลยก็ว่าได้ไฟล์สามารถอ่านได้อีกครั้งใน บางทีการรีบูตอาจทำอะไรกับมันบ้าง? แต่ฉันมีrebootรายการอื่น ๆในไฟล์และ^@ตัวละครปรากฏในสองหรือสามแห่งเท่านั้น

นี่เป็นเพียงไฟล์ตัวอย่างฉันเห็นตัวละครในไฟล์อื่น ๆ สิ่งหนึ่งที่ดูเหมือนจะเหมือนกัน - มันเกี่ยวข้องกับไฟล์ขนาดใหญ่เท่านั้นผู้ที่มีหลายบรรทัด

ไม่มีใครรู้^@ว่ามันมาจากไหนและทำไมvimไม่มีปัญหากับการอ่านไฟล์ในขณะที่geanyไม่สามารถอ่านได้เลย?

files editors

— มิคาอิล Morfikov
แหล่งที่มา

พวกเขาเป็นตัวละครโมฆะโดยทั่วไป สิ่งนี้อาจให้ข้อมูลเพิ่มเติมแก่คุณ: stackoverflow.com/questions/2398393/…

— mkc

ฉันจะตรวจสอบการเชื่อมโยงและสถานการณ์ที่อธิบายและมีความกังวล superuser UTF-16 แต่ไฟล์ที่ผมมีเป็นรหัส UTF-8 /root/.bash_history: UTF-8 Unicode text, with very long lines- ความแตกต่างอีกอย่างคือพวกเขามี^@ตัวละครแต่ละตัวระหว่างกัน แต่ในกรณีของฉันฉันมีทั้งบรรทัด^@และมันเกิดขึ้น 2-3 ครั้งในไฟล์บางไฟล์เท่านั้น

— Mikhail Morfikov

คำถามที่เกี่ยวข้องคือunix.stackexchange.com/questions/477537

— JdeBP

เมื่อคุณเคยมีตัวละครจรจัดในไฟล์ที่คุณสามารถเกณฑ์ความช่วยเหลือของเครื่องมือหรือodhexdump

ตัวอย่าง

ก่อนอื่นเราจะแสดงสิ่งที่ฐานแปด ( od) แสดงเมื่อเราบอกให้ทิ้งเนื้อหาของไฟล์a.txtในรูปแบบเลขฐานสิบหก ( -x)

$ od -x a.txt 
0000000 3737 2036 6572 6f62 746f 370a 3737 0020
0000020 0000 0000 0000 0000 0000 0000 0000 0000
*
0000140 0000 0000 0000 0000 0000 0000 0000 6567
0000160 6e61 2079 652f 6374 662f 7473 6261 380a
0000200 3332 7220 6265 6f6f 2074 380a 3432 0020
0000220 0000 0000 0000 0000 0000 0000 0000 0000
*
0000320 7865 7469 000a
0000325

เราสามารถใช้hexdumpทำสิ่งที่คล้ายกันโดยแสดงข้อมูลในรูปแบบเลขฐานสิบหกอย่างไรก็ตามมันจะแสดงค่าเป็นอักขระ ASCII หากเป็นไปได้

hexdump

$ hexdump -C a.txt 
00000000  37 37 36 20 72 65 62 6f  6f 74 0a 37 37 37 20 00  |776 reboot.777 .|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 67 65  |..............ge|
00000070  61 6e 79 20 2f 65 74 63  2f 66 73 74 61 62 0a 38  |any /etc/fstab.8|
00000080  32 33 20 72 65 62 6f 6f  74 20 0a 38 32 34 20 00  |23 reboot .824 .|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000000d0  65 78 69 74 0a                                    |exit.|
000000d5

เมื่อดูที่ผลลัพธ์ข้างต้นคุณจะสังเกตเห็นลำดับหลาย00 00 00ๆ นี่คือ^@ตัวละครที่คุณถามถึงตอนแรก

บังเอิญว่าตัวละคร00เป็นตัวละครโมฆะ

— slm
แหล่งที่มา

แต่พวกเขากำลังทำอะไรอยู่ในไฟล์ พวกเขาไปถึงที่นั่นได้อย่างไร

— Mikhail Morfikov

พวกมันดูเหมือนอักขระขยะที่ได้รับมาเมื่อคุณกดปุ่ม Backspace บนบรรทัดคำสั่งหรือคัดลอก / วางของคำสั่งที่รันก่อนหน้านี้ซึ่งมีอักขระขยะพิเศษรวมอยู่โดยไม่ตั้งใจ หรืออักขระควบคุมจากพรอมต์ของคุณรวมอยู่ แต่ถูกแปลงเป็นโมฆะเนื่องจากเป็นอักขระที่ไม่สามารถพิมพ์ได้

— slm

ฉันพยายามที่จะทำซ้ำตามสิ่งที่คุณพูด แต่ดูเหมือนจะไม่มีอะไรทำงาน อาจจะเป็นความผิดของเครื่อง? ตอนนี้ฉันใช้อันอื่นอยู่

— มิคาอิล Morfikov

สาเหตุทั่วไปอื่น ๆ ของ NULs ในไฟล์ข้อความคือ: 1. กระบวนการตัดทอนไฟล์ในขณะที่กระบวนการอื่นกำลังเขียนอยู่ดังนั้นกระบวนการที่สองของการเขียนจึงผ่าน EOF ปัจจุบันไปทันทีช่องว่างจึงกลายเป็นช่องว่างที่จัดสรรเป็นศูนย์ทั้งหมด 2. ไฟล์ถูกแก้ไขก่อนระบบล่มและระบบไฟล์กู้คืนขนาดไฟล์โดยไม่ต้องกู้คืนข้อมูลทั้งหมด

@ WumpusQ.Wumbley - ขอบคุณที่ให้เหตุผลที่เป็นไปได้มากกว่านี้!

— slm