starred/sharpcompress
1
0
Fork 0
mirror of https://github.com/adamhathcock/sharpcompress.git synced 2026-02-03 21:23:38 +00:00
Code Issues 975 Packages Projects Releases 20 Wiki Activity

[PR #30] [MERGED] Fix ansi filename decoded as gibberish in zip file #794

New Issue
Open
opened 2026-01-29 22:17:36 +00:00 by claunia · 0 comments
claunia commented 2026-01-29 22:17:36 +00:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/adamhathcock/sharpcompress/pull/30
Author: @larvata
Created: 12/24/2014
Status: ✅ Merged
Merged: 12/24/2014
Merged by: @adamhathcock

Base: master ← Head: fix-zip-ansi-filename

📝 Commits (1)

  • 0c36ff6 Fix ansi filename decoded as gibberish in zip file

📊 Changes

1 file changed (+1 additions, -1 deletions)

View changed files

📝 SharpCompress/Common/ArchiveEncoding.cs (+1 -1)

📄 Description

I have noticed the same issue was created before DecodeString (in ZipFileEntry) fails to properly decode file path

The bug occurred on the zip file entry filename has non-ascii character and created by an archive manager which didn't support unicode entry filename.

According wiki Windows code page

The OEM code pages (original equipment manufacturer) are used by Win32 console applications, and by virtual DOS, and can be considered a holdover from DOS and the original IBM PC architecture.

ANSI code pages (officially called "Windows code pages"[1] after Microsoft accepted the former term being a misnomer[2]) are used for native non-Unicode (say, byte oriented) applications using a graphical user interface on Windows systems.

If in an english windows the Language for non-Unicode programs was set to Chinese (Simplifed,RPC). The zip entry filename will be encoded with codepage 936(ANSI code pages),but sharpcompress decoded the filename with codepage 437(OEM code pages)

In the other word, the codepage for entry filename encoding relays on ANSI code pages.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/adamhathcock/sharpcompress/pull/30 **Author:** [@larvata](https://github.com/larvata) **Created:** 12/24/2014 **Status:** ✅ Merged **Merged:** 12/24/2014 **Merged by:** [@adamhathcock](https://github.com/adamhathcock) **Base:** `master` ← **Head:** `fix-zip-ansi-filename` --- ### 📝 Commits (1) - [`0c36ff6`](https://github.com/adamhathcock/sharpcompress/commit/0c36ff608221f613213d06e98bb406423f73f8a5) Fix ansi filename decoded as gibberish in zip file ### 📊 Changes **1 file changed** (+1 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `SharpCompress/Common/ArchiveEncoding.cs` (+1 -1) </details> ### 📄 Description I have noticed the same issue was created before [DecodeString (in ZipFileEntry) fails to properly decode file path](https://sharpcompress.codeplex.com/workitem/32) The bug occurred on the zip file entry filename has non-ascii character and created by an archive manager which didn't support unicode entry filename. According wiki [Windows code page](http://en.wikipedia.org/wiki/Windows_code_page) > The OEM code pages (original equipment manufacturer) are used by Win32 console applications, and by virtual DOS, and can be considered a holdover from DOS and the original IBM PC architecture. > > ANSI code pages (officially called "Windows code pages"[1] after Microsoft accepted the former term being a misnomer[2]) are used for native non-Unicode (say, byte oriented) applications using a graphical user interface on Windows systems. If in an english windows the `Language for non-Unicode programs` was set to `Chinese (Simplifed,RPC)`. The zip entry filename will be encoded with codepage 936(ANSI code pages),but sharpcompress decoded the filename with codepage 437(OEM code pages) In the other word, the codepage for entry filename encoding relays on ANSI code pages. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
claunia added the pull-request label 2026-01-29 22:17:36 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
duplicate
enhancement
feedback requested
not bug
pull-request
Mirrored from GitHub Pull Request
 question
up for grabs
wontfix
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/sharpcompress#794
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?