Tag value with space cause ExifTool write incorrectly while called from Java

[simonz]

This occurred on a Window Server 2016 (64 bit).  I didn't try on other OSs.  The exifTool is latest  11.10 (downloaded today) but same issue occurs in old version.  The issue is not any image file specific. Tried several jpg files.

My Java application is used to write xmp:ArtworkOrObject metadata into image file.  When any tag value contains space,  exifTool called from Java does not work correctly.

1. Here is output from Java
13:30:17.306 [main] INFO  util.ExifTool - startExifToolProcess Attempting to start external ExifTool process using args:
[C:\imagetesting\exiftool.exe, -overwrite_original, -xmp:ArtworkOrObject-="{AOSourceInvNo=testEvent22}", -xmp:ArtworkOrObject+="{AOSourceInvNo=testEvent22,AOSource=testAoSource 2,AODateCreated=1992,AOTitle=1992|, Kunstmuseum Düsseldorf:Lichtraum}", C:\imagetesting\bad.JPG]
13:30:17.323 [main] INFO  util.ExifTool - readExecResult Reading response back from ExifTool...
13:30:18.757 [main] INFO  util.ExifTool - readExecResult response '    1 image files updated'
13:30:18.757 [main] INFO  util.ExifTool - readExecResult response '    3 files weren't updated due to errors'

From Window console,  read metadata, you can see writing is not done correctly
      C:\imagetestinghttps://exiftool.org/forum/index.php?action=post;board=6.0#>exiftool.exe  -xmp:ArtworkOrObject -struct -X c:\imagetesting\bad.JPG
<?xml version='1.0' encoding='UTF-8'?>
<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>

<rdf:Description rdf:about='c:/imagetesting/bad.JPG'
  xmlns:et='http://ns.exiftool.ca/1.0/' et:toolkit='Image::ExifTool 11.10'
  xmlns:XMP-iptcExt='http://ns.exiftool.ca/XMP/XMP-iptcExt/1.0/'>
<XMP-iptcExt:ArtworkOrObject>
  <rdf:Bag>
   <rdf:li rdf:parseType='Resource'>
    <XMP-iptcExt:AOSource>testAoSource</XMP-iptcExt:AOSource>
    <XMP-iptcExt:AOSourceInvNo>testEvent22</XMP-iptcExt:AOSourceInvNo>
   </rdf:li>
  </rdf:Bag>
</XMP-iptcExt:ArtworkOrObject>
</rdf:Description>
</rdf:RDF>

2. But, if run the above (using above first line from Java output) from command line

C:\imagetesting>exiftool.exe -overwrite_original -xmp:ArtworkOrObject-="{AOSourceInvNo=testEvent22}" -xmp:ArtworkOrObject+="{AOSourceInvNo=testEvent22,AOSource=testAoSource 2,AODateCreated=1992,AOTitle=1992|, Kunstmuseum Düsseldorf:Lichtraum}" C:\imagetesting\bad.JPG
    1 image files updated

C:\imagetesting>exiftool.exe  -xmp:ArtworkOrObject -struct -X c:\imagetesting\bad.JPG
<?xml version='1.0' encoding='UTF-8'?>
<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>

<rdf:Description rdf:about='c:/imagetesting/bad.JPG'
  xmlns:et='http://ns.exiftool.ca/1.0/' et:toolkit='Image::ExifTool 11.10'
  xmlns:XMP-iptcExt='http://ns.exiftool.ca/XMP/XMP-iptcExt/1.0/'>
<XMP-iptcExt:ArtworkOrObject>
  <rdf:Bag>
   <rdf:li rdf:parseType='Resource'>
    <XMP-iptcExt:AODateCreated>1992</XMP-iptcExt:AODateCreated>
    <XMP-iptcExt:AOSource>testAoSource 2</XMP-iptcExt:AOSource>
    <XMP-iptcExt:AOSourceInvNo>testEvent22</XMP-iptcExt:AOSourceInvNo>
    <XMP-iptcExt:AOTitle>1992, Kunstmuseum D?sseldorf:Lichtraum</XMP-iptcExt:AOTitle>
   </rdf:li>
  </rdf:Bag>
</XMP-iptcExt:ArtworkOrObject>
</rdf:Description>
</rdf:RDF>

3. If I remove spaces from AOTitle ad AOSource, then run from Java
13:54:35.863 [main] INFO  c.g.tms.media.util.ExifTool - startExifToolProcess Attempting to start external ExifTool process using args: [C:\imagetesting\exiftool.exe, -overwrite_original, -xmp:ArtworkOrObject-="{AOSourceInvNo=testEvent22}", -xmp:ArtworkOrObject+="{AOSourceInvNo=testEvent22,AOSource=testAoSource2,AODateCreated=1992,AOTitle=1992|,KunstmuseumDüsseldorf:Lichtraum}", C:\imagetesting\bad.JPG]
13:54:35.874 [main] INFO  util.ExifTool - readExecResult Reading response back from ExifTool...
13:54:36.517 [main] INFO  util.ExifTool - readExecResult response '    1 image files updated'
13:54:36.547 [main] INFO  util.ExifTool - readExecResult Reading response back from ExifTool...done with '    1 image files updated'

C:\imagetesting>exiftool.exe  -xmp:ArtworkOrObject -struct -X c:\imagetesting\bad.JPG
<?xml version='1.0' encoding='UTF-8'?>
<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>

<rdf:Description rdf:about='c:/imagetesting/bad.JPG'
  xmlns:et='http://ns.exiftool.ca/1.0/' et:toolkit='Image::ExifTool 11.10'
  xmlns:XMP-iptcExt='http://ns.exiftool.ca/XMP/XMP-iptcExt/1.0/'>
<XMP-iptcExt:ArtworkOrObject>
  <rdf:Bag>
   <rdf:li rdf:parseType='Resource'>
    <XMP-iptcExt:AODateCreated>1992</XMP-iptcExt:AODateCreated>
    <XMP-iptcExt:AOSource>testAoSource2</XMP-iptcExt:AOSource>
    <XMP-iptcExt:AOSourceInvNo>testEvent22</XMP-iptcExt:AOSourceInvNo>
    <XMP-iptcExt:AOTitle>1992,KunstmuseumD?sseldorf:Lichtraum</XMP-iptcExt:AOTitle>
   </rdf:li>
  </rdf:Bag>
</XMP-iptcExt:ArtworkOrObject>
</rdf:Description>
</rdf:RDF>
Now from Window console,  read metadata, you can see writing is done correctly (same as from command line) except word "Düsseldorf" is written as "D?sseldorf"


Question 1. Does anyone has experience running ExifTool from Java and run into similar issue?
              2. Am I missing any ExifTool parameter to avoid such issue
              3. When writing goes wrong, the output show as below, what's the 2nd line mean, apparently I am working with a single file?
                        13:30:18.757 [main] INFO  util.ExifTool - readExecResult response '    1 image files updated'
                        13:30:18.757 [main] INFO  util.ExifTool - readExecResult response '    3 files weren't updated due to errors'
              4. In both Java and command line, the word "Düsseldorf" displayed correctly before executing but is written as D?sseldorf.   
                  Per FAQ 10, " ExifTool always encodes XMP as UTF‑8".  What charSet should I enforce?

Thanks,
Simon

[StarGeek]

I have no clue about java but a couple things jump out at me.  Is the interface to exiftool using the -Stay_Open command?  The "start external ExifTool process" part seems to indicate that to me.  If so, you might try removing that quotes as they shouldn't appear in such a case

It might also be that the call to run the command line is already encapsulating the arguments when it creates the command.  Again, fiddle with the quotes.

Somewhere, the command being run is getting messed up.  The spaces are not getting escaped and it ends up thinking that the text on either side of the spaces is a file name.

The problem with Düsseldorf probably isn't a FAQ 10 issue, it's more likely a FAQ #18 issue.  I've had terrible luck trying to deal with this, trying out a variety of solutions on StackOverflow sites.  I have no clue how you would make this work with java.

[simonz]

I have no clue about java but a couple things jump out at me.  Is the interface to exiftool using the -Stay_Open command?  The "start external ExifTool process" part seems to indicate that to me.  If so, you might try removing that quotes as they shouldn't appear in such a case

It might also be that the call to run the command line is already encapsulating the arguments when it creates the command.  Again, fiddle with the quotes.

Somewhere, the command being run is getting messed up.  The spaces are not getting escaped and it ends up thinking that the text on either side of the spaces is a file name.

The problem with Düsseldorf probably isn't a FAQ 10 issue, it's more likely a FAQ #18 issue.  I've had terrible luck trying to deal with this, trying out a variety of solutions on StackOverflow sites.  I have no clue how you would make this work with java.

Hi StarGeek,

Thanks for responding to my post.   You comments about space made me re-examined my code and I am able to solve the issue by quoted tag values !!!
Now I am struggling with the special characters in Düsseldorf .  The fact that I am able to see the word as is in window console or Java console means that  the right charset is set in the consoles. But once it is written, the value retrieved back always show differently.  I have been playing with charset option, but didn't work.  I search multiple post in the forum related to charset but unfortunately couldn't find any solution either.

Simon