<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-05-24 5:02 GMT-03:00 Reinier Olislagers <span dir="ltr"><<a href="mailto:reinierolislagers@gmail.com" target="_blank">reinierolislagers@gmail.com</a>></span>:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 24/05/2014 08:33, Michael Van Canneyt wrote:<br>
> On Fri, 23 May 2014, Craig Peterson wrote:<br>
>> The Info-zip project maintains an annotated Appnote that lists a bunch<br>
>> of the extra fields that various vendors use here:<br>
>> <a href="http://www.info-zip.org/doc/" target="_blank">http://www.info-zip.org/doc/</a><br>
</div><div class="">> Strange then that the info-zip so often creates garbled filenames on<br>
> Linux !<br>
> Probably the used zipper doesn't use the extra fields.<br>
</div>Of course it doesn't use them. It has no unicode support.<br>
<div class=""><br>
<br>
> Since it is optional, we can probably add a WideString property to the<br>
> zipitem and add an overloaded call;<br>
> Then we don't need to recreate everything,<br>
</div>Recreate everything? Don't get what you mean here.<br>
<div class=""><br>
>just add the extra fields.<br>
</div>(Yes, IIRC, the zip64 fix added support for extra fields already so it<br>
shouldn't be a big change)<br>
<br>
Agreed when writing.<br>
When reading, I'd suggest following the suggested behaviour in the spec:<br>
1. Try to read UTF8 filename from the EFS; if not present fall back to<br>
2. Try to read extra fields filename as implemented by info-zip/abbrevia<br>
etc, if not present fall back to<br>
3. current behaviour (reading filename as is)</blockquote><div><br></div><div></div></div><div>Perfect! :)</div><div><br></div>-- <br>Silvio Clécio<br>My public projects - <a href="http://github.com/silvioprog" target="_blank">github.com/silvioprog</a>
</div></div>