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?
Related
My goal is to extract the localization keys and strings from a Base.lproj's .nib files.
While most compiled nib files use the binary plist format, I ran into a few that are in a different format, where the file starts with "NIBArchive".
An example (in macOS Monterey) is the file at:
/System/Library/CoreServices/Finder.app/Contents/Resources/Base.lproj/ClipWindow.nib
For "bplist" files, I can easily read them via CFPropertyListCreateFrom… into a NSDictionary, and then find the translatable strings therein (inside the "$classes" entry they're always three consecurity dict, string and string entries, with the dict containing the keys "NS.string", "NSKey" and "NSDev", and the following strings being the key and value of a translation entry, similar to what .strings files contain).
The NIBArchive, however format doesn't seem to be documented anyway. Has anyone figured out how to decode the entries in a meaningful manner so that I could find the translation items in them? Or convert them into the bplist format?
Note that this kind of file is a compiled nib, and ibtool won't work because it gives the error: "Interface Builder cannot open compiled nibs".
I am working with random .nib files, for which I don't know the implementation specifics. All I want is to extract are the .strings contents that were originally compiled into the Base localization file.
I had googled for this format before but found nothing. Now, with a slightly modified search, I ran into some answers.
My best hope to solving this so far is this format description, determined through reverse-engineering:
https://github.com/matsmattsson/nibsqueeze/blob/master/NibArchive.md
I can build a parser based on this, but still wonder if there are easier ways.
Another possible solution is to use NSKeyedUnarchiver to decode the data, after loading it into a NSNib object, as suggested here:
https://stackoverflow.com/a/4205296/43615
This method of decoding keyed archives of unknown types is also shown in the PlistExplorer project:
https://github.com/karstenBriksoft/PlistExplorer
It seems https://github.com/kam800/MachObfuscator does include a NIBArchive-reader NibArchive+Loading written in Swift.
Hello Everyone,
I haven't been able to figure our why my .txt file shows up fine on my simulators but not my iphone.
I found info about .png's doing the same thing but because of a compiling issue.
My build throws no errors and the section headers and correct cell quantities appear but no text.
This is the code I am using to extract the array of data from the .txt files.
So is there a better way of extracting the data from a .txt file into an array?
Or is there a compiling issue like the .png?
Or am I a dummy and I should know this isn't the correct way of creating an array from a .txt file?
NSString *delimiter = #"\n";
/*
Pull contents of text file, convert to string format, separate by newline, finish by giving new local array a pointer
*/
//COWEL DOOR CHECK
NSData *cowelDoorCheckTF = [NSData dataWithContentsOfFile:#"/Users/Makey/Dropbox/iPreFlight/iPreFlight R22/Text Data Files/PreFlight/CowelDoorCheck.txt"];
NSString *cowelDoorCheckString = [[NSString alloc]initWithBytes:[cowelDoorCheckTF bytes] length:[cowelDoorCheckTF length] encoding:NSUTF8StringEncoding];
NSArray *cowelDoorCheck = [cowelDoorCheckString componentsSeparatedByString:delimiter];
Your txt file should exist as a resource in your app, not a file in some other directory on your computer. Otherwise it won't exist as part of your app.
See the physical path for my files inside the Resources folder of XCode (for IOS) for a starting point. The first answer for iOS - how to read entire content of an html resource file into an NSString *? also provides a usage example
Check the case of the filename. File names are case-insensitive in the simulator, but are case-sensitive on the device.
So, for example, if the resource's actual filename is "FOO.txt", but your code loads it as "foo.txt", then it will work in the simulator but not on the device.
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];
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" :)
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.