Why Does Copied IPTC Multilingual Text Become Unreadable?

Identify where the text first becomes unreadable

Keep a known readable copy of the approved wording outside the image. Read the source record, then a destination working copy after the proposed metadata operation. Finally inspect the receiving application. These comparisons distinguish text that was already broken in the source from a mismatch introduced while copying or displaying the destination.

Use a short recognizable phrase containing the actual language’s characters. An ASCII-only product code may look correct even when an accented caption is interpreted incorrectly. Record the exact field and record type instead of accepting a readable filename as proof about the embedded caption.

Understand why the character-set tag is special

ExifTool documents CodedCharacterSet as affecting string decoding in the IPTC Application and NewsPhoto records. Its UTF8 value is a convenience representation for the documented UTF-8 escape sequence. The important point is the relationship between that information and the text it describes, not the presence of a fashionable encoding name.

The tag is excluded from default group copying as an unsafe tag because existing destination tags may use a different encoding. Here unsafe describes the consequences of an indiscriminate metadata copy; it does not mean that all multilingual metadata is malicious or that an entire source image is unsuitable. Do not override the exclusion merely to make a list of source and destination tags look identical.

The ExifTool CodedCharacterSet documentation explains the interpretation and unsafe-copy boundary; it is documentation, not a completed compatibility test.

Distinguish an Existing Record from a New One

For an existing destination, preserve the original and a separate working copy. Record the actual fields changed, their character-set label before and after the operation, and trustworthy non-ASCII source wording. Compare read-back values and the receiving application before further edits. If the source encoding is unknown, record it as unknown and stop treating another label change as established recovery.

For a deliberately new IPTC record, the documentation suggests UTF8 when special characters may occur. Choose the encoding intentionally from approved text and verify the actual caption and keywords after writing and in the receiving application. This new-record check does not determine the original encoding of already damaged bytes.

Use a recovery boundary instead of a blind retag

If the only remaining caption is unreadable, preserve the file and recover the wording from a trustworthy editorial source. A character-set label does not supply missing knowledge about the intended product description. Avoid rewriting the approved master while investigating, and do not infer product claims from a partially readable caption.

Acceptance means the exact intended non-ASCII text is readable in the written record and in its intended receiving workflow, with the encoding decision documented. If the source encoding or application interpretation remains unknown, stop at that uncertainty. The procedure is a manual comparison based on ExifTool’s tag documentation, not a claimed automatic transcoding feature of Itemlume or a completed compatibility test.

Multilingual IPTC interpretation record — actual observations

Save a copy of this record and enter actual inputs, actions and observations. Keep incomplete checks pending; do not prefill success.

Download review worksheet (CSV)