Hello! I have a Zip file that 7-Zip fails to extract. I have used 7-Zip 22.01 (x64) and I updated to 23.01 (x64) but the results are the same: it fails. I am using Windows 10 version 22H2 (build 19045.4291).
The file is password protected. I know the password. I paste in the correct password when prompted, but 7-Zip reports "wrong password".
However, 7-Zip is not the only software that fails the task. PeaZip 8.8.8 (Win64 Build, x86_64), which uses 7-Zip (7z 22.01) also fails, but with less descriptive error message: "fatal error". Updating PeaZip to 9.7.1 (using 7z 23.01) doesn't help: it fails with the same error message. In addition, the following software also fail: Windows Explorer Zip feature, WinZip 28.0 (15640) - 64-bit.
However!... (!!). I am able to extract the file with standard tools on Linux (Nautilus and archiver GUI), and with WinRAR 6.21 (64-bit) on Windows. Using the same exact password as with 7-Zip, PeaZip, et.al. I have reason to believe that there is something inherently wrong with the Zip file because it was created on a Mac computer. The file was mailed to me on a USB flash drive. On a brand new SanDisk flash drive. By a member of a privacy team, at a company that I previously worked for. I have no reason to believe that the file is corrupted. How could it be? If it works on Linux? And even on Windows with the help of WinRAR?
I have written extensively about this issue on Reddit. In the Mac subreddit. Which was evidently the wrong place to post such anecdote/report. Because they didn't read what I had to say, they didn't want to read, they didn't care what I had to say, they only read the headline, and they took turns to bash me in the head with a rolled up Apple Mac leaflet from the 80s, because they had to stand up and defend the Mac at all cost. That's the impression they left on me, as a non-Mac user. Apple fanboys! Some of the answers they gave me made them look stupid, unintelligent for a Mac user, and just ignorant. It was like talking to an old grandma who's using a computer for the first time, and doesn't understand the problem because she decided not to read into the details and background I provided. But they were all ready to jump and happy to vote you down.
So here I am now, on the forum of the 7-Zip software, wondering if someone here could help me get to the bottom of this? Why is 7-Zip failing me? Why is software that relies on 7-Zip such as PeaZip failing me? As the software that introduced the Zip format to the world, why is WinZip failing this task? Many questions. Few answers.
I would like to share the file with you for analysis. But since it contains personal and sensitive information, I rather not do that. It uses a fairly long and randomized password, so it's safe from brute force attacks for the foreseeable future. But the list of files inside is not encrypted and that's reason enough for me not to share it.
So I'm hoping you can give me some pointers on what to look for and what to check, so that we can work this out together, perhaps? Why is 7-Zip failing to extract this Zip file? More broadly, what would cause 7-Zip to fail to extract a Zip file? Maybe you have some experience of your own that you can share with me? Do you use both Mac and Windows? Have you ever come across this type of problem? A Zip file created on a Mac not being compatible with a Windows PC? Let me know in the comments.
Last edit: Ken 2024-04-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What's the password look like? Have you tried 7z command-line in Windows? Have you tried switching the codepage on the console to UTF-8 and tried the command line?
1) open archive with 7-zip, select failed file in archive, and press Info button to get information about encryption method.
2) what exact characters are used in password?
a-z A-Z 0-9 ...
Last edit: Igor Pavlov 2024-04-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have never actually used the 7-Zip command line. I never had a reason to. I use the GUI, and it just works. I normally use PeaZip for all my archiving needs on Windows (and it uses 7-Zip), but I also have 7-Zip installed as a backup.
The password is 15 characters long and consists of lower case letters and digits (alphanumeric). It's all Latin letters, but it does contain one letter with a diacritic (non-English letter). You may be onto something here! I will try the command line and let you know how it goes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
non-English letter is the problem.
There is no strict specification rules for letter encoding in zips.
So zip programs can use different ways to encode/decode such non-english characters.
Last edit: Igor Pavlov 2024-04-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can't get any more details than this. But since it errors so early on, I thought at first that the file was corrupted. But item number 1 that it stops at is the first file in the Zip archive. It is enumerated as number 2 because it appears in the log as line number 2 and I can see this in the log of 7-Zip.
Igor, I assume you meant to check the first file within the Zip archive that errors. That would be the transcript.txt file. Here's the info I get on that file, using the GUI (7-Zip File Manager).
If it says host OS was Unix and version was 20, does that mean Darwin 20? In other words macOS Big Sur? That seems interesting, because that macOS version is no longer supported. Last update was released September 11, 2023. It's not looking good for a privacy team at a big company to be using an outdated operating system.
I am also curious about the "ZipCrypto Deflate" part. Is this encryption method no longer considered secure?
One of the .zip password protection algorithms is called ZipCrypto. ZipCrypto is supported natively on Windows, but it should never be used because it is completely broken, flawed, and relatively easy to crack. All hackers need to know is 12 bytes of plain text and where it is located in the zip (which can be easily found) in order to quickly decrypt the entire content of the archive. To give you an idea, on most laptops, it would usually takes less than a minute to decrypt the entire content of a zip file.
The author suggests using AES-256 instead. At the cost of not being able to use it natively with Windows, but 7-Zip, WinRAR and WinZip support it. It's funny how that works... encryption method that's better than ZipCrypto is not supported by Windows, but the encryption method that IS supported by Windows, doesn't support non-English letters. If I understood this correctly?
Is there no way to get past this problem and extract the file with 7-Zip?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's not a crypto problem, it's a password Unicode encoding problem. That password was probably encoded as UTF-8 when the ZIP was made. In English (US) Windows, the default codepage is 1252, not UTF-8. So any attempt to pass in a unicode character in the password prompt is going to get mis-encoded and not decrypt the file.
Which leads back to my suggestion that you use the command prompt after having modified it to default to the UTF-8 encoding.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since I'm on Windows 10 past version 1903, I enabled the Beta option "Beta: Use Unicode UTF-8 for worldwide language support" in Region Settings (accessible via intl.cpl). And it worked! I can now extract this Zip with 7-Zip, PeaZip, WinZip, WinRAR and Windows Explorer. Finally! After almost 2 weeks of head scratching, and checking and typing the password many times. I did get to it after 2 days with Linux, and then with WinRAR. But I was puzzled by why it didn't work with anything else I tried.
Mystery solved! We have gone to the bottom of it. I would never have figured this out on my own. You must have seen this before then? Thank you both! I'm glad I came on here to ask. The two of you solved what 2.9 million registered users on the Mac subreddit could not. I hope you feel proud! You're the kind of people that impress on me: true problem solvers. Respect!
I didn't know such obscure problems exist. I learned something new and important today. So thanks to Windows, or thanks to lazy Microsoft rather, anyone who uses Zip files to secure files with a password on a Mac (and possibly on Linux or other UTF-8 respectful and command line heavy operating systems) and intends to share it with Windows users, must consider this limitation and only use English letters in the password? At least that's my takeaway from this. Does the opposite also apply as well, for Zip file created on Windows and shared with a Mac user?...
I don't think I have seen it before, but there is actually a warning within WinZip that comes up when I try to extract this Zip file. I don't have context menu integration for WinZip, so I have to open the Zip file in a window and then click to extract it.
Seeing how little is known about this type of problem, I will type out the error message to grab the attention of web crawlers (and to make the "AI" systems appear more smart than they are):
This password may cause compatibility problems under MS-DOS or other operating systems. For maximum compatibility, use only the English language letters A-Z, numerals, and standard punctuation marks such as #, *, and !.
"Beta: Use Unicode UTF-8 for worldwide language support" option is not good way to use it by default.
It probably will change zip archives that you create.
So another users can have problems with extracting such archives,
because they don't use "Beta: Use Unicode UTF-8 for worldwide language support" option.
Maybe there is another way to switch to utf-8 only for extraction operation in command line if it's possible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah, I have switched it back to its default, incompatible mode. I looked at the command line options for 7-Zip, of which there are plenty. But as I understand it, this must be set right by Windows. So 7-Zip alone can't do it? There is the chcp (change code page) command in Windows, but some people on Stack Overflow warned that it's "dangerous and inefficient" to use.
C:\Users\Ken>chcp
Active code page: 65001
This is what I get when I run this command if the UTF-8 option is enabled ("Use Unicode UTF-8 for worldwide language support"). When it's disabled, it says 437: United States. Although I don't live in the US, but I use US English locale on Windows.
Lesson learned: never buy a Mac! Or better yet: don't let HR girls use a Mac, for it's not a toy. LOL! Or better still: stop using Windows and switch to Linux. But to be completely honest, I would much rather find a compromise that works for all. I think that compromise is called UTF-8. But not everyone is on board with it. Not yet anyway (Microsoft!!). Alternatively, and I have seen it mentioned on Reddit by Mac users: using 7-Zip file format to ensure cross-platform compatibility.
This is such a weird and confusing problem! I'm not sure what came first, chicken or the egg. But I have seen Zip file incompatibilities between Mac and Windows blamed on many different things, including: corrupted files, wrong passwords, odd Mac files and folders with underscores (e.g. "__MACOSX"). The latter is sometimes wrongfully blamed on Mac due to incompetence of Windows users that don't understand that they should not be using those files on a Windows PC, and so they put the blame on Mac users when they can't open the files they received.
But... why has Microsoft not fixed this already? I wonder. It seems to be as old as time. Is it due to some backwards compatibility with legacy software? This goes way back to at least VC7 (Visual C++ 7.0) from 2002 and Kaplan's blog post from 2006 that questioned this and saw his posts deleted (1, 2).
I found a somewhat related discussion on Superuser.com from 2021, about Windows and macOS zipping differences. Where someone explained that they were using macOS (at their company presumably) to submit data to a third party, and they were required by the recipient to zip their spreadsheets using Windows to ensure compatibility. Talk about a tall order!
Last edit: Ken 2024-04-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
7-Zip uses ACP codepage for zip password. There is no option to change it in 7-zip.
Note that ACP codepage is not same code as OEM (console codepage) that is used for file names.
I suppose I tried to provide more compatibility with pkzip25 / WinZip / Windows. Maybe these programs also use or used ACP codepage for passwords.
Last edit: Igor Pavlov 2024-04-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello! I have a Zip file that 7-Zip fails to extract. I have used 7-Zip 22.01 (x64) and I updated to 23.01 (x64) but the results are the same: it fails. I am using Windows 10 version 22H2 (build 19045.4291).
The file is password protected. I know the password. I paste in the correct password when prompted, but 7-Zip reports "wrong password".
However, 7-Zip is not the only software that fails the task. PeaZip 8.8.8 (Win64 Build, x86_64), which uses 7-Zip (7z 22.01) also fails, but with less descriptive error message: "fatal error". Updating PeaZip to 9.7.1 (using 7z 23.01) doesn't help: it fails with the same error message. In addition, the following software also fail: Windows Explorer Zip feature, WinZip 28.0 (15640) - 64-bit.
However!... (!!). I am able to extract the file with standard tools on Linux (Nautilus and archiver GUI), and with WinRAR 6.21 (64-bit) on Windows. Using the same exact password as with 7-Zip, PeaZip, et.al. I have reason to believe that there is something inherently wrong with the Zip file because it was created on a Mac computer. The file was mailed to me on a USB flash drive. On a brand new SanDisk flash drive. By a member of a privacy team, at a company that I previously worked for. I have no reason to believe that the file is corrupted. How could it be? If it works on Linux? And even on Windows with the help of WinRAR?
I have written extensively about this issue on Reddit. In the Mac subreddit. Which was evidently the wrong place to post such anecdote/report. Because they didn't read what I had to say, they didn't want to read, they didn't care what I had to say, they only read the headline, and they took turns to bash me in the head with a rolled up Apple Mac leaflet from the 80s, because they had to stand up and defend the Mac at all cost. That's the impression they left on me, as a non-Mac user. Apple fanboys! Some of the answers they gave me made them look stupid, unintelligent for a Mac user, and just ignorant. It was like talking to an old grandma who's using a computer for the first time, and doesn't understand the problem because she decided not to read into the details and background I provided. But they were all ready to jump and happy to vote you down.
So here I am now, on the forum of the 7-Zip software, wondering if someone here could help me get to the bottom of this? Why is 7-Zip failing me? Why is software that relies on 7-Zip such as PeaZip failing me? As the software that introduced the Zip format to the world, why is WinZip failing this task? Many questions. Few answers.
I would like to share the file with you for analysis. But since it contains personal and sensitive information, I rather not do that. It uses a fairly long and randomized password, so it's safe from brute force attacks for the foreseeable future. But the list of files inside is not encrypted and that's reason enough for me not to share it.
So I'm hoping you can give me some pointers on what to look for and what to check, so that we can work this out together, perhaps? Why is 7-Zip failing to extract this Zip file? More broadly, what would cause 7-Zip to fail to extract a Zip file? Maybe you have some experience of your own that you can share with me? Do you use both Mac and Windows? Have you ever come across this type of problem? A Zip file created on a Mac not being compatible with a Windows PC? Let me know in the comments.
Last edit: Ken 2024-04-23
What's the password look like? Have you tried 7z command-line in Windows? Have you tried switching the codepage on the console to UTF-8 and tried the command line?
https://stackoverflow.com/questions/57131654/using-utf-8-encoding-chcp-65001-in-command-prompt-windows-powershell-window
1) open archive with 7-zip, select failed file in archive, and press
Infobutton to get information about encryption method.2) what exact characters are used in password?
a-z A-Z 0-9 ...
Last edit: Igor Pavlov 2024-04-23
I have never actually used the 7-Zip command line. I never had a reason to. I use the GUI, and it just works. I normally use PeaZip for all my archiving needs on Windows (and it uses 7-Zip), but I also have 7-Zip installed as a backup.
The password is 15 characters long and consists of lower case letters and digits (alphanumeric). It's all Latin letters, but it does contain one letter with a diacritic (non-English letter). You may be onto something here! I will try the command line and let you know how it goes.
non-English letteris the problem.There is no strict specification rules for letter encoding in zips.
So zip programs can use different ways to encode/decode such non-english characters.
Last edit: Igor Pavlov 2024-04-23
Here's a log from the report tab in PeaZip. Log from 7-Zip is further down.
I can't get any more details than this. But since it errors so early on, I thought at first that the file was corrupted. But item number 1 that it stops at is the first file in the Zip archive. It is enumerated as number 2 because it appears in the log as line number 2 and I can see this in the log of 7-Zip.
It continues on like this till line number 72. It keeps repeating "wrong password" for each file. Even though the password is right.
Similarly, here's a log from 7z.exe test command, after providing the password.
Igor, I assume you meant to check the first file within the Zip archive that errors. That would be the transcript.txt file. Here's the info I get on that file, using the GUI (7-Zip File Manager).
If it says host OS was Unix and version was 20, does that mean Darwin 20? In other words macOS Big Sur? That seems interesting, because that macOS version is no longer supported. Last update was released September 11, 2023. It's not looking good for a privacy team at a big company to be using an outdated operating system.
I am also curious about the "ZipCrypto Deflate" part. Is this encryption method no longer considered secure?
I found this blog post about it from 2020:
https://blog.devolutions.net/2020/08/why-you-should-never-use-zipcrypto/
The author suggests using AES-256 instead. At the cost of not being able to use it natively with Windows, but 7-Zip, WinRAR and WinZip support it. It's funny how that works... encryption method that's better than ZipCrypto is not supported by Windows, but the encryption method that IS supported by Windows, doesn't support non-English letters. If I understood this correctly?
Is there no way to get past this problem and extract the file with 7-Zip?
It's not a crypto problem, it's a password Unicode encoding problem. That password was probably encoded as UTF-8 when the ZIP was made. In English (US) Windows, the default codepage is 1252, not UTF-8. So any attempt to pass in a unicode character in the password prompt is going to get mis-encoded and not decrypt the file.
Which leads back to my suggestion that you use the command prompt after having modified it to default to the UTF-8 encoding.
Since I'm on Windows 10 past version 1903, I enabled the Beta option "Beta: Use Unicode UTF-8 for worldwide language support" in Region Settings (accessible via intl.cpl). And it worked! I can now extract this Zip with 7-Zip, PeaZip, WinZip, WinRAR and Windows Explorer. Finally! After almost 2 weeks of head scratching, and checking and typing the password many times. I did get to it after 2 days with Linux, and then with WinRAR. But I was puzzled by why it didn't work with anything else I tried.
Mystery solved! We have gone to the bottom of it. I would never have figured this out on my own. You must have seen this before then? Thank you both! I'm glad I came on here to ask. The two of you solved what 2.9 million registered users on the Mac subreddit could not. I hope you feel proud! You're the kind of people that impress on me: true problem solvers. Respect!
I didn't know such obscure problems exist. I learned something new and important today. So thanks to Windows, or thanks to lazy Microsoft rather, anyone who uses Zip files to secure files with a password on a Mac (and possibly on Linux or other UTF-8 respectful and command line heavy operating systems) and intends to share it with Windows users, must consider this limitation and only use English letters in the password? At least that's my takeaway from this. Does the opposite also apply as well, for Zip file created on Windows and shared with a Mac user?...
I don't think I have seen it before, but there is actually a warning within WinZip that comes up when I try to extract this Zip file. I don't have context menu integration for WinZip, so I have to open the Zip file in a window and then click to extract it.
Seeing how little is known about this type of problem, I will type out the error message to grab the attention of web crawlers (and to make the "AI" systems appear more smart than they are):
Thank you again!
"Beta: Use Unicode UTF-8 for worldwide language support" option is not good way to use it by default.
It probably will change zip archives that you create.
So another users can have problems with extracting such archives,
because they don't use "Beta: Use Unicode UTF-8 for worldwide language support" option.
Maybe there is another way to switch to utf-8 only for extraction operation in command line if it's possible.
Yeah, I have switched it back to its default, incompatible mode. I looked at the command line options for 7-Zip, of which there are plenty. But as I understand it, this must be set right by Windows. So 7-Zip alone can't do it? There is the chcp (change code page) command in Windows, but some people on Stack Overflow warned that it's "dangerous and inefficient" to use.
This is what I get when I run this command if the UTF-8 option is enabled ("Use Unicode UTF-8 for worldwide language support"). When it's disabled, it says 437: United States. Although I don't live in the US, but I use US English locale on Windows.
Lesson learned: never buy a Mac! Or better yet: don't let HR girls use a Mac, for it's not a toy. LOL! Or better still: stop using Windows and switch to Linux. But to be completely honest, I would much rather find a compromise that works for all. I think that compromise is called UTF-8. But not everyone is on board with it. Not yet anyway (Microsoft!!). Alternatively, and I have seen it mentioned on Reddit by Mac users: using 7-Zip file format to ensure cross-platform compatibility.
This is such a weird and confusing problem! I'm not sure what came first, chicken or the egg. But I have seen Zip file incompatibilities between Mac and Windows blamed on many different things, including: corrupted files, wrong passwords, odd Mac files and folders with underscores (e.g.
"__MACOSX"). The latter is sometimes wrongfully blamed on Mac due to incompetence of Windows users that don't understand that they should not be using those files on a Windows PC, and so they put the blame on Mac users when they can't open the files they received.But... why has Microsoft not fixed this already? I wonder. It seems to be as old as time. Is it due to some backwards compatibility with legacy software? This goes way back to at least VC7 (Visual C++ 7.0) from 2002 and Kaplan's blog post from 2006 that questioned this and saw his posts deleted (1, 2).
I found a somewhat related discussion on Superuser.com from 2021, about Windows and macOS zipping differences. Where someone explained that they were using macOS (at their company presumably) to submit data to a third party, and they were required by the recipient to zip their spreadsheets using Windows to ensure compatibility. Talk about a tall order!
Last edit: Ken 2024-04-24
7-Zip uses ACP codepage for zip password. There is no option to change it in 7-zip.
Note that ACP codepage is not same code as OEM (console codepage) that is used for file names.
I suppose I tried to provide more compatibility with pkzip25 / WinZip / Windows. Maybe these programs also use or used ACP codepage for passwords.
Last edit: Igor Pavlov 2024-04-24