Skip to content
CCMForge
Exstream Field Archive

Exstream SBCS output shows missing European characters

Historical eraDialogue and HP Exstream 6.x-7.x SBCS applications

By Tomas Hajek, working with Exstream since 2008. Published 2026-06-11

Applies to: Classic SBCS Exstream applications receiving delimited data with Central European characters; historical encoding guidance.

Symptom

Accented characters display correctly when typed directly in Designer but come out wrong when read from a delimited data file: replaced, blank, or rendered with the wrong glyph. Changing the font does not fix it. Meanwhile XML input with the same characters behaves fine, which feels inconsistent until you know why.

Cause

Four things must agree: the data file's encoding, the operating system's language for non-Unicode programs, the application code page, and the font's glyph coverage.

A classic SBCS delimited file has no self-describing character-set header, so the engine interprets its bytes according to the configured environment. XML behaves differently precisely because it can declare its own character set; a delimited file cannot.

This is why font changes are futile here: a byte decoded under the wrong code page has already become the wrong character. No font contains the right glyph for a character that is no longer in the data.

Fix

Work from bytes toward glyphs, in order:

  1. Encode the delimited input in the agreed Windows code page, for example Windows-1250 for Central European data.
  2. Configure the host's language for non-Unicode programs consistently on the design-time machines.
  3. Confirm the languages you must support actually share the selected code page, and that the chosen font contains the glyphs.
  4. Validate the raw bytes with a hex viewer before Exstream mapping, then run the same file through design and production environments.

If the combined language set does not fit one SBCS code page, stop tuning and move to the appropriate DBCS or Unicode-capable path. Mixing incompatible code pages in one SBCS database is not solvable with more fonts.

Separate byte decoding from font rendering

Changing the keyboard layout affects what you type, not how an existing file is decoded. A Linux production host may ignore the Windows non-Unicode setting while packaging still depends on the character set and fonts built into the package. Test the same bytes in design and production.

All of this describes the historical SBCS world. Current OpenText Communications releases have Unicode-era encoding rules; validate against those before applying any of this to a new application.

Related notes

Related Exstream notes.

Ask about your case

Resolve can check the pattern against your environment.

Resolve searches your approved sources and shows its citations. If the evidence is weak, the same case reaches an experienced Exstream specialist with the evidence attached.

Discuss your Exstream problem See how Resolve works
These articles describe field experience and identify the Exstream versions they cover. They are not official vendor guidance. CCMForge is independent and is not affiliated with or endorsed by OpenText. OpenText and Exstream are trademarks of their respective owner.