Quel charset choisir ?

Mac iMesser

Membre actif
13 Mars 2005
148
0
Genève
Question de newbie

Quel charset (encodage du texte) choisir pour développer quelque chose en HTML/PHP sur du Mac (histoire que les cousins windowsiens puissent eux aussi profiter des caractères accentués du français sans avoir l'impression de lire une langue étrangère ? :zen:
 
UTF-8, sans aucune hésitation.

Mais utilise bien le html_entities() dans ton code pour éviter les mauvaises surprises...

Perso, je ne bosse qu'en UTF-8 (je ne suis pas encore sous mac, je dévellope sous linux, où tout est en UTF-8, du coup, facile de respecter le codage sur toute la longueur du flux de travail).

D'ailleurs, tiens, quel est l'encodage général de MacOSX, pour celui qui viendrait à lire ça et qui le sait ?
 
UTF-8 & Mac Roman.
Le premier pour le nom des fichiers, etc.

Le seconde est l'affichage par défauts des applications (TextEdit, …)
 
Mac iMesser a dit:
Question de newbie

Quel charset (encodage du texte) choisir pour développer quelque chose en HTML/PHP sur du Mac (histoire que les cousins windowsiens puissent eux aussi profiter des caractères accentués du français sans avoir l'impression de lire une langue étrangère ? :zen:
utf8 no bom le no bom est tres important je m'etendrais pas sur le sujet

polices web /multi langues

mac lucida-grande
win arial ms unicode
nix* helvetica
 
Pour les développements en français, j'utilise ISO-Latin-1 (ISO-8859-1).

Première remarque: certains hébergeurs ne permettent pas de choisir l'encodage, et imposent latin1_swedish_ci. Dans ce cas, vaut mieux pas enregistrer en UTF-8... Sauf à utiliser les htmlentities, mais on perd alors tout l'intérêt des encodages.

Deuxième remarque: le choix de l'encodage n'est pas si important que ça (UTF-8, iso-latin-1, etc.), ce qui est vraiment important c'est de ne pas mélanger les encodage: il faut en choisir un et s'y tenir.

Troisième remarque: ne pas oublier de déclarer le charset utilisé dans le head des pages HTML.
 
Si tu te tiens à un iso pour le dévellopement français, les ISO-8859-15 est recommandé, puisqu'il intègre les signe "€" (euro) et autres, en plus d'être rétro-compatible avec le 8859-1.

Le problème des hébergeurs est vrai, personnellement, chez le mien je configure ma partie du serveur comme je le veux via les configurations d'apache, donc defaultCharset = Off et tout mon flux de travail passe et reste en UTF-8.

Cela dit, UTF-8 est l'encodage le plus recommandé, étant donné qu'il représente "l'avenir" de l'encodage, et va progressivement devenir le standard de l'encodage des machines (mais qui reste à la traine, hein, je vous le demande...)
 
Lisaraël a dit:
Si tu te tiens à un iso pour le dévellopement français, les ISO-8859-15 est recommandé, puisqu'il intègre les signe "€" (euro) et autres, en plus d'être rétro-compatible avec le 8859-1.

Le problème des hébergeurs est vrai, personnellement, chez le mien je configure ma partie du serveur comme je le veux via les configurations d'apache, donc defaultCharset = Off et tout mon flux de travail passe et reste en UTF-8.

Cela dit, UTF-8 est l'encodage le plus recommandé, étant donné qu'il représente "l'avenir" de l'encodage, et va progressivement devenir le standard de l'encodage des machines (mais qui reste à la traine, hein, je vous le demande...)
ho il l'est déjà $ na j'aime mieux :D et t'es comme moi tu vas chez un hébergeur pas chez un épicier du net
 
Lisaraël a dit:
UTF-8, sans aucune hésitation.

Mais utilise bien le html_entities() dans ton code pour éviter les mauvaises surprises...

Perso, je ne bosse qu'en UTF-8 (je ne suis pas encore sous mac, je dévellope sous linux, où tout est en UTF-8, du coup, facile de respecter le codage sur toute la longueur du flux de travail).

D'ailleurs, tiens, quel est l'encodage général de MacOSX, pour celui qui viendrait à lire ça et qui le sait ?

Attention toutefois, on ne peut pas utiliser html_entity_decode sur de l'UTF8 en PHP4. Il faut donc bidouiller un peu si tu stockes des trucs dans une base de donnee en le passant a la moulinette html_entities, et que tu souhaites ensuite autoriser kk1 a editer le texte dans un formulaire (auquel cas il faut decoder les html entities).

Bloc de code:
function toEditableText( $sText, $sEncoding = 'ISO8859-15' )
{
	if ( $sEncoding == 'UTF-8' )
	{
		$aTranslationTable = get_html_translation_table( HTML_ENTITIES );
			
		foreach($aTranslationTable as $sKey => $sValue)
		{
			$aUnicodeTable[$sValue] = utf8_encode( $sKey );
		}
	
		$sText = strtr( trim( $sText ), $aUnicodeTable);
	}
	else
	{
		$sText = html_entity_decode( trim( $sText ), ENT_QUOTES, $sEncoding );
	}

	return $sText;
}
 
  • J’aime
Réactions: tatouille
tatouille a dit:
utf8 no bom le no bom est tres important je m'etendrais pas sur le sujet
Ah Tatouille, tu ouvres toujours des champs de recherche et je m'y plonge.

Bon, en cherchant un peu, je constate que ce marqueur BOM peut causer des soucis d'interprétation lorsque l'on utilise PHP4 (avec les sessions et le chargement des headers du peu que j'ai pu en lire)

Certains editeurs permettent d'enregistrer en utf-8 no bom mais lorsque cela n'est pas le cas, peut-on trouver dans le fichier (en ayant pris soin de faire apparaitre les caractères invisibles par exemple) une marque à effacer ?
 
byte order mark
dans les premiers caractères

-- file --
[BOM]user content user content user content user content
user content user content user content
user content
user content
user content
-- file --

:D

ça ennuie aussi
les "webbrowser"(pas les récents) et donc le "xml[sgml] parser"


pour php
-- php file --
[BOM]<?PHP


?>
-- php file --

boum bom parse error :D
:D
 
Ok merci.
 
xs_stef a dit:
c'est plus complet ici

Q: What is a BOM?

A: A byte order mark (BOM) consists of the character code U+FEFF at the beginning of a data stream, where it can be used as a signature defining the byte order and encoding form, primarily of unmarked plaintext files. Under some higher level protocols, use of a BOM may be mandatory (or prohibited) in the Unicode data stream defined in that protocol.


:zen: