Repository navigation
plistlib doesn't handle poorly-formatted plists #84561
Description
Activity
Some Info.plist files are poorly formatted. I am using plistlib to read Info.plist file from various .app bundles. On some, plistlib.load raises a ValueError when trying to parse.
Examining one of these Info.plist files, it turns out *it* is poorly formatted, but while python's plistlib is unhappy, it passes "plutil -lint" just fine and "Foundation.NSDictionary.dictionaryWithContentsOfFile_" is happy to read it.
Here's a minimal sample plist file:
"""
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"\>
<plist version="1.0">
<dict>
<key>An array</key>
<array>
<string>a string</string>
<key>A wild key appears!</key>
<string>it has a string</string>
<string>another string</string>
</array>
</dict>
</plist>
"""plistlib (correctly, I think) says that's no good. Apple's tooling just ... changes the key to another string in the array and carries on.
I've attached an actual problematic Info.plist as well.
- added3.7 (EOL)end of lifeend of lifestdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory
on Apr 24, 2020 I expect the answer here to be "plistlib is correct, that's a poorly formatted plist", but since plistlib is "for reading and writing the “property list” files used mainly by Mac OS X and supports both binary and XML plist files", and Apple's own tooling handles these poorly-formatted files without error it was worth raising the issue.
IMHO this is a bug and plistlib should behave the same as Apple’s libraries here.
Reacted by Glyph- addedtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
on Apr 28, 2020 See related issues:
#54942
#95722I suspect the answer will be the same, that plistlib shouldn't support what is essentially buggy behavior by Apple (generating and?) parsing improperly formatted XML with their tooling.
Personally, I think that even if this were the default behavior, it would be great if there was an option to be more permissive and compatible with Apple tooling. But I can understand the reluctance of embedding that kind of thing in the Python stdlib. (esp. since the behavior of Apple's tools could change at any time, with no warning, and no documentation)
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: