dams Fri Feb 16 08:50:41 2001 EDT
Modified files:
/phpdoc/fr/appendices migration4.xml
Log:
Corrected some typos.Removed illegal chars..
Index: phpdoc/fr/appendices/migration4.xml
diff -u phpdoc/fr/appendices/migration4.xml:1.2 phpdoc/fr/appendices/migration4.xml:1.3
--- phpdoc/fr/appendices/migration4.xml:1.2 Mon Feb 12 07:19:15 2001
+++ phpdoc/fr/appendices/migration4.xml Fri Feb 16 08:50:41 2001
@@ -1,289 +1,289 @@
<appendix id="migration4">
<title>Migration de PHP 3.0 à PHP 4.0</title>
<sect1 id="migration4.changes">
- <title>Ce qui a chang� en PHP 4.0</title>
+ <title>Ce qui a changé en PHP 4.0</title>
<para>
- PHP 4.0 et le moteur Zend ont significativement am�lior� les
- performances et les possibilit�s de PHP, tout en assurant une
- compatibilit� ascendante maximale. Le maximum de codes existants
- sous PHP 3.0 fonctionneront sous PHP 4.0. La migration de votre
- code de PHP 3.0 vers PHP 4.0 sera beaucoup plus facile que
- celle de PHP/FI 2.0 vers 3.0. Un grand nombre de scripts seront
- pr�ts sans modifications, mais il est bon que vous connaissiez
- les quelques diff�rences, et que vous testiez vos applications
- avant d'effecteur le changement de cadre de production. Les
- indications suivantes vous mettront sur la voie.
+ PHP 4.0 et le moteur Zend ont significativement amélioré les
+ performances et les possibilités de PHP, tout en assurant une
+ compatibilité ascendante maximale. Le maximum de codes existants
+ sous PHP 3.0 fonctionneront sous PHP 4.0. La migration de votre
+ code de PHP 3.0 vers PHP 4.0 sera beaucoup plus facile que
+ celle de PHP/FI 2.0 vers 3.0. Un grand nombre de scripts seront
+ prêts sans modifications, mais il est bon que vous connaissiez
+ les quelques différences, et que vous testiez vos applications
+ avant d'effecteur le changement de cadre de production. Les
+ indications suivantes vous mettront sur la voie.
</para>
</sect1>
<sect1 id="migration4.parser">
<title>Comportement de l'analyseur</title>
<para>
- L'analyse et l'�xecution sont d�sormais deux �tapes compl�tement
- dissoci�es, et l'�x�cution intervient lorsque le code, ainsi que
- tous ses inclusions et pr�-requis, ont �t�
- compl�tement analys� et valid�.
- </para>
- <para>
- Une des nouvelles conditions introduites est que les fichiers
- inclus et requis (<function>include</function> et
- <function>require</function>) doivent �tre syntaxiquement
- complets. Vous ne pouvez plus r�partir diff�rents cas de votre
- code dans plusieurs fichiers. Vous ne pouvez plus commner une
- boucle <literal>for</literal> ou <literal>while</literal>,
- une condition <literal>if</literal> ou un cas <literal>switch</literal>
- dans un fichier, et finir la boucle ou placer les cas
- <literal>else</literal>, <literal>endif</literal>,
- <literal>case</literal> ou <literal>break</literal>
- dans un autre fichier.
- </para>
- <para>
- Il est toujours valable d'inclure du code suppl�mentaire depuis
- une boucle ou dans une conditions, mais les accolades de
- bloc <literal>{...}</literal>, et les �l�ments de la boucle
- doivent �tre dans le m�me fichier ou cha�ne �valu�e avec
- <function>eval</function>.
- </para>
- <para>
- Cela ne devrait pas perturber trop de monde, car �taler son
- code de cette fa�on est plut�t un style � �viter.
- </para>
- <para>
- Une autre nouveaut� est qu'il est plus possible de faire
- retourner une valeur avec un fichier requis
(<function>require</function>)
- (mais c'est plut�t rare en PHP 3.0). Retourner une valeur
- avec un fichier inclus (<function>require</function>) est toujours
- possible.
+ L'analyse et l'éxecution sont désormais deux étapes
+complétement
+ dissociées, et l'éxécution intervient lorsque le code,
+ainsi que
+ tous ses inclusions et pré-requis, ont été
+ complétement analysés et validés.
+ </para>
+ <para>
+ Une des nouvelles conditions introduites est que les fichiers
+ inclus et requis (<function>include</function> et
+ <function>require</function>) doivent être syntaxiquement
+ complets. Vous ne pouvez plus répartir différents cas de votre
+ code dans plusieurs fichiers. Vous ne pouvez plus commner une
+ boucle <literal>for</literal> ou <literal>while</literal>,
+ une condition <literal>if</literal> ou un cas <literal>switch</literal>
+ dans un fichier, et finir la boucle ou placer les cas
+ <literal>else</literal>, <literal>endif</literal>,
+ <literal>case</literal> ou <literal>break</literal>
+ dans un autre fichier.
+ </para>
+ <para>
+ Il est toujours valable d'inclure du code supplémentaire depuis
+ une boucle ou dans une conditions, mais les accolades de
+ bloc <literal>{...}</literal>, et les éléments de la boucle
+ doivent être dans le même fichier ou chaîne
+évaluée avec
+ <function>eval</function>.
+ </para>
+ <para>
+ Cela ne devrait pas perturber trop de monde, car étaler son
+ code de cette façon est plutôt un style à éviter.
+ </para>
+ <para>
+ Une autre nouveauté est qu'il est plus possible de faire
+ retourner une valeur avec un fichier requis (<function>require</function>)
+ (mais c'est plutôt rare en PHP 3.0). Retourner une valeur
+ avec un fichier inclus (<function>inclus</function>) est toujours
+ possible.
</para>
</sect1>
<sect1 id="migration4.errors">
<title>Rapport d'erreur</title>
<sect2 id="migration4.error_reporting">
- <title>Changement de configuration</title>
- <para>
- Avec PHP 3.0, le niveau de rapport d'erreur �tait obtenu en
- ajoutant les constantes num�riques de chaque niveau de
- rapport. G�n�ralement, on utilisait 15 pour afficher toutes
- les erreurs, et 7 pour afficher toutes les erreurs hormis
- les alertes simples.
- </para>
- <para>
- PHP 4.0 dispose d'un nombre significativement plus grand de niveaux
- de rapport d'erreur, et l'analyseur comprend d�sormais les
- constantes, lors des modifications.
- </para>
- <para>
- Le niveau de rapport d'erreur doit d�sormais �tre explicitement
- configur� en supprimant les niveaux dont vous ne voulez pas
- du niveau maximal, gr�ce � la fonction de OU exclusif. Ca a
- l'air compliqu�? Supposons que vous souhaitiez afficher toutes les
- erreurs, hormis les alertes de style, qui sont rep�r�es par
- la constante : E_NOTICE. Il suffit d'ajouter la valeur
- suivante dans le fichier <filename>php.ini</filename>:
- <literal>error_reporting = E_ALL & ~ ( E_NOTICE )</literal>.
- Si vous voulez supprimer en plus les alertes, vous pouvez
- ajouter la constante appropri�e, en la combinant avec l'op�rateur
- OU logique '|':
- <literal>error_reporting= E_ALL & ~ ( E_NOTICE | E_WARNING )</literal>.
- </para>
- <warning>
- <para>
- L'utilisation des vieilles valeurs de 7 et 15 est une tr�s
- mauvaise id�e, car elles ne prennent pas en compte les
- nouvelles classes d'erreurs, y compris certaines erreurs
- d'analyse. Cela peut conduire � de tr�s �tranges r�sultats,
- o� le script n'affiche plus rien, malgr� une erreur d'analyse.
- </para>
- <para>
- Cela a conduit � un grand nombre de rapport d'erreur dans
- le pass�, alors que les programmeurs n'�taient tout simplement
- pas capable de rep�rer l'accolade manquante, car l'analyseur
- avait la consigne de cacher ces erreurs.
- </para>
- <para>
- V�rifier votre niveau d'erreur doit �tre le premier reflexe
- lorsque vos scripts meurent silencieusement. Le moteur
- Zend est consid�r� actuellement comme suffisament mature pour
- ne plus causer ce genre de probl�me aujourd'hui.
- </para>
- </warning>
+ <title>Changement de configuration</title>
+ <para>
+ Avec PHP 3.0, le niveau de rapport d'erreur était obtenu en
+ ajoutant les constantes numériques de chaque niveau de
+ rapport. Généralement, on utilisait 15 pour afficher toutes
+ les erreurs, et 7 pour afficher toutes les erreurs hormis
+ les alertes simples.
+ </para>
+ <para>
+ PHP 4.0 dispose d'un nombre significativement plus grand de niveaux
+ de rapport d'erreur, et l'analyseur comprend désormais les
+ constantes, lors des modifications.
+ </para>
+ <para>
+ Le niveau de rapport d'erreur doit désormais être explicitement
+ configuré en supprimant les niveaux dont vous ne voulez pas
+ du niveau maximal, grâce à la fonction de OU exclusif. Ca a
+ l'air compliqué? Supposons que vous souhaitiez afficher toutes les
+ erreurs, hormis les alertes de style, qui sont repérées par
+ la constante : E_NOTICE. Il suffit d'ajouter la valeur
+ suivante dans le fichier <filename>php.ini</filename>:
+ <literal>error_reporting = E_ALL & ~ ( E_NOTICE )</literal>.
+ Si vous voulez supprimer en plus les alertes, vous pouvez
+ ajouter la constante appropriée, en la combinant avec l'opérateur
+ OU logique '|':
+ <literal>error_reporting= E_ALL & ~ ( E_NOTICE | E_WARNING )</literal>.
+ </para>
+ <warning>
+ <para>
+ L'utilisation des vieilles valeurs de 7 et 15 est une très
+ mauvaise idée, car elles ne prennent pas en compte les
+ nouvelles classes d'erreurs, y compris certaines erreurs
+ d'analyse. Cela peut conduire à de très étranges
+résultats,
+ où le script n'affiche plus rien, malgré une erreur
+d'analyse.
+ </para>
+ <para>
+ Cela a conduit à un grand nombre de rapport d'erreur dans
+ le passé, alors que les programmeurs n'étaient tout
+simplement
+ pas capable de repérer l'accolade manquante, car l'analyseur
+ avait la consigne de cacher ces erreurs.
+ </para>
+ <para>
+ Vérifier votre niveau d'erreur doit être le premier
+reflexe
+ lorsque vos scripts meurent silencieusement. Le moteur
+ Zend est considéré actuellement comme suffisament mature
+pour
+ ne plus causer ce genre de problème aujourd'hui.
+ </para>
+ </warning>
</sect2>
<sect2 id="migration4.messages">
- <title>Nouveaux messages d'erreurs</title>
- <para>
- Un grand nombre de scripts PHP PHP 3.0 utilisent des structures qui
- doivent �tre consid�r�es comme un tr�s mauvais style, m�me s'il
- effectue bien la t�che qui lui est affect�e, car ils ne sont pas
- robustes. PHP 4.0 affichera de nombreux messages d'erreurs dans
- des situations o� PHP 3.0 restera coi.
- La solution de facilit� consiste � supprimer les messages de
- niveau E_NOTICE, mais c'est une meilleure id�e de corriger le
- code � la place.
- </para>
- <para>
- Le cas le plus courant qui g�n�rera des messages d'alertes
- est l'utilisation de constantes sans guillemets comme
- index de tableaux. PHP 3.0, comme PHP 4.0, finiront par les
- interpr�ter literalement comme des cha�nes, si aucune constante
- n'est d�finie � la place. Mais si jamais une telle constante
- est d�finie dans une autre partie du code, cela risque de
- produire des r�sultats �tonnants. Cela peut devenir un trou
- de s�curit� si un pirate arrive � red�finir les constantes
- de telle mani�re que le script lui donne acc�s � un niveau
- de droits sup�rieur. PHP 4.0 vous signalera tout oubli de
- guillemets comme par exemple dans :
- <literal>$HTTP_SERVER_VARS[REQUEST_METHOD]</literal>. Modifier
- ce code e, <literal>$HTTP_SERVER_VARS['REQUEST_METHOD']</literal>
- rendra l'analyseur heureux, et am�liorera grandement votre
- style et la s�curit� du code.
- </para>
- <para>
- PHP 4.0 vous signalera les variables ou les
- �l�ments de tableaux non initialis�s.
- </para>
+ <title>Nouveaux messages d'erreurs</title>
+ <para>
+ Un grand nombre de scripts PHP PHP 3.0 utilisent des structures qui
+ doivent être considérées comme un très mauvais
+style, même s'il
+ effectue bien la tâche qui lui est affectée, car ils ne sont
+pas
+ robustes. PHP 4.0 affichera de nombreux messages d'erreurs dans
+ des situations où PHP 3.0 restera coi.
+ La solution de facilité consiste à supprimer les messages de
+ niveau E_NOTICE, mais c'est une meilleure idée de corriger le
+ code à la place.
+ </para>
+ <para>
+ Le cas le plus courant qui générera des messages d'alertes
+ est l'utilisation de constantes sans guillemets comme
+ index de tableaux. PHP 3.0, comme PHP 4.0, finiront par les
+ interpréter literalement comme des chaînes, si aucune constante
+ n'est définie à la place. Mais si jamais une telle constante
+ est définie dans une autre partie du code, cela risque de
+ produire des résultats étonnants. Cela peut devenir un trou
+ de sécurité si un pirate arrive à redéfinir les
+constantes
+ de telle manière que le script lui donne accès à un
+niveau
+ de droits supérieur. PHP 4.0 vous signalera tout oubli de
+ guillemets comme par exemple dans :
+ <literal>$HTTP_SERVER_VARS[REQUEST_METHOD]</literal>. Modifier
+ ce code en <literal>$HTTP_SERVER_VARS['REQUEST_METHOD']</literal>
+ rendra l'analyseur heureux, et améliorera grandement votre
+ style et la sécurité du code.
+ </para>
+ <para>
+ PHP 4.0 vous signalera les variables ou les
+ éléments de tableaux non initialisés.
+ </para>
</sect2>
</sect1>
<sect1 id="migration4.initializers">
<title>Initialiseur</title>
<para>
- Les variables statiques et les membres de classes n'acceptent
- plus que des initialiseurs scalaires, tandis que PHP 3.0 acceptait
- aussi les expressions. Cela est d�, encore une fois, � la
- s�paration de l'analyse et de l'ex�cution : aucun code
- ne peut �tre ex�cut� tant que l'analye n'est pas termin�e.
+ Les variables statiques et les membres de classes n'acceptent
+ plus que des initialiseurs scalaires, tandis que PHP 3.0 acceptait
+ aussi les expressions. Cela est dû, encore une fois, à la
+ séparation de l'analyse et de l'exécution : aucun code
+ ne peut être exécuté tant que l'analye n'est pas
+terminée.
</para>
<para>
- Pour les classes, il vaut mieux initialiser les membres dans
- le constructeur. Pour les variables static, une valeur fixe
- et simple est la seule chose qui viennent � l'esprit.
+ Pour les classes, il vaut mieux initialiser les membres dans
+ le constructeur. Pour les variables static, une valeur fixe
+ et simple est la seule chose qui viennent à l'esprit.
</para>
</sect1>
<sect1 id="migration4.empty">
<title><literal>empty("0")</literal></title>
<para>
- L'�volution la plus pol�mique est celle de <function>empty</function>.
- Une cha�ne contenant seulement le caract�re
- <literal>'0'</literal> (z�ro) est maintenant consid�r�e comme
- vide, alors qu'elle ne l'�tait pas en PHP 3.0.
+ L'évolution la plus polémique est celle de
+<function>empty</function>.
+ Une chaîne contenant seulement le caractère
+ <literal>'0'</literal> (zéro) est maintenant considérée
+comme
+ vide, alors qu'elle ne l'était pas en PHP 3.0.
</para>
<para>
- Ce nouveau comportement prend tout son send dans les applications
- web, puisque tous les r�sultats de champs de type input est une
- cha�ne, m�me si un nombre est demand�, et gr�ce aux capacit�s
- de conversion automatique de PHP. D'un autre cot�, cela peut
- casser votre code d'une mani�re tr�s subtile, menant droit au
- comportement erratique, difficilement rep�rable si vous ne
+ Ce nouveau comportement prend tout son sens dans les applications
+ web, puisque tous les résultats de champs de type input sont de type
+ une chaîne, même si un nombre est demandé, et ce,
+grâce aux capacités
+ de conversion automatique de PHP. D'un autre coté, cela peut
+ casser votre code d'une manière très subtile, menant droit au
+ comportement erratique, difficilement repérable si vous ne
savez pas ce qui vous attend.
- </para>
- </sect1>
- <sect1 id="migration4.missing">
- <title>Fonctions manquantes</title>
- <para>
- Bien que PHP 4.0 dispose de nombreuses nouvelles fonctionnalit�s
- fonctions et extensions, vous vous rencontrer des fonctions PHP
- 3.0 qui manquent. Un petit nombre de fonctions de base n'ont pu
- �tre port�es en PHP 4.0, maintenant que l'analyse et l'�x�cution
- ont �t� s�par�es. D'autres fonctions, et m�mes des extensions
- enti�res sont maintenant obsol�tes, remplac�es par de nouvelles
- fonctions plus puissantes ou plus efficaces. Certaines fonctions
- n'ont tout simplement pas �t� port�es pour le moment ou pour
- des raisons de licences.
- </para>
- <sect2 id="migration4.impossible">
- <title>Fonctions manquantes pour des raisons de structure</title>
- <para>
- Comme PHP 4.0 s�pare l'analyse et l'�x�cution, il n'est plus
- possible de modifier le comportement de l'analyseur (int�gr�
- dans le moteur Zend) durant l'�x�cution, puisque toute
- l'analyse a eu lieu, et est termin�e. La fonction
- <function>short_tags</function> a cess� d'�xister. Vous pouvez
- toujours modifier le comportement de l'analyseur avec
- le fichier <filename>php.ini</filename>.
- </para>
- <para>
- Une autre fonctionnalit� qui a disparu est le d�buggeur
- de PHP 3.0, comme d�crit dans un autre appendice. Un nouveau
- d�buggeur est promis par Zend, mais il n'a pas encore montr�
- le bout de son nez.
- </para>
+ </para>
+ </sect1>
+ <sect1 id="migration4.missing">
+ <title>Fonctions manquantes</title>
+ <para>
+ Bien que PHP 4.0 dispose de nombreuses nouvelles fonctionnalités
+ fonctions et extensions, vous vous rencontrer des fonctions PHP
+ 3.0 qui manquent. Un petit nombre de fonctions de base n'ont pu
+ être portées en PHP 4.0, maintenant que l'analyse et
+l'éxécution
+ ont été séparées. D'autres fonctions, et
+mêmes des extensions
+ entières sont maintenant obsolètes, remplacées par de
+nouvelles
+ fonctions plus puissantes ou plus efficaces. Certaines fonctions
+ n'ont tout simplement pas été portées pour le moment ou
+pour
+ des raisons de licences.
+ </para>
+ <sect2 id="migration4.impossible">
+ <title>Fonctions manquantes pour des raisons de structure</title>
+ <para>
+ Comme PHP 4.0 sépare l'analyse et l'éxécution, il n'est
+plus
+ possible de modifier le comportement de l'analyseur (intégré
+ dans le moteur Zend) durant l'éxécution, puisque toute
+ l'analyse a eu lieu, et est terminée. La fonction
+ <function>short_tags</function> a cessé d'éxister. Vous pouvez
+ toujours modifier le comportement de l'analyseur avec
+ le fichier <filename>php.ini</filename>.
+ </para>
+ <para>
+ Une autre fonctionnalité qui a disparu est le débuggeur
+ de PHP 3.0, comme décrit dans un autre appendice. Un nouveau
+ débuggeur est promis par Zend, mais il n'a pas encore montré
+ le bout de son nez.
+ </para>
</sect2>
<sect2 id="migration4.deprecated">
- <title>Fonctions et extensions obsol�tes</title>
- <para>
- Les extensions Adabas et Solid n'existent plus. Elle sont int�gr�es
- dans les fonctions ODBC Unifi�.
- </para>
+ <title>Fonctions et extensions obsolètes</title>
+ <para>
+ Les extensions Adabas et Solid n'existent plus. Elle sont
+intégrées
+ dans les fonctions ODBC Unifié.
+ </para>
</sect2>
<sect2 id="migration4.unset">
- <title>Nouveau statut pour <function>unset</function></title>
- <para>
- <function>unset</function>, bient que toujours disponible, a �t�
- impl�ment� l�g�rement diff�remment en PHP 4.0, et elle n'est
- plus vraiment une 'fonction'.
- </para>
- <para>
- Cela n'a pas de cons�quence directe sur le comportement de
- <function>unset</function>, mais utiliser cette fonction
- pour faire un test avec <function>function_exists</function>
- retournera <literal>FALSE</literal> comme il se doit avec
- les fonction bas niveau comme <function>echo</function>.
- </para>
- <para>
- Une autre application pratique disparue est qu'il n'est plus possible
- d'appeler <function>unset</function> indirectement, c'est � dire que
- <literal>$func="unset"; $func($somevar)</literal> ne fonctionne plus.
- </para>
+ <title>Nouveau statut pour <function>unset</function></title>
+ <para>
+ <function>unset</function>, bient que toujours disponible, a
+été
+ implémenté légèrement différemment en
+PHP 4.0, et elle n'est
+ plus vraiment une 'fonction'.
+ </para>
+ <para>
+ Cela n'a pas de conséquence directe sur le comportement de
+ <function>unset</function>, mais utiliser cette fonction
+ pour faire un test avec <function>function_exists</function>
+ retournera <literal>FALSE</literal> comme il se doit avec
+ les fonction bas niveau comme <function>echo</function>.
+ </para>
+ <para>
+ Une autre application pratique disparue est qu'il n'est plus possible
+ d'appeler <function>unset</function> indirectement, c'est à dire que
+ <literal>$func="unset"; $func($somevar)</literal> ne fonctionne plus.
+ </para>
</sect2>
</sect1>
<sect1 id="migration4.extension">
<title>Extensions PHP 3.0</title>
<para>
- Les extensions �crites pour PHP 3.0 ne fonctionnent plus avec PHP 4.0,
- ni les ex�cutables, ni les codes sources. Il n'est pas difficile de
- porter les extensions de PHP 3.0 � 4.0 si vous avez acc�s aux
- sources originales. Une description d�taill�e du processus
- de portage ne fait pas partie de cet appendice (pour le moment).
+ Les extensions écrites pour PHP 3.0 ne fonctionnent plus avec PHP 4.0,
+ ni les exécutables, ni les codes sources. Il n'est pas difficile de
+ porter les extensions de PHP 3.0 à 4.0 si vous avez accès aux
+ sources originales. Une description détaillée du processus
+ de portage ne fait pas partie de cet appendice (pour le moment).
</para>
</sect1>
<sect1 id="migration4.substitution">
- <title>Substitution de variables dans les cha�nes</title>
+ <title>Substitution de variables dans les chaînes</title>
<para>
- PHP 4.0 dispose d'un nouveau m�canisme de substitution des
- variables dans les cha�nes. Vous pouvez d�sormais acc�der aux
- membres d'objets et aux tableaux multidimensionnels dans une
- cha�ne.
+ PHP 4.0 dispose d'un nouveau mécanisme de substitution des
+ variables dans les chaînes. Vous pouvez désormais
+accéder aux
+ membres d'objets et aux tableaux multidimensionnels dans une
+ chaîne.
</para>
<para>
- Pour cela, il suffit de placer la variables entre accolades, le signe
- $ suivant imm�diatement la premi�re accolade :
- <literal>{$variable['a']}</literal>
+ Pour cela, il suffit de placer la variables entre accolades, le signe
+ $ suivant immédiatement la première accolade :
+ <literal>{$variable['a']}</literal>
</para>
<para>
- Pour utiliser la valeur d'un membre d'objet dans une cha�ne,
- il suffit d'�crire : <literal>"text {$obj->member} text"</literal>;
- alors qu'en PHP 3.0, il fallait faire comme ceci :
- <literal>"texte".$objet->membre." texte"</literal>.
+ Pour utiliser la valeur d'un membre d'objet dans une chaîne,
+ il suffit d'écrire : <literal>"text {$obj->member} text"</literal>;
+ alors qu'en PHP 3.0, il fallait faire comme ceci :
+ <literal>"texte".$objet->membre." texte"</literal>.
</para>
<para>
- Cette technique rend le code beaucoup plus lisible, mais risque de
- poser des probl�mes dans certains scripts PHP 3.0. Vous pouvez
- facilement traquer ce probl�me en recherche les s�quences
- <literal>{$</literal> dans votre code, et en les remplacant par
- <literal>\{$</literal> avec votre outil de remplacement habituel.
+ Cette technique rend le code beaucoup plus lisible, mais risque de
+ poser des problèmes dans certains scripts PHP 3.0. Vous pouvez
+ facilement traquer ce problème en recherche les séquences
+ <literal>{$</literal> dans votre code, et en les remplacant par
+ <literal>\{$</literal> avec votre outil de remplacement habituel.
</para>
</sect1>
<sect1 id="migration4.cookies">
<title>Cookies</title>
<para>
- PHP 3.0 avait la mauvaise habitude d'envoyer les cookies dans l'ordre
- inverse de celui du code (l'orde des appels �
- <function>setcookie</function>). PHP 4.0 r�tablit l'ordre naturel
- en les envoyant dans le m�me ordre que vous m�mes.
+ PHP 3.0 avait la mauvaise habitude d'envoyer les cookies dans l'ordre
+ inverse de celui du code (l'orde des appels à
+ <function>setcookie</function>). PHP 4.0 rétablit l'ordre naturel
+ en les envoyant dans le même ordre que vous mêmes.
</para>
<para>
- Cela peut aussi prendre � contre-pied certains programmes, mais
- ce comportement �tait tellement �trange qu'il m�ritait un tel
- traitement un jour ou l'autre, pour �viter d'autres
- probl�mes ult�rieurs.
+ Cela peut aussi prendre à contre-pied certains programmes, mais
+ ce comportement était tellement étrange qu'il méritait
+un tel
+ traitement un jour ou l'autre, pour éviter d'autres
+ problèmes ultérieurs.
</para>
</sect1>
</appendix>
