public interface ZipEncoding
There are mostly two implementations, one that uses java.nio
Charset
and one implementation,
which copes with simple 8 bit charsets, because java-1.4 did not
support Cp437 in java.nio.
The main reason for defining an own encoding layer comes from
the problems with String.getBytes
, which encodes unknown characters as ASCII
quotation marks ('?'). Quotation marks are per definition an
invalid filename on some operating systems like Windows, which
leads to ignored ZIP entries.
All implementations should implement this interface in a reentrant way.
Modifier and Type | Method and Description |
---|---|
boolean |
canEncode(java.lang.String name)
Check, whether the given string may be losslessly encoded using this
encoding.
|
java.lang.String |
decode(byte[] data) |
java.nio.ByteBuffer |
encode(java.lang.String name)
Encode a filename or a comment to a byte array suitable for
storing it to a serialized zip entry.
|
boolean canEncode(java.lang.String name)
name
- A filename or ZIP comment.java.nio.ByteBuffer encode(java.lang.String name) throws java.io.IOException
Examples for CP 437 (in pseudo-notation, right hand side is C-style notation):
encode("€_for_Dollar.txt") = "%U20AC_for_Dollar.txt" encode("Ölfässer.txt") = "\231lf\204sser.txt"
name
- A filename or ZIP comment.%Uxxxx
. It is
assumed, that the byte buffer is positioned at the
beginning of the encoded result, the byte buffer has a
backing array and the limit of the byte buffer points
to the end of the encoded result.java.io.IOException
- on errorjava.lang.String decode(byte[] data) throws java.io.IOException
data
- The byte values to decode.java.io.IOException
- on errorCopyright © 2010 - 2020 Adobe. All Rights Reserved