내 시스템 Fedora 12에 있는 단일 일반 텍스트 파일의 문제에 대해 완전히 의아해합니다. 저는 생물정보학의 알려진 소프트웨어인 제작자를 사용하여 많은 일반 텍스트 파일을 생성했는데 그 중 하나는 "접근할 수 없는" 것 같습니다.
Clon1918K_PCC1.gff특히 ... 명령을 사용할 때 이름이 지정된 내 파일이 나열되지만 등 ls, ls -a, ls -li으로 액세스하려고 하면 cat, vim, cp, ls항상 동일한 오류가 나타납니다 Clon1918K_PCC1.gff: No such file or directory.
cp *.gff하지만 또는 이 파일 과 함께 모든 파일을 복사하면 해당 cp *파일도 복사됩니다.
또한 문제 없이 노틸러스로 열려고 시도했는데 두 가지 경우 중 하나에서 동일한 이름을 가진 다른 파일에 콘텐츠를 복사하면 문제가 사라집니다. 흥미롭게도 이 경우 이상한 파일이 다시 작성되지 않고 정확히 동일한 이름을 가진 2개의 파일이 나타납니다. 그 중 하나는 액세스 가능하고 다른 하나는 액세스할 수 없습니다. 숨겨진 캐릭터를 찾았지만 모두 괜찮은 것 같습니다.
누군가 이 이상한 사건에 대해 아는 사람이 있나요?? 감사해요!
답변1
동일한 디렉터리에 동일한 이름을 가진 두 개의 파일이 있을 수 없습니다. 파일 이름은 정의에 따라 고유 키입니다.
당신이 가지고 있는 것은 거의 확실히 특별한 성격입니다. 당신이 확인했다는 건 알지만, 정확히 어떻게요? ls *gff | hexdump -C특수 문자가 있는 위치를 찾는 것과 같은 것을 말할 수 있습니다 . 상위 비트가 설정된 모든 바이트(즉, 80및 사이의 16진수 값 FF)는 문제가 발생했음을 나타냅니다. 아래 20(10진수 32)도 특수 문자입니다. 또 다른 힌트는 .의 오른쪽 텍스트 열에 점이 있다는 것입니다 hexdump -C.
UTF-8에는 US ASCII 문자처럼 보이는 문자가 많이 있습니다. US ASCII에서도 1과 l은 비슷하게 보일 수 있습니다. 그런 다음 키릴 문자의 C(U+0421), 그리스 음력 시그마(U+03F9, C와 똑같음), 키릴/그리스어 소문자 'o' 등이 있습니다. 그리고 이것들은 단지 눈에 보이는 것들입니다. 거기에는 보이지 않는 유니코드 문자가 꽤 많이 있을 수 있습니다.
설명:왜 높은 비트가 뭔가 잘못되었음을 의미합니까? 파일 이름 'Clon1918K_PCC1.gff'는 100% 7비트 US ASCII인 것으로 보입니다. 이를 통해 hexdump -C다음과 같은 결과가 생성됩니다.
00000000 43 6c 6f 6e 31 39 31 38 4b 5f 50 43 43 31 2e 67 |Clon1918K_PCC1.g|
00000010 66 66 |ff|
이러한 바이트 값은 0x80모두 7비트 US ASCII 코드 포인트이기 때문에 아래에 있습니다(8번째 비트가 지워짐). 유니코드 코드 포인트 U+0000 ~ U+007F는 기존 7비트 US ASCII 문자를 나타냅니다. U+0080 이상의 코드포인트는 다른 문자를 나타내며 UTF-8에서 2~6바이트로 인코딩됩니다(Linux에서는 man utf8이 작업이 수행되는 방법에 대해 많은 정보를 얻으십시오). 정의에 따라 UTF-8은 US-ASCII 코드 포인트를 그 자체로 인코딩합니다(즉, 16진수 ASCII 문자 41, 유니코드 U+0041은 단일 바이트로 인코딩됩니다 41). 128개 이상의 코드포인트는 2~6바이트로 인코딩됩니다.각각은 8번째 비트가 설정되어 있습니다.. ASCII가 아닌 문자의 존재는 다음을 통해 쉽게 감지할 수 있습니다.스트림을 디코딩하지 않고도. 예를 들어, 파일 이름의 세 번째 문자 'o'(ASCII 6f, U+006F)를 'ο'와 같은 유니코드 문자 'U+03FB GREEK SMALL LETTER OMICRON'으로 바꾼다고 가정해 보겠습니다 . hexdump -C그러면 다음이 생성됩니다.
00000000 43 6c ce bf 6e 31 39 31 38 4b 5f 50 43 43 31 2e |Cl..n1918K_PCC1.|
00000010 67 66 66 |gff|
세 번째 문자는 이제 UTF-8 시퀀스로 인코딩되며 ce bf각 바이트에는 8번째 비트가 설정됩니다. 그리고 이것은 이 경우에 문제가 있다는 신호입니다. 또한 hexdump7비트 ASCII만 디코딩하는 가 단일 UTF-8 문자를 디코딩하지 못하고 ..대신 인쇄할 수 없는 두 문자( )를 표시하는 방법에 유의하세요.
답변2
노틸러스로 파일 이름을 바꾸려고 시도하되 원하는 이름을 입력하십시오(복사하여 붙여넣지 마십시오). 그러면 특수 문자가 확실히 제거됩니다. 사용자에게는 보이지 않지만 OS 및 프로그램에는 표시되는 파일 이름 뒤/앞에 공백이 있을 수도 있습니다. 나는 보통 진짜 이상한 파일 이름을 처리하기 위해 mc를 사용합니다.
답변3
루트킷의 존재를 고려했습니까? 옛날 옛적에 저는 루트킷이 설치된 Solaris 시스템에 액세스할 수 있었습니다. '*01'이라는 이름의 파일은 ls *01또는 로 표시되지 않았지만 ls -altr로 표시되었습니다 echo *01. 특정 파일과 프로세스가 일반적인 상황에서 나타나지 않도록 루트킷 설치 ls(및 기타 여러 실행 파일)가 변경되었습니다. 귀하의 설명은 제가 만난 루트킷과 매우 유사합니다.
답변4
누군가가 이것을 우연히 발견하고 다른 답변을 읽는 경우...~할 수 있었다많은 어려움을 뛰어넘거나 일부 답변에서 말하는 것처럼 와일드카드를 사용하여 도박을 하거나 그냥 사용하십시오 ls -b. 저는 그것을 "바이너리"로 기억합니다.
쉘의 탭 완성은 자동으로 문자를 인용해야 하지만 쉘이 아닌 것을 사용하거나(예: Nautilus) 쉘 이스케이프 인용 스타일을 사용하여 ls다른 명령에 대해 미리 인용된 편리한 문자열을 생성할 수 있습니다. 나는 다른 곳의 또 다른 긴 답변에서 이 이상한 파일 예제를 사용했지만 여기서도 관련이 있습니다.
sauer@lightning:/tmp/test> ls
a??file
sauer@lightning:/tmp/test> ls --quoting-style=shell-escape
'a'$'\t\033''file'
sauer@lightning:/tmp/test> mv -v 'a'$'\t\033''file' regular_filename
renamed 'a'$'\t\033''file' -> 'regular_filename'