Character Encoding

A logged message body is stored as bytes. To search it, show it, transform it with a Stylesheet, or let you download it as text, Nodinite must know which character encoding turns those bytes into characters. If the encoding is wrong, Ä, é, and ø turn into garbage, Search Field Expressions miss values, and XML parsers fail on an unexpected byte order mark (BOM). ^{New 7.11}

From Nodinite 7.11, you set the encoding where it belongs, and Nodinite uses it consistently everywhere the message is read:

• Per Message Type – the default for every message of that format (UTF-8 (without BOM) unless you change it)
• Per Endpoint – override the Message Type when the same format arrives in a different encoding on a specific Endpoint
• Per XML body – an encoding named in the XML declaration of the body is honored automatically
• Per Log Event – override everything for a single message with the ExtendedProperties/1.0#Encoding context property
• Base64 Decode into any encoding – decode Base64-wrapped payloads into the encoding the original content used
• Download converted to – download a message converted to the encoding a receiving system needs

Understanding encoding resolution

Nodinite picks one encoding for each message by checking four levels, highest priority first. The first level that holds a value wins.

Encoding resolution: the per-event context property (purple, priority 1) beats the XML declaration (pink, priority 2), which beats the Endpoint (orange, priority 3), which beats the Message Type (teal, priority 4). The resolved encoding (green) is used everywhere Nodinite reads the message as text.

The four levels explained

Tip

Set the encoding on the Message Type first. Add an Endpoint override only where a format arrives differently, and keep the context property for the exceptions your code knows about at runtime.

The same list of encodings is offered on Message Types and Endpoints; the Id next to each option is the numeric value the Log API accepts.

Where Nodinite uses the resolved encoding

Supported encodings

The table lists each encoding, its numeric value, and every input the Log API accepts for it in the ExtendedProperties/1.0#Encoding context property. The dropdowns in the Web Client show the display names, such as UTF-8 (without BOM) and Base64 Decode into UTF-8 (without BOM).

Important

A value that matches none of the accepted inputs falls back to UTF-8. Check the spelling when special characters look wrong for messages that carry the context property.

With BOM vs without BOM

A byte order mark (BOM) is an invisible marker at the start of a UTF-8 or UTF-16 file. Some systems require it, others choke on it.

In View Message, select a with BOM encoding and turn on Show hidden characters to see whether a message starts with a BOM.

With UTF-8 (with BOM) selected and Show hidden characters on, the BOM appears as a red BOM marker before the first character.

Base64 Decode into an encoding

Some platforms log the body as Base64 text, for example when the original content is binary or wrapped in JSON. A Base64 Decode into … encoding first decodes the Base64 text to bytes, and then reads those bytes with the encoding named after into.

Note

In earlier versions, the single Base64 Decode option always decoded into UTF-8. From 7.11 it is named Base64 Decode into UTF-8 (without BOM), and there is one Base64 Decode into … option for every other supported encoding, including UTF-8 (with BOM).

Set the encoding for a single Log Event

Add the ExtendedProperties/1.0#Encoding key to the context of the Log Event with any accepted input from the Supported encodings table. This value overrides the XML declaration, the Endpoint, and the Message Type.

{
  "Context": {
    "ExtendedProperties/1.0#Encoding": "Windows-1252"
  }
}

The numeric value works too, which is convenient from code that already uses the enumeration:

{
  "Context": {
    "ExtendedProperties/1.0#Encoding": "6"
  }
}

See Context Options for the other keys you can set on a Log Event.

Download, repair, and resubmit

These actions look alike but treat encoding differently. Repair message is deliberately kept apart from the encoding settings on this page, so a repaired message reaches the receiving system in the same encoding it originally arrived in.

Read more in What is a Log View?.

Automate with the Web API

The Web API exposes the character encoding on both the Message Type and the Endpoint models, so you can set it from DevOps pipelines together with the rest of your Repository Model. The Web API download operation accepts a target encoding as a parameter, which works like Download converted to in the Web Client.

Next Steps

• Add or manage Message Type – Set the default encoding for a format
• Add or manage Endpoint – Override the encoding for one Endpoint
• Context Options – Set the encoding for a single Log Event

Related Topics

• Log Event
• Log Views
• Search Field Wizard
• Stylesheets
• Logging Service
• Endpoint Types