Bonjour,

C'est sans doute un problème élémentaire, mais je suis bloqué depuis plusieurs jours et j'ai fait tellement d'essais que je suis un peu perdu.

J'ai des fichiers pdf qui comportent le caracère "&" dans leur nom. Mais celui-ci est retranscrit en "&" dans les fonctions php. Je n'arrive donc pas à accéder à ces fichiers.

Exemple :

<?php

$ancien = "&"."partieancien".".pdf";var_dump($ancien);
	//var_dump > &partieancien.pdf OK
	
$nouveau = "&"."partienouveau"."pdf";var_dump($nouveau);
	//var_dump > &partieancien.pdf OK
	
rename($ancien,$nouveau);
	//Warning: rename(&amp;partieancien.pdf,&amp;partienouveaupdf): Le fichier spécifié est introuvable
;
?>

Je précise que la page d'appel HTML de ces lignes php est déclarée en UTF-8.

Merci par avance pour votre aide.

Salutations.

Salut

Je suis très surpris que le système de fichiers accepte le & dans le nom au départ, je conseillerais fortement d'éviter l'utilisation de ce caractère qui peut induire des comportements inattendus suivant l'OS (comportements outre celui-ci).

Je ne serais d'ailleurs pas surpris que l'erreur survienne non pas parce qu'il n'arrive pas à renommer, mais parce qu'il n'arrive pas à trouver le fichier avant de le renommer, justement du fait de cette esperluette.

-
Edité par Ymox 2 mai 2024 à 8:44:00

Je voudrais apporter deux précisions par rapport au & vs & :

• ce n'est parce que var_dump montre un & que c'en est un : si la sortie est interprétée comme du HTML (Content-type: text/html), un "&" s'affichera & à moins d'ajouter un échappement (htmlspecialchars) - par contre le & seul pourrait "disparaître" parce que le navigateur cherche à interpréter une entité HTML qui n'existe pas/n'est pas valide ***
• PHP échappe les messages d'erreur si html_errors = on (ce qui est normalement le cas quand on utilise PHP dans un contexte web en opposition au CLI) d'où le & qui s'affiche & au niveau de ton message d'erreur

=> tu as bien un &, le & n'est que le résultat de l'échappement du message d'erreur par PHP avec html_errors = on

*** : ce n'est pas le cas ici mais je tenais tout de même à le rappeler à ceux qui liraient ce sujet

> Je précise que la page d'appel HTML de ces lignes php est déclarée en UTF-8.

Ca ne change rien, le & s'encode de la même façon dans tous les jeux de caractères qui étendent ASCII (ISO-8859-1, CP1252, UTF-8, etc)

-
Edité par julp 30 avril 2024 à 23:17:20

Bonjour,

Après moult essais, il s'avère que l'esperluette dans le nom de fichier n'est pas la cause du problème.

Tout "bêtement", la page html appelante n'était pas dans le même dossier que le module php : il fallait faire précéder le nom du fichier à traiter par celui du nom du dossier, et ceci bien que le module php et le fichier traité sont eux dans le même dossier.

Merci à ceux qui sont intervenus pour m'apporter leur aide.

Salutations.

Raison pour laquelle il vaut mieux prendre l'habitude de construire ses chemins (directement liés au système de fichiers) en se basant sur __DIR__ plutôt que de compter sur le répertoire courant.

Si le script contenant ce chemin est inclus depuis plusieurs points totalement différents de l'arborescence de l'application, celui employant __DIR__ désignera toujours la même chose alors qu'un relatif désignera 2 emplacements différents.

-
Edité par julp 3 mai 2024 à 17:16:23