Bonjour,
Savez-vous pourquoi avec Apache 2
- Le é est encodé %c3%a9 au lieu de %e9
- Les urls avec un accents encodé %e9 renvoient la page 403 Forbidden
Je migre de easyPHP 1.8 à WampServer 2.0.
sûre il ne fallait pas utiliser les accents
Bonjour,
Savez-vous pourquoi avec Apache 2
- Le é est encodé %c3%a9 au lieu de %e9
- Les urls avec un accents encodé %e9 renvoient la page 403 Forbidden
Je migre de easyPHP 1.8 à WampServer 2.0.
sûre il ne fallait pas utiliser les accents
Il est où, ton accent ? Dans un nom de fichier ou en tant que paramètre ? Il est encodé où, quand et comment par Apache 2 ?
Du détail, du détail, du détail !!!
Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute
Les accents sont dans le nom des dossiers, exemple : http://127.0.0.1/test/Références/
l'uri http://127.0.0.1/test/R%E9f%E9rences/ me renvoie une erreur 403 Forbidden.
et les uri :
me renvoient les erreurs :
C'est une erreur de configuration Apache ou PHP je suppose...Warning: Unknown: failed to open stream: No such file or directory in Unknown on line 0
Fatal error: Unknown: Failed opening required 'C:/www/test/Références/index.php' (include_path='.;C:\php5\pear') in Unknown on line 0
En clair, il est écrit dans le fichier access.log :
127.0.0.1 - - [19/Jan/2008:19:13:49 +0100] "GET /test/R%E9f%E9rences/ HTTP/1.1" 403 304
127.0.0.1 - - [19/Jan/2008:19:19:42 +0100] "GET /test/R%C3%A9f%C3%A9rences/ HTTP/1.1" 200 294
127.0.0.1 - - [19/Jan/2008:19:19:44 +0100] "GET /test/R%C3%A9f%C3%A9rences/ HTTP/1.1" 200 294
127.0.0.1 - - [20/Jan/2008:02:33:38 +0100] "GET /test/%40rbo/ HTTP/1.1" 200 7313
Pour l'instant je cherche une solution dans les fichiers :
- httpd.conf
- php.ini
Pourquoi tu mets des accents dans tes noms de fichiers ou de répertoires ? Faut jamais faire ça, tu vois bien le pb !! Le plus simple c'est de les virer, ça t'évitera bon nombre de pb. C'est possible ou tu veux vraiment conserver tes accents ?
De toutes les erreurs, je pense que la première (Forbidden) est la plus significative : je pense que c'est la bonne URL mais qu'il y a un fichier .htaccess ou une conf dans un quoi qui bloque l'accès. Tu as regardé de ce côté ?
Du détail, du détail, du détail !!!
Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute
Je veux des accents dans mes dossiers... c'est tout.
J'ai commenter dans mon fichier .htaccess la ligne :
# options All -Indexes
Elle bloque la navigation dans les répertoires sans fichier index.php et j'ai le même résultat.
Y a quoi d'autre dans ton .htaccess lié à l'authentification ? Tu peux essayer en le supprimant ?
Du détail, du détail, du détail !!!
Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute
Il n'y a rien de bien intéressant dans mon fichier .htaccess, après tout cette erreur c'est sans doute liée à un module ou à la source même d'apache... j'ai fait une recherche sur le site httpd.apache.org et je n'ai rien trouvé de concluant.
Détails sur les requêtes.
Effectivement, je viens d'installer Wampserver 2.0a et j'ai reproduit le pb. Je vais étudier la question.
EDIT : résultat de certains tests
Je viens de tester avec IE et FF, entre EasyPHP et Wamp : dans les 2 cas (EasyPHP ou Wamp), un coup ça marche avec IE mais pas avec FF ou inversement O_o.
Il se trouve effectivement que le serveur Apache de Wamp attend de l'UTF-8 dans l'URL alors que celui d'EasyPHP attend de l'ISO-8859-1. En analysant les en-têtes HTTP envoyés par l'un et l'autre des navigateurs, IE code http://localhost/test/Références/ en UTF-8 (GET /test/R%C3%A9f%C3%A9rences/ HTTP/1.1) alors que FF code la même URL en ISO-8859-1 (GET /test/R%E9f%E9rences/ HTTP/1.1). Donc effectivement, ça foire dans les deux cas (EasyPHP et Wamp).
Soit dit en passant, je trouve étrange que l'Apache de Wamp attende de l'UTF-8 alors que la spec HTTP dit que c'est ISO-8859-1 l'encodage par défaut...
Après moultes recherches, je n'ai pas l'impression qu'on puisse demander à Apache de revenir à l'ancien système ISO-8859-1 sauf à recompiler Donc, pour ton pb, utilise des URL en UTF-8 et essaie de réenregistrer tes fichiers PHP en UTF-8 également. Je dirais que l'erreur PHP vient de là : tu reçois une chaîne de caractères en UTF-8 dans un script écrit en ISO-8859-1.
Du détail, du détail, du détail !!!
Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute
Elle super compliquée ta solution il doit y avoir une autre réponse. J'ai une question plus facile à résoudre en attendant :
Pourquoi mon php_error.log affiche quand je choisi la version
- PHP 5.0.3
[21-Jan-2008 19:58:01] PHP Warning: PHP Startup: Unable to load dynamic library 'C:/Program Files/wamp/bin/php/php5.2.5/ext/php_gd2.dll' - La procédure spécifiée est introuvable.
in Unknown on line 0- PHP 5.2.5
[21-Jan-2008 20:01:34] PHP Warning: PHP Startup: Unable to load dynamic library 'C:/Program Files/wamp/bin/php/php5.0.3/ext/php_mysql.dll' - La procédure spécifiée est introuvable.
in Unknown on line 0
Il y a comme un décalage... J'ai remarqué ca parce que je n'ai plus mysql et mysqli. A les programmeurs...
NB : Pour moi le percent-encoding ( %-enconding ) est ni de l'UTF8 ni de l'ISO. Voir les pages :
- http://www.faqs.org/rfcs/rfc1738.html
- http://www.faqs.org/rfcs/rfc2396.html
- Javascript : escape et encodeURI
- PHP : rawurlencode () et rawurlencode( utf8_encode ( ))
Tu as lu ça ? http://mysql.ifrance.com/printthread.php?t=168
Du détail, du détail, du détail !!!
Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute
Merci beaucoup !
J'ai 18 fichiers libmysql.dll en tout.
- 16 pour WampServer2 ( 1 pour chaque version PHP, Apache et mySQL... )
- 2 pour easyPHP 1.8 et 2.0B1
Le tout est de trouver les versions PHP, Apache et mySQL compatibles ou d'utiliser easyPHP... mais je pense pas que la solution soit là. Je vais quand même faire quelques testes.
Note : Toutes mes extensions lançaient cette erreur !
Sinon :
Comment tu déduis ça de tes références ? le %xx sert à indiquer un octet par son code hexa. Si tu mets %C3%A9, étrangement ça correspond à la séquence d'octet UTF-8 du caractère é, alors pourquoi ne pas dire que le %xx permet de représenter des caractères UTF-8 ?
Mais ça ne fait pas avancer le pb, je ne sais toujours pas vraiment comment résoudre ton pb : tu as essayé d'enregistrer une page en UTF-8 ? Je pense vraiment que c'est lié, alors soit tu arrives à faire comprendre à Apache que le charset par défaut est ISO-8859-1 (j'ai cru lire qq part que ça pouvait être lié au charset par défaut de l'OS ) et tu es sauvé, soit tu ne changes pas Apache et tu dois réenregistrer toutes tes pages en UTF-8.
Du détail, du détail, du détail !!!
Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute
Grâce à PSPad j'ai enregistré mon fichier test/Références/index.php en UTF-8, sans changement.
Quelques liens utiles :
- http://www.answers.com/ISO-8859-1
- http://www.answers.com/UTF8?cat=technology
- http://www.answers.com/topic/percent-encoding
- http://www.w3.org/International/O-HTTP-charset.en.php
- http://www.w3.org/International/O-charset#ensuring
- http://www.w3.org/International/O-charset-lang.html
- http://www.w3.org/International/arti...-iri/#iriworks
- http://www.w3.org/2003/06/mod_fileiri/ de 2003...
... j'abandonne "pour l'instant"... je supprime les accents des nom des fichiers et des dossiers.
Pour ceux qui tomberaient sur ce forum, voici quelques infos au sujet de l'encodage des URL.
Les RFC citées précédemment sont obsolètes. Aujourd'hui, c'est la 3986 qui s'applique (http://tools.ietf.org/html/rfc3986).
Donc la recommandation est d'utiliser l'UTF-8 pour écrire le chemin puis de convertir les caractères non ASCII en utilisant %?? où ?? est l'écriture hexadécimale de l'octet.
On trouve une excellente explication et des tests sur une page du W3C : http://www.w3.org/International/articles/idn-and-iri/
Les anciens navigateurs utilisaient le jeu de caractères de la page ou latin-1 (ISO-8859-1) et non UTF-8, ce qui rejettait bien des langues. Dans IE6, l'option "URL with UTF-8 encoding" est apparue. Dans IE7, cette option est activée par défaut. Les navigateurs Opera et Safari respectent aussi la RFC. Malheureusement Firefox en est apparement resté au niveau d'IE6 (du moins dans la configuration par défaut sous Windows).
Pour illustrer mon propos : avec le lien http://serveur.fr/différentes voici ce que différents navigateurs envoient au serveur (requête HTTP GET).
FF2 : http://serveur.fr/diff%E9rentes (config FF2.11 Windows par défaut)
IE6 : http://serveur.fr/diff\xe9rentes
IE7 : http://serveur.fr/diff%C3%A9rentes (Idem pour Safari et Opera)
NB: Quelque soit l'encodage :
[client]
L 'URI "http://serveur.fr/diff%E9rentes" est prise en charge ( vu dans la barre d'adresse ) avec easyPHP 1.8, ( Apache 1.3 ) sur windows... que ce soit :
- FF 2.0.0.11
- IE7
- Safari 3.0.4
[serveur]
Par contre, quelque soit la version d'Apache sur Wamp ce type d'adresse est refusé.
La question : Comment configurer Apache ?
Remarque:
- J'ai supprimé les accents de mon système de fichier. ( fait )
- Je migre en 130 000 lignes en UTF-8 ( C'était prévu )
- J'ai peur que mes requêtes html échouent ( à voir )
- J'ai quelques caractères accentués encodés un fois de trop selon les navigateurs ( contourné )
- Supprimer les accents des dossiers et fichiers
- Conserver vos fichiers en ANSI
NotePad++ permet de convertir vos fichiers.
Bonjour à tous, ceci est mon premier message sur ce forum. C'est un utilisateur d'un forum concurrent où j'avais posté exactement le même problème, auquel je ne trouve pas de solution.
Ma config : Apache2 sur serveur Win2K3 (eh oui ... ).
Je mets un fichier "identité.html" sur mon serveur. Via IE7, j'y accède sans aucun blème via :
http://monserveur/identité.html
Avec un accent dans la barre d'adresse, oui oui! ça tombe plutôt bien que IE7 propose cette option, parce que on a à peu près 8000 fichiers qui ont été importés dynamiquement, et le lien vers leur emplacement dans l'arborescence aussi .... et les scripts d'imports n'ont pas été customisés pour prendre en compte les accents.
Y'a un truc bien dans ma situation : les fichiers "à problèmes" (ceux avec accents) ne s'accèdent pas directement, mais via des URLs stockées dans une base de données. Il me "suffit" donc de formater mes URLs correctement.
Bref, jusqu'ici donc (et étant donné que je suis sur un Intranet et que seul IE7 est le browser officiel), tout fonctionne bien. Seul souci : les gros fichiers PDF (et il y en a beaucoup). IE7 "interprète" l'accent correctement (probablement en %c3%a9 mais en vérité je n'en sais rien) , commence le download puis "relaye" celui-ci à Adobe Reader, qui plante joyeusement car il ne trouve pas le fichier en question.
Je dois donc trouver un moyen d'encoder mes URLs, et c'est comme ça que je suis tombé sur cet os :
- Je tape http://monserveur/identité.html, ça roule
- Je tape http://monserveur/identit%E9.html - boum error 403
- Je tape http://monserveur/identit%c3%a9.html - ça roule
Vous me direz, j'ai qu'à encoder toutes mes URLs de la troisième manière mais j'ai un petit problème : certaines URLs ont été créées par d'autres scripts (php) qui utilisent la fonction rawurlencode(). Celle-ci encode d'office les "é" en %E9 , point à la ligne. Je n'ai pas trouvé comment encoder directement "correctement".
L'IDEAL était de trouver une manière de faire comprendre au serveur que %E9 = é, mais visiblement si je comprends les réponses ci-dessus, ce n'est possible que moyennant une recompil Apache...
Je poste ce message au cas où entretemps une solution existe de ce côté là, ou alors je me mettrai à la lourde tâche de convertir mes URLs mais sur ce point il me faudrait un petit coup de main pour l'encoding correct ...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager