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

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.

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.

Bien amicalement.

Jean François Ortolo

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

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.

Bien amicalement.

Jean François Ortolo

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)

Merci beaucoup de vos réponses.

Bien amicalement.

Jean François 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.

Bien amicalement.

Jean François 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.

Bien amicalement.

Jean François Ortolo

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

Le 05/05/2012 19:26, Clément a écrit :

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

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.

Bien amicalement.

Jean François Ortolo

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.