Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

syntax error

22 réponses
Avatar
Pascal
Bonjour
Je tourne en rond avec ce probl=E8me : ici http://scalpa.info/1.html
Si je mets le contenu du javascript dans le fichier 1.html =E7a marche... S=
i j'appelle le javascript externalis=E9 comme dans le fichier en lien cela =
ne fonctionne plus....
Y a un truc qui m'=E9chappe....
Help !
merci

10 réponses

1 2 3
Avatar
SAM
Le 21/11/12 19:16, Pascal a écrit :
Bonjour
Je tourne en rond avec ce problème : ici http://scalpa.info/1.html
Si je mets le contenu du javascript dans le fichier 1.html ça marche... Si j'appelle le javascript externalisé comme dans le fichier en lien cela ne fonctionne plus....
Y a un truc qui m'échappe....



tu es certain que chevraiter s'écrit : chevreter ?

Help !
merci




et en enlevant les signes de CDATA ?


Je te signales que tu n'en a pas mis pour le script qui commence à la
ligne 21 du fichier 1.html
(tu y a mis les inutiles signes de commentaire (de html) au lieu de ceux
CDATA, puisque ce script n'est pas dans le HEAD)

Mébon, comme au final nos brouteurs s'en moquent un peu, on a une erreur
à la ligne 42, quand le script réclame CrosswordWidth
qui n'a pu être lu, caché qu'il était par les CDATA-trucs du fichier
fr_conj_pr7_eter_crossword.js

--
Stéphane Moriaux avec/with iMac-intel
Avatar
Pascal
Houlà de plus en plus étrange... ce matin sans avoir changé quoique c e soit tout est revenu dans l'ordre y compris mes anciens exercices..... Se rait-ce un problème serveur de chez 1&1?
J'avais tout essayé remettre les fichiers en UTF8 avec ou sans bom, déc laré les script avec <!-- sans et cdata ou non..... bref une journée de perdue.... sans explication...j'adore!

merci pour votre aide
pascal
Avatar
SAM
Le 22/11/12 08:40, Pascal a écrit :
Houlà de plus en plus étrange... ce matin sans avoir changé quoique
ce soit tout est revenu dans l'ordre y compris mes anciens
exercices...



Ha ?
Tu n'avais pas :
- relancé le brouteur ?
- tenté de *forcer* le ré-affichage ?
- essayé de lire le fichier JS directement sur serveur ?

Mais ... non ... ça ne fonctionne pas chez moi !
(ni avec Fx, ni avec Safari)

Voici ce que me dit Firefox :

Horodatage : 22/11/12 10:10:47
Erreur : SyntaxError: syntax error
Fichier Source :
http://scalpa.info/mots_croises/conj/present/fr_conj_pr7_eter_crossword.js
Ligne : 1
Code Source :
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//E

Je ne vois pas cette ligne dans le fichier JS ... ? ! ?
Le serveur se mélange les pinceaux ?

Horodatage : 22/11/12 10:10:47
Erreur : ReferenceError: CrosswordWidth is not defined
Fichier Source : http://scalpa.info/1.html
Ligne : 42

Là c'est normal, si le parser trouve une erreur dans le JS externe
(ou si le serveur a ses vapeurs)
Voici ce que me raconte Web Developer :
<http://cjoint.com/?BKwkPsPfJZL>

Le curieux : une fois sauvegardé en local ça fonctionne impec !
(nota: peut-être tenter de "franciser" ce que ça affiche ?)

En tous cas pour le w3c la page est propre :
<http://validator.w3.org/check?uri=http://scalpa.info/1.html>
Néanmoins ...
peut-être faudrait-il essayer avec un doctype plus souple ? (HTML.4)
en enlevant des scripts JS les codes <!-- ou CDATA
--
Stéphane Moriaux avec/with iMac-intel
Avatar
SAM
Le 22/11/12 08:40, Pascal a écrit :
Serait-ce un problème serveur de chez 1&1?



Pour le fichier JS lui-même, la "réponse" d'en-tête :
en local : Content-Type: application/xml
sur serveur : Content-Type: application/x-javascript

Il y aurait comme une espèce d'antinomie ?

tout essayé remettre les fichiers en UTF8 avec ou sans bom,



*JAMAIS* avec bom ! ! ! ! !

déclaré
les script avec <!-- sans et cdata ou non



Là c'est avec cDATA
... on a du mal à voir si c'est mieux ou non ...

..... bref une journée de
perdue.... sans explication...j'adore!



Ça doit vraiment être ton serveur !
car, à moins que Fx à la sauvegarde ait tout bien remis en utf-8,
le schmilblick transféré ici :
<http://je.m.arrete.free.fr/mot-X/>
fonctionne impec chez moi.



--
Stéphane Moriaux avec/with iMac-intel
Avatar
Pascal
<!-- : ces commentaires ne sont plus utiles du tout?
*JAMAIS* avec bom ! ! ! ! !


Ah !? Pourquoi t'est-ce? Il me semble avoir lu que les serveurs qui font to urner php merdouillent sinon?
Tout semble rentré dans l'ordre.... avec l'intervention du Dusseintexprix !


Au fait, tes messages s'affichent bizarrement sur Firefox depuis google g roup...
> d�clar�




merci et bonne journée
pascal
Avatar
Otomatic
Pascal écrivait :

> *JAMAIS* avec bom ! ! ! ! !
Ah !? Pourquoi t'est-ce? Il me semble avoir lu que les serveurs qui font tourner php merdouillent sinon?
Tout semble rentré dans l'ordre.... avec l'intervention du Dusseintexprix!


Par ce que, déjà, pour de l'utf-8 déclarer une entête BOM ne sert
strictement à rien et est totalement inutile. BOM, signifiant Byte Order
Mark.
Pour UTF-16, le BOM est 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). UTF-8 n'a aucun
problème d'ordre des octets, il ne sert donc à rien de mettre une entête
BOM à un fichier codé utf-8.

Si on utilise un éditeur de texte (ou autre logiciel éditeur
hexadécimal) qui permet de voir le fichier sous forme hexadécimale,
c'est à dire avec une suite d'octets qui en représente le contenu, on
peut voir si il y a des caractères supplémentaires (BOM) au début du
fichier.

Par exemple, en vue hexadécimale, le début du fichier header.php normal
est :

00000000 3C3F 7068 700D 0A2F 2A2A 2A2A 2A2A <?php../******
0000000E 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A **************
0000001C 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A **************

Le même fichier avec entête BOM est :

00000000 EFBB BF3C 3F70 6870 0D0A 2F2A 2A2A <?php../***
0000000E 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A **************
0000001C 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A 2A2A **************

On voit bien que trois octets sont insérés au début du fichier : EF BB
BF, c'est l'entête BOM.
La plupart du temps, ces trois octets sont vus comme caractères : “”
dans la fenêtre du navigateur ce qui permet de déterminer qu'il s'agit
bien d'une entête BOM.

En PHP, c'est la porte grande ouverte aux erreurs du genre :
Warning: Cannot modify header information - headers already sent by …
--
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
Avatar
Pierre Goiffon
Le 23/11/2012 09:44, Otomatic a écrit :
*JAMAIS* avec bom ! ! ! ! !





Par ce que, déjà, pour de l'utf-8 déclarer une entête BOM ne sert
strictement à rien et est totalement inutile.



C'est assez lapidaire : si l'on a besoin de mécanisme d'auto-détection
la présence du BOM (prévu et tout à fait valide dans n'importe quel des
codages Unicode : http://www.unicode.org/faq//utf_bom.html#bom4) peut
être fort utile. Mais on est là dans un cas très particulier !

Quoi qu'il en soit, les navigateurs, même très récents, n'aiment pas du
tout du tout un JS en UTF-8 avec BOM, c'est un prb que l'on a constaté
de notre côté (intervenu subrepticement dans la chaine d'intégration
continu et le processus de compression/concaténation automatisé).

En PHP, c'est la porte grande ouverte aux erreurs du genre :
Warning: Cannot modify header information - headers already sent by …



J'avais eu il y a quelques années des soucis similaires avec des
fichiers php utf-16, est-ce que l'interpréteur sait maintenant s'en
débrouiller ?
Avatar
Olivier Miakinen
Le 23/11/2012 10:46, Pierre Goiffon a écrit :

Par ce que, déjà, pour de l'utf-8 déclarer une entête BOM ne sert
strictement à rien et est totalement inutile.



C'est assez lapidaire : si l'on a besoin de mécanisme d'auto-détection
la présence du BOM (prévu et tout à fait valide dans n'importe quel des
codages Unicode : http://www.unicode.org/faq//utf_bom.html#bom4) peut
être fort utile. Mais on est là dans un cas très particulier !



Bof. À ma connaissance, le seul cas rencontré où de l'UTF-8 peut être
confondu avec autre chose, c'est un texte de deux caractères chinois
dans je ne sais plus quel encodage (d'ailleurs si quelqu'un à la
référence de cette info cela m'intéresse). Il me semble que dans un
texte en chinois de plus de deux caractères la probabilité que cela
arrive est proche du zéro absolu. Quant à un texte écrit dans une
langue occidentale et utilisant l'un des charsets tels que Latin1 ou
Latin9, il est complètement impossible qu'il soit confondu avec de
l'UTF-8 (et réciproquement).

Quoi qu'il en soit, les navigateurs, même très récents, n'aiment pas du
tout du tout un JS en UTF-8 avec BOM, c'est un prb que l'on a constaté
de notre côté (intervenu subrepticement dans la chaine d'intégration
continu et le processus de compression/concaténation automatisé).

En PHP, c'est la porte grande ouverte aux erreurs du genre :
Warning: Cannot modify header information - headers already sent by …





Notons que le problème n'est pas la présence de cette séquence en
elle-même, mais le fait qu'elle soit présente *avant* le moindre
caractère utile. En l'occurrence, il devient impossible d'appeler
une fonction PHP telle que header() ou ob_start() avant que les
premiers caractères soient émis.

J'avais eu il y a quelques années des soucis similaires avec des
fichiers php utf-16, est-ce que l'interpréteur sait maintenant s'en
débrouiller ?



Similaires, c'est-à-dire d'envoi d'un BOM ? Ou bien dus au fait que
les caractères ASCII tels que « <?php « ne sont plus codés de la
même manière (problème qui n'existe ni en ISO-8859-* ni en UTF-8) ?
Avatar
Paul Gaborit
À (at) Fri, 23 Nov 2012 10:46:39 +0100,
Pierre Goiffon écrivait (wrote):

Le 23/11/2012 09:44, Otomatic a écrit :
*JAMAIS* avec bom ! ! ! ! !







Par ce que, déjà, pour de l'utf-8 déclarer une entête BOM ne sert
strictement à rien et est totalement inutile.



C'est assez lapidaire : si l'on a besoin de mécanisme d'auto-détection
la présence du BOM (prévu et tout à fait valide dans n'importe quel des
codages Unicode : http://www.unicode.org/faq//utf_bom.html#bom4) peut
être fort utile. Mais on est là dans un cas très particulier !



La logique de l'argumentaire ne tient pas une minute.

Dans un contexte purement Unicode et avec plusieurs codages, le BOM
utf-8 ne sert à rien : il n'y a pas de byte order pour utf-8 et les
autres codages (utf-16 et utf-32 avec leurs variantes BE/LE) doivent
avoir un BOM pour s'assurer de détecter correctement leur byte order.

Dans un contexte plus général où tous les codages existants (pas
uniquement ceux liés à Unicode) co-existent (le cas typique d'un
navigateur), l'auto-détection ne marche pas (il ne faut pas oublier que
les BOM Unicode peuvent être considérer comme une suite de caractères
tout à fait valides pour des codages non Unicode).

Quoi qu'il en soit, les navigateurs, même très récents, n'aiment pas du
tout du tout un JS en UTF-8 avec BOM, c'est un prb que l'on a constaté
de notre côté (intervenu subrepticement dans la chaine d'intégration
continu et le processus de compression/concaténation automatisé).



C'est d'autant plus normal que le BOM pourrait venir en contradiction
avec l'encodage annoncé par les meta-informations du protocole de
transport.

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Avatar
SAM
Le 23/11/12 07:38, Pascal a écrit :
<!-- : ces commentaires ne sont plus utiles du tout?



Pour le code JS,
on se demande même s'ils n'ont jamais été utiles ?
(peut-être pour les navigateurs textuels du siècle dernier ?)

Pour les CDATA c'est plus nouveau
et, à ce que je crois avoir compris, ça ne s'utilise que si :
- on est en Xhtml
- et le code JS est dans le body

*JAMAIS* avec bom ! ! ! ! !


Ah !? Pourquoi t'est-ce? Il me semble avoir lu que les serveurs qui font tourner php merdouillent sinon?



à mon idée : ce serait plutôt le contraire.

Je ne comprends rien au PHP
mais il m'avait bien semblé qu'il ne fallait *absolument RIEN* avant :
<?php
au début du fichier


Tout semble rentré dans l'ordre.... avec l'intervention du Dusseintexprix!



c'est koha ça ?

En tous cas, <http://scalpa.info/1.html> ne *fonctionne toujours pas*
chez moi !!!!

--
Stéphane Moriaux avec/with iMac-intel

* Unknown - détecté
* Anglais
* Français
* Espagnol

* Anglais
* Français
* Espagnol

<javascript:void(0);>
1 2 3