C'est vraiment un truc très dommage et j'attends avec impatience que l'équipe WampServer corrige ce(s) bug(s) malheureux.
Bug 1 : Quand j'installe Wamp 1.6.6 en indiquant un répertoire d'install contenant espace et accent alors tout semble aller comme il faut sauf que les services ne démarrent pas. il n'y a pas de log non plus Exemple : si j'install wamp sous : "e:\appli\internet\wamp dév PHP" , alors les services ne marchent pas. J'ai désinstallé, puis réinstallé sous "e:\appli\internet\wamp" et la tout fonctionne comme il faut.
Bug 2 : Même problème avec les alias. Impossible de créer un alias vers un répertoire contenant espace et accent. Dans l'interface DOS, j'ai systématiquement un message "This directory doesn't exist." Alors que mon rép existe bien puisqu'un copier/coller dans la barre de navigation de Windows Explorer m'ouvre le répertoire en question. Si je trafique à la main le fichier httpd.conf pour ajouter mon alias vers ce rép avec accent ou espace, le serveur apache ne démarre pas.
Les espaces et accents sont légitimes dans les noms de rép, ils sont supportés depuis 11 ans sous Windows.
> aucune idée, mais ce serait probablement plus simple (sain) > de laisser tomber espaces et accents, enfin à mon avis ;-)
Un retour douloureux aux années 90. Cette solution n'est pas vraiment acceptable. La version précédente d'Apache (1.3.x) gérait sans problème les accents. Tous mes outils de dév pointent vers des répertoires de travail qui utilisent des accents.
Imagine si demain on te disait : "ha ben pour Apache 2 il faut bosser avec des répertoires sans utiliser la lettre a." Tu mors ton clavier.
2008, WampServer 2.0, et toujours ces mêmes problèmes lamentables !
J'ai utilisé EasyPHP durant longtemps et je viens sur Wamp car ce dernier n'est plus mis à jour. C'est avec affolement que je me rend compte que Wamp ne gère tout simplement aucun accent.
Si jamais vous installez Wamp dans un dossier dont le chemin possède le moindre accent alors le service Apache refusera de démarrer.
Et même pire que ça, vous ne pouvez tout simplement pas attribuer de DocumentRoot dont le chemin a un accent, ce qui dans mon métier est tout simplement impossible: j'ai plus de 100 dossiers correspondants à des dizaines de clients (et donc des sites) différents, tous écrits en Français forcément.
Aller, qui est le rigolo qui va venir me sortir "renommez tous vos dossiers, il ne faut jamais utiliser d'accents et de caractères spéciaux, blablabli blablabla" ? Qui va oser ?
Je connais mon métier quand même, je sais de quoi je parle, Windows le sais depuis Windows 3.x ! Aujourd'hui ABSOLUMENT TOUS les hébergements mutualisés, sans parler des dédiés bien évidement, et même n'importe quel hébergement de base, met à notre disposition des outils qui gèrent à 100% l'unicode, et ce depuis plus de 11 ans monsieur, oui monsieur depuis plus de 11 ans que nous savons, nous les êtres humains, savons écrire et gérer d'autres langues que l'anglais en informatique !
Et bien si cela vous surprend c'est que vous avez un sacré problème d'époque et d'information, si vous trouvez cela normal d'être restreint dans l'utilisation linguistique dans des systèmes tels que Apache c'est que vous êtes complètement hors compétition.
Nous ne sommes pas les seuls à nous plaindre d'une telle absurdité:
Personne ne pouvant modifier le DocumentRoot pour une cible contenant un accent: [forum.wampserver.com]
Incroyable, délirant, affolant, terrifiant même ! Wikipédia gère les accents dans l'url, comme 100% des sites Internet !
SAUF WAMP ! BIEN SÛR !
Bon, je vais cesser de perdre mon temps, si vous décidez de faire quelque chose pour arranger le problème qui empêche le fonctionnement pur et simple de Wamp alors je reviendrais peut-être vers vous.
Passez sous linux (comme les hébergeurs) et utilisez une solution LAMP. Les accents et espaces seront correctements reconnus.
Le problème vient de ce que windows utilise l'iso-8859-15 ou 1 que apache utilise l'utf-8 et que php utilise l'encodage qui lui a été spécifié (en général sous windows : iso-8859-15 ou 1)
Alors avant de critiquer et de dire que les problème de WAMP sont lamentables, cherchez par vous même les causes du problème.
Ici, ce n'est pas wamp qui est en cause, mais l'encodage utilisé dans windows, apache et php. Trouvez une solution pour tous les passer en iso-8859-1 ou 15 et vous pourrez enfin vous détendre et apprécier le faite que romain nous ai fournit un bel environnement de développement.
Bonne journée à vous.
P.S. : connaitre windows ne signifie pas connaitre l'informatique, et veillez à consommer moins de café, cela semble vous tendre un brin
Le problème c'est pas Wamp... ? vraiment ? hum... intéressant ce que vous dites...
Et bien bonne nouvelle: EasyPHP, petit logiciel développé par des étudiants est entièrement Unicodisé et fonctionne à merveille depuis plusieurs années, je le sais car je l'utilise depuis plus de 2 ans maintenant !
Et je bois autant de café qu'il me convient s'il vous plaît.
Je me permets de vous corriger, car l'horreur qui a emplis mon visage en voyant votre message me force à réagir: c'est plutôt vers l'Unicode UTF-8 qu'il faut pousser tout le monde, et non pas vers un format ISO ! Bon sang ! Dans quelques années toutes ces saloperies d'encodages ISO disparaîtront petit à petit, cette plaie de l'informatique qui fait que des problèmes de langue sont élément courant, cette plaie qui fait qu'un encodage ISO ne peut supporter tout au plus que 2 ou 3 langues à la fois, tout en prenant le plus d'espace de stockage !
Quand l'Unicode UTF-8, ce format révolutionnaire dont l'optimisation d'espace occupé est tout simplement le meilleur du monde (nombre de bit variable), et quand on sait que ce format unique, permet d'écrire dans toutes les langues du monde et d'utiliser tous les caractères spéciaux, tous les symboles correspondant à toutes les monnaies du monde, quand on sait qu'un tel format existe: ne pas l'utiliser c'est honteux !
Non je n'ai pas peur des mots monsieur, c'est littéralement honteux !
Bon, et pour finir notre soirée avec un peu moins caféine, je vous signale que j'ai trouvé remède au problème. Le fichier httpd.conf est par défaut encodé avec un encodage "Europe occidental", il suffit de changer l'encodage du document pour l'Unicode UTF-8 (attention: sans BOM sinon ça ne fonctionnera pas), des logiciels comme le Bloc-note ou Notepad++ ne permettent malheureusement pas d'enregistrer un document en Unicode UTF-8 standard (sans BOM), il vous faut un logiciel comme Dreamweaver, dans les propriétés du document choisir l'encodage Unicode (décocher la case BOM) et enregistrer.
Vous pourrez alors utiliser tous les accents que vous voulez, utiliser des noms de dossier chinois si ça vous chante vous n'aurez aucun problème.
Il faut faire de même avec les fichiers dans lesquels vous voulez utiliser des accents (extra/httpd-vhosts.conf par exemple)
Et voilà, c'est ce genre de petit détail qui fait beaucoup de différence pour 99% des personnes qui prendront la peine de tester votre logiciel. EasyPHP livre un fichier httpd.conf encodé en Unicode par défaut, ce qui évite beaucoup beaucoup de soucis.
Et bien vu que vous n'avez pas lu ou pas compris mon post, je me permet simplement de vous ignorer.
A jamais monsieur.
L'outrecuidance de vos propos n'ont eu de cesse de me choquer tant par la vergue que vous déployez à critiquer un outil gratuit mis à disposition, que par le ton hautain que vous employez.
@Robertino>Depuis l'installation de WampServer, as-tu modifié le fichier « httpd.conf » ou bien as-t-il été généré que par Wamp ?
Dans le premier cas, le responsable est ton éditeur de texte. Dans le second cas, le responsable est Wamp.
Donc, pour vérifier tout cela, il suffit de suivre la démarche suivante :
0 Avant chaque hypothèse, faire un nettoyage.
1 Sans accents 1.1 Installer WampServer 2 en lui fournissant un répertoire sans accent. 1.2 Tester.
2 L'éditeur de texte est responsable 2.1 Créer des répertoires contenant des lettres accentuées. 2.2 Modifier le fichier « httpd.conf » pour cibler le DocumentRoot dans un des répertoires créés ci-dessus. 2.3 Tester. 2.4 Quel est l'éditeur de texte utilisé ? 2.5 Recommencer les étapes 2.2 à 2.4 en changeant d'éditeur de texte ou sa configuration. 2.6 Quel est le meilleur choix ?
3 WampServer est responsable 3.1 Créer des répertoires contenant des lettres accentuées. 3.2 Installer WampServer 2 en lui fournissant un des répertoires créés ci-dessus en tant que racine. 3.3 Tester.
Oui, moi aussi je subis la douloureuse expérience de ces histoires d'encodage.
dans mon script j'ai : "include(..\commun\fonctions\mysqlfonc1.inc)" qui est traduit en "include(..\communonctions\mysqlfonc1.inc)"
si je mets include(..\commun\zonctions\mysqlfonc1.inc) ça passe !
Je n'avais pas touché au fichier httpd.conf. J'ai ensuite essayé de l'enregistrer dans phpedit en utf-8 avec ou sans BOM, mais cela ne change rien.
après, je ne sais pas si ça vient de wamp, windows ou de l'éditeur. Robertino n'a pas complètement tord de s'énerver, c'est quand même pénible de perdre du temps avec cela. Faudrait ce décider à passer tout en utf-8 et ne plus se prendre la tête avec ça.
Il faut aussi voir d'où viennent réellement les problèmes, afin que les bugs puissent être corrigé, par exemple en suivant la démarche que j'ai indiquée.
P.-S. : le contenu des fichiers PHP et leur encodage ne concerne nullement WampServer 2.
J'en ai appris un petit peu plus sur le sujet et ce terrible problème d'accent. J'ai aussi compris pourquoi il n'y avait absolument pas ce problème avec easyPHP mais qu'il était présent que sur WAMP et sur XAMPP (concurent de WAMP).
C'est tout bête: easyPHP 1.8 avait Apache 1.* alors que WAMP et XAMPP sont à jour et ont Apache 2.*
Sur le site d'Apache on peut lire, je cite: ---------------------------------- Support natif de l'Unicode sous Windows NT Apache 2.0 sur Windows NT utilise à présent l'utf-8 pour tous les noms de fichiers. Ces noms de fichiers sont directement traduits vers l'encodage Unicode du système de fichiers, ce qui permet le support multilangue pour toutes les installations sur la famille NT de Windows, y compris Windows 2000 et Windows XP.Ce support n'est pas fonctionnel pour Windows 95, 98 ni ME, qui utilisent les pages de code locales pour les accès au système de fichiers, comme auparavant. ---------------------------------- Source: "[httpd.apache.org]; [httpd.apache.org]
Seulement voilà, il n'y a pas que Apache dans WAMP, il y a aussi PHP, et quand on change l'encodage de l'un sans changer l'encodage de l'autre, alors ce qu'il arrive c'est que plus aucun caractère en dehors de ceux de la norme ASCII ne fonctionne.
Avant, quand Apache n'était pas Unicode alors il n'y avait pas de problème pour transmettre les accents etc. à PHP, lui même n'étant pas Unicode.
Désormais Apache transmet les chemins et noms de fichiers en Unicode à PHP, qui lui ne gère PAS l'Unicode.
PHP 6 qui sortira dans quelques mois, peut-être même un an, résoudra ce problème et sera ENFIN entièrement compatible Unicode.
Pour l'instant et après de très nombreuses recherches je pense pouvoir affirmer qu'il n'existe pas de solutions hormis celle de ne pas utiliser les accents dans vos chemins.
Une autre possibilité est de télécharger une version antérieure d'Apache (en dessous de la version 2.*), la 1.3 est disponible ici: "[www.wampserver.com]; [www.wampserver.com]
C'est donc une solution malgré tout.
Sinon, il existe en NTFS ce qui s'appelle des hard-link, c'est comme des raccourcis mais plus complexe, qui permettent de garder la hiérarchie derrière... Pour plus d'information: "[schinagl.priv.at]; [schinagl.priv.at] (anglais)
Personnellement j'ai opté pour la solution de ne pas utiliser d'accents en attendant PHP 6.
Ce n'est donc pas en rapport avec WAMP mais directement avec Apache et PHP, Apache ayant décidé d'évoluer trop vite sans prendre en compte le coté obsolète de PHP.
Dans un an ou deux en rira tous, d'ici là PHP 6 sera sorti et il comblera une lacune que tous autour de lui ont déjà comblé. C'est le dernier maillon faible de la chaîne:
- Apache depuis sa version 2 - MySQL depuis sa version 4.1 - et maintenant PHP depuis sa version 6
supportent tous l'Unicode. on peut dire qu'il était temps, quand l'unicode est supporté depuis 8 ans par Windows, et depuis plus de 10 ans par nombre d'autres logiciels.
Pour rappel l'Unicode est une norme universelle qui permet d'écrire dans plus de 650 langues différentes et d'utiliser plus d'un million de caractères en tous genres, notamment des opérateurs mathématiques et des symboles divers. Pour rappel BIS: l'Unicode UTF-8 étant multi-octets il n'utilise qu'un seul octet par caractère pour les caractères de la norme ASCII (c'est à dire ni plus, ni moins que si vous utilisiez l'encodage ASCII pour des caractères anglais uniquement), et peut utiliser jusqu'à 4 octets par caractère pour les langages beaucoup plus complexes comme le chinois, l'hébreu, le russe, etc. Unicode a été la première "norme" à rendre la cohabitation de toutes les langues du monde dans un seul encodage, qui de plus est le plus léger de tous de par son système multi-octets révolutionnaire.
L'Unicode c'est donc l'avenir, il est appelé à être utilisé par de plus en plus de logiciels, de sites, de systèmes, jusqu'à l'anéantissement total de toutes les autres normes d'encodage, notamment les ISO etc.
Rendez-vous dans 5 ans les gens, l'unicode sera le standard universelle pour l'encodage des caractères, plus aucun problème d'encodage, plus aucun problème d'accessibilité, des bases de données beaucoup plus légères grâce à l'espace beaucoup moindre pour les sites et forums internationales.
---- berlo a écrit: --------- Je n'avais pas touché au fichier httpd.conf. J'ai ensuite essayé de l'enregistrer dans phpedit en utf-8 avec ou sans BOM, mais cela ne change rien. --------------------------
mon astuce d'encoder httpd.conf en Unicode sans BOM fonctionne, seulement j'avais oublié de préciser que PHP, lui ne fonctionne toujours pas avec les accents.
C'est à dire qu'un dossier /développement/test.html
fonctionnera.
par contre /développement/test.php
ne fonctionnera pas car interprété par PHP, et comme PHP a toujours le problème d'accent ben ça bug, mais pas Apache.
Voilà, c'était juste pour dire que mon astuce n'était pas totalement idiote, c'est juste qu'elle fonctionne pour Apache mais pas PHP, donc tout fichier non interprété par PHP fonctionnera, et pas ceux interprétés par PHP.
Voilà, si je me suis mal exprimé me le signaler je suis toujours là.
Dernier point: la solution de télécharger Apache 1.3 permet de résoudre temporairement le problème, vous n'avez pas forcément un besoin absolue des nouveautés d'Apache 2 et cela vous permet de travailler avec PHP5 en local sans aucun problème d'accents.
Je vous recommande cette solution, tenez moi au courant