AllesMeins: /MySQL - Blob nur 64 KB gross

Hallo,

ich habe eine MySQL Tabelle in der ich auch einige Dateien speichern will (bis 200 KB gross). Das Feld in das die Dateien sollen heisst 'bild' und ist vom Typ BLOB. Attribut steht auf BINARY (laut phpMyAdmin).
Dieses Script verwende ich um den Kram in die DB zu bekommen (leicht gekürzt):

=============================================
<?php
if ($_POST['send']) {

//Datenbank Verbindung
 include("../mysql_config.php");
 $conn_id = mysql_connect($host,$id,$mysqlpw);
 mysql_select_db($datenbank,$conn_id);

$data = base64_encode(addslashes(fread(fopen($_FILES['userfile']['tmp_name'], "r"), $_FILES['userfile']['size'])));

$query = "INSERT INTO bilderquiz (bild, zugedeckt, start, zeit) VALUES ('" . $data . "','$zugedeckt',$startzeit,$startzeit)";

if(!$result=mysql_query($query)){
         die(mysql_error());
        }
    MYSQL_CLOSE();

} else {
?>
<form enctype="multipart/form-data" action="index.php" method="post">
  <table width="510" border="0" cellspacing="0" cellpadding="0">
    <tr>
      <td> <input type="hidden" name="MAX_FILE_SIZE" value="1048576">
        Send this file:
        <input name="userfile" type="file"></td>
    </tr>
        <tr>
      <td> <input type="hidden" name="send" value="1"> <input name="submit" type="submit" value="Send File"></td>
    </tr>
  </table>
</form>

<?php

}

?>

Irgend eine Idee wieso maximal 64 KB in der DB landen?

Laut einem "echo $_FILES['userfile']['size']" ist die Dateigrösse, die PHP ermittelt richtig (auf jeden Fall weit grösser als diese blöden 64 KB.

Und bitte keine Diskussionen darüber warum ich die Bilder nicht direkt auf der Platte des Servers speichere. Ich habe mir das gut überlegt und es ist so um einiges praktischer und nützlicher.

Grüsse

Marc

  1. hi,

    $data = base64_encode(addslashes(fread(fopen($_FILES['userfile']['tmp_name'], "r"), $_FILES['userfile']['size'])));

    was soll das?
    es besteht keine notwendigkeit, daten mit base64 zu kodieren, bevor man sie in ein blob schaufelt.

    behandle die daten mit mysql_escape_string(), bevor du sie in den query-string einsetzt, und gut ist.

    Und bitte keine Diskussionen darüber warum ich die Bilder nicht direkt auf der Platte des Servers speichere. Ich habe mir das gut überlegt und es ist so um einiges praktischer und nützlicher.

    http://dclp-faq.de/q/q-db-blob.html
    *scnr*
    es ist und bleibt in der überwiegenden zahl der fälle nonsens. warum dein fall anders gelagert sein soll, da würde ich gerne mal die argumente dafür hören.

    gruss,
    wahsaga

    1. Hiho,

      ok das mit mysql_escape_string() probiere ich mal, hab jetzt keine Zeit. Wenns nicht klappt schimpfe ich hier nochmal :)
      Gibt es da auch ne entsprechende Umkehrfunktion die ich beim auslesen drüber laufen lassen muss?

      Aber bist du sicher, das das das 64 KB Problem löst? Weil es sieht mir nicht nach nem fehlerhaften Query aus (ohne base64 speichert er auch nicht mehr als die 64 KB)

      es ist und bleibt in der überwiegenden zahl der fälle nonsens. warum dein fall anders gelagert sein soll, da würde ich gerne mal die argumente dafür hören.

      Naja, die Bilder sind Teil eines Quizes und müssen deswegen geschützt werden. So das sie nicht von jedem direkt per Browser aufgerufen werden können. Leider habe ich bei meinem Hoster keinen Zugriff auf ein Verzeichniss ausserhalb des http-roots, so das jeder Speicherort gefährlich wäre. Also packe ich die Dinger in die DB, denn da kommt keiner unter Umgehung der Scripte dran.

      Grüsse

      Marc

      1. Hello,

        ok das mit mysql_escape_string() probiere ich mal, hab jetzt keine Zeit. Wenns nicht klappt schimpfe ich hier nochmal :)
        Gibt es da auch ne entsprechende Umkehrfunktion die ich beim auslesen drüber laufen lassen muss?

        Nein. Die Escapes sind nicht für die Datenbank, sondern nur für die Text-Schnittstelle der Datenbank bestimmt. Sie werden nicht mit abgespeichert. Man sollte aber nicht addslashes() UND mysql_escape_string() verwenden. Das bringt durcheinander. Also an mysql_escape_string() immer nur Rohdaten übergeben.

        Liebe Grüße aus http://www.braunschweig.de

        Tom

        --
        Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
        1. Hiho,

          ok... mysql_escape_string() ist gesetzt. Klappt auch schön. Trotzdem bleibt der BLOB nur 64 KB gross. Und das ist eindeutig zu wenig... Noch irgendwelche Ideen woran das liegen könnte?

          Grüsse

          Marc

          1. Hello,

            ok... mysql_escape_string() ist gesetzt. Klappt auch schön. Trotzdem bleibt der BLOB nur 64 KB gross. Und das ist eindeutig zu wenig... Noch irgendwelche Ideen woran das liegen könnte?

            Ja, das ist wie vermutet. Ein BLOB kann 2^16 -2 Bytes Nutzdaten aufnehmen.

            http://www.mysql.de/doc/de/Storage_requirements.html

            Spaltentyp                  Speicherbedarf
            CHAR(M)                     M Bytes, 1 <= M <= 255
            VARCHAR(M)                  L+1 Bytes, wobei L <= M und 1 <= M <= 255
            TINYBLOB, TINYTEXT          L+1 Bytes, wobei L < 2^8
            BLOB, TEXT                  L+2 Bytes, wobei L < 2^16
            MEDIUMBLOB, MEDIUMTEXT      L+3 Bytes, wobei L < 2^24
            LONGBLOB, LONGTEXT          L+4 Bytes, wobei L < 2^32
            ENUM('wert1','wert2',...)   1 oder 2 Bytes, abhängig von der Anzahl
                                        der Aufzählungswerte (65535 Werte maximal)
            SET('wert1','wert2',...)    1, 2, 3, 4 oder 8 Bytes, abhängig von der
                                        Anzahl von SET-Elementen (64 Elemente maximal)

            Ist ja auch angesichts der immer noch gültigen Segmentgrenzen für durchgeängige Speicherbereiche ganz logisch.

            Da musst Du dann den Datentyp wechseln und auf MediumBlob oder LongBlob umsteigen. Man sollte diese Typen aber nur benutzen, wenn sowieso immer der gesamte Dateiinhalt benötigt wird. Die Information über Dateiformat oder die ersten 256 Bytes sollte man dann ggf. nochmals gesondert (redundant) ablegen, sodass man immer Zugriff auf den Dateiheader hat, auch ohne die Nutzdaten komplett laden zu müssen.

            Liebe Grüße aus http://www.braunschweig.de

            Tom

            --
            Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen