Re: Problems parsing plist files
Re: Problems parsing plist files
- Subject: Re: Problems parsing plist files
- From: Nicko van Someren <email@hidden>
- Date: Tue, 8 Nov 2005 12:25:58 +0000
On 7 Nov 2005, at 12:20, Peter Schols wrote:
I'm experiencing a very strange problem. The following code
initializes an NSDictionary with a .plist file on my web server.
This code used to work just fine over the past 3 years (and it sill
worked a few weeks ago) but now it does not work anymore:
NSString *traceList = @"http://www.orbicule.com/UCservices/
trace.plist";
NSURL *traceURL = [NSURL URLWithString:traceList];
NSDictionary *traceDictionary = [NSDictionary
dictionaryWithContentsOfURL:traceURL];
NSLog(@"Trace dbase: %@", traceDictionary);
The traceDictionary is null and the run log shows the following
message:
2005-11-07 13:03:45.932 uc[850] CFLog (0):
CFPropertyListCreateFromXMLData(): plist parse failed; the data is
not proper UTF-8. The file name for this data could be:
/Users/mac/Library/Cookies/Cookies.plist
The parser will retry as in 10.2, but the problem should be
corrected in the plist.
2005-11-07 13:03:46.006 uc[850] Trace dbase: (null)
Have you upgraded your web server recently? I suggest you try the
following code:
NSString *traceList = @"http://www.orbicule.com/UCservices/
trace.plist";
NSURL *traceURL = [NSURL URLWithString:traceList];
[[NSData dataWithContentsOfURL: traceURL] writeToFile: @"/tmp/
foo.xml" atomically: YES];
Now go to a terminal and type "file /tmp/foo.xml" and you'll find (I
just tried it) that the file is compressed with gzip. This is due to
a long-standing and still unfixed BUG in OS X. See the link below
[1] for a previous thread on the subject but here is a summary:
HTTP allows the server and client to negotiate different transport
encodings, which are often used to compress data before it is sent.
The Foundation implementation of NSData's -initWithContentsOfURL:
sends the header line:
Accept-Encoding: gzip, deflate;q=1.0, identity;q=0.5, *;q=0
in the request, explicitly telling the server that not only is it
happy to accept a transfer encoded with gzip or deflate but that it
would take this in preference to the uncompressed file. If you have
a nice recent web server (or a carefully configured older server)
then the server will oblige by sending back the data compressed with
gzip. Unfortunately the Apple code them flatly ignores the
indication that the data was compressed and returns the data as
transmitted, rather than uncompressing it as it should. Worse, it
gives the programmer no indication that it has done so.
This is a fairly simple bug. There is a trivial short term fix (not
to send the "Accept-Encoding" header line) and a better long term fix
(actually decompress the data). My bug report on this from way-back-
when is marked as "duplicate" in the Apple Bug Reporter but despite
three revisions of 10.4 having been released Apple have still failed
to fix this.
You have a handful of options for dealing with this. If you know
that you will always be the owner of the server you can tell the
server not to compress .plist files (or any other file you might
fetch with -initWithContentsOfURL:). If you have a handy copy of a
gzip library you can download the data into an NSData, look at the
first few bytes, try to work out if what you have got is compressed
and conditionally decompress it. Alternatively you can use
NSURLConnection and friends to construct your own request, which does
not have the broken "Accept-Encoding" header line and fetch the data
that way.
Irrespective of which of these you choose I suggest you file a bug
report with Apple in the hope that if enough people complain then
they might pull their fingers out and fix this.
Cheers,
Nicko
[1] http://www.cocoabuilder.com/archive/message/cocoa/2005/3/17/130744
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden