|
Заархивировать папку с нужной кодировкой
|
|||
---|---|---|---|
#18+
Создаю архив в Windows os.system("C:\Program Files\7-Zip\7z.exe" a FILE.zip D:\data*) при извлечении файлов из архива, имена файлов корректно отображаются (предположительно кодировка utf-8). Решил использовать zip.ZipFile() или shutil.make_archive() при попытке получить имена файлов из архива, они в непонятной кодировке. Вопрос: можно ли при формировании архива через zip.ZipFile() или shutil.make_archive() указать кодировку имен файлов в архиве? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2019, 19:53 |
|
Заархивировать папку с нужной кодировкой
|
|||
---|---|---|---|
#18+
вменяемый архиватор не меняет архивируемые данные смотрите кодировку вашей текущей консоли ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2019, 20:42 |
|
Заархивировать папку с нужной кодировкой
|
|||
---|---|---|---|
#18+
С zip всё сложно. Формат появился еще в 1989 году, про юникод еще не думали, и изначально для имен файлов поддерживалась только cp437. Ну а поскольку формат сразу был открытым, и использовался разными программами, появилось два различных способа сохранения utf-8 имен файлов в архиве. Так что вопрос кто какой из них поддерживает. Если запаковывать и распаковывать одной и той же программой, проблем обычно не возникает (ну если это не совсем древняя программа, не поддерживающая юникод). https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT APPENDIX D - Language Encoding (EFS) ------------------------------------ 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). D.3 Applications MAY choose to supplement this file name storage through the use of the 0x0008 Extra Field. Storage for this optional field is currently undefined, however it will be used to allow storing extended information on source or target encoding that MAY further assist applications with file name, or file content encoding tasks. Please contact PKWARE with any requirements on how this field SHOULD be used. D.4 The 0x0008 Extra Field storage MAY be used with either setting for general purpose bit 11. Examples of the intended usage for this field is to store whether "modified-UTF-8" (JAVA) is used, or UTF-8-MAC. Similarly, other commonly used character encoding (code page) designations can be indicated through this field. Formalized values for use of the 0x0008 record remain undefined at this time. The definition for the layout of the 0x0008 field will be published when available. Use of the 0x0008 Extra Field provides for storing data within a ZIP file in an encoding other than IBM Code Page 437 or UTF-8. D.5 General purpose bit 11 will not imply any encoding of file content or password. Values defining character encoding for file content or password MUST be stored within the 0x0008 Extended Language Encoding Extra Field. D.6 Ed Gordon of the Info-ZIP group has defined a pair of "extra field" records that can be used to store UTF-8 file name and file comment fields. These records can be used for cases when the general purpose bit 11 method for storing UTF-8 data in the standard file name and comment fields is not desirable. A common case for this alternate method is if backward compatibility with older programs is required. D.7 Definitions for the record structure of these fields are included above in the section on 3rd party mappings for "extra field" records. These records are identified by Header ID's 0x6375 (Info-ZIP Unicode Comment Extra Field) and 0x7075 (Info-ZIP Unicode Path Extra Field). D.8 The choice of which storage method to use when writing a ZIP file is left to the implementation. Developers SHOULD expect that a ZIP file MAY contain either method and SHOULD provide support for reading data in either format. Use of general purpose bit 11 reduces storage requirements for file name data by not requiring additional "extra field" data for each file, but can result in older ZIP programs not being able to extract files. Use of the 0x6375 and 0x7075 records will result in a ZIP file that SHOULD always be readable by older ZIP programs, but requires more storage per file to write file name and/or file comment fields. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 11:49 |
|
|
start [/forum/topic.php?fid=23&msg=39888276&tid=1459817]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
31ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
2ms |
others: | 251ms |
total: | 380ms |
0 / 0 |