Pas du tout ! c'est de l'UTF-16 escapé ! La syntaxe \uNNNN en JSON indique un codet 16 bits. Le codage UTF-8 escapé serait \xNN\xNN si c'était codé en UTF-8 sur 2 octets. Si le point de code est hors du BMP, on aurait \U000NNNNN pour indiquer le point de code entier, ou \uDNNN\uDNNN pour coder les deux demi-codets 16 bits.
JSON en lui-même n'indique pas quel est le codage utilisé, il doit juste supporter l'ASCII pour sa propre syntaxe mais les données transportées (dans les chaines) peuvent être dans un codage arbitraire, y compris même ne pas être du texte; à la base il y a \xNN pour cela, et \uNNNN est une extension indiquant qu'on indique un codet 16 bits dont la conversion en 8-bits est dépendante des codages 8-bit et 16-bits supportés par l'application mais en général \uNNNN suppose que c'est de l'UTF-16 et que l'autre codage (utilisé par \xNN) est UTF-8. Mais JSON vient à l'origine de Javascript dont le codage natif interne est UTF-16 (mais le codage externe 8-bits n'est pas toujours UTF-8, il peut varier selon le protocole par exemple avec indication d'un media-type MIME avec HTTP). Sinon il n'est pas nécessaire d'utiliser cette syntaxe. Même pour les caractères ASCII faisant partie de la syntaxe JSON (sauts de lignes, guillemets, ou contrôles comme le nul) il est plus pratique et plus court d'utiliser \r, \n, \", \t. Il faut aussi savoir qu'au début OSM n'a pas toujours eu sa base de données codée en Unicode avec UTF-8 : il y a eu un début avec ISO8859-1 mais parfois du "mojibake" produit avec certains navigateurs webs russes ou est-européens sui utilisaient d'autres codages ISO8859-* ou pages de code Windows, et même du codage MacOS. Et on trouve encore dans la base de données des textes provenant d'éditeurs mal réglés qui envoient autre chose que de l'UTF-8 (le plus souvent du Windows-1252 mais on a encore des traces au Japon de textes codés en JIS!). La base OSM n'a jamais réellement forcé le codage, il aurait fallu filtrer massivement les données existantes et renforcer le protocole (mais cela aurait banni certains vieux éditeurs incompatibles). Encore aujourd'hui on peut envoyer du JIS ou un codage chinois GB ou coréen HKCS et rien ne s'y oppose. UTF-8 s'est juste imposé parce que les éditeurs actuels bien supportés s'y sont tous mis ! Mais je trouve encore des données envoyées par un vieux JOSM sur Mac qui envoient du MacRoman ! Et certains utilisent encore Potlatch-1 avec de vieux navigateurs web et de vielles versions de Flash qui ne gèrent pas correctement l'UTF-8 dans les données qu'ils manipulent dans Potlatch et qu'ils envoient ensuite au serveur... On en trouve même en France ! Le 29 mai 2016 à 20:25, Christian Quest <cqu...@openstreetmap.fr> a écrit : > C'est tout à fait normal en json... c'est de l'UTF-8 escapé. > > Le 29 mai 2016 à 14:19, JB <jb...@mailoo.org> a écrit : > >> Bonjour, >> >> Je n'ai pas vu passer cette question : Est-ce que c'est moi qui me >> débrouille mal, ou bien l'api de la Ban en reverse ne gère pas les >> caractères spéciaux ? >> >> Par exemple, pour la requête : >> http://api-adresse.data.gouv.fr/reverse/?lon=2.4441661&lat=48.7897578, >> j'ai la réponse : >> >> {"limit": 1, "attribution": "BAN", "version": "draft", "licence": "ODbL >> 1.0", "type": "FeatureCollection", "features": [{"geometry": {"type": >> "Point", "coordinates": [2.444308, 48.790001]}, "properties": {"street": >> "Rue Andr\u00e9 Maurois", "label": "2 Rue Andr\u00e9 Maurois 94000 >> Cr\u00e9teil", "distance": 28, "context": "94, Val-de-Marne, >> \u00cele-de-France", "id": "94028_0068_2f0620", "citycode": "94028", >> "name": "2 Rue Andr\u00e9 Maurois", "score": 0.9999996646758574, >> "postcode": "94000", "housenumber": "2", "city": "Cr\u00e9teil", "type": >> "housenumber"}, "type": "Feature"}]} >> >> avec les morceaux choisis : 2 Rue Andr\u00e9 Maurois 94000 Cr\u00e9teil. >> >> JB. >> >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > > > -- > Christian Quest - OpenStreetMap France > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
