probleme caracteres UNIX-WINDOWS en php

probleme caracteres UNIX-WINDOWS en php - PHP - Programmation

Marsh Posté le 02-07-2010 à 09:50:21    


 Bonjour,
 
j'ai développé une application php/MySQL qui fonctionne très bien sur serveur WINDOWS: pas de problème de caractères, pas de problème de redirection de page.
 
Je dois le mettre en place sur différents serveurs et certains sont des serveurs UNIX: problèmes de caractères (différenciation des majuscules et minuscules, les accents apparaissent en "?", et certaines redirections ne se font pas).
 
j'aimerais savoir s'il y a un moyen de contourné ces diférences sans que j'ai à corriger tout mon code, c'est à dire pouvoir convertir avec une fonction ou un mode je sais pas que je pourrait mettre dans l'entête de mes pages...  
 
 
 
merci  

Reply

Marsh Posté le 02-07-2010 à 09:50:21   

Reply

Marsh Posté le 02-07-2010 à 23:57:12    

S'il s'agit des noms de fichiers à part repasser sur tes pages non. Ou faire des liens (symboliques) sous Unix, mais bon, je ne trouve pas ça top :/
 
Concernant les accents, vérifie le Charset de ta page, l'encodage des fichiers...


---------------
NewsletTux - outil de mailing list en PHP MySQL
Reply

Marsh Posté le 03-07-2010 à 13:54:32    

il faut également que tu verifies l'encodage des champs de ta base php/Mysql. le problème peut venir de là


---------------
http://www.ypikay.com
Reply

Marsh Posté le 05-07-2010 à 09:20:27    

bonjour,
merci de vos réponse.
 
Le problème se situe à l'intérieur des fichiers, par exemple lorsque dans une balise html j'écris "raté" sous windows l'affichage est correct mais sous UNIX j'obtiens "rat?"..
Le jeu de caractère que j'utilise dans l'entête de mes fichiers est "iso-8859-1"..

Reply

Marsh Posté le 05-07-2010 à 11:48:48    

- Tu peux vérifier la configuration du serveur web. J'ai rencontré quelque serveurs apache qui envoyaient un charset UTF-8 dans les entêtes HTTP. Et quoi que je fasse, le navigateur refusait d'en utiliser un autre. Un petit .htaccess règle problème, si toutefois ils sont permis dans ta configuration.
 
- Vérifie que l'encodage de ta base de données correspond bien à celui de ton choix.
 
- Tes fichiers sont-ils bien enregistrés en ISO-8859-1
 
- Assure toi que tu as correctement écris tes entêtes HTML
 
Pour autant que je sache, ton problème ne peut venir que d'un de ces points.


---------------
-- Debian -- Le système d'exploitation universel | Le gras c'est la vie! | /(bb|[^b]{2})/
Reply

Marsh Posté le 05-07-2010 à 13:02:43    

Le mieux serait quand même de bosser en 100% UTF-8 :o


---------------
Gamertag: CoteBlack YeLL
Reply

Marsh Posté le 05-07-2010 à 13:54:21    

Dj YeLL a écrit :

Le mieux serait quand même de bosser en 100% UTF-8 :o


Je plussoie !
Bien que des fois on ne choisisse pas, typiquement en installant une appli tierce.


---------------
-- Debian -- Le système d'exploitation universel | Le gras c'est la vie! | /(bb|[^b]{2})/
Reply

Marsh Posté le 05-07-2010 à 15:11:26    

Salut,
 
S'il y a des problèmes de caractères à l'intérieur des fichiers alors il faut regarder comment les fichiers sont envoyés. Si c'est pas ftp, alors il faut que le logiciel soit ne mode "texte" et pas en mode "binaire". A voir dans le manuel du programme pour savoir où vérifier et régler ça.
Si c'est envoyé sous forme de fichier zip (ou autre format du genre) alors il faudra utiliser un outil de conversion pour transformer les caractères comme il faut.
 
Après ça, il restera le problème de différentiation des majuscules/minuscules et là il n'existe pas 36 manières. Il va falloir que tu vérifies toi même si tu écris tous les noms de fichiers et de dossiers de la même manière (tout en minuscules, tout en majuscule, première lettre en majuscule et le reste en minuscule?) et que tu t'y tiennes aussi bien dans les noms que dans ton code php.

Reply

Marsh Posté le 09-07-2010 à 23:37:23    

Dj YeLL a écrit :

Le mieux serait quand même de bosser en 100% UTF-8 :o


J E   C O N F I R M E   ! ! !  


---------------
http://www.ypikay.com
Reply

Marsh Posté le 09-07-2010 à 23:41:07    

parce que si tu pars en ISO, tu vas te retrouver avec des ? à la place des éèà etc
avec je sais plus quel alphabet tu vas te retrouver avec des Â@ et autres conneries... un seul encodage et l'UTF-8 a le vent en poupe.
maintenant tout dépend de tes données de départ. pour mon moteur de recherche par exemple, je repasse tout en UTF-8 et ben je galère:
si une page est en UTF-8 ca passe tout seul, sinon je dois choper le code hexa si le caractère est codé sur deux octets. bref je vais pas te raconter ma vie mais j'ai une fonction de environ 50 lignes pour environ 500 remplacements possibles et ça arrive encore à me retourner de la merde ....


---------------
http://www.ypikay.com
Reply

Marsh Posté le 09-07-2010 à 23:41:07   

Reply

Marsh Posté le 10-07-2010 à 13:07:48    

erwan83 a écrit :

parce que si tu pars en ISO, tu vas te retrouver avec des ? à la place des éèà etc
avec je sais plus quel alphabet tu vas te retrouver avec des Â@ et autres conneries... un seul encodage et l'UTF-8 a le vent en poupe.
maintenant tout dépend de tes données de départ. pour mon moteur de recherche par exemple, je repasse tout en UTF-8 et ben je galère:
si une page est en UTF-8 ca passe tout seul, sinon je dois choper le code hexa si le caractère est codé sur deux octets. bref je vais pas te raconter ma vie mais j'ai une fonction de environ 50 lignes pour environ 500 remplacements possibles et ça arrive encore à me retourner de la merde ....


 [:cerveau vomi]  
 [:barracus:5]

Reply

Marsh Posté le 12-07-2010 à 17:48:17    

erwan83 a écrit :

parce que si tu pars en ISO, tu vas te retrouver avec des ? à la place des éèà etc


Symptomatique UTF => ISO sur les caractères qui n'existent pas en ISO

erwan83 a écrit :

avec je sais plus quel alphabet tu vas te retrouver avec des Â@ et autres conneries...

Symptomatique de l'UTF affiché comme étant de l'ISO.

erwan83 a écrit :

un seul encodage et l'UTF-8 a le vent en poupe.

:jap:

erwan83 a écrit :

maintenant tout dépend de tes données de départ. pour mon moteur de recherche par exemple, je repasse tout en UTF-8 et ben je galère:
si une page est en UTF-8 ca passe tout seul, sinon je dois choper le code hexa si le caractère est codé sur deux octets. bref je vais pas te raconter ma vie mais j'ai une fonction de environ 50 lignes pour environ 500 remplacements possibles et ça arrive encore à me retourner de la merde ....

Dis moi, tu ne peux pas utiliser les fonctions de détections d'encodage ? "mb_detect_encoding" marche très bien quand elle est disponible et qu'elle est bien configuré.
Couplé au choix à un "unicode_encode", "mb_convert_encoding" ou "iconv", on évite quasiment tous les problèmes de changement d'encodage en direction de l'UTF-8.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed