Quelle est la différence entre ces deux écritures

Ma solution: $filename = basename($file);.
Solution alternative de CosmoKnacki: $filename = substr(strrchr("/$file", '/'), 1);.
Si c'est à cause de la note ou de l'attention qui suit dans la doc, pourquoi basename n'utilise pas l'algorithme de CosmoKnacki?

La différence est la lisibilité de la première et le caractère martien de la seconde. Que reprocherais-tu à basename ? (s'il me faut obtenir le nom du fichier ou de la dernière partie d'une arborescence, c'est lui que j'utilise)

Note aussi qu'un code doit non seulement faire ce qu'il a à faire (répondre à un objectif) mais doit tout autant être propre (clean code) et lisible. Un code illisible est un mauvais code qui ajoute une charge à son maintien dans le temps.

La doc dit de faire attention à setlocale(), c'est tout.

Il vaut mieux demander la raison à CosmoCnacki dans le fil d'origine.

Perso jamais eu de soucis avec basename(), malgré les caractères accentués, les espaces, et autres caractères bizarroïdes que j'utilise dans mes chemins et noms de fichiers.

La documentation dit également que le chemin peut contenir des anti-slashes sous Windows, basename en tient compte. En cherchant rapidement dans le code source, on voit même que la version Windows gère le ':' pour prendre en compte les chemins absolus avec la lettre de lecteur.

basename fonctionnera tout le temps, la solution alternative ne pourra gérer que des chemins de type Unix.

Merci à vous tous, je me sens rassuré.

Je n'ai pas trouvé le thread en question (en es-tu l'auteur?), mais je constate qu'avec un path sans nom de fichier (se terminant par un slash) basename renvoie le nom du dernier répertoire, plutôt qu'une chaîne vide, alors que mon code renvoie bien la chaîne vide.

Exemple: https://3v4l.org/rd5tf#v8.2.7

Citation:

---

Envoyé par CosmoKnacki

mais je constate qu'avec un path sans nom de fichier (se terminant par un slash) basename renvoie le nom du dernier répertoire, plutôt qu'une chaîne vide, alors que mon code renvoie bien la chaîne vide

---

En effet : en l'absence d'un nom de fichier, basename retourne le nom du dernier répertoire (html p.e. pour /var/www/html). Ensuite si on veut s'assurer qu'il s'agit d'un fichier, il existe bien d'autres façons de procéder, je pense au simple is_file par exemple.

J'ai retrouvé le thread d'août 2019 avec une équipe d'archéologues, et rien ne justifie d'utiliser un quelconque artifice dans le code en question (puisque celui-ci ne produit pas de chemins se terminant par un slash). Dans ce cas utiliser basename convient trés bien.

Code:

---

1 2 3 4 5 6 7 8 9 10

$directory = 'path/to/your/files/'; $extensions = ['txt', 'csv']; // ... $file_list = glob($directory . '*.{' . implode(',', $extensions) . '}', GLOB_BRACE);   foreach($file_list as $file) { // ... $filename = basename($file); // substr(strrchr("/$file", '/'), 1); // ... }

---

J'ai dû copier/coller ça sur un autre code où ça devait être pertinent (enfin j'éspère).

J'ai peut-être parlé un peu trop vite! Jusqu'à la version 8.0 de PHP (novembre 2020), basename débloque complètement avec certains caractères (dés qu'on sort de la plage ASCII). Donc pour les versions précédentes, mieux vaut le code martien. https://3v4l.org/DlOg4#v7.4.33

Il s'avère que le comportement de basename dépend des locales (allez savoir pourquoi), donc si la partie encodage de la locale du serveur n'est pas spécifiquement sur utf8, cette fonction ne marchera pas correctement avec les noms de fichier utilisant cet encodage.
Donc avant PHP8.0:

Code:

---

1 2 3

setlocale('LC_ALL', 'fr_FR.utf8'); echo basename('/path/to/âne'): // âne // avec un autre encodage on obtient "ne"

---

Citation:

---

En effet : en l'absence d'un nom de fichier, basename retourne le nom du dernier répertoire (html p.e. pour /var/www/html). Ensuite si on veut s'assurer qu'il s'agit d'un fichier, il existe bien d'autres façons de procéder, je pense au simple is_file par exemple.

---

Effectivement, mais même dans le nom de la fonction : basename pour "nom de base" , rien ne précise qu'il s'agit d'un fichier, et la doc parle bien de retourner la composante finale d'un chemin, elle ne parle pas d'un fichier ou dossier.

Comme quoi il faut lire la doc, car celle-ci précise que basename est sensible à la locale, ce que je ne savais pas et ne me serais pas venu à l'idée, avant d'être confronté au prob.