# Will Identitynow supports UTF-8 encoding **URL:** \ **Category:** SHF Discussion and Questions\ **Created:** [December 10, 2021, 6:49am UTC](https://developer.sailpoint.com/discuss/t/will-identitynow-supports-utf-8-encoding/2318 "2021-12-10T06:49:55Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![colin\_mckibben](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/colin_mckibben/32/37182_2.png) [@colin\_mckibben](https://developer.sailpoint.com/discuss/u/colin_mckibben)\ **Post date:** [December 13, 2021, 5:03pm UTC](https://developer.sailpoint.com/discuss/t/will-identitynow-supports-utf-8-encoding/2318/4 "2021-12-13T17:03:53Z")
You are correct; IDN and Active Directory support UTF-8, but you might see some unexpected behavior in Active Directory and other sources if you don’t convert diacritic characters in commonly used provisioning attributes, like user name and email. One approach you can take is to add additional identity attributes to hold transformed values of attributes that are commonly used in provisioning on sources. For example, `firstName` can be pulled straight from your authoritative source without any transformation, but you might want to create another identity attribute called `preferredName` that applies the diacritic transform to the firstName field, which you can then use in any sources that don’t support UTF-8. The same strategy can be used for `email`. You can create a second attribute called `preferredEmail` that is transformed. I spoke to a member of Professional Services, and they suggest building distinguished, displayname, and email address in the Active Directory provisioning profile using transformed values so outlook address book renders them correctly. Ultimately, though, you can attempt to see how active directory will handle non-transformed values before committing your provisioning profile to production. --- _[View the full topic](https://developer.sailpoint.com/discuss/t/will-identitynow-supports-utf-8-encoding/2318)._