loufoque

Lors de l'upload tu n'as à faire attention qu'aux extensions qui permettrait d'executer des scripts PHP ou autres CGIs.

Ce sont ici les extensions qui déterminent le comportement du navigateur.

Donc le type mime, Linux et Mac on s'en fout.

Non seulement ça marche, mais c'est en plus très fortement conseillé pour des soucis d'internationalisation évidents.

Sache néanmoins qu'il ne faut pas mettre de BOM.

Je t'ai expliqué ce qu'était une collation ou interclassement.

Tu comprends bien qu'il n'y en a pas de meilleure que d'autre puisque cela dépend des usages dans certaines langues données.

latin1_general se veut général, soit plus ou moins applicable partout. Tu peux par exemple essayer celui-ci (enfin latin1_general_ci ou latin1_general_cs).

Ce ne sont pas des jeux de caractères mais des collations.

Les collations (comme apparemment tu ne sais pas ce que c'est) ce sont des façons différentes de comparer les caractères. Par exemple (je dis un truc sûrement faux, mais c'est pour l'exemple) ä > z en suédois mais ä < b en allemand (bien sûr, b < z). Cela sert pour le tri et la comparaison.

La collation dépend bien entendu du jeu de caractères ici latin1 alias ISO-8859-1.

latin1_swedish_ci suédois,

car il répertorie tous les caractères possibles et imaginables je crois bien

C'est grave de dire de pareilles conneries.

ISO-8859-1 est défini sur 8 bits avec un encodage classique à chasse fixe. Si tous les caractères possibles et imaginables du monde se limitaient à 256, ça se saurait.

En fait il y en a 1 114 112, et le jeu de caractères qui les contient tous c'est Unicode, dont l'encodage le plus connu est utf-8.

Je parle un peu de tout ça sur le dernier billet de mon blog.

Il faut savoir que GD transforme aussi toute image en 72dpi.

Ben oui, forcément, puisque PNG est un format lossless et que JPEG est un format lossy...

Normalement un PNG n'est pas vraiment gros, à part si il a été généré avec un logiciel qui gère mal les PNGs (Photoshop par exemple)

$img = imagecreatefrompng('image.png');

imagejpeg($img, 'image.jpg', 100);

imagedestroy($img);

Tu perdras en qualité, forcément.

$url=ereg_replace("SID=[^& ]+&?","",$url);

$url=ereg_replace("(http://[^ ]+)\?","\\1",$url);

$url = ereg_replace("SID=[^& ]+", "", $url), tout simplement.

Le reste est inutile.

Les navigateurs envoient les données dans l'encodage qu'on a spécifié avec l'attribut accept-charset de <form>.

Quand cet attribut n'est pas spécifié l'encodage de la page est utilisé.

Les caractères en dehors de l'encodage spécifié sont envoyés sous la forme de références numériques Unicode (€ par exemple pour le caractère euro)

Il n'y a que Internet Explorer qui se comporte de façon incohérente.

En fait, il n'a qu'une valeur possible pour accept-charset : UTF-8, et il ne l'utilise que s'il n'est pas possible d'écrire les caractères avec l'encodage utilisé pour la page.

Et si cet attribut n'est pas fourni, il choisit un encodage au hasard qui peut transmettre tous les caractères.

Bref, a priori si tu envoies tes pages en utf-8 et que tu fonctionnes en utf-8 partout il n'y aura aucun problème.

Je ne puis que te proposer quelques liens généralistes, étant donné que tu ne précises pas la nature exacte des problèmes.

http://www.genezys.net/blog/2005/06/17/99-...x-de-caracteres

http://french.joelonsoftware.com/Articles/Unicode.html

http://openweb.eu.org/articles/jeux_caracteres/

Il s'agit d'articles en français que j'avais mis de côté.

Je t'ai fournie la syntaxe correcte.

Après cela peut très bien venir que this n'est plus défini dans ce contexte ou d'une autre erreur, regarde la console js.

$contenu = substr_replace($contenu, '<u>allergène</u>', strpos($contenu, 'allergène'), 9);

Ce que tu appelles brut est sûrement de l'ISO-8859-1 (ou du windows-1252, dans ce cas, les conversions seraient plus problématiques).

Ce que tu appelles utf-xx est utf-8.

Ce que tu appelles iso-8859-xx semble être de l'ascii avec des entités html (truc vraiment sans intérêt).

setInterval('mafonction(this);', 2000);

Le safe_mode c'est nul.

Il faut chmoder en 777 le repertoire où tu veux pouvoir génerer des fichiers.

Du coup, cela signifie que n'importe quel autre utilisateur du serveur pourra accéder à ces fichiers.

Après, tu prétends qu'apache refuse d'executer un script avec pour uid son utilisateur ? Hmm ça me parait bizarre.

Par contre, je suis sûr que PHP refusera d'en faire un include si le fichier n'est pas au moins chmodé.

je cherche une solution du type :

1/génération du fichier dans un sous répertoire

2/ Download du fichier en FTP,

3/ Upload du même fichier en FTP, à la racine du site.

C'est facile à faire si tu as l'extension ftp.

Comment fait on pour remplacer un retour ligne par un <br>

Il suffit de remplacer le (ou les) caractère(s) de fin de ligne par <br>.

Avec str_replace par exemple.

nl2br le fait en prenant en compte les fins de lignes unix, win et mac et retourne <br />EOL.

ensuite le process en tâche de fond ça me parait possible, mais sur un hébergement mutualisé tu oublies vite fait

Tous les hergements mutualisés ne désactivent pas popen et/ou proc_open.

Certains hebergements proposent même de faire un pcntl_fork.

On peut aussi faire une solution 100% JavaScript, mais du coup impossible de fournir un pourcentage car on ne saura pas quand ça finira.

Ce qui est totalement faux, ASP est une interface qui te permet de choisir le langage de programmation que tu souhaites.

On peut aussi faire du JScript et depuis ASP.NET du C#.

En Asp, il y a les 2 notions

En VBScript tu veux dire.

Ce que Windows appelle unicode c'est utf-16 et ce qu'il appelle ansi c'est le charset local, windows-1252 sur les systèmes occidentaux.

N'utilise jamais notepad pour quoi que ce soit. En plus en utf-8 il met le BOM (ce qui est plus ou moins une aberration)

Unired est très bien.

Ensuite quant au support dans MySQL ou PHP.

PHP se fout totalement de l'encodage que tu utilises, mais la plupart des fonctions se basent sur le principe que chaque octet est un caractères (strlen par exemple) ce qui est évidemment faux en utf-8. Il peut être utile de recoder certaines fonctions, et iconv et mbstring peuvent aussi fournir quelques trucs. PHP6 arrangera cela et surtout, ce qui est intéressant, c'est qu'il fournira ICU avec collations etc.

MySQL s'en foutait jusqu'à la version 4.1. Maintenant il gère ça (ce qui pose énormement de problèmes aux débutants), l'utilité étant de pouvoir avoir les bonnes collations.

commence par remplacer les \ par des /.

emacs doit le faire.

Porte simplement le code en PHP (au fait, c'est pas du C ton exemple c'est du Fortran).

Le plus simple serait de lire la documentation du format grib.

Oulah ça m'étonnerait que ce soit l'effet désiré...