site_archiver@lists.apple.com Delivered-To: Pro-apps-dev@lists.apple.com It looks like the only differences from stock output (say what you would get from uuencode(1) ) are: No header or trailer lines (i.e. the first line ('begin...'), and the last two lines (grave accent and "end") ) No new lines A null byte at the end No spaces (always use backquote character instead) Let me know if anything about the above list doesn't match your experience. -eryk On Apr 27, 2010, at 9:43 AM, Kristian Harms wrote:

Thank you Eryk.

It was indeed a length-related issue. The NSKeyedUnarchiver's init no longer throws.

Regarding the uuencoding, am I right in guessing you have rolled your own implementation? The reason is that it doesn't seem to have been encoded using any of the uuencoding implementations I have found, which insert a newline at regular intervals in the encoded data. It would be nice if you could document any peculiarities of your uuencode.

Best regards, Kristian Harms

Den 2010-04-26 11:02 PM, skrev Eryk Vershen:

...

Kristian,

From the link you gave it is clear you had Paul's response; that should be the right thing to do. I agree the uudecode shouldn't have a problem. The string of bytes that NSKeyedUnarchiver mentions in the error is the string 'bplist00' (i.e. the start of a binary plist). I believe keyed archives are stored using plists these days, so that seems right.

Perhaps you've messed up the length of the data?

It's probably complaining because it's having a failure reading the plist (qua plist).

-eryk

On Apr 26, 2010, at 12:15 PM, Kristian Harms wrote:

...

Hi,

I'm doing something similar to what Steve Christensen asked about in this email to the list, a year ago:

http://lists.apple.com/archives/Pro-apps-dev/2009/Feb/msg00036.html

In brief, I want to grab from the FCP XML the parameter value for any custom parameters in my FxPlugs and deserialise them. However, when I come to the point where I instantiate the NSKeyedUnarchiver with my NSData, which I have uudecoded based on the string I acquire from the XML, I actually get an Objective-C exception, of type NSInvalidArgumentException, and with reason:

*** -[NSKeyedUnarchiver initForReadingWithData:]: incomprehensible archive (0x62, 0x70, 0x6c, 0x69, 0x73, 0x74, 0x30, 0x30)

This happens on the init call itself, and not on the [unarchiver decodeObject] call that the link above recommends doing next.

I'm stumped as to how to procede. There are no obvious things I've done that could compromise the data -- the only point where a character encoding is involved is when I extract the char* from the NSString holding the uuencoded data, but uuencoded data should be representable as 7-bit ascii anyway, so choosing utf8, latin1 or even ascii should work fine there. There are no character encodings involved after the point where I uudecode.

Version info: Running FCP 7.0.2 and plugin compiled using FxPlug SDK 1.2.5, on top of OS X 10.5.

-- Kristian Harms _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/evershen%40apple.com

This email sent to evershen@apple.com

_______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.ap... This email sent to site_archiver@lists.apple.com