I've come across a resource that I would like to use, but I'm not sure how to proceed. The resource is a plist and one of the keys holds an NSData object. However, I don't know what the NSData represents. Is there a way to figure out how I should decode the NSData object to be able to read its contents?
So I assume you can't ask the provider of the resource what the data is for? Try dumping the data out to a file using -writeToFile:atomically:. Then you can use the file command-line tool to see if it knows what format the file is in. Or you can use xxd to look at the bytes and see if you recognise the format. There's no foolproof way to go from 'arbitrary set of bytes' to 'understanding of the context of those bytes', you either need to recognise it or ask someone.
Related
I'm working with iTunes via AppleScript. The artwork element of a track contains image data (or raw data, which appears in practice to return the same thing), which can be retrieved and, say, directly written to a file. (It's an e.g. PNG bytestream.)
But I don't know how to do anything with this thing besides write it to a file. I'd like to ask it how many bytes it contains, or even rummage through it (though the latter may well be out of scope for AppleScript). In Script Debugger, it looks like «data tdtaXXXXXX.....» (hex values where I wrote the XXXs), and the iTunes scripting dictionary doesn't link through to any useful type/class for it.
I'm not really sure what the guillemets mean in AppleScript, or what the nature of this object is, or whether this thing can be interrogated natively. Any references on this would be helpful. Thanks!
See https://books.google.com/books?id=rW5k0w_wC3MC&pg=PA57&lpg=PA57&dq=guillemets+applescript+events+data&source=bl&ots=ogzi9W4jxW&sig=7ct-n0wpzdhBhtHDJtTrZDKgEEk&hl=en&sa=X&ei=-qSYVICZAsjooASo0oKwCg&ved=0CB4Q6AEwAA#v=onepage&q=guillemets%20applescript%20events%20data&f=false for explanation of raw codes and data and use of guillemets in AppleScript; See this answer:
Getting artwork from current track in Applescript
for an example of writing image data from iTunes artwork to file.
I want to guess a received NSData's encoding. I searched in Stackoverflow and found one answer here which indicates "can't".
However, I noticed a NSString method stringWithContentsOfFile:usedEncoding:error:, and I wanted to know whether I can achieve this goal in sequence below:
1> Get an NSData object
2> Store this NSData object into a file with random file name in directory /tmp
3> Call NSString's stringWithContentsOfFile:usedEncoding:error: method to read from this temporary file.
4> Delete the temporary file.
5> Read the enc parameter to determine the encoding
I know I can experiment by myself, but I have no various data source with different encoding in my hand. Therefore I raised a question here. Could my opinion work? Could this solution find every possible encoding OS X could recognized?
I have an object containing various NSString objects and variables which I us NSCoding to archive to a file on the disk and later unarchive. So far everything has been working perfectly.
Today, I wanted to add an NSMutableArray to the object and tried to encode using the:
[encoder encodeObject:myArray ForKey:#"myArray"];
and later decode it using:
[self setMyArray:[decoder decodeObjectForKey:#"myArray"]];
It doesn't appear to be working, and while I don't get any errors in the encoding or decoding itself, I do get an error if I try to modify the value of the array after decoding from the file.
I'm sure I'm doing something completely wrong here, but not entirely certain what. I'm thinking perhaps it may have something to do with it not properly allocing during the unarchive.
Anything look blatantly obvious as the source of the problem?
It doesn't appear to be working, and while I don't get any errors in
the encoding or decoding itself, I do get an error if I try to modify
the value of the array after decoding from the file.
Decoding an archive gives you immutable objects regardless of whether they were mutable or immutable when you encoded them. You're not doing anything particularly wrong -- it's working as advertised.
See this answer for another example of a similar problem, and a solution:
[self setMyArray:[[decoder decodeObjectForKey:#"myArray"] mutableCopy];
In an encryption tool I am nearly finished with, I can't seem to write the encrypted data to a file.
Here is what I have:
NSData *encryptedData = [data AES256EncryptWithKey:key];
[encryptedData writeToFile:#"~/Desktop/file.txt" atomically:YES];
If 'file.txt' is not found, it should create it.
Thank You
First, -writeToFile:atomically: is the name of the method you are trying to use-- not, as you have written, -writeToFile:automatically:. And second, this method should usually be avoided in favor of one that takes an out NSError parameter.
Try -writeToFile:options:error: if you'd like to be able to log a useful diagnostic when something goes wrong.
I need to use the writeToFile: methods in writing data (that is encrypted) to a file. However, say I have:
NSData *encryptedData = [data AES256EncryptWithKey:key];
And I write the encryptedData to a file by:
[encryptedData writeToFile:#"file.txt" automatically:YES];
This for some reason does not write the data to "file.txt." This is a very simple question and I know I am missing something super basic. If file.txt is not actually there, it must be created.
This probably has nothing to do with Cocoa or NSData.
On Unix (like Mac OS X), paths that start with / are absolute. Paths that start with ~ are relative to the current user's home directory. Anything else (such as file.txt) is relative to the current directory. When running something from Xcode, that is the path of the executable (the compiler's output path).
So, to write that to the desktop, that would be:
[encryptedData writeToFile:#"~/Desktop/file.txt" atomically:YES];
For the documents folder, that would be:
[encryptedData writeToFile:#"~/Documents/file.txt" atomically:YES];
Don't forget that paths are also case-sensitive.
- (BOOL)writeToFile:(NSString *)path atomically:(BOOL)flag
returns a boolean to say if it was successful or not. I'd start there, if you see a YES then the file wrote somewhere successfully.
If that doesn't work then i'd double check the object you're trying to encode supports the NSCoding protocol. If you object doesn't support NSCoding take a look at this blog post for a nifty simple way of adding it.
Also its "atomically" not "automatically" :)