schildi: mysql/php5, mediumtext landet nicht vollständig in der db

hallo,

ich benutze smarty/php (php 5.2.0-8) und speichere templates in der datenbank (mysql 5.0.32). läuft auch soweit ganz gut, nur leider wird ein template, welches ziemlich groß ist, ab einer bestimmten stelle an irgendeiner stelle der verarbeitung abgeschnitten. die seite hat eine größe von 623kb. in der datenbank landet sie mit 458kb (inkl. smarty header).

ich verwende utf-8. die tabelle sieht folgendermaßen aus:

CREATE TABLE avl\_smarty\_cache (
  CacheID char(32) collate utf8_unicode_ci NOT NULL default '',
  CacheContents mediumtext collate utf8_unicode_ci NOT NULL,
  CacheDatetime datetime NOT NULL,
  PRIMARY KEY  (CacheID)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

auch mit longtext wird das template abgeschnitten. seltsamerweise (bei einem test) an noch früherer stelle.

editiere ich das template testweise via phpmyadmin, so kann ich einen längeren text speichern. zumindest habe ich mal noch "test" ranhängen können u. die änderung wurde gespeichert.

an welcher stelle können komplikationen auftreten, die so etwas hervorrufen?..

auszug aus der my.ini:

key_buffer              = 32M
table_cache             = 64
max_allowed_packet      = 16M
thread_stack            = 128K
thread_cache_size       = 8
#max_connections        = 100
table_cache            = 64
#thread_concurrency     = 10

//wobei ich auf einem anderen server "höhere" einstellungen verwende, und das problem genauso auftritt. denke also nicht, dass es hiermit zusammenhängt. es scheint irgendwo in der applikation zu passieren. also tippe ich auf ein durch php verursachtes problem.

danke für jeden tipp!

  1. danke für jeden tipp!

    mediumtext erlaubt 2^24+3 bytes - das entspricht etwa 16 mb - auch wenn du extrem viele utf-8-codierte zeichen hinterlegst (die jeweils 4 bytes belegen), kommst du niemals auf diese menge

    die "bestimmte" stelle enthält vielleicht eine zeichenfolge, die entsprechend maskiert werden sollte - ist das sichergestellt?

    1. danke für jeden tipp!
      mediumtext erlaubt 2^24+3 bytes - das entspricht etwa 16 mb - auch wenn du extrem viele utf-8-codierte zeichen hinterlegst (die jeweils 4 bytes belegen), kommst du niemals auf diese menge

      die "bestimmte" stelle enthält vielleicht eine zeichenfolge, die entsprechend maskiert werden sollte - ist das sichergestellt?

      ja - das mit der länge hatte ich auch überschlagen - hätte mich auch gewundert.
      ich maskiere meines erachtens alles ordnungsgemäß:

      if (get_magic_quotes_gpc())
        $value = stripslashes($value);
      $value = mysql_real_escape_string($value);

      wenn ich übrigens den template-inhalt direkt vor absenden der query ausgebe, sieht noch alles gut aus. es muss also zwischen mysql_query und dem schreiben in die datenbank passieren.

  2. echo $begrüßung;

    ich [...] speichere templates in der datenbank (mysql 5.0.32). [...] nur leider wird ein template, welches ziemlich groß ist, ab einer bestimmten stelle an irgendeiner stelle der verarbeitung abgeschnitten. [...]
    editiere ich das template testweise via phpmyadmin, so kann ich einen längeren text speichern.
    es scheint irgendwo in der applikation zu passieren. also tippe ich auf ein durch php verursachtes problem.

    Wenn es der phpMyAdmin schafft, dann kann PHP wohl nicht grundsätzlich das Problem sein.

    die seite hat eine größe von 623kb. in der datenbank landet sie mit 458kb

    Kannst du die Anzahl in Bytes angeben und nicht gerundet? Wie sieht die Stelle rund um den Abschnitt aus? Bitte im Original und als Statement-Ausschnitt.

    CacheContents mediumtext collate utf8_unicode_ci NOT NULL,

    utf8_binary für Strings, die nicht verglichen oder sortiert werden müssen, fände ich angebrachter, wird aber das Problem nicht lösen.

    echo "$verabschiedung $name";

    1. Kannst du die Anzahl in Bytes angeben und nicht gerundet? Wie sieht die Stelle rund um den Abschnitt aus? Bitte im Original und als Statement-Ausschnitt.

      deine hinweise haben mich weitergebracht.
      habe gerade die stringlängen ausgelesen:

      stringlaenge vor replace into:551563 byte
      stringlaenge nach replace into:383236 byte
      (mb_strlen($cache_content,"utf-8"))

      und dabei nochmals genau die stelle angeschaut. das problem ist die fehlerhafte kodierung des großen Ö's in der ausgabe:

      /ï%C3%96koWorld+Lux.+S.A./

      (ÖkoWorld+Lux.+S.A./)

      ich habe Probleme mit abschneiden bei inserts durch ein großes Ö schon öfter festgestellt.
      wieso können fehler bezüglich der darstellung des großen Ö's entstehen?

      wenn ich übrigens ein preg_replace mit modifier u (utf-8) drüberlaufen lassen über den template-string, der im prinzip nix macht. zb. leerzeichen mit leerzeichen ersetzen, dann ist das ergebnis danach ok.

      danke sconmal an dieser stelle!

      1. und dabei nochmals genau die stelle angeschaut. das problem ist die fehlerhafte kodierung des großen Ö's in der ausgabe:

        /ï%C3%96koWorld+Lux.+S.A./

        (ÖkoWorld+Lux.+S.A./)

        ich habe Probleme mit abschneiden bei inserts durch ein großes Ö schon öfter festgestellt.
        wieso können fehler bezüglich der darstellung des großen Ö's entstehen?

        wenn ich übrigens ein preg_replace mit modifier u (utf-8) drüberlaufen lassen über den template-string, der im prinzip nix macht. zb. leerzeichen mit leerzeichen ersetzen, dann ist das ergebnis danach ok.

        kann mir bezüglich des umlaut-problems jemand weiterhelfen?

        1. Hallo

          ich habe Probleme mit abschneiden bei inserts durch ein großes Ö schon öfter festgestellt.
          kann mir bezüglich des umlaut-problems jemand weiterhelfen?

          wenn man es richtig macht, dann gibt es mit dem großen Ö überhaupt keine Probleme. Du musst einen Fehler in der Verarbeitungskette haben.

          Freundliche Grüße

          Vinzenz

          1. das problem war ein bug in dem smarty-modifier truncate im zusammenhang mit utf-8.

            näheres hier:

            http://www.phpinsider.com/smarty-forum/viewtopic.php?t=13670