Os arquivos realmente contêm um caractere de fim de arquivo (EOF)? [duplicado]

O formato de arquivo de texto Unix é uma sequência de linhas (ou seja, registros), potencialmente variável em comprimento, de texto eletrônico. No final de cada linha está o caractere de nova linha. No final do arquivo, há um caractere de final de arquivo.

Esta é uma descrição precisa do conteúdo de um arquivo?

Até, mas excluindo a última parte em negrito, sim. Mas não conheço nenhum sistema Unixy que use um caractere de fim de arquivo, todos eles armazenam o comprimento de um arquivo em um byte, tornando esses marcadores desnecessários.

Então, novamente, parece que houve sistemas que usaram um caractere de fim de arquivo. Pelo menos a Wikipedia afirma que:

O sistema de arquivos CP/M registrava apenas os comprimentos dos arquivos em múltiplos de "registros" de 128 bytes, portanto, por convenção, um caractere Control-Z era usado para marcar o fim de dados significativos se eles terminassem no meio de um registro.

Ter comprimentos de arquivo armazenados apenas até um bloco exigiria algum tipo de customização para codificar o final da última linha dentro do fluxo de dados. Qualquer programa que manuseie dados binários também teria que lidar com os tamanhos de arquivo mais granulares de alguma forma. No entanto, com arquivos binários, pode ser mais fácil ignorar os bytes "extras" à direita.

Acho que vi Control-Z usado como marcador EOF no MS-DOS, mas também não era necessário.

Esse texto citado parece ter uma ideia equivocada de arquivos de texto nos sistemas atuais. Se observarmos o que o padrão POSIX diz , não há menção a um caractere ou marcador de final de arquivo para arquivos de texto, apenas que eles não contêm bytes NUL e consistem em linhas (terminando em novas linhas).

Veja também: Qual é o último caractere em um arquivo?

Quanto a esta parte...

Para o sistema de solo GOES-R, [...] e os caracteres de fim de arquivo estão em conformidade com o Código Padrão Americano para Intercâmbio de Informações (ASCII).

Como outros disseram nos comentários, não há caractere para fim de arquivo em ASCII, pelo menos não com esse nome ^(*) . Control-Z mencionado acima é 26, ou "substituto" (SUB), "usado para indicar caracteres ilegíveis ou inválidos". Então, com base apenas nesse texto, seria difícil saber qual seria o caractere EOF, se fosse usado.

_{(* Há "fim de texto" (ETX, código 3), "fim de transmissão" (EOT, código 4), "fim de bloco de transmissão" (ETB, 23), "fim de meio" (EOM, 25) e também "separador de arquivos" (FS, 28). Fechado, mas não exato.)}

Eu pensei que o fim do arquivo era uma condição que o sistema operacional ou uma rotina de biblioteca estava retornando quando não mais dados podem ser lidos de um arquivo (ou outro fluxo).

Isso é o que é, de fato. A chamada do sistema read()retorna zero bytes (sem erro) quando o final de um arquivo é atingido, enquanto algumas funções stdio ( getchar()) têm um valor especial de retorno para ele, sem surpresa chamado EOF.

Veja também: Diferença entre EOT e EOF

Isso parece ser algo muito específico para o formato de arquivo que eles estão discutindo. Como regra geral, os arquivos não PRECISAM de um caractere EOF. Non é adicionado sem um programa explicitamente escrevendo um.

Verificando uma tabela ASCII, não vejo um caractere EOF. Eles podem estar se referindo a um personagem EOT ou FS, mas isso não está claro. https://www.cs.cmu.edu/~pattis/15-1XX/common/handouts/ascii.html

No entanto, é comum em alguns formatos de arquivo colocar um marcador no final do arquivo. Particularmente em formatos de arquivo simples que se destinam à comunicação. Isso protege contra arquivos truncados inadvertidamente. Se você sabe que um arquivo deve terminar com um marcador específico, e esse marcador só vem no final, o. Você pode facilmente dizer se recebeu o arquivo inteiro ou apenas parte dele. Conforme eu leio, eles estão se referindo a esse tipo de marcador.

O caractere 'fim do arquivo' ao qual eles estão se referindo é provavelmente uma única nova linha ocorrendo como o último caractere no arquivo. A maioria dos arquivos de texto convencionais em sistemas UNIX e semelhantes a UNIX terminam de tal maneira que você pode usar o catcomando (ou algo similar` para exibir o conteúdo do arquivo e ter certeza de que o próximo prompt de comando estará em sua própria linha.

Alguns aplicativos mal comportados, na verdade, não conseguem analisar os arquivos corretamente se não virem essa nova linha final. A esse respeito, é um pouco como a marca de ordem de byte Unicode no texto codificado em UTF-8, não é necessária (na verdade, nem deveria estar lá de acordo com a maioria dos padrões), mas alguns aplicativos se recusam a interpretar as coisas como UTF-8 sem ele.

Da perspectiva do próprio sistema operacional, porém, não existe tal 'personagem'. O sistema de arquivos armazena o tamanho correto para o arquivo e, quando solicitado a ler o arquivo, o sistema operacional retorna exatamente essa quantidade de dados no total, portanto, não faz sentido ter esse conceito, muito menos ter um caractere para ele.

Algumas pessoas confundem o código de controle EOT (^D) com este conceito, pois é amplamente usado em sistemas do tipo UNIX para sinalizar o fim de um fluxo de entrada interativa, mas isso é apenas uma convenção derivada do uso original (para sinalizar o fim de uma transmissão através de algum link de comunicação). Observe que isso é significativamente diferente dos sistemas DOS, onde ^Z foi usado para sinalizar o final de um arquivo tanto na entrada interativa quanto nos arquivos reais. O código de controle EOT na verdade não aparece no fluxo de dados que o aplicativo vê, é interpretado pelo terminal que sinaliza uma condição de fim de arquivo para o aplicativo quando encontra ^D.