Sto cercando di individuare un problema strano in un’installazione non dockerizzata (mi rendo conto che il supporto per questo tipo di installazione è limitato/inesistente, quindi sto solo cercando alcuni suggerimenti su cosa potrebbe essere sbagliato qui - il nostro team di packaging interno ha utilizzato le istruzioni di build per sviluppatori per capire come costruire i pacchetti necessari). Sono riuscito a confermare che il problema è specifico del modo in cui abbiamo installato: il mio team di infrastruttura non è disposto a utilizzare un’installazione dockerizzata (preferiscono costruire tutto da soli), quindi gestisco istanze sandbox che sono dockerizzate e non dockerizzate con una copia del nostro database per verificare dove si trova un problema, e questo è decisamente un artefatto del modo in cui abbiamo installato la nostra configurazione.
Aggiornando da 3.3.2 a 3.3.3, alcuni dei nostri staff del forum non anglofoni hanno notato che il testo “about” per le sezioni che utilizzano caratteri accentati non è codificato correttamente:
È interessante notare che possiamo vedere che l’intestazione così come tutto il resto del testo è codificato correttamente. Infatti, il messaggio stesso utilizzato per il messaggio “about” è codificato correttamente:
Ho confermato che si tratta dello stesso testo modificandolo e vedendo la modifica nella pagina delle categorie.
Quindi è qualcosa di specifico per il rendering di quel testo nella pagina delle categorie.
Guardando document.characterSet nel mio browser, è correttamente identificato come UTF-8. Anche il database mostra il formato come UTF-8.
Mi chiedo se qualcuno possa indicarmi cosa c’è di diverso nel modo in cui questo testo viene visualizzato nella pagina delle categorie. La mia ipotesi è che si tratti di un pacchetto ruby non correttamente compilato (forse manca il supporto UTF-8) che viene utilizzato per il rendering di quel testo ma non di altro testo nel sistema, o qualcosa che elabora il testo del messaggio “about” e lo tronca (cosa che ho notato essere il caso qui; tuttavia, abbiamo anche un link a un forum francese esterno che è un messaggio non troncato, ma immagino che sia comunque valutato dallo stesso codice).
Grazie per qualsiasi suggerimento. Sono un po’ perplesso.
Recuperando un file categories.json grezzo, si vede che è errato solo nell’estratto:
"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.).",
Creando la stessa categoria su try.discourse.org e controllando categories.json si ottiene il risultato corretto:
"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.).",
Non sono sicuro quale sia il prossimo passo per rintracciare questo problema sulla tua installazione, ma forse concentrarsi sul percorso del codice che genera l’estratto aiuterà, oltre a sapere che questo è sorto da qualcosa che interpreta la codifica UTF-8 come iso-8859-1.
Sì, è la mia ipotesi: qualunque cosa generi l’estratto è probabilmente il posto giusto. Non sono sicuro di dove sia nel codice. Ma sapere di cercare il termine “excerpt” è sicuramente utile, grazie!
Mi sembrava che stesse arrivando come iso-8859-1 a un certo punto, quindi apprezzo anche quella conferma (non ero sicuro al 100% che fosse la codifica errata che stavo vedendo, ma sembrava giusta).
Ciò che hai visto su try.discourse.org è ciò che ho visto anche nella mia installazione dockerizzata (beh, il risultato finale della codifica corretta )
○ → 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.).'
La mia ipotesi è che qualcosa stia facendo una sorta di caching. Non è di grande aiuto, ma è quello che proverei a cercare.
A meno che non odino Docker, possono creare le proprie immagini con discourse_docker. Quindi possono vedere esattamente cosa sta succedendo e non devono fidarsi delle immagini di nessun altro.
Pensavo potesse essere così, ma cambiare il messaggio ha comportato un aggiornamento, quindi non credo sia il caching: è qualcosa che viene codificato in modo errato.
Ho suggerito alcune opzioni, ma alla fine il team dell’infrastruttura ha optato per utilizzare pacchetti creati con il build service. Non credo che sia una questione di “odiamo Docker” (anche se podman sarebbe probabilmente più adatto a ciò che vorrebbero usare), ma piuttosto un modo per utilizzare gli strumenti di gestione della configurazione che stanno utilizzando per gestire tutto allo stesso modo. Avere un caso isolato che utilizza Docker/podman aggiungerebbe altre complessità all’uso della configurazione CI/CD che stanno utilizzando (o almeno così ho capito).
Quindi, in definitiva, ho impostato le mie due sandbox per poter determinare dove affondano le radici dei problemi in modo da poterli segnalare al posto giusto; sfortunatamente, ciò significa che quando si tratta di qualcosa nel modo in cui abbiamo costruito le cose, devo inseguire ciò che stiamo facendo di diverso da un’installazione standard basata su Docker in modo da poterlo correggere.
Capisco come pensano che il modo Discourse sia folle e vogliano davvero che tutto sia gestito sotto un Sistema Unificato.
Ma. L’ultimo cliente che ho avuto che ha insistito nell’utilizzare i propri strumenti preferiti mi ha fatto pagare quasi 20 ore di lavoro per ottenere un backup utilizzabile per passare all’hosting di discourse.org. Quello precedente ha pagato molto di più per modificare la propria configurazione personalizzata per evitare che il proprio sito si bloccasse più volte alla settimana, e poi un anno dopo mi ha pagato ancora di più per spostarli all’hosting di discourse.org.
Apprezzo il consiglio. La buona notizia è che i backup del nostro sistema di produzione funzionano in un’installazione dockerizzata senza problemi (l’ho testato), quindi se/quando decideranno che utilizzare un’installazione basata su Docker è la strada giusta, saremo in buona forma. Abbiamo molti dati (migrati da vBulletin qualche anno fa a Discourse) e in generale le cose hanno funzionato abbastanza bene, con qualche intoppo occasionale qua e là.
Di conseguenza, abbiamo imparato molto su come funziona Discourse, quindi non è una cosa negativa nel complesso.
Sembra che /categories.json sia un endpoint API piuttosto che un file statico che viene creato e poi letto, quindi penso che questo limiti il problema a ruby o javascript. Ho trovato dove si trova lo schema per questo endpoint, ma non avendo molta familiarità con ruby (ho accumulato molta esperienza di linguaggi di programmazione nel corso degli anni, quindi leggere la maggior parte dei linguaggi non è un problema per me anche se non posso programmare in essi - riesco a cogliere il succo abbastanza facilmente), ma sembra che javascript venga eseguito principalmente nel browser e ruby venga eseguito sul server (anche se noto che è installato anche nodejs, quindi questa generalizzazione potrebbe non essere del tutto valida).
Se riesco a trovare la funzione che elabora /categories (poiché sembra che .json alla fine dica solo al codice come formattare l’output; vedo un comportamento simile in /top vs /top.rss, ad esempio), allora questo dovrebbe restringere dove devo guardare nel codice, e questo mi dirà quali gem ruby (sono abbastanza sicuro che sarà codice ruby) devono essere controllati per assicurarsi che siano stati compilati correttamente.
Che è qualcosa che ho citato io stesso in una risposta a un utente (panorain). Mi sono imbattuto in questo per errore, poiché cercando di guardare la mia attività, ricevo un errore del server 500 e l’output di /logs mostra un errore di runtime “la stringa di input non può essere vuota” in lib/excerpt_parser.rb.
Sembra che alcune cose riconducano a qualcosa nell’elaborazione delle estrazioni, ma solo nelle installazioni in stile di sviluppo.
Nella mia installazione basata su docker, posso effettivamente visualizzare la mia attività senza errori; stranamente, però, il database in quell’installazione viene ripristinato da un recente backup del server di produzione - dove esiste il problema.
Sembra che abbiamo aggiornato nokogiri a 1.17.2, e vedo che la versione Dockerizzata è 1.16.7 - sospetto che questa sia la causa del problema. Vedrò di annullare quell’aggiornamento (e qualsiasi altra cosa sia stata aggiornata nello stesso momento).
Quindi ho retrocesso il nostro pacchetto per utilizzare nuovamente nokogiri 1.16. Quello che non capisco. Ogni volta che aggiorno una gemma per ridurre il packaging duplicato, controllo se ci sono state modifiche correlate in main, non ce ne sono state. A meno che non mi sia sfuggito qualcosa
"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!",
come puoi vedere abbiamo il testo corretto due volte, solo quando passa attraverso PrettyText.excerpt si rompe. Come viene gestito in main?
@hendersj Sto già preparando un pacchetto main in modo da poterlo testare con una copia del DB.
C’è un motivo per cui pensi così? UTF-8 è l’impostazione predefinita.
[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 funzione retrieve_title viene utilizzata per estrarre i titoli da URL esterni (ad esempio Youtube) e, sebbene non abbia familiarità con questo percorso di codice, sarei sorpreso di scoprire che questa è la causa del tuo problema.
Se stai facendo qualcos’altro (ad esempio, utilizzando questa funzione in un plugin personalizzato), il parametro encoding proviene dall’intestazione content-type della risorsa recuperata:
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)
quindi si potrebbe sospettare che il server web che risponde stia segnalando un content-type errato.
perché tutte le altre chiamate in quella patch hanno encoding: parameters specificato.
solo quella in retrieve title no, il che sembra incoerente. e la gestione impropria della codifica UTF-8 è stata l’intera discussione che ha portato a questo thread.
)
