检查类型为“NeXT / Apple typedstream”的文件。版本4（NSArchiver） [英] Inspecting files of type "NeXT/Apple typedstream" version 4 (NSArchiver)
问题描述
对于数据恢复程序，我需要能够从NSArchiver编写的文件中提取值+类型，而无需访问Apple的CF / NS框架。
For a data recovery program I need to be able to extract the values+types from files written by NSArchiver, without having access to Apple's CF / NS frameworks.
OS X 文件命令报告以下文件：
The OS X file command reports such files as:
NeXT/Apple typedstream data, little endian, version 4, system 1000
是否有关于如何编码这些文件的文档，或者是否有人提出可以解析它们的代码？
Is there any documentation on how these files are encoded, or has anyone come up with code that can parse them?
以下是此类数据的示例（同样：可下载）：
Here's an example of such data (also: downloadable):
04 0B 73 74 72 65 61 6D 74 79 70 65 64 81 E8 03 ..streamtyped...
84 01 40 84 84 84 12 4E 53 41 74 74 72 69 62 75 ..@....NSAttribu
74 65 64 53 74 72 69 6E 67 00 84 84 08 4E 53 4F tedString....NSO
62 6A 65 63 74 00 85 92 84 84 84 08 4E 53 53 74 bject.......NSSt
72 69 6E 67 01 94 84 01 2B 06 46 65 73 6B 65 72 ring....+.Fesker
86 84 02 69 49 01 06 92 84 84 84 0C 4E 53 44 69 ...iI.......NSDi
63 74 69 6F 6E 61 72 79 00 94 84 01 69 01 92 84 ctionary....i...
96 96 1D 5F 5F 6B 49 4D 4D 65 73 73 61 67 65 50 ...__kIMMessageP
61 72 74 41 74 74 72 69 62 75 74 65 4E 61 6D 65 artAttributeName
86 92 84 84 84 08 4E 53 4E 75 6D 62 65 72 00 84 ......NSNumber..
84 07 4E 53 56 61 6C 75 65 00 94 84 01 2A 84 99 ..NSValue....*..
99 00 86 86 86 .....
这包含一个NSAttributedString。我有类似的例子，包含NSMutableAttributedStrings等，但最终都解析为NSAttributedStrings，我喜欢获取文本。我不关心其余的，但我需要知道它是否有效。
This contains a NSAttributedString. I have similar examples that contain NSMutableAttributedStrings, etc., but all eventually resolve to NSAttributedStrings, for which I like to get the text. I do not care for the rest, but I need to know if it's valid.
我目前的解决方案是使用NSUnarchiver，并假设我总是应该找到一个NSAttributedString在那里，获取它的第一个元素并读取它的文本，然后从中重新创建一个存档，看它是否与原始数据相同。如果我收到异常或其他存档，我认为存档已损坏或无效：
My current solution is to use the NSUnarchiver and, assuming I always should find a NSAttributedString in there, get its first element and read its text, then recreate an archive from it and see if it is the same as the original data. If I get an exception or a different archive back, I assume that the archive is damaged or invalid:
NSData *data = [[NSData alloc] initWithBytesNoCopy:dataPtr length:dataLen freeWhenDone:false];
NSUnarchiver *a = NULL;
// The algorithm simply assumes that the data contains a NSAttributedString, retrieves it,
// and then recreates the NSArchived version from it in order to tell its size.
@try {
a = [[NSUnarchiver alloc] initForReadingWithData:data];
NSAttributedString *s = [a decodeObject];
// re-encode the string item so we can tell its length
NSData *d = [NSArchiver archivedDataWithRootObject:s];
if ([d isEqualTo:[data subdataWithRange:NSMakeRange(0,d.length)]]) {
lenOut = (int) d.length;
okay = true; // -> lenOut is valid, though textOut might still fail, see @catch below
textOut = [s.string cStringUsingEncoding:NSUTF8StringEncoding];
} else {
// oops, we don't get back what we had as input, so let's better not consider this valid
}
} @catch (NSException *e) {
// data is invalid
}
但是，有几个上述代码的问题：
However, there are several issues with the above code:
- 这不是x平台。我也需要这个在Windows上运行。
- 一些损坏数据的例子导致写入stderr或syslog的不必要的错误消息（不确定是哪个），例如：
*** mmap（size = 18446744071608111104）失败（错误代码= 12）***错误：无法分配区域***在malloc_error_break中设置断点以调试（我提交了错误报告关于这个被关闭为不会修复，遗憾地）。 - 没有什么能保证NSUnarchiver代码100％防崩溃。 malloc错误就是一个例子。在某些情况下我可能会遇到总线错误，这将是致命的。如果我有自定义代码进行解析，我可以自己处理（并修复我遇到的任何崩溃）。 （更新：我刚发现一些无效的数据确实使NSUnarchiver崩溃了。）
- It's not x-platform. I need this to work on Windows, too.
- Some examples of damaged data cause an unwanted error msg written to stderr or syslog (not sure which), such as:
*** mmap(size=18446744071608111104) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug(I filed a bug report about this which was closed as "won't fix", sadly). - Nothing guarantees that the NSUnarchiver code is 100% crashproof. The malloc error is an example for this. I might as well get a bus error in some situations, and that'd be fatal. If I had custom code for parsing, I can take care of that myself (and fix any crashes I encounter). (Update: I just found some invalid data that does indeed crash NSUnarchiver with a SIGSEGV.)
因此，我需要自定义代码来解码这些档案。我看了几个，但无法理解它使用的代码。显然，有长度字段和类型字段，显然类型在0x81到0x86范围内。此外，前16个字节是标题，包括偏移14-15的系统代码（0x03E8 = 1000）。
Therefore, I need custom code to decode these kinds of archives. I've looked at a few, but can't make sense of the codes it uses. Apparently, there are length fields and type fields, with the types being in the range around 0x81 to 0x86, apparently. Also, the first 16 byte are the header, including the system code (0x03E8 = 1000) at offset 14-15.
我也想知道源代码是否可用一些旧的NeXT资源或曾经存在的Windows版本，但我会在哪里找到它？ （注意：我被引导到GNUstep源代码（core.20131003.tar.bz2），我在其中找到了它的NSUnarchiver源代码，但该代码显然是从1998年开始使用自己的编码，而不是理解这个streamtyped编码。）
I also wonder if the source code is available in some old NeXT sources or in the Windows version that once existed, but where would I find that? (Note: I was directed to the GNUstep source ("core.20131003.tar.bz2"), in which I found its NSUnarchiver source, but that code, apparently from 1998, uses its own encoding, which isn't understanding this "streamtyped" encoding.)
推荐答案
虽然我不知道格式的任何文档，但你可以通过查看较旧的Darwin（或OpenStep）版本的公共源代码来查找您要查找的信息。
While I don't know any documentation of the format, you may find the information you are looking for by checking the public source code from older Darwin (or maybe OpenStep) versions.
例如，在文件 typedstream中查看 in typedstream 的实现。 m objc-1.tar.gz 可从这是旧达尔文分布的镜像。
For example, have a look at the implementation of typedstream in the file typedstream.m in objc-1.tar.gz available at this mirror of an old darwin distribution.
此源代码应该能够读/写 typedstream 。请务必在使用时确认Apple的许可证。
This source code should be able to read/write typedstream. Just be sure to confirm to Apple's license when using it.
这篇关于检查类型为“NeXT / Apple typedstream”的文件。版本4（NSArchiver）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
