Какие проблемы могут возникнуть с функциями zip и unzip при работе со строками

Что проверяют

Понимаете ли вы, что строка и сжатые байты это разные сущности, а граница между ними проходит через кодировку. Следом обычно просят показать, как сжать строку и сохранить результат в текстовое поле базы или в JSON.

Как отвечать

Сначала уточните, о каком zip речь. Чаще имеют в виду сжатие через java.util.zip, и тогда проблемы такие:

• кодировка на входе: getBytes() без аргумента берёт кодировку по умолчанию. С Java 18 это везде UTF-8, но на старых JDK результат зависит от машины. Пишите явно getBytes(StandardCharsets.UTF_8) и так же new String(bytes, UTF_8) на обратном пути;
• сжатые байты не текст: new String(compressed) портит данные, некорректные последовательности заменяются на U+FFFD, и распаковать это уже нельзя. Для хранения в строке нужен Base64;
• короткие строки растут: у GZIP заголовок и хвост занимают около 18 байт, а Base64 добавляет ещё треть. Строку в сто символов сжимать бессмысленно;
• нативная память: Deflater и Inflater работают через zlib вне кучи. Без end() или закрытия потока-обёртки эта память держится до сборки мусора;
• недоверенный вход: распаковка без лимита на размер результата открывает дорогу zip-бомбе. Читайте кусками и обрывайте на пороге;
• архивы: ZipInputStream по умолчанию ждёт имена в UTF-8, архив из старого Windows-архиватора падает с MALFORMED, помогает конструктор с Charset. Имена вида ../../etc без проверки через normalize() и startsWith() дают Zip Slip.

Если имелось в виду попарное объединение последовательностей, то в Stream API такого метода нет, а в Kotlin zip молча обрезает результат по более короткой стороне.

Где спотыкаются

Гоняют сжатые данные через String «для удобства», а потом ищут, почему Inflater бросает DataFormatException.

Сжимают всё подряд и не замечают, что на коротких значениях объём растёт, а процессор тратится впустую.

Распаковывают пользовательский файл целиком в память через readAllBytes() и получают OutOfMemoryError на архиве в пару мегабайт.