xmlParseEntityRef: no name
Une Bévue
This page contains the following errors:
error on line 1985 at column 28: xmlParseEntityRef: no name
Below is a rendering of the page up to the first error.
la page est pr�sent�e au butineur apr�s une transformation xslt.
le fichier xml d'origine est issu d'un fichier texte en Mac Roman, tsv,
transform� en xml par mes soins.
j'ai d�j� transform� les "&", "<" et ">" en "&", "&lt;" et
"&gt;" respectivement mais il doit me rester des entit�s non
r�f�renc�es d'apr�s ce que me dit le parser.
comme le fichier est long (la page html g�n�r�e fait 40000 lignes) je
n'ai pas envie de v�rifier � la main.
le fichier xml est confidentiel, ce sont mes mots de passe, comptes en
banque etc...
y a t'il un outil qui me permettrait de v�ifier sa validit� offline sur
Mac OS X ???
--
� Comment peser sur le bulletin?
Tu t'assieds dessus. �
(Anonyme)
Une Bévue
Pr�cisions, la ligne indiqu�e est celle du fichier r�sultat, donc html,
elle contient :
Copy & paste the above Keycode into the Program. For detailed
instructions, see below: Copy & Paste Instructions: 1. COPY the Keycode
above by highlighting the text then holding the Command key down, hit
the 'C' key. 2. Launch the SereneScreen Marine Aquarium by
double-clicking on the program icon. 3. Press the spacebar to open the
Register dialog box. 4. Hold the Command key down and hit the 'V' key,
this will copy the Keycode into the program. 5. Press the ENTER key to
complete the registration.
le fichier xml lui contient :
Copy & paste the above Keycode into the Program. For detailed
instructions, see below: Copy & Paste Instructions: 1. COPY the
Keycode above by highlighting the text then holding the Command key
down, hit the 'C' key. 2. Launch the SereneScreen Marine Aquarium by
double-clicking on the program icon. 3. Press the spacebar to open the
Register dialog box. 4. Hold the Command key down and hit the 'V' key,
this will copy the Keycode into the program. 5. Press the ENTER key to
complete the registration.
donc �a ne doit pas �tre le & -> & qui pose probl�me mais 'C' et 'V'
les ' et ' dont je ne connais pas d'entit�, mais je peux changer �a en '
ou " tout court...
Une Bévue
bon j'ai chang� les "apostrophes arrondies" en ' tout court... m�me
erreur, m�me ligne m�me colonne...
Une Bévue
>
> bon j'ai chang� les "apostrophes arrondies" en ' tout court... m�me
> erreur, m�me ligne m�me colonne...
c'est le & r�sultant qui posait probl�me aussi ai-je chang� ma
transformation :
& -> &amp; (ainsi j'ai & dans le html)
< -> &lt; (comme avant)
> -> &gt; (comme avant)
curly apostrophe gauche -> '
curly apostrophe droite -> '
et l� �a roule...
SAM
>
> et l� �a roule...
Mais ...
n'y a t-il pas une chi�e de fonctions PHP pour traiter des caract�res ?
http://fr.php.net/manual/fr/function.htmlentities.php
justement pour ne pas avoir � le faire � la main
(ou quasi : preg_replace & cie)
http://fr.php.net/manual/fr/function.html-entity-decode.php
http://fr.php.net/manual/fr/function.htmlspecialchars.php
http://fr.php.net/manual/fr/function.get-html-translation-table.php
et aussi : mb_convert_encoding ?
Ha ! ? pas de MacRoman ?
<http://fr.php.net/manual/fr/mbstring.supported-encodings.php>
--
St�phane Moriaux avec/with iMac-intel
Pierre Goiffon
> c'est le& r�sultant qui posait probl�me aussi ai-je chang� ma
> transformation :
>
> & -> &amp; (ainsi j'ai& dans le html)
> < -> &lt; (comme avant)
>> -> &gt; (comme avant)
> curly apostrophe gauche -> '
> curly apostrophe droite -> '
Les apostrophes (je suppose qu'il s'agit de U+2018 et U+2019 ??) ne
devraient pas poser probl�me � priori ?
Une Bévue
> Mais ...
> n'y a t-il pas une chi�e de fonctions PHP pour traiter des caract�res ?
>
> http://fr.php.net/manual/fr/function.htmlentities.php
>
> justement pour ne pas avoir � le faire � la main
> (ou quasi : preg_replace & cie)
>
>
>
>
> http://fr.php.net/manual/fr/function.html-entity-decode.php
> http://fr.php.net/manual/fr/function.htmlspecialchars.php
> http://fr.php.net/manual/fr/function.get-html-translation-table.php
>
> et aussi : mb_convert_encoding ?
> Ha ! ? pas de MacRoman ?
> <http://fr.php.net/manual/fr/mbstring.supported-encodings.php>
Oui mais non, en fait j'ai export� un fichier d'une application "Web
Confidential" que j'ai au moins depuis Mac OS 9 en un fichier texte tsv
(tab separated values) et �a je l'ai fait une fois pour toute, en ruby.
par contre c'est vari, pour les futures entr�es je devrai utiliser les
htmlentities de php, mais je n'en suis pas encore l�, �a va viendre
incessament sous peu )))
merci pour ces infos !!!
par contre je ne sais pas trop si php g�re bien l'UTF-8...
Une Bévue
>
> Les apostrophes (je suppose qu'il s'agit de U+2018 et U+2019 ??) ne
> devraient pas poser probl�me � priori ?
effectivement, apr�s essai, il s'av�re que c'est inutile...
merci !!!
j'avais fini par m'en douter...
SAM
>
> par contre je ne sais pas trop si php g�re bien l'UTF-8...
Je pense qu'en ses derni�res versions il devrait bien s'en sortir
(ce n'est pas pour travailler avec l'iBook G3 au moins ?)
c'est plut�t entre php et mysql qu'il vaut bien veiller � ce qu'ils se
comprennent
(crois-je)
faut sans doute bien r�gler les headers
pour communication serveur <--> navigateur
(encore que ... je ne me souviens pas avoir fait de gros efforts de ce
c�t� sur mon Mac et bien que j'�crive tout en utf-8)
Olivier Miakinen
>
> par contre je ne sais pas trop si php gï¿œre bien l'UTF-8...
1) Les noms des fonctions standard sont tous en ASCII 7 bits,
donc en UTF-8 sans aucun changement.
2) Les fonctions qui ne font pas de traitement des chaï¿œnes de
caractￜres se foutent du charset utilisￜ.
3) La plupart des fonctions qui font des traitements de chaï¿œnes,
et ont besoin de savoir si c'est du Latin1, du Big5 ou de
l'UTF-8, ont un paramï¿œtre permettant de choisir le charset.
4) Mï¿œme les noms de variables peuvent ï¿œtre en UTF-8 sans problï¿œme
(et ce, mï¿œme si tu as l'imprudence de nommer tes variables
avec des caractï¿œres autres qu'ASCII 7 bits).
Et donc, ￜ condition d'ￜviter les quelques fonctions qui traitent
des chaï¿œnes de caractï¿œres mais n'ont pas de moyen de spï¿œcifier le
charset, tu devrais pouvoir faire ce que tu veux en UTF-8.
Pour ï¿œtre sï¿œr de n'avoir aucun problï¿œme, tout d'abord tu dois ï¿œtre
au clair sur toutes tes sources de caractï¿œres (fichiers en UTF-8,
paramï¿œtres d'accï¿œs aux bases de donnï¿œes, dï¿œclaration MIME correcte
sur le serveur, etc.)
Et puis aussi, tu dois t'assurer que ton ï¿œditeur de texte n'a pas la
stupiditￜ d'ajouter un ￜ BOM ￜ au dￜbut des fichiers (trois octets
de valeurs EF BB BF). Si c'est le cas, soit tu trouves une option
pour qu'il ne le fasse pas, soit tu jettes cet ￜditeur ￜ la poubelle
et tu en prends un autre.
Cordialement,
--
Olivier Miakinen
Une Bévue
> Je pense qu'en ses derni�res versions il devrait bien s'en sortir
> (ce n'est pas pour travailler avec l'iBook G3 au moins ?)
non, non, lui il est quasi passif...
> c'est plut�t entre php et mysql qu'il vaut bien veiller � ce qu'ils se
> comprennent
> (crois-je)
oui, je me souviens de pbs de ce c�t� l� mais je n'utilise + mysql.
> faut sans doute bien r�gler les headers
> pour communication serveur <--> navigateur
> (encore que ... je ne me souviens pas avoir fait de gros efforts de ce
> c�t� sur mon Mac et bien que j'�crive tout en utf-8)
moi aussi, mais avec Apache par exemple j'ai eu des pbs si bien que je
n'utilise pas de lettres accentu�es dans les directives Apache
(.htaccess)
Une Bévue
> 1) Les noms des fonctions standard sont tous en ASCII 7 bits,
> donc en UTF-8 sans aucun changement.
>
> 2) Les fonctions qui ne font pas de traitement des cha�nes de
> caract�res se foutent du charset utilis�.
>
> 3) La plupart des fonctions qui font des traitements de cha�nes,
> et ont besoin de savoir si c'est du Latin1, du Big5 ou de
> l'UTF-8, ont un param�tre permettant de choisir le charset.
>
> 4) M�me les noms de variables peuvent �tre en UTF-8 sans probl�me
> (et ce, m�me si tu as l'imprudence de nommer tes variables
> avec des caract�res autres qu'ASCII 7 bits).
>
> Et donc, � condition d'�viter les quelques fonctions qui traitent
> des cha�nes de caract�res mais n'ont pas de moyen de sp�cifier le
> charset, tu devrais pouvoir faire ce que tu veux en UTF-8.
>
> Pour �tre s�r de n'avoir aucun probl�me, tout d'abord tu dois �tre
> au clair sur toutes tes sources de caract�res (fichiers en UTF-8,
> param�tres d'acc�s aux bases de donn�es, d�claration MIME correcte
> sur le serveur, etc.)
>
> Et puis aussi, tu dois t'assurer que ton �diteur de texte n'a pas la
> stupidit� d'ajouter un � BOM � au d�but des fichiers (trois octets
> de valeurs EF BB BF). Si c'est le cas, soit tu trouves une option
> pour qu'il ne le fasse pas, soit tu jettes cet �diteur � la poubelle
> et tu en prends un autre.
OK, merci beaucoup pour toutes ces pr�cisions, en fait, �a correspond �
ma pratique.
le BOM j'ai eu un pb r�cemment avec un "vieux" TextWrangler pour MacOS X
Panther, je m'en souviendrai, je l'esp�re...
SAM
>
> le BOM j'ai eu un pb r�cemment avec un "vieux" TextWrangler pour MacOS X
> Panther, je m'en souviendrai, je l'esp�re...
Je pense que TextWrangler vieux ou pas
,et comme BBEdit,
doit savoir faire du utf-8 "no bom"
Faut seulement bien leur pr�ciser, et comprendre que pour ces coquins
c'est UTF-8-no-BOM et UTF-8 ... avec BOM !
Tout � l'envers quoi !
(mais n�anmoins explicite ... si on creuse un peu)
Une Bévue
> Je pense que TextWrangler vieux ou pas
> ,et comme BBEdit,
> doit savoir faire du utf-8 "no bom"
ah oui, MAIS, la valeur par d�faut -- pour UTF-8, c'est AVEC BOM...
Dominique Ottello
> ah oui, MAIS, la valeur par d�faut -- pour UTF-8, c'est AVEC BOM...
�a me semble quelque peu aberrant pour UTF-8
Pour UTF-16, il y en a besoin, le BOM �tant une s�quence de deux octets
FE FF au d�but de la cha�ne cod�e, pour indiquer que les caract�res
cod�s suivants utilisent l'ordre poids fort en dernier (big-endian) ; ou
FF FE pour indiquer l'ordre poids faible en dernier (little-endian).
Alors qu'UTF-8 n'a aucun probl�me d'ordre des octets, � quoi cela
sert-il d'en mettre un.
--
Aujourd'hui, l'id�al du progr�s est remplac� par l'id�al de l'innovation :
il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau,
m�me si c'est pire qu'avant et cela de toute �vidence. Montherlant
Technologie a�ronautique - http://ottello.net - Les anciens de Vilg�nis
Olivier Miakinen
>
>> ah oui, MAIS, la valeur par dï¿œfaut -- pour UTF-8, c'est AVEC BOM...
>
> ï¿œa me semble quelque peu aberrant pour UTF-8
Oui, tu peux mￜme retirer ￜ quelque peu ￜ. ;-)
> Pour UTF-16, il y en a besoin, le BOM ï¿œtant une sï¿œquence de deux octets
> FE FF au dï¿œbut de la chaï¿œne codï¿œe, pour indiquer que les caractï¿œres
> codï¿œs suivants utilisent l'ordre poids fort en dernier (big-endian) ; ou
> FF FE pour indiquer l'ordre poids faible en dernier (little-endian).
Il sert aussi ￜ UTF-32 (00 00 FE FF ou FF FE 00 00).
> Alors qu'UTF-8 n'a aucun problￜme d'ordre des octets, ￜ quoi cela
> sert-il d'en mettre un.
ￜ ce que j'ai cru comprendre, c'ￜtait une astuce Microsoft pour
distinguer UTF-8 de UTF-16 sans avoir besoin de lire tout le
fichier. Cela dit, je peux me tromper, mï¿œme s'il y en a qui se
trompent encore plus que moi :
<http://www.paperblog.fr/1880790/l-encodage-utf-8-avec-bom-fait-apparaitre-un-i-en-haut-de-page/>
Le BOM est lￜ pour aider votre fichier (en thￜorie) : d'aprￜs ce que
j'ai lu il rï¿œgle des conflits entre les types de fichiers Windows et
Unix (mais je n'en suis pas sï¿œr du tout !)
</>
:-D