Python zipfile extract: unpack selected files safely

Select a timestamp to watch that moment on YouTube.

1. 00:00

   Imagine a downloaded ZIP that promises one text note. Its member list also contains another file, and you need to decide what should land on disk. Predict the result before the first run. We will start with the convenient library API, inspect what it does, then give the application its own narrow acceptance policy. Notice that the lesson is about extracting rather than creating a ZIP; if you need to build an archive, the linked earlier tutorial covers that separately. The search for python zipfile extract usually begins with one line: ZipFile.extractall(destination). That line is useful for a trusted archive, but it extracts every member.

2. 00:43

   This lesson answers the practical follow- up: how do you unpack only expected text files from a ZIP you did not create? We inspect each ZipInfo entry, reject unsafe names, bound uncompressed size, and then write selected bytes under a chosen directory. The browser exercise uses an in-memory ZIP and its temporary filesystem; no uploaded archive is needed. Open a ZIP with a context manager and print its member names before writing files. The archive can contain more than the one document you expected. A member list is evidence about filenames, not evidence that the contents are safe.

3. 01:23

   Do this first even when a download has a friendly name such as notes.zip. The first run is intentionally broad. It succeeds, which is precisely why it can be easy to miss the bug: the program extracted everything, including a CSV unrelated to our text-note import. This is not a claim that Python extractall ignores path safety. The standard library normalizes some path forms, but it cannot know your application expects only top-level text files. We need to make that rule explicit rather than assume a general extraction helper enforces it. Start by viewing archive.namelist() rather than assuming the contents.

4. 02:05

   A ZIP may include directories, duplicate member names, nested paths, absolute- looking names, files you did not expect, and very large expanded content. Python's extractall performs some path normalization, but an application still needs its own acceptance policy. Here the policy is deliberately narrow: one top-level .txt filename, no slash or backslash, no dot-only name, no duplicate, and at most 4096 uncompressed bytes per file. This is a teaching policy, not a universal ZIP security limit. ZipInfo offers more detail than namelist: filename, file_size, compress_size, and directory status.

5. 02:48

   The extraction policy in this lesson accepts only one-level .txt names. That deliberate restriction also means a valid archive with nested text files will be rejected. If your application needs directories, define and test a different policy rather than silently weakening this one. Now inspect the archive without writing. For each ZipInfo object, read the member name and its declared expanded size. Consider how you would treat a directory, a duplicate name, an absolute-looking name, or a nested path. This example has only two tiny entries, but the same inspection pattern works on a larger archive.

6. 03:29

   The numbers are not proof of trusted content; they are inputs to your resource policy and allow you to reject some obviously unwanted members early. Use ZipFile.infolist() so that each member's name and file_size are available before writing. Reject the archive first if any member violates the contract; do not leave a partially extracted directory when a later entry is bad. Then create the destination, read each accepted member with archive.open(info), decode UTF-8, and write it with pathlib.Path.write_text. Keeping a list of validated ZipInfo objects matters when names are duplicated: reading by name alone can be ambiguous.

7. 04:12

   Close the archive with a with block even when validation raises. Checking a filename after extracting it defeats the point of an allowlist. Validate every member before the first write. Reject empty names, names with a slash or backslash, names that are not .txt, directories, duplicates, and entries above the size limit. Compare file_size with a limit suitable for your application, not a number copied blindly from a tutorial. The corrected function validates the complete list first. It allows one-level .txt filenames up to a chosen size, rejects duplicates and path separators, then reads through the validated ZipInfo objects and writes UTF-8

8. 04:52

   text. Keeping the exact ZipInfo instance avoids ambiguity if someone tried to put the same name into the archive twice. A temporary directory makes the demonstration repeatable and ensures no permanent file is left on this machine. The final check builds two small ZIPs in memory. One contains notes.txt and can be extracted to a temporary folder. The other contains ../outside.txt and is rejected before any write. A second policy check rejects a file whose advertised expanded size is above the limit.

9. 05:32

   For real untrusted archives also consider total expanded size, compression ratio, disk capacity, symlinks, and resource limits; never assume extension alone proves that content is harmless. The earlier zipfile lesson creates archives, while this guide is specifically about inspecting and extracting their members. A ZIP can contain repeated names. ZipFile.read('name') may select an ambiguous entry, so keep the validated ZipInfo objects and read each one directly with archive.open(info). Use a set to detect duplicates. The validation pass should raise ValueError for any disallowed member,

10. 06:12

    leaving the destination empty. With more complex archives, also bound total expanded bytes. The final run changes the input to a parent-path member. We should see ValueError and an empty destination. Also try an oversized member in the web task and consider a total expanded-size limit if your application accepts many files. A real importer may need a staging directory and cleanup on I/O failure; this lesson guarantees the validation policy runs before any write, not a full disk transaction. Read the extracted file back when verifying a successful archive, because a

11. 06:52

    filename alone does not prove the bytes were correct. After validation, create the destination directory and write each selected member. Decode the bytes with the encoding your file format promises; this lesson uses UTF-8. A UnicodeDecodeError is a useful failure because mislabeled binary data should not be accepted as text. Do not catch every exception and report success with an incomplete result. A temporary directory makes this example safe to replay. Confirm the actual file contents after writing, not only the return value of the function. For a production importer, stage files in a fresh directory and consider cleanup if

12. 07:35

    an I/O failure occurs mid-write. The lesson's guarantee is that policy validation precedes writes; it does not promise atomic disk transactions.