Why fread mistakes in reading binary file ?

Hello.. i'm using php on linux --version:

PHP 5.2.5 (cli) (built: Apr 25 2008 18:40:41)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

and i'm experiencing unexpected behavior using fread with a binary
file.
Look at this code: i have a jpeg image of 2290 bytes long, but fread
cannot read it correctly, like fgetc does:

<code>
$data1 = fread(fopen($f, 'r'),2290);

$h = fopen( $f, 'r' );
while(!feof($h))
$data2 .= fgetc($h);

echo "l1(".strlen($data1).") l2(".strlen($data2).")
size(".filesize($f).")\n";

for($i=0;$i<2290;$i++)
echo "Char($i) = d1(".ord($data1[$i]).") d2(".ord($data2[$i]).")
\n";
</code>

This is the output:

<output>
l1(2384) l2(2290) size(2290)
Char(0) = d1(255) d2(255)
Char(1) = d1(216) d2(216)
Char(2) = d1(255) d2(255)
Char(3) = d1(224) d2(224)
Char(4) = d1(92) d2(0)
Char(5) = d1(48) d2(16)
Char(6) = d1(16) d2(74)
Char(7) = d1(74) d2(70)
....
</output>

As you can see, the byte at position 4 is read as 0 (correctly, it is
0) with fgetc and as a 2-byte-long sequence 92-48 by fread.. resulting
in a corrupted file.
This behaviour is repeated whenever the file has a 0ed byte in its
content

Can anyone of you explain this ?..

Tnx

On Thu, 08 May 2008 22:50:16 +0200, Giacomo <giacomo.galilei@gmail.com>
wrote:

> Hello.. i'm using php on linux --version:
>
> PHP 5.2.5 (cli) (built: Apr 25 2008 18:40:41)
> Copyright (c) 1997-2007 The PHP Group
> Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
>
> and i'm experiencing unexpected behavior using fread with a binary
> file.
> Look at this code: i have a jpeg image of 2290 bytes long, but fread
> cannot read it correctly, like fgetc does:
>
> <code>
> $data1 = fread(fopen($f, 'r'),2290);
>
> $h = fopen( $f, 'r' );
> while(!feof($h))
> $data2 .= fgetc($h);
>
> echo "l1(".strlen($data1).") l2(".strlen($data2).")
> size(".filesize($f).")\n";
>
> for($i=0;$i<2290;$i++)
> echo "Char($i) = d1(".ord($data1[$i]).") d2(".ord($data2[$i]).")
> \n";
> </code>
>
> This is the output:
>
> <output>
> l1(2384) l2(2290) size(2290)
> Char(0) = d1(255) d2(255)
> Char(1) = d1(216) d2(216)
> Char(2) = d1(255) d2(255)
> Char(3) = d1(224) d2(224)
> Char(4) = d1(92) d2(0)
> Char(5) = d1(48) d2(16)
> Char(6) = d1(16) d2(74)
> Char(7) = d1(74) d2(70)
> ...
> </output>
>
> As you can see, the byte at position 4 is read as 0 (correctly, it is
> 0) with fgetc and as a 2-byte-long sequence 92-48 by fread.. resulting
> in a corrupted file.
> This behaviour is repeated whenever the file has a 0ed byte in its
> content

This works here:
<?php
echo phpversion()."\n";
$file = tempnam(dirname(__FILE__),'foo');
$f = fopen($file,'wb');
//Both work:
fwrite($f,chr(224).chr(0).chr(16));
fwrite($f,"a\0b");
fclose($f);
$data1 = fread(fopen($file, 'r'),2290);
$data2= "";
$h = fopen($file,'r');
while(!feof($h))
$data2 .= fgetc($h);
echo "l1(".strlen($data1).") l2(".strlen($data2).")
size(".filesize($file).")\n";
for($i=0;$i<filesize($file);$i++)
echo "Char($i) = d1(".ord($data1[$i]).") d2(".ord($data2[$i]).")\n";
?>
5.2.4
0
l1(6) l2(6) size(6)
Char(0) = d1(224) d2(224)
Char(1) = d1(0) d2(0)
Char(2) = d1(16) d2(16)
Char(3) = d1(97) d2(97)
Char(4) = d1(0) d2(0)
Char(5) = d1(98) d2(98)

What happens if you use fopen($f,'rb');?
--
Rik Wasmus

>
> What happens if you use fopen($f,'rb');?
> --
> Rik Wasmus

No changes, since 'rb' is equal to 'r' in linux; anyway i just migrate
to 5.2.6 and now fread works correctly

Bye bye

Giacomo <giacomo.galilei@gmail.com> wrote:
>
><output>
>l1(2384) l2(2290) size(2290)
>Char(0) = d1(255) d2(255)
>Char(1) = d1(216) d2(216)
>Char(2) = d1(255) d2(255)
>Char(3) = d1(224) d2(224)
>Char(4) = d1(92) d2(0)
>Char(5) = d1(48) d2(16)
>Char(6) = d1(16) d2(74)
>Char(7) = d1(74) d2(70)
>...
></output>
>
>As you can see, the byte at position 4 is read as 0 (correctly, it is
>0) with fgetc and as a 2-byte-long sequence 92-48 by fread.. resulting
>in a corrupted file.

For the record, did you notice that 92 48 are the ASCII ordinals for "\0"?
Somebody was escaping the nulls in your string.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.