Evolution future de la sélection+modification d'une chaîne de caractères.

[Jean Francois Ortolo]

Bonjour

Voici le problème :

Actuellement, pour toutes les versions récentes de php ( à part
peut-être les verions bêta de php 6, je ne sais pas ), il est possible
d'accéder à une sous-chaîne d'une chaîne de caractère, avec les
opérateurs : [] et {}.

Par exemple, voyons le code :

$str = "ABCDEFGHIJKLMNOPQ";

echo $str[0] . "\n"; // donne A

echo $str[10] . "\n"; // Donne K


Mais.. Cette fonctionnalité de l'opérateur [] ( et éventuellement de
l'opérateur {} ) sur les chaînes de caractères, va-t-elle perdurer sur
toutes les versions futures, de php ?

Je suppose, qu'il y a pas mal de scripts php dans le Monde, qui
nécessite cet opérateur [] ?


Ma deuxième question, c'est pour parer à une éventuelle disparition
de cette fonctionnalité :

Il suffirait de copier la chaîne de caractère, sur une array, en
prenant comme séparateur de preg_split(), la chaîne vide.

Voici le code :

$str = "ABCDEFGHIJKLMNOPQ";

$array_str = array();

$array_str = preg_split("//", $str);

ou bien :

$array_str = preg_split("/[]/", $str);


Celà fonctionnerait-il ?

Si oui, il suffirait de sélectionner l'array $array_str , au lieu de
la chaîne $str :

echo $str[10] . "\n"; // Ne marche plus...

echo $array_str[10] . "\n"; // Donne K, comme avant.


Cette utilisation de preg_split() avec un séparateur vide,
fonctionne-t-elle ?

Merci beaucoup de vos réponses à mes deux questions.

Bien amicalement.

Jean François Ortolo

[Clément]

Bonjour,

> Je suppose, qu'il y a pas mal de scripts php dans le Monde, qui
> nécessite cet opérateur [] ?

Oui, et je ne pense pas que les futurs versions de php changent le
comportement d'une string (qui est toujours un tableau de char)

Mais bon, avec l'arrivée (enfin) d'utf-8 dans PHP, ça pourrait bouger un
peu.

Quoi qu'il en soit, quand on fait un projet, on le fait souvent pour une
plate-forme donnée. On ne met pas à jour le moteur juste pour faire bien.

> Ma deuxième question, c'est pour parer à une éventuelle disparition de
> cette fonctionnalité :

> Celà fonctionnerait-il ?

La 1ère fonctionne mais donnera un espace pour $array_str[0]

Sinon PHP a une fonction pour ça directement (autant ne pas utiliser les
regex) :

http://www.php.net/manual/fr/function.str-split.php

Enfin, si vous voulez voir la différence de résultat, j'ai mis en place
un test sur codepad.org :

http://codepad.org/jejANTSP

> Si oui, il suffirait de sélectionner l'array $array_str , au lieu de la
> chaîne $str :
>
> echo $str[10] . "\n"; // Ne marche plus...
>
> echo $array_str[10] . "\n"; // Donne K, comme avant.
>
>
> Cette utilisation de preg_split() avec un séparateur vide,
> fonctionne-t-elle ?

Donc, oui ça fonctionne mais il est préférable d'utiliser str_split dans
ce cas.

Cordialement,

Clément.

[Jean Francois Ortolo]

Le 05/05/2012 15:37, Clément a écrit :
> Bonjour,

>
>>
>> Cette utilisation de preg_split() avec un séparateur vide,
>> fonctionne-t-elle ?
>
>
> Donc, oui ça fonctionne mais il est préférable d'utiliser str_split dans
> ce cas.
>
> Cordialement,
>
> Clément.
>

Bonjour Monsieur

Super génial !

Exactement ce qu'il me fallait. ;)

Et... La fonction str_split() , ne risque pas de disparaître avec les
versions ultérieures de php ?

Merci beaucoup de votre réponse.

[Clément]

Le 05/05/2012 16:02, Jean Francois Ortolo a écrit :
> Bonjour Monsieur
>
> Super génial !
>
> Exactement ce qu'il me fallait. ;)
>
> Et... La fonction str_split() , ne risque pas de disparaître avec les
> versions ultérieures de php ?
>
> Merci beaucoup de votre réponse.
>
> Bien amicalement.
>
> Jean François Ortolo
>
>
>

Comme je l'ai dit, il ne faut pas trop réfléchir aux versions réellement
supérieures. Une application est crée pour une plate-forme. Pas pour
celles à venir. D'ailleurs, on n'est pas devin, impossible d'être sûrs à
100% que telles ou telles fonctionnalités ne sera pas DEPRECATED, ne
sera pas modifiées ou que le retour d'une fonction ne sera pas
légèrement modifié.

Bref, ce n'est pas le plus important.

Sinon, je sors ma boule de cristal et je vois dans la doc (lien donné
précédemment) que str_split a été lancée avec PHP5, je ne vois pas
pourquoi il la retirerai.

Cordialement,

Clément

[Jean Francois Ortolo]

Le 05/05/2012 16:14, Clément a écrit :
>
> Comme je l'ai dit, il ne faut pas trop réfléchir aux versions réellement
> supérieures. Une application est crée pour une plate-forme. Pas pour
> celles à venir. D'ailleurs, on n'est pas devin, impossible d'être sûrs à
> 100% que telles ou telles fonctionnalités ne sera pas DEPRECATED, ne
> sera pas modifiées ou que le retour d'une fonction ne sera pas
> légèrement modifié.
>
> Bref, ce n'est pas le plus important.
>
> Sinon, je sors ma boule de cristal et je vois dans la doc (lien donné
> précédemment) que str_split a été lancée avec PHP5, je ne vois pas
> pourquoi il la retirerai.
>
> Cordialement,
>
> Clément

Bonjour Monsieur

Je n'ai plus qu'à faire un gros audit de tout mon site
www.pronostics-courses.fr , pour ajouter le code qui rendra à priori mon
site, compatible avec les versions ultérieures de php.

A propos de la compatibilité avec php 6, qui sera en mode utf8 par
défaut :

J'ai déjà adapté mon site, pour que les fonctions de type PCRE (
exemple preg_split() ) soient utilisées à l'exclusion des fonctions de
type Posix ( split() par exemple ), et aussi les accès à la base de
données MySQL avec l'interface objet PDO, au lieu des classiques
fonctions mysql_*().

Cependant, mon site est en mode ISO-8859-1, alors que dans le cas de
php 6, la base de données sera lue et écrite en mode utf8 par défaut,
les scripts seront interprétés en mode utf8, etc...

D'après le PHP Manual, pour adapter mon site en mode iso, il faudrait
modifier un certain nombre de variables système contenues éventuellement
dans le fichier php.ini, qui définissent le mode de codage de
caractères, pour les différentes fonctionnalités :

Les fonctionnalités, devraient inclure l'interprétation des scripts
en mode iso, la lecture/écriture des fichiers en mode iso, l'aspiration
des pages html distantes en mode iso, etc...

unicode.filesystem_encoding
unicode.output_encoding
unicode.script_encoding
unicode.stream_encoding
unicode.fallback_encoding

avec, éventuellement :

unicode.http_input_encoding


Première question :

A part une instruction de type "SET NAMES" lancée juste après la
connexion à la Base de Données MySQL ( qui est en mode latin1 par défaut
), pour fixer le mode caractères à latin1 ( équivalent de ISO-8859-1 en
vocabulaire MySQL ), serait-il possible, d'affecter ces variables
système ci-dessus, dans un fichier .htaccess à la racine du site, avec
la chaîne : "ISO-8859-1", et si oui, celà suffirait-il, à ce que mon
site soit compatible PHP 6, si par ailleurs toutes ses instructions,
seraient non deprecated, et entièrement disponibles sous PHP 6 ?

Ou bien, y aurait-il d'autres variables système à modifier, pour
spécifier le mode ISO ?

Je comprend bien, que l'idéal, serait que je convertisse entièrement
mon site en mode utf8, ainsi que sa base de données, ce qui serait
théoriquement possible. Cependant, il y aurait des adaptations dans le
cas de prise en compte de la longueur des chaînes de caractères ( avec
la fonction substr() par exemple, largement employée par mon site ),
aussi je pense que si je me mettais à cette traduction complète de mon
site, ce serait un travail de Romain, et puis je ne pense pas, que même
à terme, le fait d'utiliser le mode iso, devienne impossible.

Merci beaucoup de vos réponses.

[Clément]

Le 05/05/2012 16:50, Jean Francois Ortolo a écrit :
>
>
> Bonjour Monsieur
>
> Je n'ai plus qu'à faire un gros audit de tout mon site
> www.pronostics-courses.fr , pour ajouter le code qui rendra à priori mon
> site, compatible avec les versions ultérieures de php.
>

Comme je l'ai dit, à moins d'être en php4, pourquoi vouloir changer de
version ?

On pourrait faire une analogie avec une voiture.
Imaginez qu'à chaque fois qu'un nouveau modèle de pièce de moteur, le
constructeur décide de l'installer mais, comme il y a un risque, à
chaque fois, on va tout contrôler pour une bonne rétro compatibilité.
Il perdrait énormément de temps (et d'argent).
C'est pareil pour un site web. On décide du "moteur" (généralement, on
essaye de prendre le dernier stable en date) et après, on y touche plus.

> A propos de la compatibilité avec php 6, qui sera en mode utf8 par défaut :
>

De mémoire, et à moins que ceci ait changé, PHP 6 a été annulé et est en
suspend. Si ce n'est plus le cas, je veux bien vos sources.

> J'ai déjà adapté mon site, pour que les fonctions de type PCRE ( exemple
> preg_split() ) soient utilisées à l'exclusion des fonctions de type
> Posix ( split() par exemple ), et aussi les accès à la base de données
> MySQL avec l'interface objet PDO, au lieu des classiques fonctions
> mysql_*().

ça ce n'est pas de l'adaptation pour php6 mais de php4 à 5. split() est
déprécié et les fonctions mysql_* ne sont plus maintenues. Au minima
pour un projet php5, il faut utiliser PDO ou mysqli (dixit la doc de PHP)

>
> Cependant, mon site est en mode ISO-8859-1, alors que dans le cas de php
> 6, la base de données sera lue et écrite en mode utf8 par défaut, les
> scripts seront interprétés en mode utf8, etc...
>

Vous confondez ici pas mal de chose.
Votre site est en iso-8859-1, soit (pas un choix très judicieux, mais
s'il date, pourquoi pas).
PHP 6 (s'il existe un jour) interprètera par défaut en utf-8 (utile
surtout pour toutes les fonctions sur les strings) mais ne modifiera pas
vos pages en UTF-8 et ne lira pas la base en UTF-8, il la lira comme
elle est réglée elle.
De plus, qui dit "mode par défaut" dit "réglable". Gage à vous, si vous
ne souhaitez pas d'UTF-8 de régler PHP et votre base en conséquence.

> D'après le PHP Manual, pour adapter mon site en mode iso, il faudrait
> modifier un certain nombre de variables système contenues éventuellement
> dans le fichier php.ini, qui définissent le mode de codage de
> caractères, pour les différentes fonctionnalités :
>
> Les fonctionnalités, devraient inclure l'interprétation des scripts en
> mode iso, la lecture/écriture des fichiers en mode iso, l'aspiration des
> pages html distantes en mode iso, etc...
>
> unicode.filesystem_encoding
> unicode.output_encoding
> unicode.script_encoding
> unicode.stream_encoding
> unicode.fallback_encoding
>
> avec, éventuellement :
>
> unicode.http_input_encoding
>

Je veux bien la source de tout ça, je ne le trouve pas dans la doc.

>
> Première question :
>
> A part une instruction de type "SET NAMES" lancée juste après la
> connexion à la Base de Données MySQL ( qui est en mode latin1 par défaut
> ), pour fixer le mode caractères à latin1 ( équivalent de ISO-8859-1 en
> vocabulaire MySQL ), serait-il possible, d'affecter ces variables
> système ci-dessus, dans un fichier .htaccess à la racine du site, avec
> la chaîne : "ISO-8859-1", et si oui, celà suffirait-il, à ce que mon
> site soit compatible PHP 6, si par ailleurs toutes ses instructions,
> seraient non deprecated, et entièrement disponibles sous PHP 6 ?
>

Idem pour la base, en latin1 par défaut signifie et même devrait être
obligatoirement réglable.

Ensuite, je ne vois pas le rapport avec le fichier .htaccess là.

Je tiens aussi à signaler que DEPRECATED ne signifie pas "supprimé" mais
"à éviter" (car risque de suppression dans les versions à venir). Par
exemple, rien ne vous empêche d'utiliser "split()". Il y aura juste une
alerte (sur la page ou/et dans les logs selon votre réglage de php.ini).

> Ou bien, y aurait-il d'autres variables système à modifier, pour
> spécifier le mode ISO ?
>
> Je comprend bien, que l'idéal, serait que je convertisse entièrement mon
> site en mode utf8, ainsi que sa base de données, ce qui serait
> théoriquement possible. Cependant, il y aurait des adaptations dans le
> cas de prise en compte de la longueur des chaînes de caractères ( avec
> la fonction substr() par exemple, largement employée par mon site ),
> aussi je pense que si je me mettais à cette traduction complète de mon
> site, ce serait un travail de Romain, et puis je ne pense pas, que même
> à terme, le fait d'utiliser le mode iso, devienne impossible.
>

A vous de voir au niveau temps. Remplacer substr() par un mb_substr()
n'est pas non plus titanesque.

Quoi qu'il en soit, je ne ferai que me répéter pour la 3ème fois mais :
Prendre en compte les versions ultérieures maintenant serait la pire
perte de temps que vous puissiez prendre car :
1- on ne peut pas deviner le devenir de PHP, les choix sont votés et les
modifications arrivent aux compte-goutte.
2- la version de PHP ne devrait être changée que pour une bonne raison
(faille de sécurité par exemple) mais jamais de plus d'une version (php
5.2.2 à php 5.2.3 par exemple)

[Jean Francois Ortolo]

Le 05/05/2012 17:37, Clément a écrit :
>
> Quoi qu'il en soit, je ne ferai que me répéter pour la 3ème fois mais :
> Prendre en compte les versions ultérieures maintenant serait la pire
> perte de temps que vous puissiez prendre car :
> 1- on ne peut pas deviner le devenir de PHP, les choix sont votés et les
> modifications arrivent aux compte-goutte.
> 2- la version de PHP ne devrait être changée que pour une bonne raison
> (faille de sécurité par exemple) mais jamais de plus d'une version (php
> 5.2.2 à php 5.2.3 par exemple)
>
>

Bonjour Monsieur

Je peux quand même ( comme je l'ai fait en migrant mon site entier
vers les fonctions de type PCRE et l'interface PDO de MySQL ),
m'arranger pour que mon site soit compatible à priori, avec l'évolution
probable future des versions de PHP.

La compatibilité n'est pas identité, mais simplement une question
d'adaptation. Un site peut très bien être compatible avec toutes les
versions récentes de PHP, et aussi avec les ( relativement ) proches
versions futures probable, de PHP.

Par ailleurs, cette migration, dont je suis très fier, a nécessité
que je programme en Bourne Shell et en Langage AWK, des programmes de
conversion des anciennes fonctions, vers les nouvelles fonctions, en
lisant les anciens scripts php de manière récursive dans l'arborescence
des répertoires de mon site ( sur mon ordinateur of course ), et en
traduisant les anciennes fonctions vers les nouvelles fonctions, tout en
gardant les paramètres suffisamment identiques,q ue ce soient des
variables ou des chaînes de caractères.

Le processus, fût en fait semi-automatique, car j'ai eu à corriger
les erreurs, loguées par mes soins dans des fichiers ad hoc.

J'ai fait la même chose pour mon site partenaire www.lescourses.com ,
mais la version en ligne est encore à l'ancienne mode. Cependant, la
nouvelle version a été copiée par mes soins, dans un sous-répertoire du
site.

Le processus de migration, a été plus que très accéléré par le mode
semi-automatique. En fait, je ne m'en serais jamais tiré, si j'avais eu
à changer tous les scripts manuellement... ;)

Je suis obligé de suivre l'évolution des versions de PHP, compte tenu
du fait que mon site est sur un hébergement mutualisé. Je ne maîtrise
pas la version de PHP.

Actuellement, la version de PHP pour mon site, est :

PHP 5.2.6-1 , en mode CGI/FastCGI

Le Safe Mode n'est pas activé, heureusement, ce qui me permet
d'allonger un peu le temps d'exécution de mes scripts, donc de rendre
mon site plus "Google friendly", en m'évitant des redirections de
scripts en scripts, pour éviter la limite fatidique des 30 secondes
maximum d'exécution. ;)

Une dernière question que j'aurais, qui concerne plus MySQL en PHP,
serait quelle instruction MySQL ( je crois que c'est de la forme : "SET
NAMES latin1" ou qqqhose comme çà ) je pourrais utiliser, pour fixer de
manière absolue, le mode de caractères des lectures/écritures dans la
base de données MySQL.

Merci beaucoup de vos réponses à cette dernière question.

[Jean Francois Ortolo]

Le 05/05/2012 18:25, Jean Francois Ortolo a écrit :
>
> Une dernière question que j'aurais, qui concerne plus MySQL en PHP,
> serait quelle instruction MySQL ( je crois que c'est de la forme : "SET
> NAMES latin1" ou qqqhose comme çà ) je pourrais utiliser, pour fixer de
> manière absolue, le mode de caractères des lectures/écritures dans la
> base de données MySQL.
>
> Merci beaucoup de vos réponses à cette dernière question.
>
> Bien amicalement.
>
> Jean François Ortolo
>

Bonsoir

Voilà, j'ai la réponse à ma question, donnée par Google.

La syntaxe, pour fixer les échanges entre le client et le serveur
MySQL à latin1 ( équivalent de ISO-8859-1 ), est :

SET NAMES 'latin1';

On fait pas plus simple. ;)

J'ai incorporé cette instruction immédiatement après la connexion,
dans mon fichier de configuration.

No problem, çà marche.

[Clément]

Le 05/05/2012 18:25, Jean Francois Ortolo a écrit :
> Je suis obligé de suivre l'évolution des versions de PHP, compte tenu du
> fait que mon site est sur un hébergement mutualisé. Je ne maîtrise pas
> la version de PHP.
>
> Actuellement, la version de PHP pour mon site, est :
>
> PHP 5.2.6-1 , en mode CGI/FastCGI

Un bon hébergeur mutualisé comme le votre et le mien (OVH), permet de
choisir la version PHP utilisé via .htaccess

(d'ailleurs, si ce n'est pas déjà fait, retirez les magic_quotes)

http://guide.ovh.com/php5chezovh
http://guide.ovh.com/Php4ChezOvh
http://guide.ovh.com/ConfigPhp

[Jean Francois Ortolo]

Bonsoir Monsieur

Mon hébergeur est : Sivit/Nerim.

Voici la configuration de magic quotes.

Local Value Master Value

magic_quotes_gpc On On
magic_quotes_runtime Off Off
magic_quotes_sybase Off Off


Je pense, que je ne peux pas changer le magic_quotes_gpc , mais je
peux me tromper.

Il n'y a pas de possibilité de choisir la version de php.

Je suis depuis hier, en contact avec le développeur chez mon
hébergeur, de la fonctionnalité cron bêta, qui est actuellement en phase
de tests avec les abonnés, et sera mise dans quelques temps, à
disposition des abonnés mutualisé.

Avant Sivit ( qui a fusionné avec Nerim il y a quelques mois ),
j'étais chez OVH, en mutualisé. J'avais un abonnement à un mutualisé 240
Plan ( à l'époque ).

Mais... Chez OVH, le Safe Mode était à On ( je crois, plus sûr... ),
et j'étais obligé de faire des contorsions pas possibles en redirections
entre scripts, pour ne pas dépasser la limite maximale de durée
d'exécution des scripts.

Celà nuisait à mon référencement chez Google. D'ailleurs, celà date
déjà d'un certain nombre d'années.


Maintenant que en ce qui me concerne, les tests de cette
fonctionnalité cron vont débuter très prochainement, mon hébergeur
m'apporte ( ou m'apportera ) tout ce que je désire :

- Un environnement web bien sécurisé ( patch Suhoshin ), et des accès
web suffisamment rapides,

- Une version de PHP et aussi MySQL, suffisamment récentes,

- En ce qui me concerne, je n'ai pas remarqué de cas où mon site
n'était pas joignable, je peux me tromper, d'autant plus que des abonnés
se sont plaint,

- Enfin, prochainement, la fonctionnalité cron, avec la possibilité
de lancer des scripts php en ligne de commande ( PHP en mode CLI ), avec
une durée maximale d'exécution, il est vrai limitée à 5 minutes par
script, et pas de possibilités de redirections entre scripts, seulement
la possibilité éventuelle, de lancer un script php en mode web, à partir
du premier script php en mode CLI.

Je sais que la Société OVH est une référence en matière
d'hébergement, aussi bien mutualisé que dédié ou VDS, et que ses
responsables sont de très bons administrateurs et font de bons choix
techniques. Il me semble aussi, que leurs prix ne sont pas rédhibitoires.

Cependant, je ne suis pas habitué à cette impossibilité de lancer
l'instruction ini_set(), comme c'est le cas chez eux, et puis je crois,
ce Safe Mode à On, celà ne me convient pas.

Merci beaucoup de me corriger si je dis des erreurs.

[Clément]

Le 05/05/2012 20:29, Jean Francois Ortolo a écrit :
> Bonsoir Monsieur
>
> Mon hébergeur est : Sivit/Nerim.
>

Au temps pour moi, le whois de votre 2nd site est encore sur OVH, j'ai
donc supposé que l'hébergement l'était (encore) aussi.

> Voici la configuration de magic quotes.
>
> Local Value Master Value
>
> magic_quotes_gpc On On
> magic_quotes_runtime Off Off
> magic_quotes_sybase Off Off
>
>
> Je pense, que je ne peux pas changer le magic_quotes_gpc , mais je peux
> me tromper.
>
> Il n'y a pas de possibilité de choisir la version de php.
>

C'est cela qui en fait un mauvais hébergeur (si je puis me permettre).
Un hébergeur dont on ne peut pas choisir la version ou qui change de
version sans prévenir est "dangereux" à mon avis.

> Je suis depuis hier, en contact avec le développeur chez mon hébergeur,
> de la fonctionnalité cron bêta, qui est actuellement en phase de tests
> avec les abonnés, et sera mise dans quelques temps, à disposition des
> abonnés mutualisé.
>
> Avant Sivit ( qui a fusionné avec Nerim il y a quelques mois ), j'étais
> chez OVH, en mutualisé. J'avais un abonnement à un mutualisé 240 Plan (
> à l'époque ).
>
> Mais... Chez OVH, le Safe Mode était à On ( je crois, plus sûr... ), et
> j'étais obligé de faire des contorsions pas possibles en redirections
> entre scripts, pour ne pas dépasser la limite maximale de durée
> d'exécution des scripts.

C'est faux. safe_mode à off : http://240plan.ovh.net/infos/test.php
Le register_global est à on mais un petit .htaccess à la racine permet de :
- choisir la version php voulue
- mettre register_global à off
- mettre magic_quote à off
comme expliqué précédemment.

>
> Celà nuisait à mon référencement chez Google. D'ailleurs, celà date déjà
> d'un certain nombre d'années.
>
>
> Maintenant que en ce qui me concerne, les tests de cette fonctionnalité
> cron vont débuter très prochainement, mon hébergeur m'apporte ( ou
> m'apportera ) tout ce que je désire :
>
> - Un environnement web bien sécurisé ( patch Suhoshin ), et des accès
> web suffisamment rapides,
>
> - Une version de PHP et aussi MySQL, suffisamment récentes,
>
> - En ce qui me concerne, je n'ai pas remarqué de cas où mon site n'était
> pas joignable, je peux me tromper, d'autant plus que des abonnés se sont
> plaint,
>
> - Enfin, prochainement, la fonctionnalité cron, avec la possibilité de
> lancer des scripts php en ligne de commande ( PHP en mode CLI ), avec
> une durée maximale d'exécution, il est vrai limitée à 5 minutes par
> script, et pas de possibilités de redirections entre scripts, seulement
> la possibilité éventuelle, de lancer un script php en mode web, à partir
> du premier script php en mode CLI.

Rien que n'ait pas les hébergements mutu ovh ;-) à part le mode CLI (je
crois)

>
> Je sais que la Société OVH est une référence en matière d'hébergement,
> aussi bien mutualisé que dédié ou VDS, et que ses responsables sont de
> très bons administrateurs et font de bons choix techniques. Il me semble
> aussi, que leurs prix ne sont pas rédhibitoires.
>
> Cependant, je ne suis pas habitué à cette impossibilité de lancer
> l'instruction ini_set(), comme c'est le cas chez eux, et puis je crois,
> ce Safe Mode à On, celà ne me convient pas.

ini_set() n'est pas bloqué chez OVH (je l'utilise sur pas mal de mes
pages), il l'est même pas chez free :/
et encore une fois safe_mode est à off ;)

>
> Merci beaucoup de me corriger si je dis des erreurs.
>
> Bien amicalement.
>
> Jean François Ortolo
>
>
>

Je ne tiens pas à faire plus de pub que ça pour OVH. Je suis chez eux
depuis 8 ans en 60GP mutu et je règle tout comme je veux, sans aucun
problème.

[Jean Francois Ortolo]

Bonsoir Monsieur

Finalement, voici le code résistant à toutes les modifications
possibles des fonctions suivant les versions de PHP.

Ce code est destiné, à fonctionner en mode ISO-8859-1 exclusivement,
ce qui implique simplement, que le script soit codé en ISO, et soit
interprété en mode ISO, ce qui devrait rester possible quelle que soit
l'évolution à terme de PHP, si la programmation php en mode iso reste
possible.

Celà veut dire, que la seule possibilité pour que ce code ne soit
plus valide, serait que des versions ultérieures de PHP, rendent
strictement obligatoire, un mode de codage de caractères différent de
ISO-8859-1 et ISO-8859-15, ce qui vous l'avouerez, est plus que très
improbable.

Voici le code :


function array_to_to_str($tmp_array)
{
$str = "";

for($i = 0; $i < count($tmp_array); $i++)
$str .= $tmp_array[$i];

return($str);
}

function str_to_to_array($str)
{
$tmp_array = array();

for($i = 0; $i < strlen($str); $i++)
$tmp_array[$i] = substr($str, $i, 1);

return($tmp_array);
}


Ce code sous-entend, que la fonction substr() perdurera à terme dans
le futur pour toutes les versions ultérieures de PHP

Pour adapter le code de mon site, avec $str étant le nom de la
variable sélectionnée jusqu'ici par l'opérateur [] , il me suffira de
rajouter, avant chaque groupes de sélections, la ligne suivante :

$str = str_to_to_array($str);

Et après chaque groupes de sélections, la ligne :

$str = array_to_to_str($str);

Pour retrouver une chaîne de caractère modifiée par la sélection+
modification sur l'array temporaire $str

Si j'ai besoin de sauvegarder la variable chaîne $str avant un groupe
de sélections, je peux le faire très facilement, puis adapter le code de
manière très facile.

Il me suffit d'incorporer le code de ces deux fonctions dans mon
script php de configuration, inclus dans tous mes scripts php, pour
disposer de ces deux fonctions, sans aucune possibilité de confusion
avec des fonctions existantes.

Je pense, qu'en ce qui me concerne, le problème est résolu.

[Clément]

Malheureusement pour vous, il ne l'est pas.
$str = str_to_to_array('£$épourquoi ç a @& à');
donnera quelque chose d'éronné.

http://codepad.org/pm2pZy6y

(ce même bout de code a fait planter http://codepad.viper-7.com d'ailleurs

J'ai mis 20 caractères et pourtant le tableau résultant en aura 24.
Car £, é, ç, à sont des caractères utf-8. À moins que vous ne vouliez
pas utiliser d'accent (site en anglais par exemple), votre fonction ne
fonctionnera pas partout. En effet, strlen() est une fonction qu'il faut
utiliser avec parcimonie. mb_strlen() pourrait pallier à ça.

Et encore une fois, rien n'indique que les fonctions basiques utilisées
dans les vôtres ne seront pas modifiées. Ainsi, à tenter de faire du
"compatible" sur le long terme, vous risquez de perdre du temps
maintenant et plus tard.

[Jean Francois Ortolo]

Bonjour Monsieur

Je ne comprend pas très bien.

L'utilisation de ce code, présuppose, que les données paramètres des
fonctions, seront tous codés en mode ISO-8859-1 ou ISO-8859-15 à la rigueur.

Quant à é , ç, et à, ils peuvent très bien être codés en ISO-8859-1,
et je m'arrange bien, avec la fonction iconv() pour des données
provenant de l'extérieur, pour que mes données soient toutes en iso.

J'ai évidemment tenu compte du fait, que les fonctions strlen() et
substr() dans mon code, n'acceptent que des paramètres en mode ISO.

D'ailleurs, c'est le but de mon site, de rester en mode iso, sans
limite de temps, compte tenu du fait, qu'il est peu probable, que même à
terme, le comité PHP décide d'obliger strictement les utilisateurs de
php, à programmer en mode utf8 ( ou utf16, ou utf32 ).

Bien à vous.

Amicalement.

Jean François Ortolo

[Clément]

Le 08/05/2012 11:34, Jean Francois Ortolo a écrit :
> Bonjour Monsieur
>
> Je ne comprend pas très bien.
>
> L'utilisation de ce code, présuppose, que les données paramètres des
> fonctions, seront tous codés en mode ISO-8859-1 ou ISO-8859-15 à la
> rigueur.
>
> Quant à é , ç, et à, ils peuvent très bien être codés en ISO-8859-1, et
> je m'arrange bien, avec la fonction iconv() pour des données provenant
> de l'extérieur, pour que mes données soient toutes en iso.
>
> J'ai évidemment tenu compte du fait, que les fonctions strlen() et
> substr() dans mon code, n'acceptent que des paramètres en mode ISO.
>
> D'ailleurs, c'est le but de mon site, de rester en mode iso, sans limite
> de temps, compte tenu du fait, qu'il est peu probable, que même à terme,
> le comité PHP décide d'obliger strictement les utilisateurs de php, à
> programmer en mode utf8 ( ou utf16, ou utf32 ).
>
> Bien à vous.
>
> Amicalement.
>
> Jean François Ortolo
>

Bon je n'insisterai pas. Mais c'est quand même étrange comme point de
vue (vouloir absolument être compatible avec les versions PHP
ultérieures mais vouloir absolument resté en iso, habituellement, on
fait l'inverse).