On 2009-02-11, sebb wrote:
> That seems likely to produce some confusion - would it not be better
> to default to UTF-8?
Yes, that's been my initial question. Is it OK to have no default at
all or should we keep with UTF-8?
Given that ZipArchiveInputStream doesn't support anything but UTF-8 at
On 11/02/2009, Stefan Bodewig wrote:
> On 2009-02-11, Torsten Curdt wrote:
>
> > I am also not so sure this really all that bad. I guess there are 3
> scenarios
>
> > 1: the archive standard is known to use a specific encoding
> > 2: the encoding is specified inside the archive (which is simi
On 2009-02-11, Torsten Curdt wrote:
> I am also not so sure this really all that bad. I guess there are 3 scenarios
> 1: the archive standard is known to use a specific encoding
> 2: the encoding is specified inside the archive (which is similar to 1)
> 3: we have no clue about the encoding of t
I am also not so sure this really all that bad. I guess there are 3 scenarios
1: the archive standard is known to use a specific encoding
2: the encoding is specified inside the archive (which is similar to 1)
3: we have no clue about the encoding of the strings in the archive
Unless I am missing
On 2009-02-10, Christian Grobmeier wrote:
> Can this be simulated when creating a file within testcase and then
> changing java.encoding stuff and extracting it again?
Likely. I'm not sure whether String#getBytes consults the system
property for each invocation.
> If so I can write a testcase
On 2009-02-10, Mark Fortner wrote:
> I meant specifically if I was using this library at both ends of the
> equation.
Then if you don't specify an encoding explicitly, you will have a
problem, yes. Of course only, if your file names have non-ASCII
characters in the first place since most native
I meant specifically if I was using this library at both ends of the
equation. I assume that if you use different tools at either end, you may
have some challenges. But if I use this library at both ends, and use the
default settings, then I imagine I would have some difficulty on the
decompressi
>> > ZipArchiveOutputStream will now use the platform's native encoding
>> > instead of UTF8 by default now, while JarArchiveOutputStream
>> > explicitly sets the encoding to UTF8. Does anybody consider this a
>> > problem?
>>
> What happens if you try to take a file that was created on a machine
On 2009-02-10, Mark Fortner wrote:
>>> ZipArchiveOutputStream will now use the platform's native encoding
>>> instead of UTF8 by default now, while JarArchiveOutputStream
>>> explicitly sets the encoding to UTF8. Does anybody consider this a
>>> problem?
> What happens if you try to take a fil
>
> > ZipArchiveOutputStream will now use the platform's native encoding
> > instead of UTF8 by default now, while JarArchiveOutputStream
> > explicitly sets the encoding to UTF8. Does anybody consider this a
> > problem?
>
>
What happens if you try to take a file that was created on a machine wit
On 2009-02-10, Torsten Curdt wrote:
>> Ant never had a ZipInputStream replacement, we only use ZipFile since
>> the zip format is a lot easier to implement on top of
>> RandomAccessFile.
> Hm ... never thought this would be a problem for just reading.
You need to merge data from the local file
> I've merged ZipEntry into ZipArchiveEntry and ZipOutputStream into
> ZipArchiveOutputStream. As a side effect ZipArchiveOutputStream now
> supports encoding of file names and the zip file comment (among other
> things that it does better than java.util.zip.ZipOutputStream like
> providing usable
Hi,
I've merged ZipEntry into ZipArchiveEntry and ZipOutputStream into
ZipArchiveOutputStream. As a side effect ZipArchiveOutputStream now
supports encoding of file names and the zip file comment (among other
things that it does better than java.util.zip.ZipOutputStream like
providing usable Unix
13 matches
Mail list logo
