☰

파일에 실제로 EOF(파일 끝) 문자가 포함되어 있습니까? [복사]

tag-icon • tag-icon files ascii
파일에 실제로 EOF(파일 끝) 문자가 포함되어 있습니까? [복사]

이것정지궤도 운용환경위성(GOES)-R 제품 사용자 가이드(PUG)NOAA(National Oceanic and Atmospheric Administration)의 문서에는 일반 텍스트 파일(§4.3)에 대한 다음과 같은 다소 긴 설명이 포함되어 있습니다(강조 항목).

Unix 텍스트 파일 형식은 레벨 1b 및 레벨 2+ 반정적 소스 데이터 파일의 작은 하위 집합에 사용됩니다. Unix 텍스트 파일 형식(파일 끝 문자 제외)은 제품 메타데이터 값을 포함하여 netCDF 파일 사양의 XML 기반 NcML(netCDF Markup Language) 표현을 저장하기 위해 GRB 메타데이터 패키지에 포함되어 있습니다. .

Unix 텍스트 파일 형식은 가변 길이일 수 있는 전자 텍스트의 일련의 행(예: 레코드)입니다. GOES-R 지상 시스템의 경우 전자 텍스트, 줄 바꿈 및 파일 끝 문자는 미국 정보 교환 표준 코드(ASCII)를 준수합니다. 각 줄의 끝은 개행 문자입니다.파일 끝에는 파일 끝 문자가 있습니다..

파일 내용에 대한 정확한 설명인가요? 파일 끝은 파일(또는 다른 스트림)에서 더 이상 데이터를 읽을 수 없을 때 운영 체제나 라이브러리 루틴이 반환하는 조건이라고 생각합니다. 이 바이트가 실제로 파일에 포함되어 있습니까?

답변1

Unix 텍스트 파일 형식은 가변 길이일 수 있는 전자 텍스트의 일련의 행(예: 레코드)입니다. 각 줄의 끝은 개행 문자입니다.파일 끝에는 파일 끝 문자가 있습니다.

파일 내용에 대한 정확한 설명인가요?

마지막 굵은 글씨 부분까지만 가능합니다. 그러나 나는 파일 끝 문자를 사용하는 Unixy 시스템을 모릅니다. 그들은 모두 파일 길이를 1바이트로 저장하므로 그러한 표시가 필요하지 않습니다.

그러나 일부 시스템에서는 파일 끝 문자를 사용하는 것 같습니다. 적어도위키피디아의 주장저것:

CP/M 파일 시스템은 128바이트 "레코드"의 배수로만 파일 길이를 기록하므로 일반적으로 Ctrl-Z 문자는 레코드 중간에서 끝나는 경우 의미 있는 데이터의 끝을 표시하는 데 사용됩니다.

파일 길이가 하나의 블록에만 저장된 경우 데이터 스트림의 마지막 줄 끝을 인코딩하려면 일부 사용자 정의가 필요합니다. 물론 이진 데이터를 처리하는 모든 프로그램은 어떤 방식으로든 더 세분화된 파일 크기도 처리해야 합니다. 그러나 바이너리 파일의 경우 뒤에 오는 "추가" 바이트를 무시하는 것이 더 쉬울 수 있습니다.

MS-DOS에서 Control-Z가 EOF 표시로 사용되는 것을 본 것 같지만 거기에서도 그럴 필요는 없습니다.

인용된 텍스트는 현재 시스템에 어떤 텍스트 파일이 있는지 잘못 알고 있는 것 같습니다. 우리가 보면POSIX 표준의 조항은 무엇입니까?, NUL 바이트를 포함하지 않고 줄(개행 문자로 끝나는)로 구성된다는 점을 제외하고는 파일 끝 문자나 텍스트 파일에 대한 표시에 대한 언급이 없습니다.

또한보십시오:파일의 마지막 문자는 무엇입니까?

이 부분에 관해서는...

GOES-R 지상 시스템의 경우 [...] 및 파일 끝 문자는 ASCII(American Standard Code for Information Interchange)를 따릅니다.

다른 사람들이 의견에서 말했듯이 ASCII에는 적어도 해당 이름 (*) 에는 파일 끝 문자가 없습니다 . 위에서 언급한 Control-Z는 26 또는 "대체"(SUB)로 "잘못되거나 유효하지 않은 문자를 나타내는 데 사용됩니다." 따라서 해당 텍스트만으로는 EOF 문자가 무엇인지(사용된 경우) 알기 어렵습니다.

(*"End of Text"(ETX, 코드 3), "End of Transfer"(EOT, 코드 4), "End of Transfer Block"(ETB, 23), "End of Medium"(EOM, 25)이 있습니다. 그리고 "파일로 구분된" 부적”(FS, 28)도 있습니다.

파일 끝은 파일(또는 다른 스트림)에서 더 이상 데이터를 읽을 수 없을 때 운영 체제나 라이브러리 루틴이 반환하는 조건이라고 생각합니다.

물론. read()파일 끝에 도달하면 시스템 호출은 0바이트(오류 없음)를 반환하고 일부 stdio 함수( getchar())에는 놀랍지도 않게 호출되는 반환 특수 값이 있습니다 EOF.

또한보십시오:EOT와 EOF의 차이점

답변2

이는 그들이 논의하고 있는 파일 형식에 매우 구체적으로 보입니다. 일반적으로 파일에는 EOF 문자가 필요하지 않습니다. Non는 프로그램이 명시적으로 작성하지 않고 추가됩니다.

ASCII 테이블을 확인해 보니 EOF 문자가 보이지 않습니다. EOT 또는 FS 역할을 언급할 수도 있지만 이는 확실하지 않습니다.https://www.cs.cmu.edu/~pattis/15-1XX/common/handouts/ascii.html

그러나 일부 파일 형식에서는 파일 끝에 마커를 추가하는 것이 일반적입니다. 특히 통신을 위한 간단한 파일 형식입니다. 이렇게 하면 파일이 실수로 잘리는 것을 방지할 수 있습니다. 파일이 특정 표시로 끝나야 하고 해당 표시가 끝 부분에만 나타나는 경우 파일 전체를 받았는지 아니면 일부만 받았는지 쉽게 알 수 있습니다. 내가 읽어보니 그들은 이런 종류의 표시를 언급하고 있었습니다.

답변3

그들이 언급하는 "파일 끝" 문자는 파일의 마지막 문자로 나타나는 단일 개행 문자일 수 있습니다. UNIX 및 UNIX 유사 시스템의 대부분의 기존 텍스트 파일은 명령 cat(또는 유사한 명령)을 사용하여 파일 내용을 표시하고 다음 명령 프롬프트가 자체 줄에 있는지 확인할 수 있도록 이러한 방식으로 끝납니다 .

일부 제대로 작동하지 않는 응용 프로그램은 최종 개행 문자가 표시되지 않으면 실제로 파일을 올바르게 구문 분석하지 못합니다. 이런 점에서 이는 UTF-8로 인코딩된 텍스트의 유니코드 바이트 순서 표시와 약간 비슷합니다. 이는 전혀 필요하지 않지만(사실 대부분의 표준에 따르면 존재하지 않아야 함) 일부 응용 프로그램에서는 해석을 거부합니다. UTF-8에는 없기 때문입니다.

그러나 운영 체제 자체의 관점에서 보면 그러한 "역할"은 존재하지 않습니다. 파일 시스템은 파일의 정확한 크기를 저장하고, 파일을 읽으라는 요청을 받으면 운영 체제는 단일 문자는 물론 그러한 개념을 갖는 것조차 의미가 없을 정도로 총체적으로 너무 많은 데이터를 반환합니다.

어떤 사람들은 EOT 제어 코드(^D)가 UNIX 계열 시스템에서 대화형 입력 스트림의 끝을 나타 내기 위해 널리 사용되기 때문에 이 개념과 혼동하지만 이는 원래 사용법에서 파생된 규칙일 뿐입니다(끝을 나타 내기 위해). ). 일부 통신 링크를 통해 전송됨) 이는 ^Z가 대화형 입력 및 실제 파일에서 실제로 파일 끝을 나타내는 데 사용되는 DOS 시스템과 크게 다릅니다. EOT 제어 코드는 실제로 애플리케이션이 보는 데이터 스트림에 나타나지 않습니다. 터미널에서 해석되어 ^D를 발견하면 애플리케이션에 파일 끝 조건을 알립니다.

관련 정보