patsplat / plist

All-purpose Property List manipulation library

Home Page:http://www.rubydoc.info/gems/plist

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support json plist format

grosser opened this issue · comments

Nope. That's not a plist, just some random file with a plist extension.

Is that a json plist?

On Wed, Oct 5, 2011 at 11:49 AM, Michael Grosser <
reply@reply.github.com>wrote:

Is it possile to parse something like this ?

https://raw.github.com/kangax/textmate-js-language-syntax-file/master/JavaScript.plist

Reply to this email directly or view it on GitHub:
#7

Patrick May
+1 (347) 232-5208

That was my initial thought too, but I looked around and couldn't find any official spec for json plists. I think maybe it's something that TextMate has done to encode plists in a friendlier format?

If there's a standard, even if it's emerging, I'd be happy to add support for it. I just want documentation so we don't end up implementing something broken.

I thin kits this:
http://en.wikipedia.org/wiki/Property_list

From the look of it its the same content, just another format

Well, just about any data structure can be turned into a plist. My opinion is that if plutil doesn't speak it, we shouldn't support it.

That said... turns out plutil has a json format now. I can't find any docs, but it should be relatively easy to write tests to verify that we're doing the right thing.

Reopening this request.

i tried this: http://scw.us/iPhone/plutil/plutil.pl
but it did not read or convert this file, how did you do it ?

$ man plutil

:)

also did not work, maybe its outdated on ubuntu...

Ah, ubuntu. plutil is part of OSX. Can't help you on other platforms.

Don't have any problems with supporting NeXT property lists but it seems a bit esoteric. Parsing and emitting binary and json plists is definitely a desired feature.

@bleything FYI that is not "just some random file with a plist extension."

It's a NextStep plist format (aka the original plist format), It is parsable by both plutil and PlistBuddy.


  • Strings are represented in C literal style: "This is a plist string\n"; simpler, unquoted strings are allowed as long as they consist of alphanumerics and/or these symbols _$+/:.-.

  • Binary data are represented as: < [hexadecimal codes in ASCII] >. Spaces and comments between paired hex-codes are ignored.

  • Arrays are represented as: ( "1", "2", "3" ). Trailing commas are permitted.

  • Dictionaries/Hashes are represented as: { "key" = "value"; ... } The left-hand side must be a string, but it can be unquoted. Key value pairs can be delimited by ; or newline (or both optionally).

  • Comments are allowed as: /* This is a comment */ and // as in C

Given that XCode generates these files today and has done since ... well, a long time. (i.e. since it existed)

Being able to parse these is useful.

I'd recommend the issue be re-titled correctly, as this is not a JSON format and obviously leads to confusion.

@jasonm23 thanks for the info, but I haven't been involved in this project for many years. I think this is @mattbrictson's call now.

@patsplat I assume it's your decision.