[php + mysql 4.1 + utf-8] tekst veranderd tijdens invoer

[BetuweKees]

heb een database met utf8 ondersteuning waarin ik in dit geval japans probeer in te voeren. (dat kan eindelijk met 4.1 )
probleem waar ik mee zit is dat de karakters die ik invoer in de database er vervolgens op een andere manier uitkomen. niet helemaal de bedoeling dus..
database en tabellen zijn gedefinieerd als utf8 evenals de charset van het html documentje.

doe momenteel het volgende:

PHP:

    // definieren
    $japans = "日本語";
    echo "normaal: ". $japans ."<br>\n";
    echo "utf8 encoded: ". utf8_encode($japans) ."<br>\n";

    
    // invoeren in database
    $sqlQuery = "UPDATE languages SET name = '". utf8_encode($japans) ."' WHERE code = 'ja';";
    
    // opvragen
    $sqlQuery = "SELECT name FROM languages WHERE code = 'ja';";
    if($sqlResult = mysql_query($sqlQuery)) {
        $myrow = mysql_fetch_array($sqlResult);
        echo "database, utf8 decoded: ". utf8_decode($myrow['name']) ."<br>\n";
    }

output:

code:

normaal: 日本語
utf8 encoded: 日本語
database, utf8 decoded: 濥濬調

iemand enig idee wat ik hier fout doe en hoe ik dit zou kunnen oplossen?
is natuurlijk niet helemaal de bedoeling dat er zometeen japanse chars ingevoerd worden die vervolgens een eigen leven gaan leiden..


[edit]
daar gaan me mooie japanse tekens..
er staan een utf-8 versie van de code (dus met japanse chars) op http://www.weijmans.net/utf-8/utf-8.html

[ Voor 15% gewijzigd door BetuweKees op 04-01-2004 02:14 ]

[hobbit_be]

wat is de definitie van je field in SQL?

persoonlijk vind ik die urlencoded er al erg vreemd uitzien. Zeker omdat je infeite je htmlstring al UNICODE is (ie: &#128+ == unicode).

als je geen search wil doen op je japans opslaan als gewoon string (ie: niks encode/decode)

[BetuweKees]

wat is de definitie van je field in SQL?

gebruik de volgende CREATE TABLE:

code:

CREATE TABLE languages (
  language_id tinyint(3) unsigned NOT NULL auto_increment,
  code varchar(2) NOT NULL default '',
  name varchar(32) NOT NULL default '',
  PRIMARY KEY  (language_id),
  UNIQUE KEY language_id (language_id),
  KEY code (code)
) TYPE=MyISAM DEFAULT CHARSET=utf8;

persoonlijk vind ik die urlencoded er al erg vreemd uitzien. Zeker omdat je infeite je htmlstring al UNICODE is (ie: &#128+ == unicode).

als je geen search wil doen op je japans opslaan als gewoon string (ie: niks encode/decode)

ik doe een utf8_encode() niet een urlencode() maar ik neem aan dat dat een tikfoutje is. reden dat ik deze functie gebruik is dat de waarde die ik anders terug krijg in de verste verte niet op mijn japanse chars lijkt. (berg meuk met unknown chars erin)
met utf8_encode() en utf8_decode() krijg ik tenminste iets japans lijkends terug, dus dacht dat dat de manier was..

hoef in deze tekst niet per se te zoeken, dus dat van die gewone string snap ik, blijft alleen de vraag waarom ik meuk in mijn db krijg..
reden om mysql 4.1.1 te gaan testen was nl de mogelijkheid om oa als utf-8 op te slaan en daar leuke dingen mee te doen.. anders kan ik even goed ouderwetse 3.23 weer gaan gebruiken en gewoon opslaan als binary met een BLOBje..


[edit]
als ik 'name' verander in een binary (dus name varchar(32) binary NOT NULL default '') dan is probleem inderdaad verholpen, maar dat lijkt me niet helemaal de bedoeling

daarnaast valt het me op dat een speciaal teken met de charset op utf8 twee keer meer bytes kost dan met binary; zou het kunnen dat mysql de binnenkomende data zelf nog eens converteerd??

[ Voor 14% gewijzigd door BetuweKees op 04-01-2004 20:42 ]

[BetuweKees]

om bovenstaande te tesen heb ik volgende gedaan:
eerst charset voor veld op utf8 zetten, data invoeren, database weergeven.
dan charset naar binary, opnieuw invoeren en weergeven.

bronbestand is opgeslagen als unicode, html charset ingesteld op utf8. invoeren gebeurd vanuit php script doormiddel van hardcoded namen ($frans = "français"; etc) en vervolgens een update comando ("UPDATE languages SET name='$frans' WHERE code='fr';")

hierbij is in de database dump duidelijk te zien dat alle unicode characters bij utf8 per stuk twee bytes meer in beslag nemen. bij het weergeven van de 'europese' karakters is dit geen probleem, maar mijn hypothese is dat dit bij de aziatische tekens wel het geval is.

sql dumps zijn te vinden op http://www.weijmans.net/utf-8/sql.output
(door de display van je browser naar utf-8 te forcen zie je dat de chars bij de binary versie wel goed gaan, maar bij de utf-8 versie niet. forceer je iso-8859-1 dan kan je de individuele bytes zien)

[BetuweKees]

heb probleem uit eindelijk kunnen oplossen door middel van
1. gebruik "SET NAMES utf8;" direct na connecten met db server
2. iconv() gebruiken alvorens data naar server te sturen

heeft me heel wat pijn en moeite gekost hierachter te komen; wellicht dat iemand anders er nog iets aan heeft..