Signature File Encoding

Historically Outlook has used various file formats for signatures. ANSI, Unicode, UFT-8.

Since Outlook 2016 UTF-8 has been the best format because it could accomodate all languages.

Default encoding for HTML5 became UFT-8.

But with the introduction of the Roaming Signature feature at the end of 2022, UTF-8 encoding with Byte-order-mark (BOM)* became a problem, since the sync-function apparently only supports ANSI. This must be an oversight on the part of Microsoft. It seems strange that after everyone has embraced UTF-8, we should return to an older and perhaps obsolete format.

*UTF-8 without BOM doesn't work either.

Here are some facts about the UTF-8 standard:

UTF-8 is superior in every way to ANSI. There is no reason to choose ANSI over UTF-8 in creating new applications as all computers can decode it. The only reason to be using ANSI is when you are forced to run an old application that you do not have any replacement for.

Summary:

1.UTF-8 is a widely used encoding while ANSI is an obsolete encoding scheme

2.ANSI uses a single byte while UTF-8 is a multibyte encoding scheme

3.UTF-8 can represent a wide variety of characters while ANSI is pretty limited

4.UTF-8 code points are standardized while ANSI has many different versions

However, Outlook is currently not able to sync signatures with UTF-8 and the signature on Outlook-online (OWA) will show the BOM. Like this:

To mitigate this problem we have made it so that the file-encoding now follows the code-page of the template. (Previously it followed the file encoding used on disk). In this way the encoding can be changed easily, and if Microsoft makes changes later on, it can be switched back to UTF-8.

Setting the code-page using the page properties on the toolbar.

When set, a meta entry is made in the template header:

When selecting e.g. Western Europe or Central Europe (the slavic country etc.) the signatures will be saved in ANSI instead of UFT-8.

ANSI can only accomodate 256 chars as mentioned above. So DynamicSignature will then parse the resulting signature data and convert all chars above the 256 limit into Unicode points so they are preserved and can survive the transfer to the cloud.

Unicode point encoding inside a signature showing cyrillic chars stored in ANSI.

We do not know presently if the BOM is a problem on all language platforms. We have not tested this on Arabic or Chinese Windows version for example, and do not know if it is the same, or if Microsoft has another scheme there.

But if you are having trouble with the BOM or characters becoming garbled, then we advice to switch to Western/Central Europe encoding, so that the signatures gets saved in ANSI and the high-chars gets encoded.

Full synchronization

It is also unclear what triggers a synchronization of signatures, wether it be some fixed time after Outlook starts or by going to the signatures dialog. But we have noticed that switching the New/Reply signature here, immediately triggers Outlook to make a full sync.

Understanding is relevant if signatures have been altered, either from a design change or from user data changes.

On a technical side note

Using a Json scanner we discovered that the roaming signatures are stored in what is called "the substrate".

And we also discovered that this substrate does actually support UTF-8, and that it is only the Outlook transmission part that does not. So we think it highly likely that in the near future MS will release an update to fix this ANSI backwardness.

Note also from this scan that the endpoint is still in beta. And the URL is /ows. Perhaps it refers to "Outlook Web Services". A new name for "Exchange Web Services"?