Safari a du mal à afficher les images aux noms complexes
Un bug curieux frappe Safari : il arrive que le navigateur n’affiche pas une image, alors que d’autres butineurs en sont tout à fait capables. L’exemple donné par Pierre Dandumont est parlant : sur cette page, l’image censée apparaître après le premier sous-titre se contentera d’afficher un pavé blanc avec au centre, la petite icône caractéristique en forme de point d’interrogation.
Le bug se retrouve également sur iOS, et ce aussi bien sous iOS 9 qu’iOS 10. Il semble que le navigateur interprète mal l’URL d’une image dont le nom est composé de lettres accentuées et autres caractères exotiques. Cela ne pose pourtant pas de problème pour un autre navigateur.
Après une rapide recherche, et à notre connaissance, le problème n’est pas référencé sur le site d’assistance d’Apple. Si vous ne voyez absolument aucune image dans Safari, assurez-vous de ne pas avoir désactivé les images dans le menu de développement du logiciel (Préférences > Avancées > Afficher le menu Développement dans la barre des menus).
Cela fait au moins 2 ans que je connais ce bug. Wordpress est rempli de plugins pour parer à celui-ci. Il change le nom des images au moment de l'upload.
Un wordpress installé par défaut n'affiche pas les images avec nom de fichier accentué sur safari que ce soit sur Mac ou iOS. Je ne pensais pas que le bug était général.
@Chriscatfr :
Je confirme ! J'avais ce problème lorsque je travaillais sur wordpress en 2014 !
Cela explique quelques bizzareries.
Mais faut comprendre, à Cupertino on va jamais sur des sites avec des fichiers en langues bizarres, tout semblait aller bien.
-
Plus sérieusement le problème des caractères exotiques (hors ascii) continue de sévir dans l'informatique, voir de servir de faille de sécurité. Encore trop de bibliothèques de programmation en circulation qui ne gèrent pas tous les cas. ça fait tâche.
J'en suis encore à conseiller aux gens de ne pas mettre d'accents et autres dans les noms de fichiers (au cas où ils sont publiés dans un quelconque cms ou système web encore mal foutus ou lu par un utilisateur avec un logiciel problématique).
Je me demande si celui qui a programmé ça n'est pas le meme qui a programmée le bug 1970 d'iOS???
Parce que encoder les dates sur un nombre d'octets insuffisant et ne pas utiliser l'Unicode pour le nom des fichiers cela semble du meme acabit...
Et dire qu'Apple a ouvert une "école" pour enseigner la programmation d'iOS...
Bien que je n'en sache rien du bug de Safari (et le code source de webkit doit contenir la réponse), typiquement une bibliothèque quelque part dans la pile interprète mal une représentation des caractères.
ce n'est pas aussi simple que "duuh, j'ai oublié d'utiliser la baguette magique unicode.lib pour tout solutionner."
idem avec un bug dit de 1970 ou variante. C'est un travers typique des systèmes unix dû à des décennies de code par des milliers de personnes pour qui tout commence au temps zéro unix et codé sur 32b. Ce n'est pas simplement un oubli d'un programmeur.
-
"Et dire qu'Apple a ouvert une "école" pour enseigner la programmation d'iOS..."
qui d'autres ? des gens qui n'ont jamais programmé et donc jamais fait d'erreurs ? ;)
@ C1rc3@0rc : « ne pas utiliser l'Unicode pour le nom des fichiers cela semble du meme acabit... »
Je soupçonne quelque chose de plus complexe que ça (le problème ne se posant pas avec tous les noms contenant des caractères accentués). Un truc du genre NFC vs NFD, par exemple.
Mais il reste ahurissant que ça n'ait pas été repéré et corrigé depuis longtemps.
Ben... Vous savez, à Cupertino...le support de la langue du coin est plutot bon, on s'est aperçu de rien.
@BeePotato
Le mecanisme de gestion peut etre alambiquée et on peut effectivement penser que le probleme est plus complexe. Neanmoins je vois pas d'autres explications permettant a ce bug d'exister: si l'unicode avait ete utilisé integralement dans la gestion des nom de fichiers ce type de problemes n'existerait pas.
Dans ses guidelines Apple a toujours mis en garde contre la manipulation de fichiers a partir du nom ou du chemin d'acces, favorisant l'utilisation d'une reference specifique de l'API. Il est probable que le probleme survienne a un moment ou il y a la conversion dans un sens ou l'autre...
@ C1rc3@0rc : « Neanmoins je vois pas d'autres explications permettant a ce bug d'exister »
Ça doit être parce que tu ne lis pas bien les commentaires qui indiquent une autre explication. ;-)
« si l'unicode avait ete utilisé integralement dans la gestion des nom de fichiers ce type de problemes n'existerait pas. »
Ben si. Comme je l'ai déjà dit. :-P
« Utiliser Unicode », ce n'est pas un truc magique qui résout tout. Il faut aussi comprendre comment Unicode fonctionne et l'utiliser correctement. Il semble bien que ce ne soit pas le cas ici – mais du côté serveur/site web, plutôt que du côté navigateur (qui, en revanche, ne fait pas l'effort que font ses concurrents pour compenser ce genre d'erreur des sites web).
Tu es payé par Microsoft pour dénigrer Apple?
Quel que soit le sujet, tes commentaires = Apple s'est nul.
Il y a plusieurs comptes comme ça.
Si Apple c'est nul, pourquoi vous venez sur ce site ?....
Ben Apple se comporte depuis 2012 comme Microsoft sous le regne de Gates: obsolescence programmée a tous les etages, des softs qui sont commercialisés en beta, des patch a n'en plus finir qui rajoutent autant de bug qu'ils en resolvent, des OS qui mettent a terre les machines avec des fonctions superflues et une non optimisation flagrante, une ergonomie qui n'est plus que l'ombre de ce qu'elle a ete, ça part dans tous les sens sauf celui de la demande du client...
Et on ne parle meme pas du materiel qui est completement decalé des besoins du marché : l'inutile Apple Watch et ses depenses pharaoniques en marketing, le Mac Pro 2013 mal conçu et mal realisé, le Macbook un netbook archaique ultralimité et hors de prix, le MacMini qui regresse a chaque "mise a jour" depuis 2012, l'iMac sous dimensionné et toujours aussi peu ergonomique,...
Ce sont la des constatations inevitables et qui sont amere pour des gens comme moi qui sont clients d'Apple depuis plus de 20 ans... J'ai orienté mes relations et interloccuteurs, dans les secteurs pro ou privé, vers les solutions Apple pendant des annees parce que c'etait pragmatique et je n'ai jamais eu autres choses que des remerciements. Aujourd'hui je ne peux plus conseiller Apple a quiconque, je conseille a ceux qui ont de l'Apple de faire durer et a ceux qui doivent acheter, c'est Window, Linux ou Chromebook... pas que ces solutions soient devenues meilleures qu'Apple mais Apple est devenu pire.
En même temps la bonne pratique pour les noms de fichiers destinés à se retrouver sur un site web c'est pas de caractères accentués, pas de majuscules, pas de caractères spéciaux ni d'espaces.
pas de caractères accentués, pas de majuscules, pas de caractères spéciaux, pas d'espace, pas de culture, pas de spécificité, pas de sel, pas de sucre, pas d'épice, pas de gluten, uniquement le collectif BORG.
-
oui c'est aussi ce que je conseille comme bonne pratique aux webmasters et secrétariats mais c'est TRISTE !
Et il est grand temps de sortir l'informatique de la domination de l'anglais (même si j'adore lire du Tolkien et du Dunsany).
Triste, mais comme toi, j'en suis encore à ce genre de conseils, autant pour moi que pour… bah, les autres petit à petit, je commence à m'en taper, donc bon, au final, j'ai plus trop le problème sur mes sites ;)
@oomu :
J'ai fait ça pendant longtemps, pas d'accentuation, des noms de 8 caractères maximum (merci les vieilles habitudes pourries des systèmes DOS antédiluviens). Hé puis un jour j'en ai eu raz le bol d'écrire des noms de fichiers illisibles, retours au français, à ma langue. Pas mon problème si ça ne marche pas, démerdez vous les informaticiens. Je fais mon job, faites le votre.
@ Philactere : « Hé puis un jour j'en ai eu raz le bol d'écrire des noms de fichiers illisibles, retours au français, à ma langue. »
Tout à fait. Si on a choisi d'utiliser un Mac, ce n'est pas pour avoir des noms de fichiers façon MS-DOS (déjà qu'à cause des systèmes inférieurs qui ont envahi le monde, on est obligé de se frapper les extensions de noms de fichiers pour indiquer leur type…).
Ouaip... J'ai eu un mal de chien il y a quelque temps pour arriver à obtenir un visa pour les USA sur le site de l'ambassade US en France. Warum ? Parce que j'habite "Résidence des xxx". Adresse qui m'envoyait systématiquement aux pelotes. J'ai fini par me dire "Ah oui, scrongneugneu, l'ambassade US en France ne doit pas savoir que l'on a des caractères accentués". J'ai tapé "Residence" au lieu de "Résidence" et zou, c'est passé.
Y a des coups de pied au luc qui se perdent...
Autant le problème est compréhensible sur le nom d'un fichier, autant il est innacceptable dans un formuliare, bon, en même temps on parle de l'embassade US hein ! :P
Les USA ne connaissent que l'ascii, sans accent, sans diacritique, sans.... pas parce que l'anglais est la langue officielle (y a pas de langue officielle aux USA) mais parce qu'ils ne veulent reconnaitre que ça. Heureusement avec l'espagnol qui devient progressivement la langue la plus parlée ils vont bien devoir passer a un moment a l'unicode...
@MaamuT
«Autant le problème est compréhensible sur le nom d'un fichier»
Ben non, ce n'est ni comprehensible ni excusable. Le Mac a ete la machine qui a ete une des premiere a permettre la gestion simple et standard des langues non romanes et le systeme de fichier d'Apple a ete un des plus rapide - au niveau commercial - a faire sauter la limitation des caracteres utilisables en longueur et en signes...
Je voulais surtout relever le foutage de gueule de compèt du formulaire où là, aucune excuse ne tiens la route.
Quant aux noms de fichiers… que dire, pour ma part, je renomme toujours avant envoi… après, ne pas oublier que c'est du WordPress aussi, donc bon, faut pas attendre du bon non plus… hm !
Oui, enfin... Le comble c'est que le nom de fichier provient d'une capture d'écran réalisée avec un OSX en français...
Moi qui ne poste que des photographies anciennes en noir et blanc sur ma page FaceBook, j'ai du abandonner Safari à cause de ce problème.
Mes photos n'apparaissaient pas sur ma page version Safari, j'ai du me rabattre sur Chrome qui lui, ne pose aucun problème.
Ce problème existe depuis au moins 6, 8 mois et concerne pratiquement 60% des photos postées.
Quel est le rapport entre les photo ancienne et le bug du nom des fichier?
justement, j'en ai aucune idée !!
Mais ce prob est assez récent et personne n'a pu me répondre ou trouver une solution !
Ce qui me parait bizarre, c'est que tout fonctionnait bien il y a encore quelque mois.
Et je pense pas que le nom de mes fichiers photos ait évolué.
Je ne suis pas un grand amateur de Safari (Je ne l'utilise jamais ;) et je sais qu'on est à l'heure des internet 2.0, Mais franchement a t'on idée de mettre une photo sur le web avec un nom pareil ??
(Capture d’écran 2016-08-02 à 19.06.53.png )
Des espaces, des accents, et des points partout !!
@Grug :
Totalement d'accord... Quel idée de laisser un nom pareil....
@ Grug & mat 1696 : À part son côté non-informatif quant au contenu de l'image, il n'a rien de choquant, ce nom de fichier.
@ être
Bien sur que si il est choquant, le format officiel en France pour la date c'est «jour/mois/année» ou plus rarement «jour-mois-année» !
Le «.» n'est pas le séparateur normal des dates
Et pour les heures le format c'est «heure(24):minutes:secondes»
Le plus drôle aux USA c'est que le format civil officiel c'est «mois/jour/année» (année sur 4 chiffres) suivi par le plus international et cohérent «année-mois-jour» pour les secteurs militaires, academiques, scientifiques, industriels,...
Mais bon les USA sont aussi en systeme métrique officiellement, mais la population utilise le systeme impériale anglais, peut etre par nostalgie...
Voilà, quand je parlais de renommage, je met toujours un AAAAMMJJXX-nom-du-ficher.ext ou XX est l'incrément différentiel en cas de multiples publications pour le même jour.
Jamais eu de blème nulle part.&
@ C1rc3@0rc : « Bien sur que si il est choquant »
Non. Il n'a rien de choquant en tant que nom de fichier, ce qui est ce que je disais.
Ce dont tu parles n'a rien à voir avec cette question et ne concerne que le choix pas très heureux des formats de dates retenus pour nommer les captures d'écran dans Mac OS.
Notons que pour la partie date, il n'y rien d'absurde à avoir choisi le format ISO 8601 (qui, contrairement à ce que tu sembles affirmer dans ton commentaire, ne contient pas de « . » comme séparateur). C'est un format international et à la composition assez logique (contrairement à l'horrible format utilisé aux US).
Moi aussi, je préfèrerais une date en jj/mm/aaaa, mais l'usage du slash dans les noms de fichiers ne s'exporte pas bien au delà des frontières de Mac OS – là, pour le coup, WordPress, le serveur sur lequel il tourne, et les clients tournant sur les autres OS auraient eu beaucoup de mal avec un tel nom de fichier ! :-)
En revanche, concernant le format retenu pour l'heure, je suis bien d'accord qu'il n'y a aucune excuse à l'usage de ce bête point en tant que séparateur.
Titre sur la photo de l'illustration (qui doit remonter aux années 1950 quand même…):
«Main Characters in Trial»
Hmmm
"/sites/default/files/Capture d’écran 2016-08-02 à 19.06.53.png"
4 espaces
2 lettres accentuées
1 apostrophe
Ça ne marche pas non plus dans safari 5 (SNOW)
En copiant le nom de fichier sur un PNG chez moi, ça l'ouvre parfaitement dans le même safari.
Bizarre ?
Ce n'est pas un bug de Safari mais un bug de wordpress (entre autre). Les noms avec des accents sont mal encodé.
Les autres navigateurs quand ils ont le problème lance une deuxième requête au cas ou. C'est très facile à observer avec un Charles Proxy par exemple. Conséquence direct : on a deux fois plus d'appels réseaux.
Dans ce cas je pense que ici c'est Safari qui a raison et que Chrome Firefox et consort font plus de mal au web que de bien en proposant cette feature.
Essayez avec un navigateur un peu ancien et vous verrez vous aurez le même problème.
@ mhausherr : Merci pour cette explication.
@mhausherr :
Merci pour ces précisions ! ?
Cela me fait penser au problème similaire avec ownCloud sur OS X Server : les fichiers dont les noms comportes des caractères accentués ne sont pas affichés dans l'interface web, même s'ils sont toujours présents et intègres sur le volume de stockage. Mais là, on a pas le petit carré bleu avec le point d'interrogation ; on a rien du tout. ?
Pour mon édification personnelle, où est l'erreur d'encodage ? La page étant déclarée en utf-8, j'ai le droit d'utiliser des caractères accentués non ?
@ Ast2001 : « La page étant déclarée en utf-8, j'ai le droit d'utiliser des caractères accentués non ? »
La subtilité, c'est qu'avec Unicode (donc en UTF-8 ou tout autre encodage d'Unicode), il y a caractère accentué et caractère accentué. :-)
Plus précisément, il y a les caractères pré-composés (incluant l'accent), tels qu'on les connaissait dans les vieux jeux de caractères, et il y a aussi des accents pouvant se combiner aux caractères non accentués. Du coup, pour afficher « é », on a le choix entre coder ça sur un caractère (« é ») ou sur deux (« e + ´ »).
Une fonction de comparaison de chaînes de caractères devrait toujours, sauf cas très spécial, considérer ces deux approches comme étant synonymes. Mais ce n'est malheureusement pas le cas partout. On peut facilement, sur la plupart des Linux (ainsi, me semble-t-il, que sur Windows), créer deux fichiers aux noms visuellement (et sémantiquement) identiques, mais considérés comme différents par le système de fichiers (c'est stupide, oui, mais apparemment ça ne choque pas grand monde).
Il semble que le cas présent soit lié à un problème de ce genre, avec un nom de fichier encodé d'une façon dans le code HTML et de l'autre façon sur le disque du serveur. Du coup, une requête faite avec le nom indiqué par le HTML ne permet pas de récupérer le fichier.
D'après ce que nous a dit mhausherr, les autres navigateurs compensent ça en faisant, en cas d'erreur, une deuxième requête avec le nom de fichier encodé différemment.
Au passage, je ne suis pas d'accord avec sa conclusion comme quoi ce n'est pas une bonne idée de faire ça, car il est bien plus facile d'inclure ce comportement dans tous les navigateurs que d'espérer que les développeurs de sites web, de WordPress, d'Apache et de Linux réunis se mettent tous à utiliser correctement Unicode. :-)
Même coder correctement un navigateur ils savent pas faire.
Incompétents notoires
"Même coder correctement un navigateur ils savent pas faire.
Incompétents notoires"
Dixit le gars incapable de lire les quelques commentaires postés avant le sien. ?
Toujours la faute des autres, jamais d'Apple, oui, on sait.
Le fameux bug du tiers qui n'affecte qu'un seul navigateur.
Là on est quand même dans le cas trop fameux du couple WordPress + PEBKAC… hm !
@ TmrFromNO
Le problème c'est que l'URL en question n'est pas valide (cf. mon commentaire plus loin).
Et les différents navigateurs gèrent différemment les choses invalides...
Quel rapport avec les noms complexes ? L'article ne l'explique pas
Peut-être que la raison est que cette URL ne respecte pas les normes ?
En effet elle contient une apostrophe et un accent:
http://www.slate.fr/sites/default/files/Capture%20d’écran%202016-08-02%20à%2019.06.53.png
D'ailleurs, comme vous le voyez cela perturbe aussi le code de reconnaissance d'URLs de macg.
RFC 3986 _ Uniform Resource Identifier
When a new URI scheme defines a component that represents textual data consisting of characters from the Universal Character Set [UCS], the data should first be encoded as octets according to the UTF-8 character encoding [STD63]; then only those octets that do not correspond to characters in the unreserved set should be percent-encoded.
For example, the character A would be represented as "A", the character LATIN CAPITAL LETTER A WITH GRAVE would be represented as "%C3%80", and the character KATAKANA LETTER A would be represented as "%E3%82%A2".
Et si c'est WordPress qui a généré cette URL invalide, c'est WordPress qui est responsable du problème.
En attendant, il y a une solution simple : Eviter d'utiliser des caractères non ASCII dans les noms de fichiers. Mais cela demande un petit, tout petit effort de la part de la personne chargée d'entrer les données. C'est trop fatiguant je suppose. Le pire, c'est qu'aucun système n'utilise ce genre de caractère quand il génère un nom. Là, c'est le rédacteur ou l'auteur de l'image qui a cru que ce serait plus cool de se foutre des contingences techniques et d'utiliser un beau nom respectant la grammaire et l'orthographe à la lettre. Ou bien peut-être sont-ils juste ignorants. Mais s'ils le restent après avoir constaté le problème, que dire...
@ marc_os : « Le pire, c'est qu'aucun système n'utilise ce genre de caractère quand il génère un nom. »
Euh… si : Mac OS. Le nom de ce fichier est celui donné par le système de capture d'écran de Mac OS. Le rédacteur ne l'a pas modifié (ce qu'il aurait du faire, au moins pour que le nom soit plus informatif).
@ BeePotato
J'utilise toujours des systèmes en anglais...
Chez moi ça donne ça:
Screen Shot 2014-07-17 at 19.14.43.png
Ce qui me fait voir que le gugus n'a même pas converti l'image en JPEG. Je l'ai fait. Vu la qualité de l'image, une compression à 60% est largement suffisante. Avec GraphicConverter ça donne un fichier de 86Ko contre 526Ko pour le fichier PNG d'origine !
S'il n'en avait pas rien à faire du poids des média et des questions de temps de chargement chez les lecteurs ne disposant pas d'une bonne connexion, l'auteur aurait converti son image. Et il aurait pu en profiter pour virer les accents et autres apostrophes.
@ marc_os : « J'utilise toujours des systèmes en anglais... »
C’est bien.
Mais maintenant, tu sauras que pour ceux qui préfèrent que leur OS leur parle français, il existe bel et bien des systèmes qui « utilisent ce genre de caractère quand ils génèrent un nom ». ;-)
Pour le reste, je suis d’accord au sujet des efforts qui auraient dû être faits lors de la mise en ligne de cette image – à part qu’il n’y a pas de raison de s’interdire les accents lors du renommage, si je nouveau nom en contient.
C'est vrai que ça ne choque pas que mac OS génère des noms de fichiers avec apostrophes et espaces et c'est ce qu'il faut faire avec la version française de mac OS.
Mais les remarques de marc_os sont très pertinentes : une URI ça n'est pas un nom de fichier.
Dans l'un il peut y avoir ces caractères spéciaux, dans l'autre non.
C'est ce que j'ai toujours appris depuis 20 ans en tant que développeur web.
Par contre je ne crois pas que le souci vienne uniquement de word press : j'ai essayé de renommer une image de mon serveur avec le nom fautif (avec apostrophes, accents et espaces, non encodé) et ça ne fonctionne pas non plus.
@pecos, justement ça a changé en 20 ans, maintenant tous les caractères nationaux sont autorisés dans les URI, même l'arabe ou le japonais.
C'etait une forte demande qui a été entendue. Cet article de 2010 est le premier listé sur google lors d'une recherche : http://www.numerama.com/magazine/15677-les-url-peuvent-maintenant-s-ecrire-integralement-en-caracteres-arabes.html
On a droit aux accents dans les URI depuis 6 ans...
@ Chriscatfr : « On a droit aux accents dans les URI depuis 6 ans... »
Si je ne m’abuse, ce changement ne concerne que les noms de domaines, et non le reste d’une URL.
Pages