ob_start

(PHP 4, PHP 5, PHP 7, PHP 8)

ob_startEnclenche la temporisation de sortie

Description

ob_start(?callable $callback = null, int $chunk_size = 0, int $flags = PHP_OUTPUT_HANDLER_STDFLAGS): bool

Cette fonction active la mise en mémoire tampon de la sortie. Lorsque la mise en mémoire tampon est active, aucune sortie n'est envoyée depuis le script ; au lieu de cela, la sortie est stockée dans une mémoire tampon interne. Consultez Quelle sortie est bufferisée ? pour savoir exactement quelles sorties sont concernées.

Les tampons de sortie sont empilables, c'est-à-dire ob_start() peut être appelée pendant qu'un autre tampon est actif. Si plusieurs tampons de sortie sont actifs, la sortie est filtrée séquentiellement à travers chacun d'eux dans l'ordre d'emboîtement. Consultez Imbrication des tampons de sortie pour plus de détails.

Consultez Tampons de sortie au niveau utilisateur pour une description détaillée des tampons de sortie.

Liste de paramètres

callback

Un callback callable optionnel peut être spécifié. Il peut également être contourné en passant null.

callback est invoqué lorsque le tampon de sortie est vidé (envoyé), nettoyé, ou lorsque le tampon de sortie est vidé à la fin du script.

La signature du callback est la suivante :

handler(string $buffer, int $phase = ?): string
buffer
Contenu du buffer de sortie.
phase
Masque de bits des constantes PHP_OUTPUT_HANDLER_* . Consultez Drapeaux passés aux gestionnaires de sortie pour plus de détails.

Si callback renvoie false, le contenu du tampon est renvoyé. Consultez Valeurs de retour des gestionnaires de sortie pour plus de détails.

Avertissement

Appeler l'une des fonctions suivantes à partir d'un gestionnaire de sortie entraînera une erreur fatale : ob_clean(), ob_end_clean(), ob_end_flush(), ob_flush(), ob_get_clean(), ob_get_flush(), ob_start().

Consultez Gestionnaires de sortie et Travailler avec les gestionnaires de sortie pour plus de détails sur les callbacks (gestionnaires de sortie).

chunk_size

Si le paramètre optionnel chunk_size est passé, la fonction de rappel est appelée à chaque nouvelle ligne après chunk_size octets d'affichage. La valeur par défaut 0 signifie que toute la sortie est mise en mémoire tampon jusqu'à ce que la mémoire tampon soit désactivée. Consultez Taille du tampon pour plus de détails.

flags

Le paramètre flags est un masque qui contrôle les opérations qui peuvent être effectuées sur le tampon de sortie. Par défaut, il autorise le tampon de sortie à être nettoyé, envoyé et supprimé, ce qui peut être défini explicitement avec les indicateurs de contrôle de la mémoire tampon . Consultez Opérations autorisées sur les tampons pour plus de détails.

Chaque drapeau contrôle l'accès à un jeu de fonctions, tel décrit ci-dessous :

Constante Fonctions
PHP_OUTPUT_HANDLER_CLEANABLE ob_clean(),
PHP_OUTPUT_HANDLER_FLUSHABLE ob_flush(),
PHP_OUTPUT_HANDLER_REMOVABLE ob_end_clean(), ob_end_flush() et ob_get_clean(). ob_get_flush().

Note: Avant PHP 8.4.0, le paramètre flags pouvait définir les drapeaux d'état du gestionnaire de sortie également.

Valeurs de retour

Cette fonction retourne true en cas de succès ou false si une erreur survient.

Exemples

Exemple #1 Exemple de gestion de sortie avec fonction de rappel

<?php

function rappel($buffer)
{
// remplace toutes les pommes par des carottes
return (str_replace("pommes de terre", "carottes", $buffer));
}

ob_start("rappel");

?>
<html>
<body>
<p>C'est comme comparer des carottes et des pommes de terre.</p>
</body>
</html>
<?php

ob_end_flush
();

?>

L'exemple ci-dessus va afficher :

<html>
<body>
<p>C'est comme comparer des carottes et des carottes.</p>
</body>
</html>

Exemple #2 Crée un tampon de sortie in-effaçable

<?php

ob_start
(null, 0, PHP_OUTPUT_HANDLER_STDFLAGS ^ PHP_OUTPUT_HANDLER_REMOVABLE);

?>

Voir aussi

add a note

User Contributed Notes 6 notes

up
53
Ray Paseur (Paseur ... ImagineDB.com)
19 years ago
You can use PHP to generate a static HTML page. Useful if you have a complex script that, for performance reasons, you do not want site visitors to run repeatedly on demand. A "cron" job can execute the PHP script to create the HTML page. For example:

<?php // CREATE index.html
ob_start();
/* PERFORM COMLEX QUERY, ECHO RESULTS, ETC. */
$page = ob_get_contents();
ob_end_clean();
$cwd = getcwd();
$file = "$cwd" .'/'. "index.html";
@
chmod($file,0755);
$fw = fopen($file, "w");
fputs($fw,$page, strlen($page));
fclose($fw);
die();
?>
up
20
net_navard at yahoo dot com
18 years ago
Hello firends

ob_start() opens a buffer in which all output is stored. So every time you do an echo, the output of that is added to the buffer. When the script finishes running, or you call ob_flush(), that stored output is sent to the browser (and gzipped first if you use ob_gzhandler, which means it downloads faster).

The most common reason to use ob_start is as a way to collect data that would otherwise be sent to the browser.

These are two usages of ob_start():

1-Well, you have more control over the output. Trivial example: say you want to show the user an error message, but the script has already sent some HTML to the browser. It'll look ugly, with a half-rendered page and then an error message. Using the output buffering functions, you can simply delete the buffer and sebuffer and send only the error message, which means it looks all nice and neat buffer and send
2-The reason output buffering was invented was to create a seamless transfer, from: php engine -> apache -> operating system -> web user

If you make sure each of those use the same buffer size, the system will use less writes, use less system resources and be able to handle more traffic.

With Regards, Hossein
up
28
ed.oohay (a) suamhcs_rodnan
21 years ago
Output Buffering even works in nested scopes or might be applied in recursive structures... thought this might save someone a little time guessing and testing :)

<pre><?php

ob_start
(); // start output buffer 1
echo "a"; // fill ob1

ob_start(); // start output buffer 2
echo "b"; // fill ob2
$s1 = ob_get_contents(); // read ob2 ("b")
ob_end_flush(); // flush ob2 to ob1

echo "c"; // continue filling ob1
$s2 = ob_get_contents(); // read ob1 ("a" . "b" . "c")
ob_end_flush(); // flush ob1 to browser

// echoes "b" followed by "abc", as supposed to:
echo "<HR>$s1<HR>$s2<HR>";

?></pre>

... at least works on Apache 1.3.28

Nandor =)
up
6
Asher Haig (ahaig at ridiculouspower dot com)
17 years ago
When a script ends, all buffered output is flushed (this is not a bug: http://bugs.php.net/bug.php?id=42334&thanks=4). What happens when the script throws an error (and thus ends) in the middle of an output buffer? The script spits out everything in the buffer before printing the error!

Here is the simplest solution I have been able to find. Put it at the beginning of the error handling function to clear all buffered data and print only the error:

$handlers = ob_list_handlers();
while ( ! empty($handlers) ) {
ob_end_clean();
$handlers = ob_list_handlers();
}
up
7
Chris
14 years ago
Careful with while using functions that change headers of a page; that change will not be undone when ending output buffering.

If you for instance have a class that generates an image and sets the appropriate headers, they will still be in place after the end of ob.

For instance:
<?php
ob_start
();
myClass::renderPng(); //header("Content-Type: image/png"); in here
$pngString = ob_get_contents();
ob_end_clean();
?>

will put the image bytes into $pngString, and set the content type to image/png. Though the image will not be sent to the client, the png header is still in place; if you do html output here, the browser will most likely display "image error, cannot be viewed", at least firefox does.

You need to set the correct image type (text/html) manually in this case.
up
3
ernest at vogelsinger dot at
19 years ago
When you rely on URL rewriting to pass the PHP session ID you should be careful with ob_get_contents(), as this might disable URL rewriting completely.

Example:
ob_start();
session_start();
echo '<a href=".">self link</a>';
$data = ob_get_contents();
ob_end_clean();
echo $data;

In the example above, URL rewriting will never occur. In fact, rewriting would occur if you ended the buffering envelope using ob_end_flush(). It seems to me that rewriting occurs in the very same buffering envelope where the session gets started, not at the final output stage.

If you need a scenario like the one above, using an "inner envelope" will help:

ob_start();
ob_start(); // add the inner buffering envelope
session_start();
echo '<a href=".">self link</a>';
ob_end_flush(); // closing the inner envelope will activate URL rewriting
$data = ob_get_contents();
ob_end_clean();
echo $data;

In case you're interested or believe like me that this is rather a design flaw instead of a feature, please visit bug #35933 (http://bugs.php.net/bug.php?id=35933) and comment on it.
To Top