The UNA segment: delimiters are not always the same

26 August 2026 · If a file opens with UNA, forget the defaults — that line says which character does what.

Most EDIFACT files separate elements with +, components with : and segments with '. But that is only the default, not a rule. The UNA segment at the start of a file can change those characters.

What does UNA look like?

In its default form:


UNA:+.? '

The six characters after UNA define, in order:

Position	Default	Purpose
1	`:`	Component (sub-element) separator
2	`+`	Data element separator
3	`.`	Decimal mark
4	`?`	Release (escape) character
5	space	Reserved / repetition separator
6	`'`	Segment terminator

Note that the sixth character is not a space — it is ', and the first real segment follows immediately after it.

Why would anyone change them?

Because the data contains that character. If a product description contains a +, then in a file using + as a separator that character splits the line in the wrong place. There are two ways out: escape it, or change the separator.

A file with different separators looks like this:


UNA|^.! ~UNB^UNOC|3^A|14^B|14^260117|1030^R1~

Here ^ separates elements, | components and ~ segments. It reads oddly, but the structure is identical.

How does the release character work?

Instead of changing the separator you can escape occurrences one by one. The default release character ? makes the character that follows it data.


FTX+AAI+++ACME?+SONS ?: 50?? discount'

Decoded, that line reads:

?+ → + (data, not a separator)
?: → : (data, not a separator)
?? → ? (the release character itself)

So the text is actually ACME+SONS : 50? discount. A parser that ignores the release character splits this line incorrectly and usually notices only much later, when the field count does not add up.

What if there is no UNA?

The defaults apply. UNA is optional; a file may start directly with UNB, and that is perfectly valid.

So a parser should do this: if the file starts with UNA, read the separators from it; otherwise use the defaults.

The common mistake

Hard-coding the separators. Code that calls split('+') will quietly produce wrong results on a file that uses UNA — it does not crash, it just misreads. Faults of this kind can live in production unnoticed for a long time.

The same concern applies to ANSI X12, but the mechanism differs: there the separators are not in a segment like UNA but at fixed positions in the ISA line. The element separator is character 4, the component separator 105 and the segment terminator 106. This is why the space padding in an ISA line is not decoration; shorten it and the file can no longer be parsed.

Checklist

Does the file start with UNA? If so, take the separators from it
Does your parser understand the release character?
On the X12 side, is the ISA line exactly 106 characters?

The quickest way to find out which separators a file uses is to look at its first line.

Related reference

UNB

← All posts