The VideoLAN Forums

Hi!

In the changelog for 1.0.0 I see:

* On-the-fly zip file decompression and browsing (MRL of the form zip://file.zip|file.avi to specify the file)

Did you consider the already existing* jar URI scheme ?

Regards,
David

* - defined, implemented, tried, tested,...

Did you consider the already existing* jar URI scheme ?

AFAIK no-one mentioned jar URI scheme on mailing list when this issue was discussed.
http://mailman.videolan.org/pipermail/v ... 54699.html

Let me complete the first post: Already existing jar scheme, that works wit ZIP files. (JAR files are just ZIP files with changed file name)

What about detailling what jar URI is?

Google throws out this:
http://docs.sun.com/source/819-0913/aut ... arprotocol
http://java.sun.com/javase/6/docs/api/j ... ction.html

Did you consider the already existing* jar URI scheme ?
...
* - defined, implemented, tried, tested,...

Hello,

Yeah I considered it, but forgot about the idea. Maybe !/ can be used as separator, it would indeed be more "standardized"...
But we cannot use zip:file://blahblah because of VLC's own access/demux:// notation.

My problem with Zip urls is that you can always create a folder named "wonderful.zip!" (even on Windows!) and then... you can't simply cut after the first "!/" otherwise you try to open a folder as a Zip archive! I have the same issue with '|'.
Still, this is a nice idea. Let me have a look.

rgds,
jpeg

Special characters in URLs can (and must) be escaped in the percent notation.
Example: jar:file:///folder1/wonderful.zip%21!/dir_in_zip/file_in_zip

You think the unix guys did not test this with jar: protocol ?

Also all other "funny" cases work. As I said, this is thought over and tested stuff.

Special characters in URLs can (and must) be escaped in the percent notation.
Example: jar:file:///folder1/wonderful.zip%21!/dir_in_zip/file_in_zip

Here we have a bug (in VLC) when we URL-encode (%-notation) special UTF-8 characters like ë (e with 2 dots on it). Encoding is OK, but decoding fails to go back to ë, it writes two random characters instead. I don't know if VLC's URL-encoding/decoding is broken, but this seems to be the only case (Zip) where it does not work as expected.

You think the unix guys did not test this with jar: protocol ?
Also all other "funny" cases work. As I said, this is thought over and tested stuff.

I never doubted of that.
But in this very particular case of Zip demux/access, I can't rely on a simple URL-encoding (one reason being that XML reading will automatically decode % stuff... yeah there's XML somewhere :-/).
Still, I'll use !/ instead of | if possible.

Thanks for your interest,
jpeg

You think the unix guys did not test this with jar: protocol ?

Usually, the Unix guys don't care about windows, if you see what I mean.

"fixed" in http://git.videolan.org/gitweb.cgi?p=vl ... b8759a9a65.
I'm neither using %-notation, nor zip:access:// URLs (for different reasons), but I choose to use !/.

Best regards,
jpeg

You think the unix guys did not test this with jar: protocol ?

Usually, the Unix guys don't care about windows, if you see what I mean.

I don't.

URLs etc. are platform independent standards.

But in this very particular case of Zip demux/access, I can't rely on a simple URL-encoding (one reason being that XML reading will automatically decode % stuff... yeah there's XML somewhere :-/).

% should be transparent to XML.
Unless it is yet another case of "our own invented implementation of XML"

But in this very particular case of Zip demux/access, I can't rely on a simple URL-encoding (one reason being that XML reading will automatically decode % stuff... yeah there's XML somewhere :-/).

% should be transparent to XML.
Unless it is yet another case of "our own invented implementation of XML"

This is exactly my problem: VLC handles XML correctly with %-encoded stuff
Thus, if I have a "!/" (not the final one) encoded in "%21/", it will be decoded automatically while reading the XML. So I can't know which of the two "!/" is the good one and I fail to open the file!

Also, I wanted to be compatible with XML but also with hand-written URL, so "vlc zip://noël.zip!/fête.avi" will work. That's why i chose to control my encoding/decoding instead of leaving XML do the job for me. Btw, you will never see the XML we're talking about. And %-encoded URLs should work also as VLC will decode them before feeding them into the module.

Finally, I agree that this is not URL standard. I don't care as this fulfills all my needs.

rgds,
jpeg

I don't follow.

So there is some step in the procedure, where the URL is stored inside XML, then retreived and the final URL is not the same as the original ?

Well that is plain simple "XML not done correctly". Unless I misunderstood.

Can you give an example ?

So there is some step in the procedure, where the URL is stored inside XML, then retreived and the final URL is not the same as the original ?

Yeah, I understand you feel a bit lost with my partial explanation

If you directly type "vlc zip://file.zip!/file.avi", well.. there's no XML, no URL encoding, nothing strange here.
But if you open "vlc file.zip" then, internally, VLC will read the index of the Zip file, generate an in-memory XSPF playlist containing encoded URLs of the form zip://file.zip!/file.avi.
This internal playlist will be immediately read by the XSPF demuxer, so that the tree of the files inside the Zip archive appears in VLC playlist.
The playlist items have encoded URLs (not web encoding).

Opening file.zip directly should be the preferred behaviour, otherwise you would have to encode the URL by yourself if it contains a "!/" (or more easily copy/paste a playlist item's URL). If the URL does not contain a !/ (except for the jar-style separator), you can happily use any utf-8 url (the decoding function will not mess with that).

Finally, if you use a URL-encoded (%-notation) URL, it also works because VLC internally decodes the URL before sending it to the module. So you should be happy in every case

Hope this helps you understand, because this was a bit tricky.

rgds,
jpeg