Je cherche à résoudre un problème étrange dans une installation non-dockerisée (je réalise que le support pour ce type d’installation est limité/inexistant, donc je cherche juste quelques pistes sur ce qui pourrait clocher ici - notre équipe de packaging interne a utilisé les instructions de ‘build développeur’ pour comprendre comment construire les paquets nécessaires). J’ai pu confirmer que le problème est spécifique à la façon dont nous avons installé - mon équipe d’infrastructure ne souhaite pas utiliser une installation dockerisée (ils préfèrent tout construire eux-mêmes), donc j’exécute des instances sandbox qui sont dockerisées et non-dockerisées avec une copie de notre base de données afin de vérifier où se situe un problème, et c’est définitivement un artefact de la façon dont nous avons installé notre configuration.
En passant de la version 3.3.2 à 3.3.3, certains de nos membres du personnel du forum non-anglophones ont remarqué que le texte “à propos” des sections utilisant des caractères accentués n’est pas correctement encodé :
Fait intéressant, nous pouvons voir que le titre ainsi que tout le reste du texte est correctement encodé. En fait, le message lui-même utilisé pour le message “à propos” est correctement encodé :
J’ai confirmé qu’il s’agissait du même texte en le modifiant et en voyant le changement sur la page des catégories.
C’est donc quelque chose de spécifique au rendu de ce texte sur la page des catégories.
En regardant document.characterSet dans mon navigateur, il est correctement identifié comme UTF-8. La base de données affiche également le format comme UTF-8.
Je me demande si quelqu’un peut m’indiquer ce qui est différent dans la façon dont ce texte est rendu sur la page des catégories. Ma supposition est qu’il s’agit d’un paquet ruby qui n’est pas correctement construit (manque de support UTF-8 peut-être) qui est utilisé pour rendre ce texte mais pas d’autres textes sur le système, ou quelque chose qui traite le texte du message “à propos” et le tronque (ce qui est le cas ici, comme je l’ai noté ; cependant, nous avons aussi un lien vers un forum français externe qui est un message non tronqué, mais je suppose qu’il est toujours évalué par le même code).
Merci pour toute piste. Je suis un peu perplexe ici.
Extraire un fichier categories.json brut montre que ce n’est faux que dans l’extrait :
"description": "Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüística castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).",
"description_text": "Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüística castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).",
"description_excerpt": "Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüÃstica castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).",
Créer la même catégorie sur try.discourse.org et vérifier categories.json donne le résultat correct :
"description": "Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüística castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).",
"description_text": "Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüística castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).",
"description_excerpt": "Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüística castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).",
Je ne suis pas sûr de quelle serait la prochaine étape pour traquer cela sur votre installation, mais peut-être que se concentrer sur le chemin de code qui génère l’extrait aidera, ainsi que de savoir que cela est survenu parce que quelque chose interprétait l’encodage UTF-8 comme iso-8859-1.
Oui, c’est mon hypothèse - quoi que ce soit qui génère l’extrait est probablement le bon endroit. Je ne suis juste pas sûr où c’est dans le code lui-même. Mais savoir qu’il faut chercher le terme « excerpt » est certainement utile - merci !
Il m’a semblé que cela arrivait en iso-8859-1 à un moment donné, donc j’apprécie cette confirmation également (je n’étais pas sûr à 100% que c’était le mauvais encodage que je voyais, mais cela semblait correct).
Ce que vous avez vu sur try.discourse.org est ce que j’ai vu dans mon installation dockerisée également (enfin, le résultat final de l’encodage correct )
○ → ipython3
In [1]: 'Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüística castellana
...: , de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualq
...: uiera de las variedades latinoamericanas, etc.).'.encode('utf-8').decode('iso-8859-1')
Out[1]: 'Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüÃ\xadstica castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).'
Mon hypothèse est que quelque chose effectue une sorte de mise en cache. Ce n’est pas d’une grande aide, mais c’est ce que j’essaierais de rechercher.
À moins qu’ils ne détestent Docker, ils peuvent construire leurs propres images avec discourse_docker. Ensuite, ils pourront voir exactement ce qui se passe et n’auront pas à faire confiance aux images de quelqu’un d’autre.
Je pensais que c’était peut-être le cas, mais changer le message a entraîné une mise à jour, donc je ne pense pas que ce soit une mise en cache - c’est quelque chose qui est mal encodé.
J’ai suggéré quelques options, mais au final, l’équipe d’infrastructure a choisi de se contenter de paquets construits à l’aide du service de construction. Je ne pense pas qu’il s’agisse d’une question de “nous détestons Docker” (bien que podman serait probablement plus susceptible de ce qu’ils voudraient utiliser), mais plutôt d’une manière d’utiliser les outils de gestion de la configuration qu’ils utilisent pour tout gérer de la même manière. Avoir un cas unique qui utilise Docker/podman ajouterait d’autres complexités à l’utilisation de la configuration CI/CD qu’ils utilisent (du moins, c’est ce que je comprends).
Donc, finalement, j’ai configuré mes deux bacs à sable pour pouvoir déterminer d’où proviennent les problèmes afin de pouvoir les signaler au bon endroit ; malheureusement, cela signifie que lorsqu’il s’agit de quelque chose dans la façon dont nous avons construit les choses, je dois rechercher ce que nous faisons différemment d’une installation standard basée sur Docker afin de pouvoir le corriger.
Je comprends qu’ils pensent que la manière Discourse est folle et qu’ils veulent vraiment que tout soit géré sous un système unifié.
Mais. Le dernier client que j’ai eu qui a insisté pour utiliser ses outils préférés m’a payé près de 20 heures de travail pour obtenir une sauvegarde utilisable afin de migrer vers l’hébergement discourse.org. Le précédent a payé encore plus cher pour ajuster sa configuration personnalisée afin d’éviter que son site ne plante plusieurs fois par semaine, puis un an plus tard, il m’a encore payé plus cher pour le migrer vers l’hébergement discourse.org.
J’apprécie le conseil. La bonne nouvelle est que les sauvegardes de notre système de production fonctionnent parfaitement dans une installation dockerisée (je l’ai testé), donc si/quand ils décideront qu’utiliser une installation basée sur Docker est la bonne approche, nous serons en bonne posture. Nous avons beaucoup de données (migrées de vBulletin il y a quelques années vers Discourse), et en général, les choses ont plutôt bien fonctionné, avec quelques ratés étranges par-ci par-là.
Par conséquent, nous avons beaucoup appris sur le fonctionnement de Discourse, donc ce n’est pas une mauvaise chose dans l’ensemble.
Il semble que /categories.json soit un point d’API plutôt qu’un fichier statique qui est créé puis lu, donc je pense que cela limite le problème au ruby ou au javascript. J’ai trouvé où se trouve le schéma pour ce point d’API, mais n’étant pas particulièrement familier avec le ruby (j’ai accumulé beaucoup d’expérience en langages de programmation au fil des ans, donc lire la plupart des langages ne me pose pas de problème même si je ne peux pas coder dedans - je peux facilement en saisir l’essentiel), il semble que le javascript soit principalement exécuté dans le navigateur, et le ruby sur le serveur (bien que je note que nodejs est également installé, donc cette généralisation pourrait ne pas être tout à fait exacte).
Si je peux trouver la fonction qui traite /categories (car il semble que .json à la fin indique simplement au code comment formater la sortie ; je vois un comportement similaire dans /top par rapport à /top.rss, par exemple), cela devrait me permettre de cerner où je dois chercher dans le code, et cela me dira quels gems ruby (je suis presque certain que ce sera du code ruby) doivent être vérifiés pour s’assurer qu’ils sont correctement construits.
Il semble que ce soit quelque chose de spécifique aux fonctions d’extraction - je viens de remarquer que cela se produit également sur nos pages de résultats de recherche :
Ce que j’ai moi-même cité dans une réponse à un utilisateur (panorain). Je suis tombé dessus par accident, car en essayant de regarder mon activité, j’obtiens une erreur serveur 500, et la sortie de /logs montre une erreur d’exécution « la chaîne d’entrée ne peut pas être vide » dans lib/excerpt_parser.rb.
Il semble que quelques éléments ramènent à quelque chose dans le traitement des extraits, mais uniquement dans les installations de type développement.
Dans mon installation basée sur Docker, je peux effectivement consulter mon activité sans erreur ; étrangement, cependant, la base de données de cette installation est restaurée à partir d’une sauvegarde récente d’un serveur de production - où le problème existe.
Il semble que nous ayons mis à niveau nokogiri vers la version 1.17.2, et je vois que la version Dockerisée est la 1.16.7 - je soupçonne que c’est la cause de ce problème. Je vais essayer de revenir sur cette mise à jour (et tout le reste qui a été mis à jour en même temps).
J’ai donc rétrogradé notre package pour réutiliser nokogiri 1.16. Ce que je ne comprends pas. Chaque fois que je mets à jour une gemme pour réduire les emballages dupliqués, je vérifie s’il y a eu des changements connexes dans main, il n’y en a pas eu. Sauf si j’ai manqué quelque chose
"description": "Witaj w polskiej sekcji społeczności openSUSE!",
"description_text": "Witaj w polskiej sekcji społeczności openSUSE!",
"description_excerpt": "Witaj w polskiej sekcji społeczności openSUSE!",
comme vous pouvez le voir, nous avons le bon texte deux fois, ce n’est que lorsqu’il passe par PrettyText.excerpt qu’il est cassé. Comment cela est-il géré dans main ?
@hendersj Je prépare déjà un package main afin que nous puissions le tester avec une copie de la base de données.
Une raison pour laquelle vous pensez cela ? UTF-8 est la valeur par défaut.
[1] pry(main)> Nokogiri::VERSION
=> "1.18.2"
[2] pry(main)> t = '<div>Witaj w polskiej sekcji społeczności openSUSE!</div>'
=> "<div>Witaj w polskiej sekcji społeczności openSUSE!</div>"
[3] pry(main)> Nokogiri.HTML5(t).to_s
=> "<html><head></head><body><div>Witaj w polskiej sekcji społeczności openSUSE!</div></body></html>"
[4] pry(main)> Nokogiri.HTML5(t, encoding: Encoding::UTF_8).to_s
=> "<html><head></head><body><div>Witaj w polskiej sekcji społeczności openSUSE!</div></body></html>"
[5] pry(main)> Nokogiri.HTML5(t).to_s == Nokogiri.HTML5(t, encoding: Encoding::UTF_8).to_s
=> true
La fonction retrieve_title est utilisée pour extraire les titres des URL externes (par exemple, Youtube) et bien que je ne sois pas très familier avec ce chemin de code, je serais surpris de constater que c’est la source de votre problème.
Si vous faites autre chose (par exemple, utiliser cette fonction dans un plugin personnalisé), le paramètre d’encodage provient de l’en-tête content-type de la ressource récupérée :
if !encoding && content_type = _response["content-type"]&.strip&.downcase
if content_type =~ /charset="?([a-z0-9_-]+)"?/
encoding = Regexp.last_match(1)
encoding = nil if !Encoding.list.map(&:name).map(&:downcase).include?(encoding)
end
end
max_size = max_chunk_size(uri) * 1024
title = extract_title(current, encoding)
on pourrait donc suspecter que le serveur web répondant signale un content-type incorrect.
car tous les autres appels dans ce correctif ont encoding: parameters spécifié.
seul celui dans retrieve title ne l’a pas. ce qui semble incohérent. et la mauvaise gestion de l’encodage UTF-8 était toute la discussion qui a mené à ce fil de discussion.
)