According to IIM v4.1 ("IPTC headers") specs, ch. 5 Envelope Record, 1:90 Coded Character Set, there seems to be a provision for utf-8 support. I understand this is not often implemented due both to implementation difficutlies and native utf-8 support in XMP. I've read ExifTool's documentation but I couldn't find anything on this. Is utf-8 for IPTC supported? Many thanks in advance.

Thank you for the reply. ExifTool never ceases to amaze me with what it can do. I'm still having some difficulty. Here's what I do: 1. make a txt file with all the iptc tags needed, including the line "-iptc:CodedCharacterSet=ESC % G" 2. pass the file to exiftool using the -@ ARGFILE. The resulting jpg's iptc is not in utf-8. Must the txt file be in utf-8 encoding to begin with? If yes, what is the use of CodedCharacterSet?

Phil, This is crystal clear, many thanks for your clarification :-) Pandelis

The actual hex byte sequence that must be written to the file is 0x1b 0x25 0x47 (3 bytes).

ExifTool converts "ESC " to 0x1b only if there is a space after "ESC". Then it packs the remaining bytes by removing spaces and commas. Note that '%' = 0x25 and 'G' = 0x47.

So with your examples, either 1 or 2 will work, but 3 will not because of the way that ExifTool translates the escape character.

-IPTC:CodedCharacterSet=UTF8 (not UTF-8) works again as of version 6.86 (somehow this feature got broken before this version).

IPTC uses the ISO 2022 standard for alternate character sets, and character sets are specified via a sequence of escape characters. For UTF-8, the escape sequence is "ESC % G", and for convenience ExifTool allows you to also specify "UTF8" which is translated to the appropriate escape sequence internally.

You can use the -n option to bypass this translation to see actual escape sequence (but in this case, the "ESC" character will appear as a "." because all control characers are converted to "." in the output. But you can add the -b option to prevent this conversion too if you want.)

I hope this makes sense.

- Phil