java - 文件格式规范中的空终止字符短语

Question

我正在为一个旧的(ish)但仍然相关的科学编写一个Java编解码器file format 。引用文档中给出了 C header ，但我在到达特定变量时处理的字节数不足。我很确定一切都很好，直到出现以下几行:

b = new byte[9];
in.readFully(b);
this.fres = new String(b); //37-45
b = new byte[9];
in.readFully(b);
this.fsource = new String(b);
this.fpeakpt = in.readUnsignedShort(); //46-54
//this.fpeakpt = in.readUnsignedShort();
b = new byte[4];
this.fspare = new Float[8]; //55-86
for (int i = 0; i < 7; i++) {
    in.readFully(b);
    this.fspare[i] = ByteBuffer.wrap(b).getFloat();
}
b = new byte[130];
in.readFully(b);
this.fcmnt = new String(b);//87-216

注释中的数字是自文件开头以来读取的字节数。不幸的是，引用是一个 C 头文件，因此由于我缺乏丰富的 C 经验，我不能 100% 确定每个变量要读取多少字节。以下摘自引用:

char  fres[9]; /* Resolution description text (null terminated) */
char  fsource[9]; /* Source instrumentdescription text (null terminated) */
WORD  fpeakpt; /* Peak point number for interferograms (0=not known) */
float  fspare[8]; /* Used for Array Basic storage */
char  fcmnt[130]; /* Null terminated comment ASCII text string */

fres 在调试时似乎没问题 - 它读取的字符串以实际字符开头，以额外空格结尾，并包含有意义的信息。然而，fcmnt 字符串在任何文本之前都有 4 个额外空格，并且在我的代码末尾读取的总字节数减少了 4 个字节。我的一个问题是 readUnsignedShort 读取的字节数是否与 WORD 相同。 1996 年，一个 WORD 是 4 个字节吗？我读过的所有内容都表明确实如此。

有什么想法吗？

这是迄今为止我得到的唯一测试文件的十六进制转储。正如您所看到的，这对于确定所有空值的问题没有多大帮助。

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  00 4B 00 02 32 07 00 00 00 00 00 80 15 41 AF 40  .K..2......€.A¯@
00000010  FF FF FF FF F1 16 7C 40 01 00 00 00 01 02 00 00  ÿÿÿÿñ.|@........
00000020  B6 23 83 7C 34 2E 30 20 43 4D 2D 31 00 00 00 00  ¶#ƒ|4.0 CM-1....
00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000040  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000050  00 00 00 00 00 00 00 00 54 65 78 74 67 6F 65 73  ........Textgoes
00000060  68 65 72 65 74 65 78 74 67 6F 65 73 68 65 72 65  heretextgoeshere
00000070  74 65 78 74 67 6F 65 73 68 65 72 65 00 00 00 00  textgoeshere....
00000080  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000090  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000100  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000110  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000120  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000130  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000140  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000150  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
etc. the nulls continue for awhile

Answer 1

我认为它就像规范中第一个值之前的 36 字节文件头一样简单。