Не "в UTF8", а "как дали на файловой системе".

Предлагаю либо не пользоваться zip на Linux для создания архивов с файлами,
имена которых не умещаются в ASCII (поскольку ни Host OS, ни тем более
локаль/кодировка там не фигурируют); либо пропатчить zip на манер unzip для
использования libnatspec.

Пример патча -- см. #12313 (вообще такое пожелание к zip уже высказывалось в
#4871, но вместе с уже исправленным в unzip).

Я этого делать не умею, мож Вы сделаете или приглашённые в Cc:...

Блокером Desktop 4.0 эту багу считать не могу -- разумный человек не создаёт
.zip на Linux (скорее .7z или .rar, если уж надо на win32 утащить).  Если очень
припекло -- поможет ru_RU.CP1251.

ИМХО все же баг ибо unzip(zip x) != x

Да, и кстати, при попытке отправить аттач в kmail в зипе получается тоже... Не 
очень... 

unzip(zip x) == x, когда x non-ASCII, только при условии использования zip и
unzip из одного источника(infozip, winzip и т.п.), при одинаковой операционной
системе. Так что это не бага - это фича формата!

Жень, тут как получается... у нас даже zip и unzip из одного источника на одном
ALT 4.0 некомплементарны потому, что unzip летом таки пропатчили, а вот zip -- нет.

Бага висела, мне слабо.  Но на совете из первого комментария стою -- не стоит
работать с .zip с не-ASCII-именами на Linux без крайней на то необходимости...

Ну так у нас zip/unzip сейчас из "разных" источников :))) 

Ну так что, всё-таки дописать zip? Кто-то брался уже, я даже патчи отсылал, но 
не доделал...
Мне вот zip очень удобен в качестве формата, который "откроют все".