FileSystem fichier ZIP

Version imprimable

11/08/2020, 23h25
ouelado

FileSystem fichier ZIP

Bonjour les amis,

Je me permet de créer cette discussion pour poser une bête question.
Quelqu'un pourrait-il m'expliquer à ce que fait cette ligne de code exactement :

Code:

(FileSystem zipFS = FileSystems.newFileSystem(Paths.get("monFichier.zip"), null))

Les amis, croyez moi, j'ai cherché pendant des heures pour trouver une explication simple et concise, mais rien à faire. Je suis arrivé à un moment où la colère est montée parce que je trouve pas de réponse, alors que je suis sûr que l'explication est simple.
Partout où je vais, on utilise la class FileSystem comme si sa définition allait de soit.

Et tant que j'y suis, je me permet de rajouter une question. Pouvez-vous aussi m'expliquer cette ligne de code :

Code:

(DirectoryStream<Path> stream = Files.newDirectoryStream(zipFS.getPath("/")))

Ceci est, je pense, comme un itérateur, il sert à parcour les fichier que j'ai dans mon dossier zip, mais à quoi sert la barre oblique "/" qui est passé en argument de la méthode "getPath()"

Je tiens juste à rajouter que je suis vraiment débutant.

Et un grand merci d'avance pour votre aide :) :D
12/08/2020, 01h15
thelvin

Hello,

un FileSystem, c'est juste ce que le nom dit, en français un système de fichiers. On peut lister les fichiers et répertoires qu'il contient, et lire les fichiers qui s'y trouvent.
La première ligne que tu montres, sert à construire un FileSystem qui se basera sur le contenu du fichier zip donné : il devient du coup possible de parcourir le contenu du zip, en utilisant des méthodes de lecture d'un système de fichier.
Ce genre de choses évite de devoir programmer différemment, selon qu'on lise des vrais fichiers du disque dur, ou des fichiers compressés dans une archive zip.

Le "/" dans la deuxième ligne, est un standard courant pour désigner la racine d'un système de fichiers, le répertoire qui contient tout ce qu'il y a dans le système de fichiers, soit directement, soit dans les répertoires descendants. En partant de lui, on parcourt tout.
Bien que "/" soit un standard courant, ce n'est pas la seule manière de penser les systèmes de fichiers, et par exemple dans les systèmes Windows il n'y a pas de racine unique, mais plusieurs volumes (c:, d:, e: etc).
Du coup pour être raisonnablement compatible avec toutes les façons de penser un système de fichiers, FileSystem ne peut pas proposer une simple méthode getRootDir() pour donner la racine, car il existe des systèmes où la racine n'est pas unique et il ne pourrait pas deviner laquelle donner.
A la place il propose d'énumérer toutes les racines disponibles. Mais comme ce que tu as construit là, c'est basé sur un fichier zip, avec racine unique donc, c'est lourdingue de devoir demander toutes les racines et prendre la première puisque c'est la seule. A la place on préfèrera demander le répertoire "/", ça te donne la racine directement.
13/08/2020, 21h49
ouelado

Bonjour Thelvin,

Tout d'abord un grand merci d'avoir pris le temps de répondre et de m'expliquer.
Donc si j'ai bien compris, la première ligne de code

Code:

(FileSystem zipFS = FileSystems.newFileSystem(Paths.get("monFichier.zip"), null))

sert à lister les fichier à l'intérieur de mon fichier zip pour qu'on puisse lire, écrire, manipuler, ... etc les fichiers qui s'y trouvent.

Une dernière chose, à quoi sert le "null" qui est aussi passé en paramètre?

Et la deuxième ligne de code sert à parcourir les fichiers, et la barre oblique indique qu'on doit partir du fichier zipFS.
Si on doit remplacer la barre oblique, se serait par quoi exactement? Par un nom de fichier qui se trouve à l'intérieur du fichier zip zipFS ?

C'est bien ça?
13/08/2020, 22h26
thelvin

Hello,

Citation:

Envoyé par ouelado

sert à lister les fichier à l'intérieur de mon fichier zip pour qu'on puisse lire, écrire, manipuler, ... etc les fichiers qui s'y trouvent.

Non, cette ligne ne liste rien du tout, elle construit un object qui est capable de lire le fichier zip, pour que, quand tu demandes à cet objet de le faire, il puisse lister les fichiers présents, ou les ouvrir.

À noter que je ne suis pas sûr qu'il permette de "manipuler" les fichiers du zip. Je ne serais pas surpris que tout ça soit en lecture seule. Il faudrait essayer, parce que c'est vrai que le format zip permet en principe de faire des modifications à ce qu'il contient.

Citation:

Envoyé par ouelado

Une dernière chose, à quoi sert le "null" qui est aussi passé en paramètre?

À rien. La personne qui a écrit cette ligne n'aurait pas dû le mettre. Ça aurait dû être :

Code:

(FileSystem zipFS = FileSystems.newFileSystem(Paths.get("monFichier.zip")))

À la place du null, il est possible de fournir des options de configuration pour contruire cet objet FileSystem.
Par exemple, si le fichier zip était chiffré, il serait serait impossible de l'ouvrir sans un mot de passe, ou une clé de déchiffrage, ou une chaîne de certificats qui puisse produire cette clé. Dans ce cas, il faut bien un moyen de le fournir, et d'expliquer lequel c'est.
Dans ton exemple, c'est un fichier .zip qui s'ouvre tout seul sans problème, et il n'y a aucun besoin d'indiquer quoi que ce soit d'autre que le fichier lui-même.

Citation:

Envoyé par ouelado

Si on doit remplacer la barre oblique, se serait par quoi exactement? Par un nom de fichier qui se trouve à l'intérieur du fichier zip zipFS ?

Vu qu'il s'agit de parcourir, un nom de fichier ne ferait pas sens. On ne parcourt pas un fichier, on parcourt une arborescence de fichiers.
Ce serait plutôt le nom d'un répertoire contenu dans le zip. Plus exactement le chemin complet de ce répertoire dans le zip.
17/08/2020, 20h19
ouelado

Thelvin Un GRAND merci.
Je pense avoir tout compris. Tes explications m'ont aidé à voir plus clair dans ce chapitre des flux entrée/sortie.

Je met cette discussion en "résolu".

Juste une dernière chose, pour la ligne de code

Code:

(FileSystem zipFS = FileSystems.newFileSystem(Paths.get("monFichier.zip"), null))

Moi je suis obligé de mettre le "null" sinon le code ne fonctionne pas et il y a une erreur. Mais c'est pas grave, Je vais faire avec.

Encore Merci!
17/08/2020, 21h00
thelvin

Effectivement, la possibilité de ne pas donner de deuxième paramètre, a été ajoutée avec Java 13, donc pas une version à longue vie. D'ailleurs avec ce Java 13, la ligne avec null ne compile plus, car le null devient ambigu la méthode ayant été surchargée.

Je viens de me rendre compte qu'en fait, avant Java 13, le deuxième paramètre accepte un ClassLoader et pas une Map. Le ClassLoader est celui dans lequel on va chercher des classes qui implémentent FileSystem des fois qu'il y en ait une qui sache gérer le fichier donné. Si on met null, c'est le ClassLoader par défaut qui est utilisé.

On peut utiliser un ClassLoader notamment pour charger un .jar externe, qui ne serait pas lié dès le départ au programme et qui serait plutôt choisi par l'utilisateur parce que quelqu'un d'autre le lui aurait donné, et qui contiendrait de nouvelles classes qui implémentent FileSystem en gérant d'autres fichiers. (Comme un .rar par exemple)
30/08/2020, 14h59
sekaijin
Bonjour de façon général un système de fichiers est un système informatique donnant accès à des contenus (File) organisés en général hiérarchiquement (Path).

Windows à son propre système de fichiers tout comme linux ou MacOS. Ces systèmes de fichiers gèrent des disques à partir de points de montage
les fameux C: D: etc de Windows. Linux lui mont un disque dans un PATH en général /mnt/mydisk

pour décrire un chemin dans système de fichiers on utilise un séparateur windows utilise \ linux / et les vieux macOS :

du point de vu du développeur les besoin sont :
définir le chemin à un fichier précis (calculer un chemin absolu à partir d'un autre chemin par exemple)
connaitre les droits de l'utilisateur sur ce chemin
connaitre la nature du chemin (un dossier ou un fichier ?)
Lister les objets présent dans un dossier (des PATH)
lire ou écrire dans un fichiers
créer ou supprimer des chemins

on retrouve cela dans tous les systèmes de fichiers. et finalement seuls les implémentations spécifiques à chaque OS diffèrent.
L'API java pour traiter ces besoins du développeur a évolué au fil du temps et aujourd'hui nous avons
FileSystems, FileSystem, Paths, Path, Files, DirectoryStream<Path>, InputStream, OutputStream etc.
le séparateur dans les PATH par défaut est "/" il fonction quelque soit l'implémentation.

une fois qu'on a cette API on s'aperçoit que lorsqu'on se connecte à un serveur FTP on a les même fonctionnalité.
Si on se connecte à un serveur WebDaV on a encore les même fonctionnalité.
et si on regarde comment est organisé le contenu d'un ZIP on a encore les même fonctionnalités.

enfin si on réfléchi à des truc comme virtualbox ou autre l'OS virtualisé écrit dans son propre système de fichiers qui sur la plateforme hôte est stocké dans un fichier. on appelle ça un système de fichier virtuel.

Cette idée a été généralisé pour accéder à de nombreux Système de fichier virtualisé.
https://commons.apache.org/proper/co...lesystems.html
Finalement la seule chose qui change c'est l'implémentation du système de fichier physique pour Windows, Linux, MacOS, Connecté pour FTP, SFTP, FTPS, WebDAV, CIFS,... et totalement virtuels pour tous les formats d'archive.

C'est cela qui a été généralisé dans JAVA
un exemple est https://github.com/robtimus/ftp-fs
Code:

1 2 3 FTPEnvironment env = new FTPEnvironment() .withCredentials(username, password); FileSystem fs = FileSystems.newFileSystem(URI.create("ftp://example.org"), env);
à partir de là fs se comporte comme un accès au disque local tout comme pour ton zip où tu manipule le contenu du ZIP comme si tu accédais au disque de ta machine.

A+JYT