C 文件读取错误的字符数
我偶然发现了一个问题，我试图读入一个文件，根据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 个字符的内容。我需要在较低级别补偿或期望什么吗？我需要扩展一些缓冲区或者我需要留意一些奇怪的字符？
I have stumbled across a problem where I am attempting to read in a file, which is, according to windows, '87.1 kb' in size, and using the ftell method in program, returns '89282', effectively confirming what windows is saying.
So why is every method to read chars from the file only returning 173 or 174 characters?
The file is a .GIF file renamed to .txt (and I am trying to build a program that can load the data fully as I am working on a program to download online images and need to run comparisons on them).
So far I have tried:
- fgetc - This returns 173/174 chars.
- fread - Same as above, this is with a string with 1024 or more spaces available.
- fgets - Doesn't work (as it doesn't return how many characters it has read - characters which include nulls).
- setvbuf - Disabling this with _IONBF, or even supplying a buffer of 1024 or more only means 173/174 is still returned.
- fflush - This produced a 'result', although a negative one - it returned '2' chars instead of '173'.
I am utterly stumped as to why it isn't reading anything more than 173/174 chars. Is there something I need to compensate for or expect at the lower level? Some buffer I need to expand or some weird character I need to look out for?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
有一点值得关注。在十六进制查看器中查看该文件，看看 173/174 偏移量周围是否有 CTRL-Z。
然后检查是否使用
"r"模式打开它。如果是这样，则可能是文本和二进制之间的 Windows 转换阻止了您的阅读，因为 CTRL-Z 是文本模式下的 EOF 标记。如果是这样，您可以使用
fopen上的"rb"模式修复此问题。如果做不到这一点，您需要发布显示问题行为的最小代码段。对于我们中的一些人来说这可能是显而易见的，但通常只有在我们能看到代码的情况下:-)
Here's one thing to look at. Have a look at the file in a hex viewer and see if there's a CTRL-Z somewhere around that 173/174 offset.
Then check to see if you're opening it with the
"r"mode.If so, it may be that the Windows translation between text and binary is stopping your reading there because CTRL-Z is an EOF marker in text mode. If so, you can probably fix this with
"rb"mode on thefopen.Failing that, you need to post the smallest code segment that exhibits the problem behaviour. It may be obvious to some of us here but only usually if we can see the code :-)