<div dir="ltr">The caption saved with exiv2 was readable on the commandline AND in Digikam, but saving in Digikam would replace the caption with junk.<div><br></div><div>If Digikam 6 refuses to write non-ascii data to Exif maybe that is not such a bad thing, but it must be careful to DELETE the old Exif data in this case - otherwise you can end up with old captions or other data hanging around in Exif when the user expected it to be overwritten.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 19 April 2018 at 19:27, Remco Viëtor <span dir="ltr"><<a href="mailto:remco.vietor@wanadoo.fr" target="_blank">remco.vietor@wanadoo.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On jeudi 19 avril 2018 10:43:41 CEST meku wrote:<br>
> Strange exiv2 commandline appears to work, eg:<br>
> exiv2 -M"set Exif.Image.ImageDescription 'ミスタードーナツ'" FILE.JPG<br>
> <br>
> I filed a bug for Exif.Image.ImageDescription field not updating in DK6,<br>
> <a href="https://bugs.kde.org/show_bug.cgi?id=393283" rel="noreferrer" target="_blank">https://bugs.kde.org/show_bug.<wbr>cgi?id=393283</a><br>
> <br>
> On 19 April 2018 at 17:48, Gilles Caulier <<a href="mailto:caulier.gilles@gmail.com">caulier.gilles@gmail.com</a>> wrote:<br>
> > Hi,<br>
> > <br>
> > Exif do not support any special character encoding, as UTF8<br>
> > <br>
> > Using XMP is the right way.<br>
> > <br>
> > Note : IPTC is limited to Latin1 (ASCII extended). Take a care too.<br>
> > <br>
> > Gilles Caulier<br>
> > <br>
> > 2018-04-19 9:43 GMT+02:00 meku <<a href="mailto:digikam@meku.org">digikam@meku.org</a>>:<br>
> >> I discovered that my UTF captions appear to be corrupted using<br>
> >> Digikam-5.9.0, but only in the Exif.Image.ImageDescription field.<br>
> >> <br>
> >> Using exiv2 command line it appears I can write UTF caption to this<br>
> >> field.<br>
> >> <br>
> >> I tried loading up Digikam-6.0.0 and it appears to ignore the field when<br>
> >> writing, even though the default settings in Metadata>Advanced are set to<br>
> >> write to the field.<br>
> >> <br>
> >> Is this an issue with Digikam or is this a limitation of EXIF?<br>
<br>
</div></div>I think the key here is "appears" to work. According to the standard, EXIF <br>
tags can only use (7-bit) ASCII characters, but that does not mean that <br>
programs reading and writing the tags scrupulously respect that. <br>
<br>
At least in standard C and C++, the easiest way is to grab the string the user <br>
gives as a sequence of bytes, and write that to the metadata. And just read <br>
the contents from the metadata as a sequence of bytes. All that without <br>
worrying about the encoding... (which is not all that straightforward with <br>
those languages). Somewhere there must be a translation to the encoding the <br>
user wants, but that's not the problem of the library handling the metadata.<br>
<br>
As long as there aren't any unexpected \000 bytes in such a sequence, that may <br>
appear to work correctly, *as long as the same encoding is used on writing and <br>
on reading*. But if the encodings for reading and writing differ, you'll get <br>
garbled output, and *no* sure way to get the correct encoding (though you can <br>
find an encoding that's 'close enough').<br>
<br>
And changing the character encoding between reading and writing can happen <br>
without the user realising it: a few years ago, my linux distro switched to <br>
utf-8 as the default. But a lot of older files are in one of the ISO encodings. <br>
Result: those appear garbled for any character outside the ASCII range. And it <br>
might get even worse between operating systems<br>
<br>
Personally, I think it might be a good thing if Digikam 6 refuses to write <br>
non-ascii data to Exif tags, provided the information can get written to <br>
corresponding XMP tags (which afaik is always possible).<br>
<span class="HOEnZb"><font color="#888888"><br>
Remco<br>
<br>
</font></span></blockquote></div><br></div>