7
votes

Pourquoi Jquery.parsjson () ne fonctionne-t-il pas sur tous les serveurs?

hé là-bas, j'ai un script de contact arabe qui utilise ajax pour récupérer une réponse du serveur après avoir rempli le formulaire.

sur certains serveurs Apache, jquery.parsjson () code> jette un JSON invalide CODE> EXCEPION pour le même JSON Il analyse parfaitement sur d'autres serveurs. Cette exception n'est lancée que sur chrome et c'est-à-dire. P>

Le contenu JSON est codé à l'aide de la fonction JSON_ENCODE () CODE> PHP. J'ai essayé d'envoyer la bonne en-tête avec les données JSON et de définir l'UNICODE sur UTF-8, mais cela n'a pas aidé. P>

C'est l'une des réponses JSON que j'essaie d'analyser (supprimé la deuxième partie de Si parce que c'est long): p>

{"pagetitle": "\ u0623 \ u0644 \ u0627 \ u0644 \ u0625 \ u0644 \ u0625 \ u0631 \ u0633 \ u0627 \ u0633 \ u0627 \ u0644!" } code> p>

note em>: Ce langage de ces données est l'arabe, c'est pourquoi il ressemble à ceci après avoir été analysé avec PHP 'code> json_encode () code> . P>

Vous pouvez essayer de faire une demande dans les exemples donnés et examinez les données de réponse complètes à l'aide des outils de développeur Firebug ou WebKit. La réponse passe jsonlint ! P>

Enfin, j'ai deux URL utilisant la même version de la même version du Script, essayez de les parcourir en utilisant Chrome ou IE pour voir l'erreur dans l'exemple brisé. P>

L'exemple de travail strong>: http://nameodg.com/n/ p>

L'exemple cassé fort>: http://www.mt-is.co.cc/my/call-me/ P >

mis à jour: strong> Pour clarifier davantage, je voudrais noter que je m'intamé pour résoudre ce problème en utilisant l'ancien eval () code> pour analyser le contenu, j'ai publié un autre Version avec ce correctif, c'était comme ceci: p>

// Parse the JSON data
try
{
    // Use jquery's default parser
    data = $.parseJSON(data);
}
catch(e)
{
    /*
     * Fix a bug where strange unicode chars in the json data makes the jQuery
     * parseJSON() throw an error (only on some servers), by using the old eval() - slower though!
     */
    data = eval( "(" + data + ")" );
}


2 commentaires

Je ne trouve aucune occurrence d'Eval ou de Parsejson dans l'un ni l'autre exemple. Pouvez-vous nous donner un indice à l'emplacement où le Json est analysé? Aussi, votre exemple analyse bien avec JQuery.Parse en chrome


J'ai publié une autre version 1.3.1 qui utilise le eval () , vous pouvez le voir ici: Namodg .com / Essayez (c'est sous la méthode envoyer dans namodg.main.js). Parsejson est utilisé automatiquement lorsque $. Ajax DataType est défini sur JSON .


3 Réponses :


1
votes

Vous devriez essayer d'utiliser JSON2.JS (c'est sur https://github.com/douglascrockford/json- JS )

Même John Resig (Créateur de JQuery) dit que vous devriez:

Cette version de JSON.JS est fortement recommandée. Si vous utilisez toujours l'ancienne version, veuillez vous mettre à niveau (celui-ci, sans aucun doute, causer moins de problèmes que le précédent).

http://ejohn.org/blog/the-state-of-json /


2 commentaires

Merci d'avoir pointé cet analyseur, mais pourquoi l'équipe JQuery n'a-t-elle pas utilisé cette nouvelle API au lieu de leur propre?


Je ne peux pas comprendre quelle version de jQuery il a été incluse, mais probablement pas 1.3.1 car il y a un billet bugs.jquery.com/ticket/4990 pour l'obtenir inclus int 1.3.2.



0
votes

Je ne vois rien de liés à Parsejson ()

La seule différence que je vois est que, dans l'exemple de travail, une session-cookie est définie (suppose qu'il est nécessaire pour le "captcha", le calcul mathématique), dans l'autre exemple de Session-Cookie est défini. Donc, peut-être que la comparaison du résultat de calcul échoue sans le cookie de session.


1 commentaires

La réponse de CAPTCHA se situe dans un champ caché crypté à l'aide d'une clé. Il ne nécessite donc pas la session du tout. Les en-têtes de réponses des serveurs sont presque identiques, mais on brise la méthode Parsejson !



6
votes

trouvé le problème! Il était très difficile de remarquer, mais j'ai vu quelque chose drôle de cette attelle d'ouverture ... Il semblait y avoir deux petits points près de ce. J'ai utilisé ce bookmarklet JavaScript pour savoir ce qu'il était: XXX

J'ai la page de résultats . Devinez quel est le problème! Il existe un caractère invisible, répété deux fois réellement, au début de votre sortie. L'espace non-casseur de largeur zéro est également appelé la marque d'ordre d'octet de l'octet d'océan de l'unicode (BOM) . C'est la raison pour laquelle JQuery rejetant votre JSON autrement valide et pourquoi contempler le JSON dans Jsonlint fonctionne mystérieusement (en fonction de la façon dont vous le faites).

Un moyen d'obtenir ce caractère indésirable dans votre sortie est de sauvegarder Vos fichiers PHP à l'aide de Windows Notepad en mode UTF-8! Si tel est ce que vous faites, obtenez un autre éditeur de texte tel que Notepad ++ . Récupérez tous vos fichiers PHP sans la nomenclature pour résoudre votre problème.

Étape 1: Configurez le bloc-notes ++ pour encoder des fichiers dans UTF-8 sans bom par défaut. utf-8 sans réglage de la nomenclature dans un nouvel onglet Document des préférences

Étape 2 : Ouvrez chaque fichier PHP existant, modifiez le réglage de codage et la resouez-la. codage ... Encodage ... Encode UTF-8 sans bom


1 commentaires

Monsieur, je ne peux pas vous remercier assez. J'ai eu toutes sortes de problèmes à cause de la naissance, mais je m'assure toujours que je sauvegarder mes fichiers sans bom. Ce qui s'est passé, c'est que le gars qui a le serveur brisé a sauvé le fichier avec le mauvais encodage après avoir modifié le fichier de configuration. J'aurai encore besoin d'utiliser la correction eval () pour les utilisateurs qui feront la même erreur, mais au moins je sais maintenant la cause du problème. :)