Encoding issue: Cocoa Error 261?

Question

So I'm fetching a JSON string from a php script in my iPhone app using:

NSURL *baseURL = [NSURL URLWithString:@"test.php"];
NSError *encodeError = [[NSError alloc] init];
NSString *jsonString = [NSString stringWithContentsOfURL:baseURL encoding:NSUTF8StringEncoding error:&encodeError];
NSLog(@"Error: %@", [encodeError localizedDescription]);
NSLog(@"STRING: %@", jsonString);

The JSON string validates when I test the output. Now I'm having an encoding issue. When I fetch a single echo'd line such as:

{ "testKey":"é" }

The JSON parser works fine and I am able to create a valid JSON object. However, when I fetch my 2MB JSON string, I get presented with:

Error: Operation could not be completed. (Cocoa error 261.)

and a Null string. My PHP file is UTF8 itself and I am not using utf8_encode() because that seems to double encode the data since I'm already pulling the data as NSUTF8StringEncoding. Either way, in my single-echo test, it's the approach that allowed me to successfully log \ASDAS style UTF8 escapes when building the JSON object.

What could be causing the error in the case of the larger string?

Also, I'm not sure if it makes a difference, but I'm using the php function addslashes() on my parsed php data to account for quotes and such when building the JSON string.

Solution 1

Don't know if this is your problem, but I just had a similar thing (stringWithContentsOfFile, no JSON), and the problem was that the file had CRLF (windows) line-endings and Western-whatever-it's-called encoding. I used SubEthaEdit to convert to LF (Mac/Unix line-endings) and UTF-8 encoding, and now everything works fine.

Solution 2

I'm surprised no one has mentioned using a different encoding value instead of NSUTF8StringEncoding when calling [NSString stringWithContentsOfFile:encoding:error:].

I also got Cocoa error 261 when parsing a JSON file. I just went through the list of NSString encodings until one worked. Fortunately the first one worked for me: NSASCIIStringEncoding!

You can also use NSString stringWithContentsOfFile:usedEncoding:error: to try to find the correct encoding (as described here: How to use stringWithContentsOfURL:encoding:error:?).

Solution 3

Encoding issue: Cocoa Error 261? I solved this issue by trying different encoding. First I was using NSUTF8 then I switched to NSASCIIStringEncoding and it worked.

NSString* path = [[NSBundle mainBundle] pathForResource: @"fileName" ofType: @"type"];
NSData* data = [NSData dataWithContentsOfFile:path];
NSString *string = [[NSString alloc] initWithData:data encoding:NSASCIIStringEncoding];
NSLog(@"%@",string);

Comments

[Mike A]

I'm not quite sure I understand what you mean by defensive enough, or what this is accomplishing extra... could you elaborate a bit more please?

[martinr]

oh if your encoding happens to be 32bit characters (ie eg UTF32) rather than 8bit characters, to get an end 32bits all null (to terminate the C string, required by the stringWithCString: API call) can only be ensured by adding 7 NUL characters (4 needed if perfectly aligned; an extra 3 needed in worst case of misalignment). If its just ASCII 8bit encoding, 1 NUL byte will suffice, but I stuck extra in because I don't know what encoding you're using.

[martinr]

I of course mean US ASCII with high bit clear (so 7bit codes in an eight bit byte). And I'm not sure how many Null bytes are required really, even for UTF32. I'm handing checking such over to you, to check for your (particular) encoding. Thankyou..!

[Mike A]

This didn't seem to change anything, unfortunately.

[martinr]

Well once you have the character bytes in memory, you can manually with some C bit-twiddling code in a loop to check the encoding rules to see what is broken with the encoding. My experience with the iPhone API and character encoding is that even though one might assume it is supposed to helpfully replace any bad encoding with the replacement character, it does break and return no helpful output if you give it even slightly broken encoding, and I had to write my own encoding pre-validators and pre-fixers in some cases.

[martinr]

EDIT: "have seen it break" instead of "does break".

[Joseph DeCarlo]

That was totally my problem. The problem I have with the accepted answer is you may not have the ability to change the input file.

[Olie]

Agreed that you may not be able to change the input file. My point was: the problem isn't about json (or php), it's about string encodings. I changed the file, but one can change the NS-encoding value, too.

[TigerCoding]

It can also be useful to examine the file encoding type. I used Text Wrangler to do this. Open the file, and at the bottom of the window it will show what kind of encoding it is. I needed UTF16 but there are many variations.