Pagina 4 di 7 primaprima ... 2 3 4 5 6 ... ultimoultimo
Visualizzazione dei risultati da 31 a 40 su 61
  1. #31
    Originariamente inviato da Jarno
    PROBLEMA 0,01%
    un campo del db contenente nominativi pieni di accentate e dell'apostrofo "piegato" di office, mi produce errori di validazione, addirittura il detecting del doctype fallisce. E' curioso che se ai valori presi da MySql applico utf8_encode (che non avrebbe senso perchè i valori del db sono in utf-8) il detecting avviene, le accentate si vedono, ma tale apostrofo invalida producendo un "?"
    sto diventanto :berto:

    a questo punto ho solo 2 idee:
    - che in qualche modo c'entri il fatto che carico i dati in un'array JavaScript ma non credo che sia questo il problema
    - che l'aver convertito la codifica di tale campo/tabella/db non ha realmente convertito i valori ma solo l'impostazione...ma eppure con PhpMyAdmin si vede correttamente l'accentate
    ho convertito il campo del db in "binary" ...e funziona!!! e viene validato!!! ma che cax significa!?!? VVoVe: ora vo' a cena poi ci studio....
    Farmacia di Jarno - le mie pillole: Cookie [#780810], Dom4Php4 [#1123236], Fade [#1139489], getCssProperty [#1152911]
    Inchinatevi difronte al Prof! Nacchio!

    A me pare che l'uomo vada avanti con la retromarcia

  2. #32
    Fai un po' di confusione.
    Originariamente inviato da Jarno
    ma se non erro XML, che ancora non uso ma voglio esser pronto, impone l'uso di UTF
    Sbagliato. Puoi usare il charset che vuoi in XML, UTF-8 è il predefinito, ma ti basta dichiararne un altro nel documento e usarlo senza alcun problema.
    DUBBIO
    ma ho una perplessità: i txt creati con windows sono in DOS (che credo sia Latin1)
    Il formato DOS, Unix o Mac non c'entra con la codifica, bensì con gli accapo.
    Unix &C. usano solo \n, Mac usa \r e Windows usa entrambi, \n\r per codificare il carattere di accapo. Questo prescinde dalla codifica in uso.


    PROBLEMA 0,01%
    un campo del db contenente nominativi pieni di accentate e dell'apostrofo "piegato" di office, mi produce errori di validazione, addirittura il detecting del doctype fallisce. E' curioso che se ai valori presi da MySql applico utf8_encode (che non avrebbe senso perchè i valori del db sono in utf-8) il detecting avviene, le accentate si vedono, ma tale apostrofo invalida producendo un "?"
    sto diventanto :berto:
    Se il contenuto del db era 8859-1, dovrai cambiarlo in utf-8.

  3. #33
    ok, allora se sta storia delle codifiche è solo una questione di coerenza e allineamento che senso ha questa informazione che viene riportata su tutti i manuali di conversione da HTML a XHTML?

    Usualmente tutti i documenti in occidente sono codificati con il set di caratteri UTF-8 o ISO-8859-1. Questi due set sono facilmente distinguibili, infatti, se per scrivere una lettera accentata come "à" nel nostro codice avete scritto "à" probabilmente state usando l'UTF-8, mentre se avete scritto puramente "à" probabilmente state usando l'ISO-8859-1.
    quindi da quello che avete scritto e da quello che ho provato a fare, questa cosa è una fesseria, difatti da oggi le mie pagine sono in UTF-8 e le accentate ci stanno alla grande

    nb: il problema col database l'ho risolto. credevo che cambiando la codifica convertisse in automatico i valori già inseriti (almeno così si intuisce dalla guida ufficiale ) ma a occhio qualcosa non funziona, quindi svuotato la tabella (che ho già convertito in utf8), ed ho rifatto l'upload indicando che il file sql era Latin1 ...così magicamente ha funzionato
    Farmacia di Jarno - le mie pillole: Cookie [#780810], Dom4Php4 [#1123236], Fade [#1139489], getCssProperty [#1152911]
    Inchinatevi difronte al Prof! Nacchio!

    A me pare che l'uomo vada avanti con la retromarcia

  4. #34
    Originariamente inviato da Jarno
    le mie pagine sono in UTF-8 e le accentate ci stanno alla grande
    Ovviamente.
    La differenza è che ora le tue lettere accentate occupano 2 byte, mentre prima ne occupavano uno.

  5. #35
    Comunque in generale, se inizialmente utf8 può richiedere degli sforzi, devo dire che poi premia.
    Prima di tutto perchè se si comprendono bene i problemi di codifica si risolvono facilmente eventuali inghippi (quelli classici dei caratteri che non si vedono o si vedono strani) e poi perchè quando si realizza qualcosa con utf8 è utilizzabile con tutte le lingue senza alcun timore (e questo torna utile per riutilizzare il codice in qualsiasi situazione).
    Per il resto devo dire che utf8 non è la soluzione a tutti i mali, ma come tutti gli strumenti se utilizzato correttamente può dare vantaggi.
    Il più grosso vantaggio, per quanto mi riguarda, è la totale coerenza dei caratteri quando si riceve input dai form.
    Voglio dire, se si fa un sito in ISO-8859-* (o altro) e viene a postare un cinese, i problemi sono inevitabili.
    Mentre se il sito è realizzato con utf8, i testi saranno sempre coerenti.
    Chi di noi sa leggere il cinese? Boh, certo non io... però almeno dal punto di vista tecnico siamo ineccepibili
    Lungo le due rive del fiume gelato si stendeva la cupa e tetra foresta di abeti, dai quali il vento aveva appena spazzato il manto di brina. Nella luce crepuscolare quegli abeti neri e sinistri sembravano inclinarsi l'uno verso l'altro. Un silenzio minaccioso incombeva sul paesaggio, privo di qualsiasi segno di vita o di movimento, e desolato e freddo al punto da non poter ispirare che un solo sentimento: quello della più triste malinconia. E nello stesso tempo pareva che da quel paesaggio trapelasse una specie di riso, un riso ben più spaventoso di qualsiasi malinconia o tristezza, un riso tragico, come quello di una sfinge, un riso agghiacciante più della brina e che rammendava l'incombere minaccioso dell'ineluttabile. Era la saggezza potente e impenetrabile dell'eternità che irrideva alla vita, alla sua futilità e agli sforzi degli uomini.

  6. #36
    Originariamente inviato da Jarno
    credevo che cambiando la codifica convertisse in automatico i valori già inseriti (almeno così si intuisce dalla guida ufficiale ) ma a occhio qualcosa non funziona, quindi svuotato la tabella (che ho già convertito in utf8), ed ho rifatto l'upload indicando che il file sql era Latin1 ...così magicamente ha funzionato
    Cambiare codifica su mysql non cambia assolutamente nulla a livello di dati (quelli sono e quelli rimangono).
    L'unica cosa che cambia, naturalmente, è il comportamento delle funzioni mysql che hanno a che fare con le stringhe
    Lungo le due rive del fiume gelato si stendeva la cupa e tetra foresta di abeti, dai quali il vento aveva appena spazzato il manto di brina. Nella luce crepuscolare quegli abeti neri e sinistri sembravano inclinarsi l'uno verso l'altro. Un silenzio minaccioso incombeva sul paesaggio, privo di qualsiasi segno di vita o di movimento, e desolato e freddo al punto da non poter ispirare che un solo sentimento: quello della più triste malinconia. E nello stesso tempo pareva che da quel paesaggio trapelasse una specie di riso, un riso ben più spaventoso di qualsiasi malinconia o tristezza, un riso tragico, come quello di una sfinge, un riso agghiacciante più della brina e che rammendava l'incombere minaccioso dell'ineluttabile. Era la saggezza potente e impenetrabile dell'eternità che irrideva alla vita, alla sua futilità e agli sforzi degli uomini.

  7. #37

    ............

    Ciao.
    Per fissare dei punti fermi e sicuri
    pagina con il form:
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    Db Collation
    utf8_general_ci
    a questo punto non c'è alcun bisogno
    almeno per i caratteri di htmlentities

    E lo stesso vale se utilizzo file Xml.

    Giusto ?

    Ps.
    Scusate il punto rilevabile da tutto
    il thread ma come si dice ..............


    Without faith, nothing is possible. With it, nothing is impossible
    http://ilwebdifabio.it

  8. #38
    anche lo stesso file deve essere codificato in utf-8 (impostazioni dell'editor).

  9. #39
    Il charset scelto per la tabella va bene e anche il metatag, ti consiglio però di mettere UTF-8 in maiuscolo nell'attributo (mi sembra di ricordare che qualche browser rompeva le scatole per questo).
    La tabella per il database va bene se non devi fare ricerche o usare funzioni mysql con 'case-sensistive' attivo.
    L'importante poi è che quello che metti nel db sia effettivamente utf8, questo perchè mysql non fa alcun controllo in proposito.
    Comunque tutto ok
    Lungo le due rive del fiume gelato si stendeva la cupa e tetra foresta di abeti, dai quali il vento aveva appena spazzato il manto di brina. Nella luce crepuscolare quegli abeti neri e sinistri sembravano inclinarsi l'uno verso l'altro. Un silenzio minaccioso incombeva sul paesaggio, privo di qualsiasi segno di vita o di movimento, e desolato e freddo al punto da non poter ispirare che un solo sentimento: quello della più triste malinconia. E nello stesso tempo pareva che da quel paesaggio trapelasse una specie di riso, un riso ben più spaventoso di qualsiasi malinconia o tristezza, un riso tragico, come quello di una sfinge, un riso agghiacciante più della brina e che rammendava l'incombere minaccioso dell'ineluttabile. Era la saggezza potente e impenetrabile dell'eternità che irrideva alla vita, alla sua futilità e agli sforzi degli uomini.

  10. #40
    giusto, stai attento al minuscolo/maiuscolo

    UTF-8 per xhtml, html, xml, ...
    utf8 per MySql
    utf8_general_ci per la collation di MySql, purtroppo c'è solo "ci" e non "cs" come dici
    UTF-8 no BOM per per gli editor, il problema qui (come anche IroN@xiD se non sbaglio ha chiarito) è che non esiste una vera gestione del coding, ma solo funzioni che ti trasformano in modo "stupido"
    Farmacia di Jarno - le mie pillole: Cookie [#780810], Dom4Php4 [#1123236], Fade [#1139489], getCssProperty [#1152911]
    Inchinatevi difronte al Prof! Nacchio!

    A me pare che l'uomo vada avanti con la retromarcia

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.