C fseek为32位无符号偏移量

我正在读取一种文件格式（TIFF），它从文件开头开始有32位无符号偏移量

不幸的是，fseek的原型（我通常使用的处理特定文件偏移量的方法）是：

int fseek ( FILE * stream, long int offset, int origin );

---

所以偏移量是有符号的。我该如何处理这种情况？我应该使用不同的函数进行搜索吗？

您可以尝试使用

lseek64（）

（）

来自

此函数类似于lseek函数。不同之处在于，offset参数的类型是off64\u t而不是off\u t，这使得在32位计算机上可以寻址大于2^31字节、最多2^63字节的文件。必须使用open64打开文件描述符filedes，否则off64\t可能产生的较大偏移量将导致小文件模式下的描述符出错

当源文件在32位机器上使用_file_OFFSET_BITS==64编译时，此函数实际上在名称lseek下可用，因此可以透明地替换32位接口

关于

fd

和

stream

，来自

由于流是根据文件描述符实现的，因此可以从流中提取文件描述符，并直接在文件描述符上执行低级操作。您还可以首先将连接作为文件描述符打开，然后将流与该文件描述符关联

---

在更深入地研究这个问题并考虑其他注释和答案（谢谢）之后，我认为最简单的方法是在偏移量大于2147483647字节时进行两次搜索。这允许我将偏移保持为

uint32\u t

，并继续使用

fseek

。因此，定位代码如下所示：

// note: error handling code omitted
uint32_t offset = ... (whatever it is)
if( offset > 2147483647 ){
   fseek( file, 2147483647, SEEK_SET );
   fseek( file, (long int)( offset - 2147483647 ), SEEK_CUR );
} else {
   fseek( file, (long int) offset, SEEK_SET );
}

使用64位类型的问题是代码可能在32位体系结构上运行（除其他外）。有一个函数

fsetpos

，它使用结构

fpos\u t

来管理任意大的偏移量，但这会带来一系列复杂性。虽然

fsetpos

如果我真的使用任意大的偏移量可能会有意义，因为我知道最大的可能偏移量是uint32\t，那么双寻道就满足了这一需要

---

请注意，此解决方案允许在32位系统上处理所有TIFF文件。如果你考虑像PixInsight这样的商业计划的话，这是显而易见的。在32位系统上运行时，PixInsight只能处理小于2147483648字节的TIFF文件。要处理完整大小的TIFF文件，用户必须在64位计算机上使用64位版本的PixInsight。这可能是因为PixInsight程序员使用64位类型在内部处理偏移量。因为我的解决方案只使用32位类型，所以我可以在32位系统上处理全尺寸的TIFF文件（只要底层操作系统可以处理这么大的文件）。

您使用的是什么操作系统？您使用的是32位体系结构吗？@melpomene该代码需要在32位和64位体系结构上工作，并且可以在不同的机器和操作系统上运行。大于2或4 jiggabytes的TIFF文件并不少见。您的CRT有一个需要长时间参数的替代方案，您必须查看它的文档。

fseeko

是否更适合替代

fseek

lseek64

不适用于

文件*

lseek64

使用

fd

，但在答案顶部附近，有一种方法可以从

文件*

中检索

fd

，

int-fd=fileno（流）

（）弄乱

文件的底层文件描述符听起来像是混淆stdio和损坏数据的好方法。我不需要寻址大于2^31字节的文件。它可以是32位，它必须是无符号的32位。@TylerDurden那么我不理解这个问题。
fseek
有什么问题？
  int fd = fileno (stream);

// note: error handling code omitted
uint32_t offset = ... (whatever it is)
if( offset > 2147483647 ){
   fseek( file, 2147483647, SEEK_SET );
   fseek( file, (long int)( offset - 2147483647 ), SEEK_CUR );
} else {
   fseek( file, (long int) offset, SEEK_SET );
}