[ajax] posten/ophalen van data

[Saven]

Hallo GoT'ers
Ik heb een irritant probleem waar ik serieus uren mee heb zitten stoeien, maar het nog niet heb kunnen oplossen. (Noot: ik wist niet zeker of ik hem in programming of hier moest plaatsen)

Ik heb namelijk een soort kladblok op mijn site. Persoonlijke notities waar je dus tekst in op kan slaan (kan handig zijn ).
Opzich functioneert het. Maar het doet zijn werk niet goed.
Dit systeempje werkt met javascript en zijn AJAX techniek. En het lijkt er op dat het probleem bij de javascript ligt, maar weet niet hoe ik het moet oplossen.

Probleem :
Dit is tijdens het opslaan van het kladblok. Normale tekst zoals 'abcd09' slaat hij prima op. Alleen als ik een é of een € teken wil plaatsen krijg ik rare tekens. Hij kan er niet goed mee overweg.
Als ik deze tekens rechtstreeks in de database invoer worden ze wel goed weergegeven als ik hetkladblok weer ophaal, maar als ik hem dan weer opsla is het weer een raar teken.
Nu dacht ik dus dat dit aan de charset lag. Ik had zelfs in mijn verwerkingsscript de volgende regel bovenaan staan geprobeerd:

PHP:

header('Content-Type: text/html; charset=iso-8859-1');

Maar dit mocht niet baten.
En opzich is dat wel logisch imo, WANT... bij een gewoon form (zoals bij je hobby's invullen bij je profiel) gaat dit wel goed. Dus het probleem moet bij de javascript liggen dacht ik zo. Alleen ik weet mijn god niet wat te doen om dit op te lossen.

Ik zal even wat code posten.
Functie om een request te maken en data te sturen:

JavaScript:

function make_request(url, callback_function, http_method, post_values, return_xml)
{
    http = create_http_object();
    
    if(!http)
    {
        alert('Je browser ondersteunt deze feature niet.');
        return false;
    }
    
    http.onreadystatechange = function()
    {
        //overbodig voor dit topic denk ik, wat statussen checken en de callback functie uitvoeren
    }
    
    if(!post_values)
    {
        post_values = null;
    }
    
    if(!http_method)
    {
        http_method = "GET";
    }
    
    http.open(http_method, url, true);
    
    if(http_method == "POST")
    {
        http.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
    }
    
    http.send(post_values);
}

Via javascript de request maken

JavaScript:

//----------------------------------------------------------------
// Save 'em
//----------------------------------------------------------------
function save_usernotes()
{
    var value = document.getElementById('usernotes').value;
    
    value = trim(value); // eigen functie: value = value.replace(/^\s+/,'');      value.replace(/\s+$/,'');
    
    if( value.length > 5000 )
    {
        document.getElementById('notes-saved').innerHTML = 'Je hebt meer dan 5000 tekens ingevoerd';
        document.getElementById('notes-saved').style.display = 'block';
    }
    else
    {
        var post_string = "value=" + value;
        
        make_request(url + 'app/js/notes.php', 'handle_save_usernotes', 'POST', post_string);
    }
}

En dit is een stukje PHP code, waar voor zover ik weet het probleem niet ziet. Want als ik een extra teken toevoeg in de $value bijvoorbeeld $value.= 'é' dan komt die wel gewoon in de database. Hier had ik dus ook die extra PHP header toegevoegd:

PHP:

if( isset($_POST['value']) )
{
    if( $core->user->logged_in === true )
    {
        $value = trim($_POST['value']);
        // hier voegde ik dan $value .= ' ééé'; toe. dat werkte wel gewoon
        
        if( strlen($value) > 5000 )
        {
            echo '200::too_long';
        }
        else
        {
            $query = $core->db->prepare
            ('
                UPDATE
                    members
                SET
                    notes = :notes
                WHERE
                    id = :uid
                LIMIT
                    1
            ');
            
            $query->bindParam(':notes', $value, PDO::PARAM_STR);
            $query->bindParam(':uid',   $core->user->fetch['id'], PDO::PARAM_INT);
            
            $query->execute();
            
            echo '100::success';
        }
    }
    else
    {
        echo '300::not_logged_in';
    }
}

Kan iemand mij misschien helpen want het werkt nu wel een beetje, maar niet zoals het hoort. Graag wil ik ook normaal é en euro-tekens opslaan enzo

[MueR]

Klinkt alsof je UTF8 stuurt. Probeer in ieder geval om je output netjes in html entities weer te geven.

[Verwijderd]

Vraag 1: Waarom geen UTF-8?
Vraag 2: Zijn de content-types van je database velden, je JavaScripts, en al je PHP ook iso-8859-1?

[Verwijderd]

De charset moet overeen komen met het formulier.
Als het HTML formulier een andere charset gebruikt, krijg je vreemde tekens.

Wat je ook kan proberen is de functie utf8decode() / utf8encode(), zie PHP.net voor meer informatie.

[Saven]

MueR schreef op vrijdag 06 februari 2009 @ 14:14:
Klinkt alsof je UTF8 stuurt. Probeer in ieder geval om je output netjes in html entities weer te geven.

Dat is een beetje een tweede probleem.
Bij het outputten (dus het ophalen van de notities) gebruik ik in mijn php wel htmlentities met ENT_QUOTES

PHP:

echo html($fetch['notes']) ; //alias voor die htmlentities

Als ik deze tekst insert via mijn systeempje:

code:

test

euroteken : €
e met streepje: é

en nu proberen html:
<noscript>

of quotes:
"test dubbel"
'test enkel'

doei

en die vraag ik weer op met het systeempje, dan krijg ik:

code:

test

euroteken : �
e met streepje: é

en nu proberen html:
<noscript>

of quotes:
"test dubbel"
'test enkel'

doei

Als ik dan in de html kijk wat in het textarea staat, doet hij vreemd genoeg niet helemaal htmlentities, kijk maar naar de quotes

code:

test

euroteken : �
e met streepje: é

en nu proberen html:
<noscript>

of quotes:
"test dubbel"
'test enkel'

doei

Ga ik rechtstreeks naar notes.php?get_notes dan is is de html:

code:

test

euroteken : €
e met streepje: é

en nu proberen html:
<noscript>

of quotes:
"test dubbel"
'test enkel'

doei

Ik snap er niks meer van

Verwijderd schreef op vrijdag 06 februari 2009 @ 14:17:
Vraag 1: Waarom geen UTF-8?
Vraag 2: Zijn de content-types van je database velden, je JavaScripts, en al je PHP ook iso-8859-1?

De database velden staan op latin_1_swedisch_ce ofzo dat stonden automatisch. ook als ik een nieuwe tabel aanmaak is dat automatisch de coallitie

en utf8? dreamweaver gaf bij mij standaard deze charset dus ik dacht dat is wel goed. tevens is tweakers ook iso-nogwat dus ik denk dat zit wel goed? is UTF-8 beter dan?

Verwijderd schreef op vrijdag 06 februari 2009 @ 14:25:
De charset moet overeen komen met het formulier.
Als het HTML formulier een andere charset gebruikt, krijg je vreemde tekens.

Wat je ook kan proberen is de functie utf8decode() / utf8encode(), zie PHP.net voor meer informatie.

de database is latin_1, dus ook die iso charset.
En ik heb even gekeken voor de gein, als ik deze code wil opslaan in het kladblok:

code:

Visit%20W3Schools%21
%3F%21%3D%28%29%23%25%26

dan un-escape't hij ze automatisch al ofzo dan krij ik bij het opvragen via het systeem, danwel direct, de echte output. hij slaat hem dus un-encoded in de database op waardoor je meteen de echte tekst ziet.

[ Voor 16% gewijzigd door Saven op 06-02-2009 14:30 ]

[Janoz]

Belangrijk leesvoer : http://www.joelonsoftware.com/articles/Unicode.html

[Noork]

Kan het misschien liggen dat het http request niet in iso-8859-1 wordt verstuurd? Dat kan ook aan de instelling van de webserver liggen. Kun je dit testen met iets als Firebug. Sowieso is het handig om even alle headers te controleren in Firefox.

Misschien kun je zoiets toevoegen aan je request:

code:

http.setRequestHeader('Content-Type: text/html; charset=iso-8859-1');

[Spinal]

Lichtelijk offtopic: € zit niet in iso-8859-1, wel in iso-8859-15.

[Noork]

ZanderZ schreef op vrijdag 06 februari 2009 @ 16:20:
Lichtelijk offtopic: € zit niet in iso-8859-1, wel in iso-8859-15.

Niet helemaal offtopic. Ik wist dat niet. Dan moet je dus sowieso iets van & euro; gebruiken om het als html weer te geven. Maar verklaart natuurlijk niet de é.

[Saven]

ik heb de POST header iets veranderd:

JavaScript:

http.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded; text/html; charset="iso-8859-1"');

Dit heeft nog steeds geen nut.
Wel heb ik ontdekt dat als ik escape() over de post_value doe:

JavaScript:

var post_string = "value=" + escape(value);
        
make_request(url + 'app/js/notes.php', 'handle_save_usernotes', 'POST', post_string);

dat hij dan wel de é goed in de database stopt.
De € stopt hij er dan in als: %u20AC


EDIT:
Met de bovenstaande POST header, zegt Firebug dat het verzoek een UTF-8 verzoek is.
Content-Type
application/x-www-form-urlencoded; text/html; charset=UTF-8

Terwijl ik toch echt die header heb aangepast?

[ Voor 19% gewijzigd door Saven op 06-02-2009 16:45 ]

[MBV]

Hij kijkt niet alleen naar de header, geloof ik. Als je server eerst een UTF8 BOM verstuurt, dan wordt het alsnog als UTF8 gezien. Maar hier is belangrijk dat alles hetzelfde is. Met welke header wordt je HTML-pagina verstuurd? En hoe ziet Firefox dat?

[Saven]

ik heb bovenin index.php:

PHP:

header('Content-Type: text/html; charset=iso-8859-1');

en ook in de html.

Het lijkt nu te werken Alleen het euro teken doet het nog niet.
Als ik alles verander naar die charset met 15 ipv 1 doet hij het nog niet.

heeft dat te maken met het feit dat mijn kolom collatie op latin1_swedish_ce staat? en zoja waarop moet ik die dan zetten, ik had gezocht dat dat 8859-15 latin9 is, maar die staat niet tussen mijn lijst.
Want als ik het goed begrijp kan je met die 8859-15 wel euro tekens doen

[MBV]

waarom maak je niet overal UTF8 van? Dan ben je sowieso van het gedoe af... en voor de opslag maakt het niet uit of het -1 of -15 is: alleen in PHPmyAdmin krijg je dan rare tekens, bij weergave als -15 wordt het weer goed.

Maar wat doet hij niet bij het euroteken? Wordt het gewoon genegeerd of komen er rare tekens voor in de plek?

[crisp]

Gebruik geen escape() (die is deprecated en niet RFC-compliant) maar encodeURIComponent
Deze laatste zet altijd alles om naar UTF8, dus als je serverside latin gebruikt moet je daar nog wel een utf8_decode overheenhalen.

[Cartman!]

Gewoon UTF8 pakken, werkt lekker makkelijk en in principe nooit meer gezeik met niet-ondersteunde tekens

[Saven]

crisp schreef op vrijdag 06 februari 2009 @ 20:19:
Gebruik geen escape() (die is deprecated en niet RFC-compliant) maar encodeURIComponent
Deze laatste zet altijd alles om naar UTF8, dus als je serverside latin gebruikt moet je daar nog wel een utf8_decode overheenhalen.

Dat was ik even vergeten te vermelden, ik gebruik inderdaad encodeURIComponent in combinatie met:

PHP:

$value = trim($_POST['value']);
$value = utf8_decode($value);

Dat werkt nu ook goed, op het euro teken na. Dat wordt een vraagteken '?'

Cartman! schreef op vrijdag 06 februari 2009 @ 20:22:
Gewoon UTF8 pakken, werkt lekker makkelijk en in principe nooit meer gezeik met niet-ondersteunde tekens

Stel ik wil utf8 gebruiken. Waar moet ik mijn database collatie op zetten dan? Want je hebt heel veel verschillende soorten utf8_xxx

[Cartman!]

utf8_unicode (de onderste )

[Saven]

Cartman! schreef op vrijdag 06 februari 2009 @ 20:40:
utf8_unicode (de onderste )

Hehe oke en heeft dat ook nog een aparte naam nodig voor de content type. Of kan ik daar gewoon UTF-8 gebruiken zonder die _unicode:)