че-то я намучался с поддержкой unicode, поначалу файлы не открывались, я поправил файл ioapi.c, сделал открытие через _wfopen с предварительным конспектированием из utf8
теперь проблема с поиском файлов внутри zip, запаковал файл ф1.txt, нашел функцию где идет стравнение имен - unzip.c unzStringFileNameCompare
когда вызываю unzLocateFile передаю ей имя переведенное в utf8 - С„1.txt
но останавливая на функции сравнения имен, вижу что из zip достается файл с именем д1.txt, почему так? как научить zlib нормально переваривать файлы с любыми именами?
Alibego
> я поправил файл ioapi.c,
не нужно ничего там править, есть функция unzOpen2 в которой можно определить свой "zopen_file".
> теперь проблема с поиском файлов внутри zip
вот с этим даже не пробовал, собственно нафига? %) если мы о играх говорим, то это точно не нужно.
zlib как бы вообще не работает с .zip файлами, там просто есть пример как можно было бы это сделать. есть zziplib например
berserkovich
> zlib как бы вообще не работает с .zip файлами
minizip в составе zlib работает
Alibego
> не нужно ничего там править, есть функция unzOpen2 в которой можно определить свой "zopen_file".
оу, эту функцию я не заметил, и переделать не сложно, пасиб
> вот с этим даже не пробовал, собственно нафига?
принципы, бесит ПО которое придирчиво к именам файлов, не хочу быть на месте таких создателей
имена файлов внутри zip закодированы в dos-кодировке, юзай CharToOem() и OemToChar()
Alibego
> принципы, бесит ПО которое придирчиво к именам файлов, не хочу быть на месте
> таких создателей
Ура, вы еще добавте юникод в имена классов в C++, ну так из принцыпа давайте называть классы китайскими иероглифами, просто чтобы интересней было. Или пусть теперь все хэш таблицы (надо, не надо) работают с 2-х байтными строками (наверно сравнения будут быстрее от этого).
А если серьзно, то ВСЁ что не связанно с локализацией должно быть СТРОГО латиницей, а еще лучше по английски и никаких юникодов там и близко быть не должно.
Bishop
> Ура, вы еще добавте юникод в имена классов в C++, ну так из принцыпа давайте
> называть классы китайскими иероглифами, просто чтобы интересней было
фиговый аргумент, я видел исходники где имена классов на китайском, и ничего, живут люди
cranky, попробую
Снова проблема, при конвертировании через CharToOem() из ф1.txt получается д1.txt и все работает
Но если изменить имя файла на 漢ф1.txt, файл не архивируется стандартным зип упаковщиком Win7 (что странно, zip вроде сейчас уже поддерживает юникод), а вот WinRar'ом (или 7Zip) в zip - архивируется, и при этом внутри имя файла сохраняется в utf8, изменил имя на ф1.txt и winrar (или 7zip) сохраняет его в oem, но в каждом из этих случаев распаковывает так как было, значит наверно кодировка где-то хранится, где и как научить zlib ее учитывать?
Alibego
> при конвертировании через CharToOem() из ф1.txt получается д1.txt и все
> работает
это при просмотре в режиме отладки в ide или файл с таким именем получается?
> если изменить имя файла на 漢ф1.txt, файл не архивируется стандартным зип
> упаковщиком Win7
внутри зип-файла все строки с именами файлов состоят из oem набора символов, т.е. стандартная ascii таблица + расширенная, которая заполняется роизводителем пк. в россии, как ни странно, эта таблица обычно содержит кириллицу, а в китае наверное иероглифы.
з.ы. реализуй свой контейнер, это ведь не сложно, и помещай туда строки в юникоде на здоровье, другое дело, что как говорилось выше - так никто не делает.
cranky
> это при просмотре в режиме отладки в ide или файл с таким именем получается?
первое
> внутри зип-файла все строки с именами файлов состоят из oem набора символов,
> т.е. стандартная ascii таблица + расширенная, которая заполняется роизводителем
> пк. в россии, как ни странно, эта таблица обычно содержит кириллицу, а в китае
> наверное иероглифы.
нет, когда я запаковал файл 漢ф1.txt, то при отладке функции unzStringFileNameCompare, zlib доставал строку жјўС„1.txt, т.е. архиватор не смог сохранить имя в одно байтовую кодировку, и сохранил в utf8. Т.е. если я эту utf8 передам в unzLocateFile то файл находится, а вообще zip с версии 2007ого года поддерживает юникод в именах файлах, только я не пойму где обозначается в какой кодировке имя файла
Alibego
> первое
ide отображает строки в cp1251 по умолчанию, тогда как на выходе CharToOem() строка закодирована в cp866
Alibego
> zip с версии 2007ого года поддерживает юникод в именах файлах
это вроде как опционально, так что не факт, что в minizip эта фича поддерживается
cranky
> ide отображает строки в cp1251 по умолчанию, тогда как на выходе CharToOem() строка закодирована в cp866
что это меняет? я знаю это
> это вроде как опционально, так что не факт, что в minizip эта фича поддерживается
minizip вообще не поддерживает никакие кодировки, он имена файлов предоставляет в сыром виде, в том в котором они сохранены внутри zip
вопрос в том что архиваторы могут сохраняют имена в разных кодировках, и разархивируются они нормально, значит она где-то хранится
На ZIP формат есть вполне доступная спецификация, в которой сказано как кодировку сохранять.
http://www.pkware.com/documents/casestudies/APPNOTE.TXT
(Appendix D)
Alibego
> архиваторы могут сохраняют имена в разных кодировках
это слишком расплывчатое определение, если говорить конкретно о minizip, то этой библиотекой добавление/извлечение файлов с именами в юникоде не поддерживается, во всяком случае я не заметил.
Тема в архиве.