使用 ExtractToDirectory 方法解压缩会扭曲非拉丁符号
Unzipping with ExtractToDirectory method distorts non-latin symbols
我有几个包含文件的文件夹，一些文件夹的名称中包含非拉丁符号（在我的例子中是俄语）。此文件夹正在 "D:\test.zip" 中发送到 zip 存档（通过 windows 资源管理器）。
然后我执行 method
ZipFile.ExtractToDirectory(@"D:\test.zip", @"D:\result");
它成功解压了所有内容，但是所有非拉丁符号都变成了错误。
例如，我得到的不是 "D:\result\каскады\file.txt"，而是 "D:\result\Є бЄ ¤л\file.txt"。
我系统的默认编码是 windows-1251 我通过将 Encoding.GetEncoding("windows-1251") 包含在 ExtractToDirectory 的第三个参数中并得到同样的结果。我还尝试了 UTF-8，但在路径中得到了另一个工件 ("D:\result\��᪠��\file.txt")。正在尝试 Unicode return 关于不支持编码的消息。
当我通过执行 method
通过代码创建相同的存档时
ZipFile.CreateFromDirectory(@"D:\zipdata", @"D:\test.zip");
然后使用与问题顶部相同的代码行解压一切，即使没有指定特定的编码。
问题是：如何从存档中获取正确的编码以在 ExtractToDirectory 方法中应用它，因为在实际任务存档中来自外部源，我不能依赖它创建的位置 'by hands' 或以编程方式？
编辑
question 非拉丁符号（中文）也会导致问题，但这个事实就像问题的解决方案一样给出，而这正是我的情况的问题。
没有正式标准化的 ZIP 规范。然而，事实上的标准是 the PKZIP "application note" document，截至 2006 年，它仅记录代码页 437 ("OEM United States") 和 UTF8 作为存档中文件条目的合法文本编码：
D.1 The ZIP format has historically supported only the original IBM PC character
encoding set, commonly referred to as IBM Code Page 437. This limits storing
file name characters to only those within the original MS-DOS range of values
and does not properly support file names in other character encodings, or
languages. To address this limitation, this specification will support the
following change.
D.2 If general purpose bit 11 is unset, the file name and comment should conform
to the original ZIP character encoding. If general purpose bit 11 is set, the
filename and comment must support The Unicode Standard, Version 4.1.0 or
greater using the character encoding form defined by the UTF-8 storage
specification. The Unicode Standard is published by the The Unicode
Consortium (www.unicode.org). UTF-8 encoded data stored within ZIP files
is expected to not include a byte order mark (BOM).
换句话说，使用代码页 437 或 UTF8 以外的任何文本编码是任何 ZIP 创作工具中的错误。根据您的经验，Windows Explorer 似乎存在此错误。 :(
不幸的是，"general purpose bit 11" 是指示存档中使用的实际文本编码的唯一官方机制，它只允许原始 437 代码页或 UTF8。就连这点was not supported by .NET until .NET 4.5。在任何情况下，即使从那时起，.NET 或任何其他 ZIP 存档感知软件也无法可靠地确定用于对存档中的文件条目名称进行编码的非标准、不受支持的编码。
但是，您可以，如果用于创建存档的源计算机已知且可用，请确定安装在该计算机上的默认代码页，通过 CultureInfo class。以下表达式将 return 安装在执行该表达式的计算机上的代码页标识符（当然，假设该进程没有更改其当前的默认区域性）：
System.Globalization.CultureInfo.CurrentCulture.TextInfo.OEMCodePage
这为您提供代码页 ID，可以将其传递给 Encoding.GetEncoding(Int32) 以检索 Encoding 对象，然后在打开现有存档时将其传递给适当的 ZipArchive 构造函数, 以确保正确解码文件条目名称。
如果您无法从作为存档源的机器检索实际的文本编码，那么您将陷入枚举编码的困境，尝试每一种编码，直到找到一种以清晰格式报告条目名称的编码。
据我了解，Windows8 及更高版本可以支持 ZIP 存档文件中的 UTF8 标志。我没试过，但 Windows 的此类版本也可能使用该标志 write 存档。如果是这样，那将（有人希望）减轻早期 Windows 错误的痛苦。
最后请注意，自定义工具可以将编码记录在存档本身中的特殊文件条目中。当然，只有该工具能够识别特殊文件并使用它来确定正确的编码（该工具必须打开存档两次：一次是检索文件，然后在工具确定了编码）。这不是一个理想的解决方案，当然对 Windows Explorer 创建的存档没有帮助。我提到它只是为了完整起见。
我有几个包含文件的文件夹，一些文件夹的名称中包含非拉丁符号（在我的例子中是俄语）。此文件夹正在 "D:\test.zip" 中发送到 zip 存档（通过 windows 资源管理器）。 然后我执行 method
ZipFile.ExtractToDirectory(@"D:\test.zip", @"D:\result");
它成功解压了所有内容，但是所有非拉丁符号都变成了错误。
例如，我得到的不是 "D:\result\каскады\file.txt"，而是 "D:\result\Є бЄ ¤л\file.txt"。
我系统的默认编码是 windows-1251 我通过将 Encoding.GetEncoding("windows-1251") 包含在 ExtractToDirectory 的第三个参数中并得到同样的结果。我还尝试了 UTF-8，但在路径中得到了另一个工件 ("D:\result\��᪠��\file.txt")。正在尝试 Unicode return 关于不支持编码的消息。
当我通过执行 method
通过代码创建相同的存档时 ZipFile.CreateFromDirectory(@"D:\zipdata", @"D:\test.zip");
然后使用与问题顶部相同的代码行解压一切，即使没有指定特定的编码。
问题是：如何从存档中获取正确的编码以在 ExtractToDirectory 方法中应用它，因为在实际任务存档中来自外部源，我不能依赖它创建的位置 'by hands' 或以编程方式？
编辑
question 非拉丁符号（中文）也会导致问题，但这个事实就像问题的解决方案一样给出，而这正是我的情况的问题。
没有正式标准化的 ZIP 规范。然而，事实上的标准是 the PKZIP "application note" document，截至 2006 年，它仅记录代码页 437 ("OEM United States") 和 UTF8 作为存档中文件条目的合法文本编码：
D.1 The ZIP format has historically supported only the original IBM PC character encoding set, commonly referred to as IBM Code Page 437. This limits storing file name characters to only those within the original MS-DOS range of values and does not properly support file names in other character encodings, or languages. To address this limitation, this specification will support the following change.
D.2 If general purpose bit 11 is unset, the file name and comment should conform to the original ZIP character encoding. If general purpose bit 11 is set, the filename and comment must support The Unicode Standard, Version 4.1.0 or greater using the character encoding form defined by the UTF-8 storage specification. The Unicode Standard is published by the The Unicode Consortium (www.unicode.org). UTF-8 encoded data stored within ZIP files is expected to not include a byte order mark (BOM).
换句话说，使用代码页 437 或 UTF8 以外的任何文本编码是任何 ZIP 创作工具中的错误。根据您的经验，Windows Explorer 似乎存在此错误。 :(
不幸的是，"general purpose bit 11" 是指示存档中使用的实际文本编码的唯一官方机制，它只允许原始 437 代码页或 UTF8。就连这点was not supported by .NET until .NET 4.5。在任何情况下，即使从那时起，.NET 或任何其他 ZIP 存档感知软件也无法可靠地确定用于对存档中的文件条目名称进行编码的非标准、不受支持的编码。
但是，您可以，如果用于创建存档的源计算机已知且可用，请确定安装在该计算机上的默认代码页，通过 CultureInfo class。以下表达式将 return 安装在执行该表达式的计算机上的代码页标识符（当然，假设该进程没有更改其当前的默认区域性）：
System.Globalization.CultureInfo.CurrentCulture.TextInfo.OEMCodePage
这为您提供代码页 ID，可以将其传递给 Encoding.GetEncoding(Int32) 以检索 Encoding 对象，然后在打开现有存档时将其传递给适当的 ZipArchive 构造函数, 以确保正确解码文件条目名称。
如果您无法从作为存档源的机器检索实际的文本编码，那么您将陷入枚举编码的困境，尝试每一种编码，直到找到一种以清晰格式报告条目名称的编码。
据我了解，Windows8 及更高版本可以支持 ZIP 存档文件中的 UTF8 标志。我没试过，但 Windows 的此类版本也可能使用该标志 write 存档。如果是这样，那将（有人希望）减轻早期 Windows 错误的痛苦。
最后请注意，自定义工具可以将编码记录在存档本身中的特殊文件条目中。当然，只有该工具能够识别特殊文件并使用它来确定正确的编码（该工具必须打开存档两次：一次是检索文件，然后在工具确定了编码）。这不是一个理想的解决方案，当然对 Windows Explorer 创建的存档没有帮助。我提到它只是为了完整起见。