f



prob with exec, exiftool and one photo

Hey all,

I have a folder with photos :

$ ls -al '/Users/yt/Sites/tests/Flipping_image/photos/'
total 4848
drwxr-xr-x  10 yt  staff   340B 13 déc 09:46 .
drwxr-xr-x  10 yt  staff   340B 13 déc 07:48 ..
-rw-r--r--   1 yt  staff   1,1M 12 déc 10:01 20161202_085945.jpg
-rw-r--r--   1 yt  staff    66K 13 déc 08:10 Cirques.jpg
-rw-r--r--   1 yt  staff   662K 13 déc 08:27 Cirques.png
-rw-r--r--   1 yt  staff   541K  6 déc 13:43 IMG_3130.JPG

those photos have the same user and group and also the same rights 
'-rw-r--r--'.

i need to read exif infos from those files using the php script :

   $EXIFTOOL = '/usr/local/bin/exiftool';
   $cmd = "$EXIFTOOL " . $data['PATH'];
   exec($cmd, $Infos, $ExitStatus);
   foreach($Infos as $line) {
     $fields = explode(' : ', $line, 2 );
     if(count($fields) == 2) {
       $data[rtrim($fields[0])] = $fields[1];
     }
   }
   $data['ExitStatus'] = $ExitStatus;

for 3 of those photos :
Cirques.jpg
Cirques.png
IMG_3130.JPG

i get back the good exif infos, like :
{
   "ExifTool Version Number":  "10.20",
   "File Name":  "IMG_3130.JPG",
   "Directory":  "\/Users\/yt\/Sites\/tests\/Flipping_image\/photos",
   "File Size":  "541 kB",
   [...]
   "Hyperfocal Distance":  "1.82 m",
   "Light Value":  "4.0",
   "ExitStatus":  0
}

($data is send thru json_encode)

however for the photo '20161202_085945.jpg' the php script returns 
nothing even no error althought I'm able, on terminal to retrieve those 
datas :
$ /usr/local/bin/exiftool 
/Users/yt/Sites/tests/Flipping_image/photos/20161202_085945.jpg
ExifTool Version Number         : 10.20
File Name                       : 20161202_085945.jpg
Directory                       : 
/Users/yt/Sites/tests/Flipping_image/photos
File Size                       : 1128 kB
File Modification Date/Time     : 2016:12:12 10:01:18+01:00

[...]

Field Of View                   : 60.3 deg
Focal Length                    : 3.7 mm (35 mm equivalent: 31.0 mm)
Hyperfocal Distance             : 1.47 m


the only difference I see is the weight of this photo (1,1MB, the other 
being less than 0.7MB)

then i need some light in order to find what is broken here.

best,

YT
0
UTF
12/13/2016 4:14:01 PM
comp.lang.php 32646 articles. 0 followers. Post Follow

30 Replies
213 Views

Similar Articles

[PageSpeed] 20

I forgot to mention I'm working on macOS Sierra with PHP 5.6.25.


0
UTF
12/13/2016 4:15:25 PM
On 13.12.2016 at 17:14, Une Bévue wrote:

> i need to read exif infos from those files using the php script :
> 
> […]
>
> however for the photo '20161202_085945.jpg' the php script returns
> nothing even no error althought I'm able, on terminal to retrieve those
> datas :
> $ /usr/local/bin/exiftool
> /Users/yt/Sites/tests/Flipping_image/photos/20161202_085945.jpg
> ExifTool Version Number         : 10.20
> File Name                       : 20161202_085945.jpg
> Directory                       :
> /Users/yt/Sites/tests/Flipping_image/photos
> File Size                       : 1128 kB
> File Modification Date/Time     : 2016:12:12 10:01:18+01:00
> 
> [...]
> 
> Field Of View                   : 60.3 deg
> Focal Length                    : 3.7 mm (35 mm equivalent: 31.0 mm)
> Hyperfocal Distance             : 1.47 m
> 
> 
> the only difference I see is the weight of this photo (1,1MB, the other
> being less than 0.7MB)
> 
> then i need some light in order to find what is broken here.

Due to security fixes in PHP 5.6.24 and 7.0.9 some of the Exif
funtionality has been broken.  So, which PHP version do you use?

-- 
Christoph M. Becker

0
Christoph
12/13/2016 4:28:15 PM
Une,

> the only difference I see is the weight of this photo (1,1MB,
> the other being less than 0.7MB)

Another difference is that the other three are compliant to the old 8.3 DOS
format, while the latter has a much longer filename.

Try renaming it to something short and see what happens.

Regards,
Rudy Wieser


-- Origional message:
Une B�vue <unbewusst.sein@fai.invalid> schreef in berichtnieuws
o2p6o9$pgl$1@shakotay.alphanet.ch...
> Hey all,
>
> I have a folder with photos :
>
> $ ls -al '/Users/yt/Sites/tests/Flipping_image/photos/'
> total 4848
> drwxr-xr-x  10 yt  staff   340B 13 d�c 09:46 .
> drwxr-xr-x  10 yt  staff   340B 13 d�c 07:48 ..
> -rw-r--r--   1 yt  staff   1,1M 12 d�c 10:01 20161202_085945.jpg
> -rw-r--r--   1 yt  staff    66K 13 d�c 08:10 Cirques.jpg
> -rw-r--r--   1 yt  staff   662K 13 d�c 08:27 Cirques.png
> -rw-r--r--   1 yt  staff   541K  6 d�c 13:43 IMG_3130.JPG
>
> those photos have the same user and group and also the same rights
> '-rw-r--r--'.
>
> i need to read exif infos from those files using the php script :
>
>    $EXIFTOOL = '/usr/local/bin/exiftool';
>    $cmd = "$EXIFTOOL " . $data['PATH'];
>    exec($cmd, $Infos, $ExitStatus);
>    foreach($Infos as $line) {
>      $fields = explode(' : ', $line, 2 );
>      if(count($fields) == 2) {
>        $data[rtrim($fields[0])] = $fields[1];
>      }
>    }
>    $data['ExitStatus'] = $ExitStatus;
>
> for 3 of those photos :
> Cirques.jpg
> Cirques.png
> IMG_3130.JPG
>
> i get back the good exif infos, like :
> {
>    "ExifTool Version Number":  "10.20",
>    "File Name":  "IMG_3130.JPG",
>    "Directory":  "\/Users\/yt\/Sites\/tests\/Flipping_image\/photos",
>    "File Size":  "541 kB",
>    [...]
>    "Hyperfocal Distance":  "1.82 m",
>    "Light Value":  "4.0",
>    "ExitStatus":  0
> }
>
> ($data is send thru json_encode)
>
> however for the photo '20161202_085945.jpg' the php script returns
> nothing even no error althought I'm able, on terminal to retrieve those
> datas :
> $ /usr/local/bin/exiftool
> /Users/yt/Sites/tests/Flipping_image/photos/20161202_085945.jpg
> ExifTool Version Number         : 10.20
> File Name                       : 20161202_085945.jpg
> Directory                       :
> /Users/yt/Sites/tests/Flipping_image/photos
> File Size                       : 1128 kB
> File Modification Date/Time     : 2016:12:12 10:01:18+01:00
>
> [...]
>
> Field Of View                   : 60.3 deg
> Focal Length                    : 3.7 mm (35 mm equivalent: 31.0 mm)
> Hyperfocal Distance             : 1.47 m
>
>
> the only difference I see is the weight of this photo (1,1MB, the other
> being less than 0.7MB)
>
> then i need some light in order to find what is broken here.
>
> best,
>
> YT



0
R
12/13/2016 5:03:43 PM
Le 13/12/2016 à 17:28, Christoph M. Becker a écrit :
> Due to security fixes in PHP 5.6.24 and 7.0.9 some of the Exif
> funtionality has been broken.  So, which PHP version do you use?
PHP Version 5.6.25

Butnotice I'm not using an Exif functionnality bultin PHP but rather the 
commandline exiftool.

0
UTF
12/13/2016 5:23:40 PM
Le 13/12/2016 à 18:03, R.Wieser a écrit :
> Another difference is that the other three are compliant to the old 8.3 DOS
> format, while the latter has a much longer filename.

OK, but I'm using macOS Sierra...

> Try renaming it to something short and see what happens.

Anyway, I renamed it 'glasgow.jpg', no result with php, and again using 
terminal I got it :

$ exiftool /Users/yt/Sites/tests/Flipping_image/photos/glasgow.jpg
ExifTool Version Number         : 10.20
File Name                       : glasgow.jpg
Directory                       : 
/Users/yt/Sites/tests/Flipping_image/photos
File Size                       : 1128 kB
File Modification Date/Time     : 2016:12:12 10:01:18+01:00

[...]

Circle Of Confusion             : 0.004 mm
Field Of View                   : 60.3 deg
Focal Length                    : 3.7 mm (35 mm equivalent: 31.0 mm)
Hyperfocal Distance             : 1.47 m
0
UTF
12/13/2016 5:28:52 PM
On 12/13/2016 05:14 PM, Une Bévue wrote:

> i need to read exif infos from those files using the php script :
> 
>   $EXIFTOOL = '/usr/local/bin/exiftool';
>   $cmd = "$EXIFTOOL " . $data['PATH'];
>   exec($cmd, $Infos, $ExitStatus);
>   foreach($Infos as $line) {
>     $fields = explode(' : ', $line, 2 );
>     if(count($fields) == 2) {
>       $data[rtrim($fields[0])] = $fields[1];
>     }
>   }
>   $data['ExitStatus'] = $ExitStatus;
> 
> for 3 of those photos :
> Cirques.jpg
> Cirques.png
> IMG_3130.JPG
> 
> i get back the good exif infos, like :
> {
>   "ExifTool Version Number":  "10.20",
>   "File Name":  "IMG_3130.JPG",
>   "Directory":  "\/Users\/yt\/Sites\/tests\/Flipping_image\/photos",
>   "File Size":  "541 kB",
>   [...]
>   "Hyperfocal Distance":  "1.82 m",
>   "Light Value":  "4.0",
>   "ExitStatus":  0
> }
> 
> however for the photo '20161202_085945.jpg' the php script returns
> nothing even no error

What's the exit status code?

Have you verified that the path is correct? Is it a full path or a
relative path (in this case it may not be relative to the script
executed first)?


If your script takes all the files in the directory, but always missing
one file, then your outer loop has issues, as you haven't provided how
you get your $data in the first place, it's just a guessing game for us
who ain't mind readers.


-- 

 //Aho


0
J
12/13/2016 10:42:03 PM
On 13.12.2016 at 18:23, Une Bévue wrote:

> Le 13/12/2016 à 17:28, Christoph M. Becker a écrit :
>
>> Due to security fixes in PHP 5.6.24 and 7.0.9 some of the Exif
>> funtionality has been broken.  So, which PHP version do you use?
>
> PHP Version 5.6.25
> 
> Butnotice I'm not using an Exif functionnality bultin PHP but rather the
> commandline exiftool.

I was so fixated on the ext/exif issues that I didn't fully read your
post.  Sorry for the noise!

-- 
Christoph M. Becker


0
Christoph
12/13/2016 11:19:12 PM
Thomas,

> and *you* have not used the correct locale encoding to decode it.

Thats bull, and you know it.   It does not need to be "decoded", it needs to
be *extracted", and nothing more.

The only place where that locale decoding is needed is when it needs to be
*displayed*.   Nowhere else.


Une, there *might* be a possibility that PHP for some reason does not want
to store unicode and therefore returns an empty result.

J.O. did a good suggestion: Check which error is returned.  It's provided
especially for you as the programmer so you have an easier task to home-in
on the cause of the problem.

Also, do not let "pointed ears" here scare you.  He's just like that.  He
tries to sound as if he's either some internet cop or otherwise allowed to
make demands, but he's harmless.

> You are an obnoxious, anti-social pseudonymous address munger
> who does not deserve this piece of advice

And as always you are the hypocrite, demanding stuff like other people must
use "true names" -- and even telling them where exactly in the message they
should put it --  while violating it yourself with impunity.  :-)

Regards,
Rudy Wieser



-- Origional message:
Thomas 'PointedEars' Lahn <PointedEars@web.de> schreef in berichtnieuws
3256428.MHq7AAxBmi@PointedEars.de...
> Une B�vue wrote:
>
> > from command line, using :
> > exiftool  -s
> > '/Users/yt/Sites/tests/Flipping_image/photos/20161202_085945.jpg'
> >
> > i saw a faulty encoding line :
> > Comment                         : File written by Adobe Photoshop? 5.0
> > looks here_______________________________________________________^_____
>
> That is not faulty encoding; the "?" ("R") for "registered trademark" or
the
> "T" ("(tm)") for "trademark" *belongs there*, and *you* have not used the
> correct locale encoding to decode it.
>
> But as you can see from my other follow-up, you have much bigger problems
to
> solve than "faulty encoding".
>
> --
> PointedEars
> Zend Certified PHP Engineer
<http://www.zend.com/en/yellow-pages/ZEND024953>
> <https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
> Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per
E-Mail.


0
R
12/14/2016 1:01:01 AM
Le 13/12/2016 à 23:42, J.O. Aho a écrit :
> What's the exit status code?
>
> Have you verified that the path is correct? Is it a full path or a
> relative path (in this case it may not be relative to the script
> executed first)?

full PATH

>
> If your script takes all the files in the directory, but always missing
> one file, then your outer loop has issues, as you haven't provided how
> you get your $data in the first place, it's just a guessing game for us
> who ain't mind readers.

no the script is activated by :
http://mbp.local/tests/Flipping_image/php/exiftool-json.php?PATH=/Users/yt/Sites/tests/Flipping_image/photos/glasgow.jpg

and the whole script is :

<?php
$EXIFTOOL = "/usr/local/bin/exiftool";
$SITES = "/Users/yt/Sites";
$data = array();
if(isset($_GET['URL'])) {
   $data['URL'] = $_GET['URL'];
   $data['PATH'] = $SITES . $_GET['URL'];
}
if(isset($_GET['PATH'])) {
   $data['URL'] = explode($SITES, $_GET['PATH'], 2 )[1];
   $data['PATH'] = $_GET['PATH'];
}
header('Content-Type: application/javascript');
date_default_timezone_set('Europe/Paris');
setlocale(LC_CTYPE, 'fr_FR');
error_reporting(E_ALL);

function exifTool() {
   global $EXIFTOOL;
   global $data;
   $cmd = "$EXIFTOOL " . $data['PATH'];
   exec($cmd, $Infos, $ExitStatus);
   foreach($Infos as $line) {
     $fields = explode(' : ', $line, 2 );
     if(count($fields) == 2) {
       $data[rtrim($fields[0])] = $fields[1];
     }
   }
   $data['ExitStatus'] = $ExitStatus;
   return $data;
}
echo json_encode(exifTool());
?>

the script is not missing one file. even if I hardcode the path within 
the script has for example :
$data['PATH'] = '/Users/yt/Sites/tests/Flipping_image/photos/glasgow.jpg';

i get absolutely nothing. no errors.

0
UTF
12/14/2016 6:02:40 AM
from command line, using :
exiftool  -s 
'/Users/yt/Sites/tests/Flipping_image/photos/20161202_085945.jpg'

i saw a faulty encoding line :
Comment                         : File written by Adobe Photoshop� 5.0
looks here_______________________________________________________^_____

then i write to the file :

$ exiftool  -s -Comment='' 
'/Users/yt/Sites/tests/Flipping_image/photos/20161202_085945.jpg'
     1 image files updated

afterwards I'm able to read other infos, using php.

I don't know this comment tag speaking about photoshop, because this 
photo comes from a Samsung SM-N7505 phone.

The photo, by itself didn't be open by Photoshop rather send by email...
0
UTF
12/14/2016 7:11:39 AM
Une Bévue wrote:

> Le 13/12/2016 à 23:42, J.O. Aho a écrit :
>> What's the exit status code?
>>
>> Have you verified that the path is correct? Is it a full path or a
>> relative path (in this case it may not be relative to the script
>> executed first)?
> 
> full PATH
> 
>> If your script takes all the files in the directory, but always missing
>> one file, then your outer loop has issues, as you haven't provided how
>> you get your $data in the first place, it's just a guessing game for us
>> who ain't mind readers.
> 
> no the script is activated by :
> http://mbp.local/tests/Flipping_image/php/exiftool-json.php?PATH=/Users/yt/Sites/tests/Flipping_image/photos/glasgow.jpg

You are an obnoxious, anti-social pseudonymous address munger who does not 
deserve this piece of advice.  But to prevent you from harming others in 
your blissful ignorance, and as a warning to others, I am making an 
exception and reply:

You *really* do NOT want to do that.  The least you want to do here is 
calling escapeshellarg($_GET['PATH']) before you pass it to exec(), so that 
an attacker cannot execute *arbitrary code* on that box (see below for an 
example of that).

But even then allowing *anyone* to access *any* file on that box poses a 
great security risk.  You must realize that as by your code any information 
output by exiftool(1) is contained in the JSON HTTP response, an attacker 
can determine which files are on that box, what is the file size, the file 
modification and access times, the file permissions, and for which processor 
architecture have binaries been compiled.  Because exiftool(1) is much more 
than just a tool to read EXIF (image) metadata.

Fasten your seatbelt and try

http://mbp.local/tests/Flipping_image/php/exiftool-json.php?PATH=/bin/sh

I can debug this manually, and make a good prediction as to what you will 
get:

> and the whole script is :
> 
> <?php
> $EXIFTOOL = "/usr/local/bin/exiftool";
> $SITES = "/Users/yt/Sites";
> $data = array();

processed

> if(isset($_GET['URL'])) {

false

>    $data['URL'] = $_GET['URL'];
>    $data['PATH'] = $SITES . $_GET['URL'];
> }

ignored

> if(isset($_GET['PATH'])) {

true

>    $data['URL'] = explode($SITES, $_GET['PATH'], 2 )[1];

irrelevant

>    $data['PATH'] = $_GET['PATH'];

  $data['PATH'] = '/bin/sh';

> }
> header('Content-Type: application/javascript');

That is the *wrong* MIME media type for a JSON response.  JSON is a data 
format, not executable source code.

<http://json.org/>
<http://fr.wikipedia.org/wiki/JSON>

> date_default_timezone_set('Europe/Paris');
> setlocale(LC_CTYPE, 'fr_FR');
> error_reporting(E_ALL);
> 
> function exifTool() {
>    global $EXIFTOOL;
>    global $data;
>    $cmd = "$EXIFTOOL " . $data['PATH'];

  $cmd = "/usr/local/bin/exiftool /bin/sh";

>    exec($cmd, $Infos, $ExitStatus);

  exec("/usr/local/bin/exiftool /bin/sh", $Infos, $ExitStatus);

Imagine what would have happened here if I had accessed

http://mbp.local/tests/…/php/exiftool-json.php?PATH=%2F%3Brm%20-rf%20%2F

(Just IMAGINE; DO NOT TRY this [at least not without changing “exec” to 
“echo”]!)

>    foreach($Infos as $line) {
>      $fields = explode(' : ', $line, 2 );
>      if(count($fields) == 2) {

AFAICS there will always be two fields with exiftool(1).

>        $data[rtrim($fields[0])] = $fields[1];
>      }
>    }
> 
>    $data['ExitStatus'] = $ExitStatus;

  $data = [
    'URL'                             => 'something irrelevant',
    'PATH'                            => '/bin/sh',
    'ExifTool Version Number        ' => '10.25',
    'File Name                      ' => 'sh',
    'Directory                      ' => '/bin',
    'File Size                      ' => '110 kB',
    'File Modification Date/Time    ' => '2016:07:05 23:59:04+02:00',
    'File Access Date/Time          ' => '2016:12:14 10:44:49+01:00',
    'File Inode Change Date/Time    ' => '2016:07:10 17:50:26+02:00',
    'File Permissions               ' => 'rwxr-xr-x',
    'File Type                      ' => 'ELF shared library',
    'File Type Extension            ' => 'so',
    'MIME Type                      ' => 'application/octet-stream',
    'CPU Architecture               ' => '64 bit',
    'CPU Byte Order                 ' => 'Little endian',
    'Object File Type               ' => 'Shared object file',
    'CPU Type                       ' => 'AMD x86-64',
    'ExitStatus'                      => 0
  ];

or similar.

>    return $data;
> }
> echo json_encode(exifTool());
> ?>

Omit the last line: <http://www.php-fig.org/psr/psr-2/#2-2-files>
 
> the script is not missing one file. even if I hardcode the path within
> the script has for example :
> $data['PATH'] = '/Users/yt/Sites/tests/Flipping_image/photos/glasgow.jpg';
> 
> i get absolutely nothing. no errors.

There may be no error messages, but certainly there is an _$ExitStatus_ (as 
your fellow anti-social address munger, “J.O. Aho”, said).

Also, $data is only filled if there are exactly two fields.  Maybe that is 
the problem – in addition to the many other problems with this code.

-- 
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.
0
Thomas
12/14/2016 4:37:05 PM
Une Bévue wrote:

> from command line, using :
> exiftool  -s
> '/Users/yt/Sites/tests/Flipping_image/photos/20161202_085945.jpg'
> 
> i saw a faulty encoding line :
> Comment                         : File written by Adobe Photoshop� 5.0
> looks here_______________________________________________________^_____

That is not faulty encoding; the “Ⓡ” (“R”) for “registered trademark” or the 
“™” (“(tm)”) for “trademark” *belongs there*, and *you* have not used the 
correct locale encoding to decode it.

But as you can see from my other follow-up, you have much bigger problems to 
solve than "faulty encoding".

-- 
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.
0
Thomas
12/14/2016 4:43:12 PM
Le 14/12/2016 à 17:37, Thomas 'PointedEars' Lahn a écrit :
>> }
>> header('Content-Type: application/javascript');
> That is the *wrong* MIME media type for a JSON response.  JSON is a data
> format, not executable source code.

U're right ! according to :
<http://www.ietf.org/rfc/rfc4627.txt>

i changed that to :
header('Content-Type: application/json');

for the security issue, i don't take care because this page in only a 
***local*** test.

0
UTF
12/14/2016 5:13:53 PM
Le 14/12/2016 à 17:43, Thomas 'PointedEars' Lahn a écrit :
> That is not faulty encoding; the “Ⓡ” (“R”) for “registered trademark” or the
> “™” (“(tm)”) for “trademark” *belongs there*, and *you* have not used the
> correct locale encoding to decode it.

my locale encoding is "fr_FR.UTF-8".

I don't want to change it for Photoshop ;-)

I think if "Ⓡ” is the correct glyph, I would have seen it on terminal :
..-[yt@mbp.local:~]-[16-12-14 18:20:35]
'->$ set toto ®
..-[yt@mbp.local:~]-[16-12-14 18:20:35]
'->$ echo $toto
®

then the metadatas for this photo isn't UTF-8 encoded ?
only US-ASCII is correct.
0
UTF
12/14/2016 5:24:06 PM
R.Wieser wrote:

> Thomas,

Don’t you "Thomas" me, _R._Wieser.  You have yet to earn that privilege.

>> and *you* have not used the correct locale encoding to decode it.
> 
> Thats bull, and you know it.   It does not need to be "decoded", it needs
> to be *extracted", and nothing more.

Utter nonsense.
 
> The only place where that locale decoding is needed is when it needs to be
> *displayed*.   Nowhere else.

Not displayed, but output.  And, if you cared to read, they are using the 
output of an external program.
 
> Une, there *might* be a possibility that PHP for some reason does not want
> to store unicode and therefore returns an empty result.

And Santa Claus comes down the chimney.
 
>> You are an obnoxious, anti-social pseudonymous address munger
>> who does not deserve this piece of advice
> 
> And as always you are the hypocrite, demanding stuff like other people
> must use "true names" -- and even telling them where exactly in the
> message they should put it --  while violating it yourself with impunity.  

I would have killfiled you for this if that were not done automatically 
already because of your anti-social address munging on top of your anti-
social denying to post with your real name.  FOAD.

-- 
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.
0
Thomas
12/14/2016 6:39:52 PM
Une Bévue wrote:

> Le 14/12/2016 à 17:43, Thomas 'PointedEars' Lahn a écrit :
>> That is not faulty encoding; the “Ⓡ” (“R”) for “registered trademark” or
>> the “™” (“(tm)”) for “trademark” *belongs there*, and *you* have not used
>> the correct locale encoding to decode it.
> 
> my locale encoding is "fr_FR.UTF-8".
> 
> I don't want to change it for Photoshop ;-)

You could change it temporarily when executing exiftool(1).

But you really need to fix the gaping security leaks in your code first.

When you have done that, you need to post with an e-mail address and a real 
name before I consider reading to your postings again.  I can only give you 
that much leeway.

> then the metadatas for this photo isn't UTF-8 encoded ?

Very likely.

> only US-ASCII is correct.

How did you get that idea?

-- 
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.
0
Thomas
12/14/2016 6:57:53 PM
In comp.lang.php, Une Bévue  <unbewusst.sein@fai.invalid> wrote:
> from command line, using :
> exiftool  -s 
> '/Users/yt/Sites/tests/Flipping_image/photos/20161202_085945.jpg'
> 
> i saw a faulty encoding line :
> Comment                         : File written by Adobe Photoshop� 5.0
> looks here_______________________________________________________^_____

Not-so-much faulty as software that doesn't understand character set
encodings. JPEG comments are a 32,767 octet block of whatever randomness
you want to put in there. There is no way to indicate what encoding or
set of characters are represented. Adobe is probably just using
something stupid like ISO-8859-1 or (worse) the Microsoft "equivilents"
like Windows-1250 or Windows-1252.

The JPEG file format dates back to the bad old days of "ASCII is good
enough for everyone (but we'll grudgingly allow EBCIDIC, too)".

http://www.unicode.org/history/publicationdates.html
	1.0.0 	1991 	October

http://fileformats.archiveteam.org/wiki/JFIF
	JFIF 1.00 (undated)
	JFIF 1.01 (1991-12-10) may have changed the subsampling
	     position to centered. 

(JFIF is JPEG File Interchange Format; that was the first standardized
way to store JPEG compressed data; now JPEG could be JFIF or Exif, which
is a modified JFIF.)

Elijah
------
(would recommend ignoring pointedly-rude pointedears)
0
Eli
12/14/2016 10:19:03 PM
Le 14/12/2016 à 19:01, R.Wieser a écrit :
> Une, there *might* be a possibility that PHP for some reason does not want
> to store unicode and therefore returns an empty result.
>
> J.O. did a good suggestion: Check which error is returned.

That's true, however, with that Trademark glyph in the comment field, I 
don't have even an error, with :
exec($cmd, $Infos, $ExitStatus);

$Infos and $ExitStatus are empty...

In fact, in the meantime, I've found another solution, for the time 
being : don't read comment field.

then my $cmd has to be completed :
   $options = '-s -c \"%.8f\" ' . $data['short_options'];
   $cmd = "$EXIFTOOL $options" . $data['PATH'];

with :

$EXIFTOOL = "/usr/local/bin/exiftool";

and "$data['short_options']" build from :
$SHORT_INFOS = array();
$SHORT_INFOS['XMP'] = ['Lens'];
$SHORT_INFOS['EXIF'] = explode(' ', 'Make Model ExposureTime FNumber ISO 
FlashMode FocalLength');

$data['short_options'] = getOptions($SHORT_INFOS);

function getOptions($tab) {
   $out = ' ';
   foreach ($tab as $key => $fields){
       foreach($fields as $field) {
         $out .= "-$key:$field ";
       }
   }
   return $out;
}


0
UTF
12/15/2016 5:19:07 AM
Le 14/12/2016 à 23:19, Eli the Bearded a écrit :
> Adobe is probably just using
> something stupid like ISO-8859-1 or (worse) the Microsoft "equivilents"
> like Windows-1250 or Windows-1252.

I do agree with that, because when using exiftool by command line on 
terminal I get a question mark in a square instead of ®.
Generally it is due to ISO-8859-1 coded character in US_ASCII / UTF-8.
By terminal (macOS Sierra) works well with UTF-8 even with 🍺...


0
UTF
12/15/2016 5:30:45 AM
Thomas,

> Utter nonsense.

Poppycock.

> Not displayed, but output.

Not output, just stored.

> And, if you cared to read, they are using the output of an external
program.

You say that is if its important.    Which it isn't.

> And Santa Claus comes down the chimney.

Actually that sounds less dumb than you "you just match your local language
setting with whatever is used in the image" suggestion.   Really doable when
those pictures could come from sources (people as well as devices) the OP
has absolutily no control over.

And there has even been talk that Santa can "fold" himself so he can even
pass thru the smallest of airducts, to visit the good kids in homes without
a fireplace. :-)

> I would have killfiled you for this if that were not done automatically
> already because of your anti-social address munging on top of your anti-
> social denying to post with your real name.  FOAD.

Lol.   You would just doing me a favour, as I can than just warn other
people without you posting another of your obnoxious "I'm the president of
the internet, heed my demands" posts. :-)

Besides, you're lying.  You neither killfile, nor are doing it
automatically.  How I know that ?   Because we met before where you said
pretty-much the same and you *still* respond to my posts. :-)

> because of your anti-social address munging on top of your
> anti-social denying to post with your real name

Lol again.   The hypocrite demanding something he refuses to give himself,
and just plain stupid enough to not being able to understand, in this
time-and-age of internet spam, why email adresses are being kept private.

Regards,
Rudy Wieser


-- Origional message:
Thomas 'PointedEars' Lahn <PointedEars@web.de> schreef in berichtnieuws
2144039.jE0xQCEvom@PointedEars.de...
> R.Wieser wrote:
>
> > Thomas,
>
> Don't you "Thomas" me, _R._Wieser.  You have yet to earn that privilege.
>
> >> and *you* have not used the correct locale encoding to decode it.
> >
> > Thats bull, and you know it.   It does not need to be "decoded", it
needs
> > to be *extracted", and nothing more.
>
> Utter nonsense.
>
> > The only place where that locale decoding is needed is when it needs to
be
> > *displayed*.   Nowhere else.
>
> Not displayed, but output.  And, if you cared to read, they are using the
> output of an external program.
>
> > Une, there *might* be a possibility that PHP for some reason does not
want
> > to store unicode and therefore returns an empty result.
>
> And Santa Claus comes down the chimney.
>
> >> You are an obnoxious, anti-social pseudonymous address munger
> >> who does not deserve this piece of advice
> >
> > And as always you are the hypocrite, demanding stuff like other people
> > must use "true names" -- and even telling them where exactly in the
> > message they should put it --  while violating it yourself with
impunity.
>
> I would have killfiled you for this if that were not done automatically
> already because of your anti-social address munging on top of your anti-
> social denying to post with your real name.  FOAD.
>
> --
> PointedEars
> Zend Certified PHP Engineer
<http://www.zend.com/en/yellow-pages/ZEND024953>
> <https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
> Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per
E-Mail.


0
R
12/17/2016 1:01:01 AM
Une,

I don't think its unsolvable, but maybe it takes a bit more work.

Going back to your first post:

   $EXIFTOOL = '/usr/local/bin/exiftool';
   $cmd = "$EXIFTOOL " . $data['PATH'];
   exec($cmd, $Infos, $ExitStatus);
   foreach($Infos as $line) {
     $fields = explode(' : ', $line, 2 );
     if(count($fields) == 2) {
       $data[rtrim($fields[0])] = $fields[1];
     }
   }
   $data['ExitStatus'] = $ExitStatus;

Have you ever display the contents of the $Infos array (print_r) ?   Did it
contain anything ?    If it does, have you displayed the contents of each
$line ?

If $Infos doesn't contain anything you might do a google for information
about that "exec" command in combination with character encodings.

But if you just want the data you could try to output the exif data into a
file ("'/usr/local/bin/exiftool' > temp.dat"), and than check if the file
contains the data.   If it does you could see what happens when you try to
parse that file (even if it does not work you're likely to get a usable
error).

Regards,
Rudy Wieser


-- Origional message:
Une B�vue <unbewusst@fai.invalid> schreef in berichtnieuws
o32o8o$ec2$1@shakotay.alphanet.ch...
> Le 14/12/2016 � 23:19, Eli the Bearded a �crit :
> > Not-so-much faulty as software that doesn't understand character set
> > encodings.
>
> In fact, after reading the photo content it appears that the only wrong
> "character" is ? (C2 AE in UTF-8) encoded in MacRoman as "A8" in this
> file who's encoding is UTF-8.
>
> No way to change that any :
> -charset exif=MacRoman, doesn't work.
>
>


0
R
12/17/2016 1:01:01 AM
Une,

> > Have you ever display the contents of the $Infos array (print_r) ?
> > Did it contain anything ?    If it does, have you displayed the contents
> > of each $line ?
>
> As I said : no output at all !

Yeah, but as far as I can tell you have just been looking at the $data array
result, not at any of the intermediate variables.    Correct me if I'm
wrong.

> Obviously, this should work reading the "temp.dat" in byte mode

You do not understand: If that file gets filled with data it stands to
reason that the $Infos variable also gets filled.   If the file gets filled
but the variable not then there would be something rather odd on, possibly
with the "exec" command (on the other hand, that "exec" command may be
exactly doing what its told to do, and we simply are not aware of what it
has been told :-) ).

In other words: I'm not working towards a solution, I'm working towards
figuring out where the problem actually occurs, and what causes it.  Which
those two in hand you're much more likely to find a/the solution.

Also, with that temp file you have a possibility to check what's *really*
been outputted.    Maybe you'll even find that there is a ctrl-z in there
(EOF), causing the capturing of standard output (from the exiftool) to
terminate early.  Who knows.

> Rather heavy for one char isnt'it?

If its really only for that one character, and you already have a method to
deal with it than I could agree with you.    But as you have no idea what
actually causes the problem of the character resulting in an emptyresult you
might be bumping into other characters causing the same effect too.    And
ofcourse, if we may take Murphy's Law as a guideline, at the most
in-opportune moment imaginable. :-)

Regards,
Rudy Wieser


-- Origional message:
Une B�vue <unbewusst.sein@fai.invalid> schreef in berichtnieuws
o331fg$vqi$1@shakotay.alphanet.ch...
> Le 17/12/2016 � 09:26, R.Wieser a �crit :
> > Have you ever display the contents of the $Infos array (print_r) ?   Did
it
> > contain anything ?    If it does, have you displayed the contents of
each
> > $line ?
>
> As I said : no output at all !
>
> > If $Infos doesn't contain anything you might do a google for information
> > about that "exec" command in combination with character encodings.
>
> Yes, right, but, from carfull hex reding of the datascontained in this
> photo, the encoding of the exif part (and like) is in UTF-8 only one
> character is in MacRoman.
>
> > But if you just want the data you could try to output the exif data into
a
> > file ("'/usr/local/bin/exiftool' > temp.dat"), and than check if the
file
> > contains the data.   If it does you could see what happens when you try
to
> > parse that file (even if it does not work you're likely to get a usable
> > error).
>
> Obviously, this should work reading the "temp.dat" in byte mode (as of a
> binary file) then, rewriting "A8" (ie. MacRoman) to "C2 AE" (UTF-8).
>
> Rather heavy for one char isnt'it?
>
> I'll try that this afternoon...
>


0
R
12/17/2016 1:01:01 AM
Le 14/12/2016 à 23:19, Eli the Bearded a écrit :
> Not-so-much faulty as software that doesn't understand character set
> encodings.

In fact, after reading the photo content it appears that the only wrong 
"character" is Ⓡ (C2 AE in UTF-8) encoded in MacRoman as "A8" in this 
file who's encoding is UTF-8.

No way to change that any :
-charset exif=MacRoman, doesn't work.


0
UTF
12/17/2016 7:08:06 AM
Le 17/12/2016 à 09:26, R.Wieser a écrit :
> Have you ever display the contents of the $Infos array (print_r) ?   Did it
> contain anything ?    If it does, have you displayed the contents of each
> $line ?

As I said : no output at all !

> If $Infos doesn't contain anything you might do a google for information
> about that "exec" command in combination with character encodings.

Yes, right, but, from carfull hex reding of the datascontained in this 
photo, the encoding of the exif part (and like) is in UTF-8 only one 
character is in MacRoman.

> But if you just want the data you could try to output the exif data into a
> file ("'/usr/local/bin/exiftool' > temp.dat"), and than check if the file
> contains the data.   If it does you could see what happens when you try to
> parse that file (even if it does not work you're likely to get a usable
> error).

Obviously, this should work reading the "temp.dat" in byte mode (as of a 
binary file) then, rewriting "A8" (ie. MacRoman) to "C2 AE" (UTF-8).

Rather heavy for one char isnt'it?

I'll try that this afternoon...

0
UTF
12/17/2016 9:45:20 AM
On 12/17/2016 3:11 AM, R.Wieser wrote:
> Thomas,
> 
>> Utter nonsense.
> 
> Poppycock.
> 
>> Not displayed, but output.
> 
> Not output, just stored.
> 
>> And, if you cared to read, they are using the output of an external
> program.
> 
> You say that is if its important.    Which it isn't.
> 
>> And Santa Claus comes down the chimney.
> 
> Actually that sounds less dumb than you "you just match your local language
> setting with whatever is used in the image" suggestion.   Really doable when
> those pictures could come from sources (people as well as devices) the OP
> has absolutily no control over.
> 
> And there has even been talk that Santa can "fold" himself so he can even
> pass thru the smallest of airducts, to visit the good kids in homes without
> a fireplace. :-)
> 
>> I would have killfiled you for this if that were not done automatically
>> already because of your anti-social address munging on top of your anti-
>> social denying to post with your real name.  FOAD.
> 
> Lol.   You would just doing me a favour, as I can than just warn other
> people without you posting another of your obnoxious "I'm the president of
> the internet, heed my demands" posts. :-)
> 
> Besides, you're lying.  You neither killfile, nor are doing it
> automatically.  How I know that ?   Because we met before where you said
> pretty-much the same and you *still* respond to my posts. :-)
> 
>> because of your anti-social address munging on top of your
>> anti-social denying to post with your real name
> 
> Lol again.   The hypocrite demanding something he refuses to give himself,
> and just plain stupid enough to not being able to understand, in this
> time-and-age of internet spam, why email adresses are being kept private.
> 
> Regards,
> Rudy Wieser
> 
> 

That's Pointed Head for you, Rudy.  He never has anything positive to
add to a conversation but demands everyone follow *his* rules.  Its no
wonder he is known as a troll in so many newsgroups.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
0
Jerry
12/17/2016 2:33:22 PM
Le 17/12/2016 à 11:41, R.Wieser a écrit :
> Une,
>
>>> Have you ever display the contents of the $Infos array (print_r) ?
>>> Did it contain anything ?    If it does, have you displayed the contents
>>> of each $line ?
>> As I said : no output at all !
> Yeah, but as far as I can tell you have just been looking at the $data array
> result, not at any of the intermediate variables.    Correct me if I'm
> wrong.

No no, because $Infos is supposed to be an array, I've put in data output :

$data['count_infos'] = count($Infos);

giving 0

also I've tried :

shell("$cmd > /path/to/some.file", $Infos, $ExitStatus);

no "/path/to/some.file" created.

another way, with system :

$result = system($cmd, $ExitStatus);

and with intermediate file :

$result = system("$cmd > /path/to/some.file", $ExitStatus);

again no "/path/to/some.file" created.

in both cases $result = ''
and $ExitStatus = 1

doing the same on terminal using :
$ exiftool 20161202_085945.jpg > 20161202_085945.txt
$ cat 20161202_085945.txt
ExifTool Version Number         : 10.20
File Name                       : 20161202_085945.jpg
Directory                       : .

[...]

Comment                         : File written by Adobe Photoshop� 5.0

[...]

Circle Of Confusion             : 0.004 mm
Field Of View                   : 60.3 deg
Focal Length                    : 3.7 mm (35 mm equivalent: 31.0 mm)
Hyperfocal Distance             : 1.47 m


>> Obviously, this should work reading the "temp.dat" in byte mode
> You do not understand: If that file gets filled with data it stands to
> reason that the $Infos variable also gets filled.

right, however, see above...

> If the file gets filled
> but the variable not then there would be something rather odd on, possibly
> with the "exec" command (on the other hand, that "exec" command may be
> exactly doing what its told to do, and we simply are not aware of what it
> has been told :-) ).
>
> In other words: I'm not working towards a solution, I'm working towards
> figuring out where the problem actually occurs, and what causes it.  Which
> those two in hand you're much more likely to find a/the solution.

right

> Also, with that temp file you have a possibility to check what's *really*
> been outputted.    Maybe you'll even find that there is a ctrl-z in there
> (EOF), causing the capturing of standard output (from the exiftool) to
> terminate early.  Who knows.

here I don't understand really your speaking because, i did this 
experiment using command line on Terminal where I see � instead of ®.
even I examined the photo file itself using on hex Editor (reading the 
file as a binary one and listing all the bytes in hex format).

>> Rather heavy for one char isnt'it?
> If its really only for that one character, and you already have a method to
> deal with it than I could agree with you.    But as you have no idea what
> actually causes the problem of the character resulting in an emptyresult you
> might be bumping into other characters causing the same effect too.    And
> ofcourse, if we may take Murphy's Law as a guideline, at the most
> in-opportune moment imaginable. :-)

you're right again, Murphy's Law must be my guideline here.

> Regards,
> Rudy Wieser

0
UTF
12/17/2016 4:39:53 PM
Une,

> No no, because $Infos is supposed to be an array,

I know.    Thats why I suggested that "print_p" command.  It can display the
contents of an array.   Like so: "print_p($Infos)".

.... though I just noticed that I'm using "print_r" myself instead ....

> $data['count_infos'] = count($Infos);
>
> giving 0

Well, you're right in that that is a good indication nothing is in there.

> also I've tried :
>
> shell("$cmd > /path/to/some.file", $Infos, $ExitStatus);
>
> no "/path/to/some.file" created.

Have you tried that with any of the images which normally do give usefull
output ?    They certainly should give some output.  If they also don't than
maybe the method we're trying to use is incorrect.

....  I've just tested what would happen when I would use that command myself
(using a ZWAMP installation, PHP 5.3.3), and have no problems with either
capturing a programs output, or redirecting it to a file.

I also made the program output all characters from 0x01 thru 0xFF, and had
no problem with capturing that output either.

So, I can't recreate your problem and I'm also outof ideas to try.   Sorry.

Regards,
Rudy Wieser


-- Origional message:
Une B�vue <unbewusst.sein@fai.invalid> schreef in berichtnieuws
o33pop$ccm$1@shakotay.alphanet.ch...
> Le 17/12/2016 � 11:41, R.Wieser a �crit :
> > Une,
> >
> >>> Have you ever display the contents of the $Infos array (print_r) ?
> >>> Did it contain anything ?    If it does, have you displayed the
contents
> >>> of each $line ?
> >> As I said : no output at all !
> > Yeah, but as far as I can tell you have just been looking at the $data
array
> > result, not at any of the intermediate variables.    Correct me if I'm
> > wrong.
>
> No no, because $Infos is supposed to be an array, I've put in data output
:
>
> $data['count_infos'] = count($Infos);
>
> giving 0
>
> also I've tried :
>
> shell("$cmd > /path/to/some.file", $Infos, $ExitStatus);
>
> no "/path/to/some.file" created.
>
> another way, with system :
>
> $result = system($cmd, $ExitStatus);
>
> and with intermediate file :
>
> $result = system("$cmd > /path/to/some.file", $ExitStatus);
>
> again no "/path/to/some.file" created.
>
> in both cases $result = ''
> and $ExitStatus = 1
>
> doing the same on terminal using :
> $ exiftool 20161202_085945.jpg > 20161202_085945.txt
> $ cat 20161202_085945.txt
> ExifTool Version Number         : 10.20
> File Name                       : 20161202_085945.jpg
> Directory                       : .
>
> [...]
>
> Comment                         : File written by Adobe Photoshop? 5.0
>
> [...]
>
> Circle Of Confusion             : 0.004 mm
> Field Of View                   : 60.3 deg
> Focal Length                    : 3.7 mm (35 mm equivalent: 31.0 mm)
> Hyperfocal Distance             : 1.47 m
>
>
> >> Obviously, this should work reading the "temp.dat" in byte mode
> > You do not understand: If that file gets filled with data it stands to
> > reason that the $Infos variable also gets filled.
>
> right, however, see above...
>
> > If the file gets filled
> > but the variable not then there would be something rather odd on,
possibly
> > with the "exec" command (on the other hand, that "exec" command may be
> > exactly doing what its told to do, and we simply are not aware of what
it
> > has been told :-) ).
> >
> > In other words: I'm not working towards a solution, I'm working towards
> > figuring out where the problem actually occurs, and what causes it.
Which
> > those two in hand you're much more likely to find a/the solution.
>
> right
>
> > Also, with that temp file you have a possibility to check what's
*really*
> > been outputted.    Maybe you'll even find that there is a ctrl-z in
there
> > (EOF), causing the capturing of standard output (from the exiftool) to
> > terminate early.  Who knows.
>
> here I don't understand really your speaking because, i did this
> experiment using command line on Terminal where I see ? instead of �.
> even I examined the photo file itself using on hex Editor (reading the
> file as a binary one and listing all the bytes in hex format).
>
> >> Rather heavy for one char isnt'it?
> > If its really only for that one character, and you already have a method
to
> > deal with it than I could agree with you.    But as you have no idea
what
> > actually causes the problem of the character resulting in an emptyresult
you
> > might be bumping into other characters causing the same effect too.
And
> > ofcourse, if we may take Murphy's Law as a guideline, at the most
> > in-opportune moment imaginable. :-)
>
> you're right again, Murphy's Law must be my guideline here.
>
> > Regards,
> > Rudy Wieser
>


0
R
12/18/2016 1:01:01 AM
Une,

> Obviously,

:-) For you that might be.  For large swats of people its not.   And even
for the smarter 'uns it simply might have simply slipped their mind.

> yes, that gaves me the correct number of lines.

Good.   I asked to make sure that the problem was indeed only present with
that one image.  You might be amazed how many people forget that kind of
stuff, and only after days of effort suddenly find the problem is not at all
unique to to what they thought it was.

But as I already said, I'm out of ideas.

Regards,
Rudy Wieser


-- Origional message:
Une B�vue <unbewusst.sein@fai.invalid> schreef in berichtnieuws
o3dlum$uro$1@shakotay.alphanet.ch...
> Le 18/12/2016 � 10:27, R.Wieser a �crit :
> > Have you tried that with any of the images which normally do give
usefull
> > output ?
>
> Obviously, yes, that gaves me the correct number of lines.
>


0
R
12/21/2016 1:01:01 AM
Le 18/12/2016 à 10:27, R.Wieser a écrit :
> Have you tried that with any of the images which normally do give usefull
> output ?

Obviously, yes, that gaves me the correct number of lines.

0
UTF
12/21/2016 10:36:06 AM
Le 21/12/2016 à 16:58, R.Wieser a écrit :
> But as I already said, I'm out of ideas.

me 2

best,

Yvon

0
UTF
12/22/2016 6:08:21 AM
Reply: