Null以文件格式规范终止字符短语

问题描述 投票：0回答：2

我正在为旧的（ish）编写Java编解码器，但仍然是相关的科学file format。参考文档中给出了一个C标题，但是我得到的是当我到达一个特定变量时处理的字节数。我很确定一切都很好，直到以下几行：

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头文件，因此我不能100％确定每个变量要读取多少字节，因为我缺乏实质性的C经验。以下内容摘自参考文献：

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字节？我读过的所有内容都表明它是。

有任何想法吗？

这是我到目前为止唯一的测试文件的hexdump。正如您所看到的，它对于确定所有空值的问题并不是很有帮助。

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
java c++ c
2个回答
0
投票

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

0
投票

我认为你正走在正确的道路上。

不同语言类型中的字节数是不同的，并且通常无益地定义为“短是至少X个字节且不大于int”。

我也不是c-expert，但我认为问题是你使用Java来读取在c中定义的数据类型，你得到的是Java定义的短片大小，而不是原始c程序员理解的大小（以字节为单位）。

您必须在字节数方面协调c-header的期望与Java对类型大小（不同类型的字节计数）的看法。

这有点令人困惑。您是否有大量旧数据需要现在由Java程序处理并且数据是二进制的？如果这是问题，那么你必须让Java解码文件的字节，因为它们是由c编写的，你不能使用Java提供的“readShort readInt”方法，因为它们会读取太多或太少的字节。

您对程序中不同点读取的字节数有一些期望，这表明您正在读取由C写入Java程序的字节流。

我不知道任何图书馆会弥补差异;你将不得不逐字节地读取文件，并使用自定义代码从那些字节汇集预期的数据值，并掌握用于创建数据的c实现的简短字节数。

很高兴我不是你:)

非常好运反正!!!!

编辑：还有，这个：

http://www.javapractices.com/topic/TopicAction.do?Id=42

基本上，如果你有一个字节文件而你不知道编码是什么，你必须使用科学方法来得出最佳猜测。猜测下一个数据类型的字节数，转换为您当前的编码，查看结果，看看它是否合理。冲洗并重复。

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.