Reprise du message précédent :
je vais fouiller dans www.php.net, je pense qu'il doit y avoir quelques fonctions traitant l'unicode ...

arf, ...
 
 
... a character is the same as a byte, that is, there are exactly 256 different characters possible. This also implies that PHP has no native support of Unicode. Note: It is no problem for a string to become very large. There is no practical bound to the size of strings imposed by PHP, so there is no reason ...

et il fait comment joce alors? parce qu'ici ca marche pas.

je sais pas du tout ...
je pense plutot a une configuration de apache/php pour ne pas accepter l'unicode

[edtdd]--Message édité par skylight--[/edtdd]

je vais encore creusé, je ne m'avoue pas vaincu

je pense utiliser cette fonction :  
 
http://dev.nexen.net/docs/php/anno [...] en=unicode
 
mb_encode_numericentity()  
 
on peux spécifier le type de string

j'ai pas suivit votre truc d'unicode c pour eviter koi?, les titre ou corps de message vide ...
 

[edtdd]--Message édité par speedyop--[/edtdd]

speedyop a écrit a écrit : j'ai pas suivit votre truc d'unicode c pour eviter koi?, les titre ou corps de message vide ...

 
oui, mais surtout les pseudo vide ou similaires...

mouais les pseudo vide ca craint, le mieux est de se faire une fucntion style  
 
string_clean($text)
{
text=eregi_replace(' ',' &
#039;,$text);
$text=htmlspecialchars(trim($text));
}
 
ca suffirait ?

[edtdd]--Message édité par speedyop--[/edtdd]

arf et en plus il ne veut pas m'afficher & # 1 6 0 ; a coté!

si tu lisais de quoi on parle ...  
la fonction trim() joue tres bien son role mais pas pour le caractere d'espace incassable ... (alt + 0160)
et c'est ca qu'on cherche !

bah le eregi_replace ca marche pas? apres avoir fait un html_entities... mouias c moche...

putain je pige pas, je viens de faire d'autres tests et le htmlentities le remplace bien par   je dois avoir une couille quelque part dans mon code.

trim ajoute des paramletre depuis la version 4.1.0
http://www.zend.com/manual/function.trim.php
 
 
trim
(PHP 3, PHP 4 >= 4.0.0)
 
trim --  Strip whitespace from the beginning and end of a string  
Description
 
string trim (string str [, string charlist])
 
 
Note: The second parameter was added in PHP 4.1.0  
 
This function returns a string with whitespace stripped from the beginning and end of str. Without the second parameter, trim() will strip these characters:  
 
 
" " (ASCII 32 (0x20)), an ordinary space.  
 
"\t" (ASCII 9 (0x09)), a tab.  
 
"\n" (ASCII 10 (0x0A)), a new line (line feed).  
 
"\r" (ASCII 13 (0x0D)), a carriage return.  
 
"\0" (ASCII 0 (0x00)), the NUL-byte.  
 
"\x0B" (ASCII 11 (0x0B)), a vertical tab.  
 
 
You can also specify the characters you want to strip, by means of the charlist parameter. Simply list all characters that you want to be stripped. With .. you can specify a range of characters.  
 
ca dvrait aller ca

[edtdd]--Message édité par speedyop--[/edtdd]

oui, mais comme c'est pour donner les source, faut que ce soit un maximum compatible

  les sources de koi ?

skylight a écrit a écrit :     les sources de koi ?

de mon forum pardis.
 
Sinon c'est bon, j'ai trouvé l'erreur dans mon code. visiblement il n'aimait pas ca: preg_replace("/ /","",$char) je l'ai remplacé par " " et ca marche. Je sais pas pourquoi, vu que j'utilies "" dans d'autres fonctions...
 
donc au final ca donne
 
$new_pseudo=htmlentities($pseudo);
$new_pseudo=preg_replace("/ /"," ",$new_pseudo);
$new_pseudo=trim($new_pseudo);

bon moi g un pb avec mon forum
effectivement, vu que je l'heberge chez moi (et etant abonné wanadoo) j'utilise le smtp.wanadoo.fr
 
mais hebergé sur multimania ou free... ca marche plus, normal quoi
 
ya quoi comme serveur smtp qui supporte le relaying ?

sinon au lieu de faire nbsp: pourquoi ne pas utiliser chr(160)?
 
trim($string,chr(160));
 
c simple et elegant non? klk peut tester j'ai pas mes sources sous la main
 
parceque ce ki etait moche avec le htmlentities c'est qu'apres si tu veut n'afficher q'un certain nombre de charactere pour pas foutre en l'air la presentation... et kil coupe au milieu d'un caractere convertit...
 
 
argh merde vous parler sur 2 thread en meme temps j'arrive po a suivre  

[edtdd]--Message édité par speedyop--[/edtdd]

 
Parce que chr n'utilise que de l'ASCII et que seul les 127 premiers caratères sont standardisés. chez moi par exemple ca me donne un a avec accent.

de plus, comme c'est pas compatible avec toutes les version de php4...

 
et encore moins php3

bah alors faut rester avec le htmlentities, pensais que ca serait asser relou de faire la reconversion d'une chaine htmlentitiesé mais non
 
get_html_translation_table et array_flip() rends les chose assez simple
http://www.php.net/manual/fr/funct [...] -table.php
 
bon vous aller me dire que c'est encore du php4

tant que ce reste du php4 classique, ca me va, vu que j'utilise les sessions.

c'est + rapide les sessions ?

 
j'en sais rien, j'ai pas encore fait des test, mais c'est bien partique en tout cas.

avantage d'une session par rapport au cookie? et pis t'es bien obliger d'avoir un systeme de cookie kan meme?

je me suis pas encore interressé aux sessions vu que je n'en ai pas encore besoin, mon forum marche nikel avec 2 cookies.

2?

SetCookie("login__forum",$pseudo,99999999);
        SetCookie("pass__forum",$password,99999999);
 
je sais pas si c'est considéré comme 2 cookies, ou une.

[edtdd]--Message édité par skylight--[/edtdd]

ok je sait pas si c'est bien de mettre le mot de pass en cookie, ni le login...
des avis?

a condition de proposer une fonction pour te délogger qui effcae le mdp, ca gène pas.
 
Sinon pour les session, l'avantage se situe au niveau de l'upload, tu peux avoir plus d'info sur la personne sans devoir aller a chaque fois chercher dans la DB

bah dans ma librairie je fait une requette pour le user et recupere toute les infos de celui ci en tableuax associatif

ok, et tu fais cette requette a chaque fois, pas avec les sessions. Mainteant faut voir ce qui est plus rapide, un accès a une session ou a la db.

evidemment, sur mon forum, ya un truc pour tuer la cookie.. kan meme

un cookie n'est qu'une string, qui quand elle est formée du style var1=value1&var2=value2 est interprétée par php comme deux variables.
 
tu stockes le mot de passe en clair ? pas bien ça ... perso je stocke le login (en clair) + le md5(password).

quel intérêt de stocké en md5?

de ne pas stocker le mot de passe en clair, c'est tout

pas te faire choper ton pass par un sniffer

youdontcare a écrit a écrit : de ne pas stocker le mot de passe en clair, c'est tout

 
donc ca sert a rien, vu que si on sait voir le mdp en clair, c'est qu'on a acces au cookies, donc suffit de recopier tout le cookie et ton truc n'a plus aucun intérêt.

 
ca revient au même que de recopier le mdp crypté dans un cookie.