Skip to content

Declare UTF-8 in IPTC data written from cloned profiles - #3226

Open
jafin wants to merge 1 commit into
SixLabors:mainfrom
jafin:jf/iptc-utf8-cloned-profiles
Open

jafin wants to merge 1 commit into
SixLabors:mainfrom
jafin:jf/iptc-utf8-cloned-profiles

Conversation

@jafin

@jafin jafin commented Oct 17, 2026 •

Copy link
Copy Markdown

Prerequisites

  • I have written a descriptive pull-request title
  • I have verified that there are no overlapping pull-requests open
  • I have verified that I am following the existing coding patterns and practice as demonstrated in the repository. These follow strict Stylecop rules 👮.
  • I have provided test coverage for my change (where applicable)

Description

IptcProfile.UpdateData writes the 1:90 Coded Character Set dataset (ESC % G, UTF-8) before the application records when a value is UTF-8. It checked this with a reference comparison, value.Encoding == Encoding.UTF8. IptcValue.DeepClone clones the encoding, so every value in a cloned profile failed the check. A common case is image.Clone(...) followed by a save. A value set with the caller's own UTF8Encoding instance failed the check too. Those profiles were written without the character set declaration, so other applications read non-ASCII text such as "ESPAÑA" as Latin-1 ("ESPAÃ'A").

The check now compares the encoding's code page with UTF-8. The UpdateData documentation now says when the 1:90 dataset is written, including that ASCII-only UTF-8 values also get it.

Tests

New tests in IptcProfileTests:

  • A deep-cloned profile writes the 1:90 dataset.
  • A value set with new UTF8Encoding(false) writes the 1:90 dataset.
  • A cloned image saved as JPEG, reloaded, cloned and saved again keeps exactly one 1:90 dataset followed by the caption, and reads back "ESPAÑA".

The Release build passes for net10.0. All Metadata, EXIF, IPTC and ICC tests pass (1417 tests).

Fixes #3238

UpdateData only wrote the 1:90 Coded Character Set dataset when a value's
encoding was the Encoding.UTF8 instance. Cloning an IPTC value clones its
encoding, so a profile from a cloned image, or a value set with a caller's own
UTF8Encoding, was written without the declaration and other readers fell back
to Latin-1 for non-ASCII text. The encoding is now matched by code page.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

IPTC data from a cloned profile or image is written without the 1:90 UTF-8 character set record

1 participant