对于那些希望非 ASCII 字符串以当前区域编码的程序，区域编码仍可作为传统模式使用：例如，在西方（Windows）系统上，程序仍希望 tuple_ord 返回 CP1252 编码（在 Unicode 模式下，欧元符号是 "128" ，而不是 "8364" ），而日文编码的变通方法应在不改变编码的情况下工作。
可以通过将环境变量 HALCON_ENCODING 设置为 LOCALE 或使用 set_system 来启用传统模式：
set_system('filename_encoding', 'locale')
使用 HALCON/C 或 HALCON/C++ 接口调用 HALCON 算子的应用程序也可以独立于 HALCON 编码设置接口的编码。
不过，在传统编码模式下，以下编码问题可能无法按预期运行：
- 元组字符串算子不会按字符顺序工作。它们的行为与旧版 HALCON 相同，以保持传统模式一如既往地工作。
- 通过 set_system 将文件名编码从 "utf8" 改为 "locale" 或反之，在 JIT 编译的函数中都不起作用。传递给函数的字符串会根据进入函数时的文件名编码进行编码。函数中的字符串常量在创建或最后一次编辑函数时按照文件名编码进行编码。
- 在非拉丁语系系统（如日文 Windows）上，包含非 ASCII 字符的错误信息过去和将来都不会正确显示。在拉丁文系统中，只有两条英文信息受到影响：
H_ERR_CAL_NEGTS (8445) “Tilt must be within the range of
0° and 90°” 和
H_ERR_CAL_NEGRS (8446) “Rot must be
within the range of 0° and 360°”。
带有 Umlaut 的德语错误信息也无法正确显示。
- 在日文系统中，如果路径包含日文字符，而第二个 Shift-JIS 字节的代码与反斜杠相同，函数 list_image_files 可能会产生无效路径。
- 传给算子 read_string 的长度仍然限制了字节数。这会影响可有效输入的亚洲多字节字符的数量。
- 当设置全局系统变量 window_name 和 icon_name 时，它们将以 HALCON 库的编码方式存储。当通过 set_system 更改编码时，名称不会被转码。
- HDevelop中的所有字符串都始终以UTF-8编码，与文件名编码无关。这意味着在传统模式下无法用本地十六进制代码创建字符串（而不是将它们写成字符，例如用 \ xe4 来表示 Latin-1 字符 "ä" ）。十六进制代码不会作为预期的本地字符处理，而是首先被解释为 UTF-8 字节，只有在传递给 HALCON 库时才会转换为本地 8 位编码。
与编码模式无关，主机名必须以纯 ASCII 编码。不支持特殊字符。如要查询用于套接字连接的主机名，请使用：
get_system('hostname', Hostname)