【问题标题】:C file reading incorrect number of charsC文件读取不正确的字符数
【发布时间】:2011-08-29 07:50:42
【问题描述】:

我偶然发现了一个问题,我试图读入一个文件,根据 windows,该文件的大小为“87.1 kb”,并在程序中使用 ftell 方法返回“89282”,有效地确认了哪些 windows在说。

那么为什么每个从文件中读取字符的方法都只返回 173 或 174 个字符?

该文件是一个重命名为 .txt 的 .GIF 文件(我正在尝试构建一个可以完全加载数据的程序,因为我正在开发一个下载在线图像并需要对其进行比较的程序)。

到目前为止我已经尝试过:

  • fgetc - 这将返回 173/174 个字符。
  • fread - 与上面相同,这是一个包含 1024 个或更多可用空格的字符串。
  • fgets - 不起作用(因为它不返回已读取的字符数 - 包括空值的字符)。
  • setvbuf - 使用 _IONBF 禁用此功能,甚至提供 1024 或更大的缓冲区仅意味着仍返回 173/174。
  • fflush - 这产生了一个“结果”,虽然是一个否定的结果 - 它返回了“2”个字符而不是“173”。

我完全不知道为什么它读取的内容不超过 173/174 个字符。有什么我需要在较低的水平上补偿或期望的吗?一些我需要扩展的缓冲区或一些我需要注意的奇怪字符?

【问题讨论】:

  • 尝试发布调用上述函数的代码。 AFAIK,如果您可以访问文件(fopen 不返回 NULL),您应该完全能够读取数据。
  • 问题不是处于二进制模式。我可以扇自己一巴掌。
  • 天哪,我也有这样的日子 :-) 很高兴你发现了问题!

标签: c file-io


【解决方案1】:

这里有一件事要看。在十六进制查看器中查看文件,看看 173/174 偏移附近是否有 CTRL-Z。

然后检查您是否使用"r" 模式打开它。

如果是这样,可能是因为 CTRL-Z 是文本模式下的 EOF 标记,文本和二进制文件之间的 Windows 转换正在停止您的阅读。如果是这样,您可能可以在fopen 上使用"rb" 模式解决此问题。

否则,您需要发布表现出问题行为的最小代码段。这对我们中的一些人来说可能很明显,但通常只有在我们能看到代码的情况下:-)

【讨论】:

  • 很有可能,因为它是一个图像文件,因此不受文本文件的限制。我会在二进制模式下尝试一下,看看有什么结果。
  • 是的。它是。这样的新手错误。为什么每当我发布堆栈溢出时,尽管看起来很复杂,但它总是一个简单的疏忽。
猜你喜欢
  • 2018-02-07
  • 1970-01-01
  • 2020-08-01
  • 1970-01-01
  • 2020-10-20
  • 1970-01-01
  • 1970-01-01
  • 2017-07-13
  • 2021-12-21
相关资源
最近更新 更多