Gentile Pietro,

i file HTML vengono salvati con il charset UTF8 in Evo 9, questo avviene per consentirti di scrivere i testi in qualsiasi lingua nella stessa pagina. Potresti gentilmente contattare il tuo provider e verificare che lui supporti questa tipologia di charset per cortesia?
Grazie Pietro.

certo che supporta Aruba server windows ultima generazione e come dire se in ameica conoscono la coca cola !!!!!!!!!!!!!!!!!

Hai avuto una risposta da Aruba? Potresti gentilmente contattarli e verificare? Attendo la tua conferma.

Nel frattempo potrei avere l'URL del tuo sito?

Ecco la risposta

Gentile cliente,il charset della pagina web può essere impostato da apposito tag nella pagina in questione; imposti il tag corretto nel codice della pagina web in cui intende mostrare il charset indicato. Contatti eventualmente un webmaster che la possa affiancare in tale gestione o posti in community.aruba.it dove altri webmaster Le potranno dare supporto. Restiamo a Sua disposizione.

Ti ringrazio per i dettagli.  Al momento staimo verificando la questione sul tuo sito http://www.capoverdelfimmobiliare.com/, appena possibile ti forniremo una soluzione.

QUESTO PROBLEMA SI PRESENTA CON TUTTI I SITI CHE HANNO HOSTING ARUBA SERVER WINDOWS POSSIAMO SENTIRCI IN PRIVATO?

GRAZIE

Ciao Pietro, ho letto la risposta di Aruba... ma mi sa che non hanno neanche guardato la tua pagina. Il tag relativo a UTF8 è specificato in tutte le pagine, quindi il problema non è quello! 

<meta charset="utf-8" />

all'ora qual'è il problema con la v8 tutto ok con la v9 è un caos, tutti i siti fanno lo stesso errore HOSTING ARUBA SERVER WINDOWS

Non facciamo uno scarica barile

GRAZIE

Ciao, è come ti ha indicato sopra Samantha.

La versione 8 salva i file in formato ANSI specificando il charset della lingua. Questo consente la visualizzazione delle pagine in una sola lingua.

La versione 9, invece, salva i file in formato UTF8 UNICODE specificando anche nel codice HTML il corretto tag (come dice Aruba). Questo consente di poter inserire nella stessa pagina qualsiasi lingua, anche russo e greco insieme!

Il server deve però essere in grado di vedere che le pagine sono in UTF8 e dichiararle in trasmissione. Questo deve essere verificato da Aruba, dato che il server è suo. Aruba ti ha detto che ci deve essere il tag nelle pagine HTML, ma questo c'è già... quindi non è la risposta corretta. Hai contattato loro per dirglielo e verificare quindi meglio le impostazioni del server?

Fammi sapere.

ok grazie ma su tutti i  siti è così e sono molti provate voi su rerver aruba windows e vedte cosa succede, è possibile che tutti i server siano impostati sbagliati ?

grazie

Questo lo può solo sapere Aruba e potrebbe essere, dato che tutti i tuoi siti sono su Aruba e sono su server Windows. Dovrebbe essere sufficiente che loro effettuino la dovuta modifica. Fammi sapere cosa ti dicono... 

OK HO FATTO PRESENTE CIAO

Ecco la nuova risposta di Aruba

Gentile cliente, non facciamo debug alle applicazioni, modifiche al server hosting o personalizzazioni specifiche; per quanto riguarda il coding del charset, se deve utilizzare il charset "charset iso-8859" il tag sarà:<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
Impostando il charset in questo modo, la codifica avviene:
http://www.carraraonline.com/blog/index_test.html
ovviamente vanno riviste le entità testuali etc. se utilizza software specifici (come Websitex) posti nelle apposite community dove altri utenti che usano lo stesso applicativo Le potranno dare informazioni a riguardo. Il server hosting non presenta alcun tipo di problema.

Sono un po' sorpreso.... dalla risposta sembra che se un utente deve pubblicare un sito in italiano e russo nella stessa pagina oppure in greco o giapponese o altre lingue che usano altri charset diversi da 8859, non può farlo!

Ho fatto una prova su uno spazio web su Aruba Windows (che non usiamo più): vedi tu ma penso che possa essere utile per l'assistenza Aruba http://www.incomedia.it/temp/test/

Fammi sapere! 

quindi cosa devo fare ?

si puo usare una variante x per chi usa questo server su questo hosting ?

Grazie

Ciao, direi che è certo che sia una questione di impostazione server e non di programma che crea le pagine HTML, su questo mi sembra che ci siamo capiti. Quindi non posso che suggerirti di farti risolvere il problema da Aruba, come evidenziato già da subito all'inizio di questo post. 

Cosa hanno risposto? Mi sembra (non sono sicuro) che altri avessero avuto lo stesso problema e che contattando il provider questo aveva risolto facilmente.

io continuo a non capire, avevo la v8 e tutto ok, perchè avete sostituite cose che funzionavano perfettamente  sostituendole con agg vari che creano problemi è evidente che nessun dei vostri clienti ha hostin windows.

Su aruba il motore interno del sito da questo errore, il blog da lo stesso errore, voi non potete fare nulla per loro funziona tutto ma il risultato non cambia.

Quando rilasciate nuovi agg prendete in considerazione i server di chi pubblica un sito?

Forse è meglio specificare che il software gira perfettamente su i vostri spazi web e segnalare i server dove creano problemi.

Certo è che resto ammareggiato pensavo di migliorare con la v9 e invece mi trovo in una serie di problematiche senza via di uscita.

Riporto l'ultimo messaggio assistenza aruba

Gentile cliente,come da contatto telefonico, di seguito la pagina di test dove viene risolto il problema del "?" del post dell'utente:http://www.carraraonline.com/blog/index_test.php?id=qv5
come potrà Lei stesso verificare, sarà da rivedere l'intero testo sopra il post. Le confermo che restiamo a Sua disposizione. 

Saluti

Da quello che ho capito, e da qualche test che ho eseguito, tu stai parlando dell'importazione di un blog realizzato con la 8 e convertito alla 9.

Se quello che ho capito è giusto, tutti i discorsi scritti qui, sono fesserie. Il problema deriva dal fatto che i commenti erano scritti utilizzando una codifica diversa da quella attuale che è l' utf-8 e per risolverlo è necessario convertire tutti i testi preesistenti alla nuova codifica e ... non c'entra niente il server, le varie codifiche sono supportate regolarmente e di default su quasi tutti i webserver.

Se, invece, non ho capito nulla del reale problema, allora le fesserie le ho dette io e me ne scuso.

fesserie o no il problema esiste anche facendo una ricerca interna al sito utilizzando il motore interno, parola cerca curiosità in allegato trovi il risultato.

Questo come lo spieghi

GRAZIE

Sempre che io abbia ben capito il problema specifico di "Pietro B.", ma indipendentemente da questo, il problema del blog esiste ed è dimostrato su:

http://www.unofficialwsx5.com/index.php?topic=456.0

ho visto il tuo esempio all'ora il problema esiste riporto la tua dicitura

pertanto occorrerebbe rimediare a questo pasticcio e quindi bisogna spezzare il file in due parti e convertire il primo pezzo da ANSI a UTF-8, riunire i due pezzi fino ad ottenere:

cosa consigli oltre a migrare su server linux?

Grazie, siete forti di la spesso vengo a rompere

Negativo.

Ho fatto un test su windows di aruba e funziona correttamente se il sito è realizzato direttamente con la 9 ed esportato completamente.

Il problema va analizzato meglio, ma l'answers non è il posto più adatto ... checchè ne dica icm .... tenderei ad escludere problemi di hosting .... diciamo al 99.99%

Se migri a linux, fai cosa buona e giusta, ma non risolvi il problema. La piattaforma non c'entra nulla, in questo caso.

Troppo buono ... 

Ciao Pietro, ripeto ancora quanto descritto sopra: 

Ho modificato il sito test metterdo il campo cerca e il blog con un commento, ecco i link:

Cerca -> http://www.incomedia.it/temp/test/imsearch.php?search=prova

Commento -> http://www.incomedia.it/temp/test/blog/?id=e812z4zo

Il server è Aruba Windows. 

Per verificare meglio ancora, prova a fare anche tu un mini progetto e caricarlo online. 

Se parti da un progetto realizzato con la versione 9 ed esporti, ovunque tu lo faccia, il sito funziona correttamente. Se invece siamo in presenza di dati inseriti con la versione 8 il problema viene fuori e dipende SOLO dalla variazione della codifica e richiede una conversione che non avete previsto, ma che è facilmente realizzabile in maniera autonoma ... a patto di sapere come fare. 

Grazie serzio FINALMENTE UNA PERSONA CHE AMETTE IL PROBLEMA SUI VECCHI MESSAGGI IMPORTATI DALLA V8 ALLA V9

IL PROBLEMA ESITE ALLO STESSO MODO USANDO IL MOTORE DI RICERCA NEL SITO TUTTE LE PAROLE CON GLI ACCENTI VENGONO RICERCARTE COSI à = ?

Incomedia ci 6 o lo fai ?

Non è questione di ammettere o negare. Ho publicato l'evidenza dei fatti, indicato il percorso per ricreare l'errore e  .... tra le righe, anche la soluzione. 

Ciao,

WSX5 ricrea sempre tutti i file HTML e PHP, quindi non cambia se il documento è stato creato da zero o convertito dalla 8. Come già detto WSX5 li ricrea con codifica UTF8. Il tuo server di Aruba forse salva i file su server in codifica ISO-8859-1 oppure esegue gli script PHP (come quello della ricerca) in codifica ISO-8859-1 e non come UTF8 come dichiarato, provocando tale problema.

Si potrebbe verificare una delle ipotesi scaricando via FTP uno dei file (es: imsearch.php o blog.inc.php). Se vuoi puoi allegarli qui come ZIP. 

La pagina che hai modificato tu non funziona, io vedono dei caratteri non corretti.

http://www.carraraonline.com/blog/index_test.php?id=qv5

Hai modificato il meta mettendolo come ISO-8859-1. Infatti per vederla correttamente ho dovuto forzare da Firefox la visualizzazione come UTF8.

Grazie.

No, Steve, non ti confondere, quello che hai detto non è completamente vero. La codifica non vale solo in fase di visualizzazione ma anche e soprattutto sulla scrittura su disco.

Apri un documento vuoto con l'eccellente notepad++, imposta la codifica in ANSI e scrivi qualcosa.

Apri un'altra volta un documento vuoto, imposta la codifica ad UTF-8, scrivi la stessa cosa e salva con un nome diverso.

Se confronti i due file ti accorgi che sono, ovviamente, diversi. Il codice in php che effettua i salvataggi non scrive in ASCII ma seguendo la codifica che avete impostato da progetto. Quindi in un caso ISO-8859-1 e nell'altro in UTF-8.

Tanto per chiarire, una "à" in unicode UTF-8 è codificata su disco con 0x00E0 mentre in ISO-8859-1 diventa 0xE0 ... ma la prima codifica la leggi in iso ottieni due caratteri diversi, un NUL (che ti incasina l'output) seguito da una "à" che non vedrai correttamente a causa del NUL precedente, due cose ben diverse ma che a prima vista sembrano uguali poichè spesso il software che utilizzi per la lettura del file è in grado di riconoscere il charset ed impostarsi correttamente. 

Hai letto il link che ti ho riportato?

Dai uno sguardo anche su

http://www.utoronto.ca/web/HTMLdocs/NewHTML/iso_table.html

Ciao Serzio, non dovrebbe dipendere da questo. Ad ogni modo per velocizzare la cosa evitando di discutere sulle ns teorie, sarebbe più utile testare il tutto.

Se Pietro mi manda il suo file IWP realizzato con la v8 posso verificare direttamente per capire cosa ha fatto. Se non fosse sufficiente allora si potrebbe anche verificare direttamente accedendo al server via FTP. 

@Pietro: se non volessi allegare in questo post pubblico il tuo progetto, apri un post privato, fai uno ZIP del file IWP e allegalo.

Rimango in attesa del materiale richiesto. Posterò ovviamente qui eventuali sviluppi. Grazie.

Sempre che io abbia capito il reale problema e che quindi si tratti di una importazione del progetto da v8 a v9 riferito al blog di cui ho letto i riferimenti in qualche post, devo precisare che io NON ritengo che il problema sia di evo8 o 9 che sia, ma dal fatto che ci sono dei dati (i commenti e forse qualche pagina preesistente) realizzati tramite il sito esportato con la v8 e che con la nuova esportazione fatta dalla v9 non sono più leggibili correttamente.

In altri termini. Evo9 con tutti i problemi che ci sono, ma anche con quelli che erroneamente gli vengono attribuiti, ma che non ci sono, non è direttamente responsabile di questo malfunzionamento. E quindi studiare l' iwp non serve a nulla.

Il problema deriva soltanto dal fatto che ci sono file creati e riempiti con la 8 che usava la ISO8859 che con la 9 vengono aggiornati con la nuova codifica.

E' necessario eseguire la conversione, tutto qui, un'operazione banale e che ho anche quasi descritto nel mio post ma che poteva essere prevista anche da un tool per la migrazione ... era un problema prevedibile.

il problema succede in tutti i siti è possibile che sbagli io qualcosa, o ogni server da errori,io non credo dato ke si comporta allo stesso modo x tutti i siti sia nel blog che nel campo ricerca interna ( basta provare ad andare sul sito e cercara la parola curiosità e vedre cosa trovawww.carraraonline.com) al sito, il fatto è come dice SerZio questo caos succede con i siti importati dalla v8 alla v9.

Ciao Pietro, puoi inviarmi il tuo file IWP fatto con la 8, cosi faccio dei test? Grazie.

ho scritto a ***;

Non ho capito, hai inviato il file? Ad ogni modo quella casella non è attiva. Se vuoi inviare il file dovresti scrivere alla mail automatica file@answers.websitex5.com indicando come oggetto il link di questo post. 

Puoi anche fare uno ZIP del solo file IWP e allegarlo qui oppure in un post privato se non vuoi che altri lo scarichino. Grazie.

OK INVIATO ORA

Ciao Pietro, non ho ancora ricevuto nulla. Ti ricordo l'indirizzo file@answers.websitex5.com

Se vuoi fare uno ZIP del file IWP è meglio, in questo modo viene sicuramente di ridottissime dimensioni e puoi anche allegarlo qui. Fammi sapere, grazie.

Buongiorno, ho inviato ieri ed in questo momento all' indirizzo da lei indicato,

Dal mio client di posta risulta inviata correttamente ieri e oggi.

Grazie

Ciao, l'ho ricevuta. E' solo che non avevi zippato il file che era di quasi 7MB. Controllo e ti faccio sapere se trovo qualcosa. Grazie.

Ciao Pietro, ho controllato il tuo file, anche se era rovinato quello che abbiamo ricevuto, quindi ho prelevato solo alcune pagine. Ce ne sono arrivati 2 uno di quasi 7MB e l'altro sui 5MB. Ad ogni modo era indipendente da questo ma ci è stato utile per capire meglio. 

Abbiamo fatto diverse prove. Dato che non ho potuto accedere ai tuoi dati FTP dal documento, potresti provare a sovrascrivere il file PHP allegato (è nello ZIP) con quello presente sul tuo server nella cartella res ?

Fammi sapere, grazie.

Ok ora ci siamo, funziona tutto alla grande sia i commenti vecchi e i nuovi.

Funziona anche il campo ricerca le parole cercate con segni e accenti sono visualizzate correttamente.

Grazie mille, sono contento che è stato risolto il problema, vedo da altri post che la cosa succede anche ad altri, quindi per gli altri siti che hanno lo stesso problema come mi devo comportare?

GRAZIE

Ti spiego cosa abbiamo fatto: non si tratta di problemi di conversione dalla 8 alla 9, di impostazione di default del charset da parte del server o altro.

E' un bug di una funzione PHP che avviene solo su server IIS Windows. Per tale bug, penso te ne sia accorto, solo il carattere à veniva sostituito in modo errato con il ? Tutti gli altri caratteri accentati erano corretti (èéìòù) 

Per completezza di invito a visualizzare la pagina di test caricata su server Aruba Windows http://www.incomedia.it/temp/test/test.php

Noterai che la seconda riga è errata (usa la funzione con il bug). Ti allego anche il file PHP, provalo se vuoi.

Questo vale solo per gli script PHP che usano tale funzione (come la visualizzazione dei dati della ricerca), e non valgono per le pagine statiche, dove infatti il problema non sussisteva.

Spero di averi chiarito e di essere stato di aiuto. Tale file verrà inserito nei prossimi aggiornamenti.

certo 6 stato utile, fa piacere sapere che questo problema esiste.

Posso sostituire anche negli altri siti il file x5engine.zip

Grazie ancora

Su http://www.serzio.it/evo829/serzioblog/blog/index.php un esempio di blog ancora non funzionante in cui ho sostituito l' x5engine.php ed in cui il primo commento è inserito durante l'esecuzione con l'esportazione della 8 mentre il secondo con l'esportazione dello stesso progetto importato nella build 1699 ... dovrei riprovare con la 1748, ma credo sarà la stessa cosa.

a me funziona versione 1748

Scusate, il mio link è stato offline in quanto ho voluto ricreare l'errore con la 1748 italiana piuttosto che la vecchia 1699 ed ho inserito i tre passaggi:

1) esportazione con la 8 su http://www.serzio.it/evo829/serzioblog_8/blog

2) esportazione con la 9 importando il progetto senza la modifica proposta su http://www.serzio.it/evo829/serzioblog_9/blog

3) duplicato della 9 al punto 2 ma con la sostituzione dell' x5engine.php su http://www.serzio.it/evo829/serzioblog/blog

Il progetto è sempre lo stesso ma con l'esportazione della 8 ho inserito qualche commento che con il passaggio alla 9 si vede male.

L'unica cosa che non mi convince, a parte che nel mio caso la patch non sortisce alcun effetto, è che vedo una modifica in riga 612, una in 748 e l'aggiunta della 1175 in cui vedo che avete inserito l'azzeramento della variabile session_page che causava il famoso problema dell'area riservata  ... bene bene ...

... come dicevo ..... sarò "de' coccio" ..... maaa ..... sarà anche che io lavoro su linux ....... vabbè ... non ho motivo di non fidarmi  

infatti il problema si presenta su server windows

ciao SerZio

... dimenticavo:

4) su http://www.serzio.it/evo829/serzioblog_9c/blog c'è un clone della http://www.serzio.it/evo829/serzioblog/blog ma su cui ho applicato la mia medicina ..... non quella di icm ....e come si vede, riappaiono anche i commenti inseriti con la 9 e che risultavano spariti ... con il primo commento a ciascun post viene effettuata la conversione in xml ed è qui che andrebbe applicata la medicina piuttosto che ai file già convertiti ed a posteriori come ho fatto io

Non sarebbe più semplice ammettere questo ulteriore problema e dire "prendiamo atto di questa segnalazione e provvederemo" (anche se la soluzione è pronta col cucchiaino) piuttosto che far finta di niente? Boh? Non capisco.

No penso che faranno finta di niente anche perchè il problema esiste riporto cosa ha scritto Steve R " Tale file verrà inserito nei prossimi aggiornamenti."

Bah!!!! Sono abituato .... a memoria .... non ricordo che mi sia mai stato detto "grazie per la segnalazione, provvederemo a mettere una toppa" piuttosto che "no, non è un problema, si tratta di un comportamento voluto e stabilito in fase di progettazione". Forse vengo considerato come "lo scemo del villaggio" ..... meno male che il villaggio è (era, è stato) virtuale, .... ma non importa, va bene così. 

Rieccomi con la promessa, o forse no, prova su un hosting windows di aruba. Qui posto solo gli screenshot in quanto non posso pubblicare il link.

Qui sopra ho inserito un commento che potete leggere. 

Sotto si vede che il commento non è leggibile.

Mentre qui sotto si vede che l'inserimento dell'ultimo commento ha causato la perdita dei commenti precedenti.

Inutile specificare di aver impostato correttamente percorsi e permessi ... altrimenti la cancellazione non sarebbe potuta avvenire, oltretutto.

Il sito web utilizzato per questa ennesima prova su win di aruba è l'ultimo disponibile,  patchato con l' x5engine.php, con la conversione in xml già avvenuta ma senza aver applicato la mia medicina.

Rileggendo l'ultimo mio post, mi sono accorto di una imprecisione sul secondo screenshot .... probabilmente in quella fase non doveva essere visibile l'ultimo commento appena inserito e probabilmente il contenuto della pagina non è stato aggiornato subito dopo l'inserimento altrimenti il primo commento sarebbe sparito in quanto già non più presente nel file xml apposito.

Insomma, ho perso la voglia di fare ulteriori prove su questo argomento che non mi interessa più (ed in fin dei conti non interessa nemmeno a chi dovrebbe) e di cui ho riportato uno stralcio su:

http://www.unofficialwsx5.com/index.php?topic=470.0

a cui invito chi volesse approfondire, ma senza il sottoscritto che ha già dato ... senza ricevere.

Ciao Serzio, il problema qui segnalato riguarda il carattere à accentato che non viene visualizzato correttamente solo nei risultati della ricerca per via di un bug di PHP che si presenta solo suserver Windows (forse solo di Aruba?).

Questa segnalazione è stata risolta.

Mi sembra di capire che tu stia parlando dei commenti del blog per i documenti convertiti con la 8, quindi di un altro argomento. Se vuoi posso spostare tutti i tuoi post su uno nuovo, ma preferirei che ne aprissi uno nuovo indicando tutto quello che serve (qui ormai c'è un po' di confusione dato che si parla di un altra cosa).

Reinserisci pure le informazioni che ritieni utili in modo che possiamo valutarle per comprendere eventuali difetti e, nel caso, provvederemo a correggere.

Se avevi già aperto un post a riguardo, ti prego di segnalarmelo e mi scuso se non avevi ricevuto una ns risposta.

Fammi sapere, grazie.

Grazie Pietro, spero tu abbia compreso meglio quale fosse il problema. Sarebbe stato utile sapere se dipende solo da Aruba Windows o da Windows in generale. Sicuramente è molto più veloce fare noi la modifica piuttosto che lasciare che la cosa venga risolta da Aruba, MS o PHP.

Ad ogni modo se riscontraste altre problematiche (commenti, area riservata o altro) vi prego di aprire un nuovo post indicando tutte le info in merito. 

Aspetto info da Serzio sulle sue segnalazioni e poi puoi impostare il tuo commento sopra come corretto, in modo da chiudere questa segnalazione. Grazie.