In Safari, you can drag a link out to the Finder, and it gets saved as a .webloc file. Opening that file opens the corresponding URL in your web browser. It’s a nice simple bookmarking scheme.
Annoyingly though, Apple don’t (that I’m aware of) provide us any facility to programmatically create or read these files. If I’m wrong on this please, please, please, somebody correct me!
In KSFileUtilities, we have some routines cooked up to try and parse web location files using the Carbon Resource Manager APIs. Since those functions were deprecated in OS X 10.8, I thought it about time to revisit and see what we could do better.
I started by cooking up some tests of the existing code. From webloc files, we try to retrieve the URL, but also the title. Run the tests, and all is good. Check it in, and then try that on a different machine. The tests fail.
That’s odd. What’s going on here?
Poking at it, I think I understand the problem. Our existing code is working by looking purely at the resource forks. When creating a webloc file, it looks like Safari is kind enough to generate both the actual file, and some resource forks to go with it, one for the URL, one for the title/name.
Trouble is, you check that into git, and it only sees and cares about the main file, not the resource forks. So those forks are being lost, and our test fails. Clearly we’re going about this the wrong way.
Some research tells me that the raw data in a webloc file is actually just a simple binary plist. So all you have to do in order to read one is something along these lines:
Obviously, don’t use this code as-is; make sure to check for errors and so-on!
I’ve decided to scrap our existing code. The above approach is so simple, I don’t think it’s worth publishing a method for.
And I’ve decided to not to bother trying to retrieve the location's name/title. It’s a bit weird that Safari includes that info in the resource fork, but there’s basically no opportunity us as users ever get to see or edit that data! Best left ignored :-)