{
  "WorkItem": {
    "AffectedComponent": {
      "Name": "",
      "DisplayName": ""
    },
    "ClosedComment": "Not a bug.  Read the documentation. ",
    "ClosedDate": "2011-03-20T06:47:50.457-07:00",
    "CommentCount": 0,
    "Custom": null,
    "Description": "http://stackoverflow.com/questions/4654860/using-dotnetzip-library-unzip-file-with-non-ascii-characters",
    "LastUpdatedDate": "2013-05-16T05:31:39.43-07:00",
    "PlannedForRelease": "",
    "ReleaseVisibleToPublic": false,
    "Priority": {
      "Name": "Low",
      "Severity": 50,
      "Id": 1
    },
    "ProjectName": "DotNetZip",
    "ReportedDate": "2011-01-10T22:54:04.17-08:00",
    "Status": {
      "Name": "Closed",
      "Id": 4
    },
    "ReasonClosed": {
      "Name": "Unassigned"
    },
    "Summary": "Encoding of danish character ø and Ø gets mangled",
    "Type": {
      "Name": "Issue",
      "Id": 3
    },
    "VoteCount": 1,
    "Id": 12810
  },
  "FileAttachments": [],
  "Comments": [
    {
      "Message": "It's not a bug. DotNetZip follows the zip spec with respect to non-ascii characters in filenames. You need to use the ZipFile.Read() overload that allows you to specify a code page when reading a zip file like that. In the ZIP spec, the default, supported formats are IBM437 (effectively a subset of ASCII) and UTF8. If your file is neither of those you need to specify the code page explicitly - there's no way for any library to reliably infer the correct page from the zip file. Assuming it is \"the default code page on the desktop\", as those other libraries do, is incorrect and risky. – Cheeso Jan 11 at 13:32  \r\n\r\n Also - the handling of codepages is all documented extensively in the helpfile for DotNetZip. – Cheeso Jan 11 at 13:33  \r\n\r\n hmm, perhaps. The main point is that is does not work out off the box. All the other zip programs and libraries, its just works. – Morten Lyhr Jan 11 at 18:43 \r\n\r\n Morten, just because it worked doesn't mean it's safe or correct. DotNetZip \"works\", too, but you need to know how to use it. If your zip file were compliant (either UTF8 or IBM437) then it would \"just work\" in DotNetZip without requiring you to specify a code page. Because your zip file is non-compliant, DotNetZip requires that you take extra steps. – Cheeso Jan 12 at 1:01  \r\n\r\n If my zip file is not compliant, how come TotalCommander, Windows nad 7zip can readit just fine? – Morten Lyhr Jan 12 at 8:10 \r\n\r\n Because they make assumptions that DotNetZip does not make - specifically that the zipfile was constructed with the local code page \r\n\r\n",
      "PostedDate": "2011-03-20T06:47:36.773-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2011-03-20T06:47:50.457-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-02-21T18:43:18.957-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-05-16T05:31:39.43-07:00",
      "Id": -2147483648
    }
  ]
}