golang bufio.Read 或 bufio.ReadByte 检测文件是否在 EOF

Question

我想通过尝试再读取一个字节(并捕获 EOF)来确认没有更多的字节可以从缓冲读取器(既不是来自内部缓冲区，也不是来自底层文件对象)中读取。

使用 bufio.Read 或 bufio.ReadByte 是否适合此目的？

从bufio.Read看不清楚documentation在非 EOF 情况下，返回的整数是否可以为零。即，如果 len(p) > 0，0, nil 是有效的返回值吗？

func (b *Reader) Read(p []byte) (n int, err error)

Read reads data into p. It returns the number of bytes read into p. The bytes are taken from at most one Read on the underlying Reader, hence n may be less than len(p). To read exactly len(p) bytes, use io.ReadFull(b, p). At EOF, the count will be zero and err will be io.EOF.

同样，bufio.ReadByte 文档并没有很好地将错误情况与 EOF 情况区分开来，也没有准确定义“可用”的含义(即在内部缓冲区中可用) ，或在基础文件中可用)？

func (b *Reader) ReadByte() (byte, error)

ReadByte reads and returns a single byte. If no byte is available, returns an error.

Answer 1

将长度为 1 的缓冲区传递给 bufio.Read，当读取器得到底层 os.File 的支持时，确实会返回 n==0 , io.EOF 如果文件在 EOF。

文档有点不精确，因为某些行为取决于您传递给 bufio 阅读器的底层阅读器。 bufio.Read() 的代码画出更准确的画面。我将概述逻辑。

bufio.Read:只有在内部缓冲区中的所有字节都已用完时，才会向底层读取器发出一个Read。因此，据推测，如果您已经从缓冲读取器中读取的字节数与底层文件中的字节数一样多，那么当您最后一次调用 bufio.Read(buf[0: 1]) 检查 EOF。

当内部缓冲区耗尽时，您向 bufio 读取器请求更多，bufio.Read 将最多 调用一次底层读者。您得到的错误类型将取决于您的底层读者。

当读取指针已经位于 EOF 时，要求从 os.File 读取 n > 0 字节应该返回 0, io.EOF(根据 os.File File.Read 上的文档)。但是，如果您的底层读取器是其他东西，也许是特定于您的应用程序的自定义类型，旨在在 EOF 处返回 0, nil，那么 bufio.Read 会回显它。

bufio.ReadByte:bufio.ReadByte背后的逻辑略有不同，但在底层读取器是 os.File 的情况下，结果应该与 bufio.Read 相同。与 bufio.Read 的主要区别在于 bufio.ReadByte 可以多次尝试重新填充内部缓冲区。如果在重新填充期间遇到错误(对于 EOF 处的 os.File 读取器就是这种情况)，它将在第一次错误读取尝试后返回。因此，如果您的底层阅读器是一个 os.File 阅读器，那么您将获得 0, io.EOF 当且仅当您的底层文件位于 EOF。如果您的底层阅读器是自定义阅读器类型，它仅在 EOF 处返回 0, nil，则 bufio.ReadByte 最终会发出“NoProgress”错误。我不确定为什么重试逻辑仅在 bufio.ReadByte 中，但好消息是如果您的基础文件的行为类似于 os.File，则可以使用任一选项>.

其他信息:

这并不直接适用于 golang，但您可能会发现以下线程很有趣:Can read(2) return zero bytes when not at EOF .它的主题是 read() 系统调用的语义 (POSIX)。读取非阻塞套接字/文件，即使没有数据准备好，也应该返回 -1，而不是 0，并设置 errno EAGAIN(或中断时的 EINTR)。非阻塞套接字/文件并不是真正的原生概念(据我所知)，特别是 bufio 模块将 panic() 无论何时/如果底层读取器返回负数，因此您不必担心。