I'm in the process of writing an API that relies on (file-)streams to be passed around.
There are situations where a string instead needs to be used, and for these purposes the data: stream wrapper is used. Initially I thought it was only possible to encode the actual string in base64, which I didn't like because of the added footprint.
- <?php
-
- $string = "I should have really done some laundry tonight.";
-
- $stream = fopen('data://text/plain;base64,' . base64_encode($string),'r');
-
- echo stream_get_contents($stream);
-
- ?>
Quickly checking out the rfc, it turns out that ';base64' can be omitted to just pass along the raw data, which makes a lot more sense in the context of PHP.
Thankfully, PHP gladly supports it:
- <?php
-
- $string = "I tried, honestly!";
-
- $stream = fopen('data://text/plain,' . $string,'r');
-
- echo stream_get_contents($stream);
-
- ?>
My favorite usage of the data: wrapper is for raw uploaded csv data. If you let user's cut-n-paste a csv for upload you can use the data: wrapper to fopen the POST data then fgetcsv() on it to save yourself from parsing it manually.
Great tip, thanks! I might use this to simplify some code I have that works with either IPC pipes or strings.
@Josh: Thanks for an awesome example of how to use it.
Note that PHP will read the data as an URL so the concatenated string must be URL encoded. The example above should read:
$stream = fopen('data://text/plain,' . urlencode($string), 'r');
Otherwise PHP will try to decode URL special characters like the "+" (as a space) or the hex chacter codes like "%20".
Uninformal micro benchmarks have shown that base64 is much faster than url encoding, so the preferred way to process strings with the stream api should be to use the base64 filter.