特殊功能字符（例如 FNC1 到 FNC4）属于“非数据字符”类别，可以在各种条形码符号体系中进行编码，但在解码的数据流中没有任何直接的 ASCII 表示。支持此类字符的每种符号系统都有不同的方案，用于在其内部表示中对它们进行编码，这与任何面向字节的字符数据截然不同。
FNC 字符既可用作标志字符（向读者表明一些特别的东西）以及格式化字符（修改编码数据的含义）。因此，它们不打算在主机系统从基本条形码读取器接收的数据中直接传输，尽管在这两种情况下它们可能对传输的消息产生“影响”。
每个 FNC 字符的通常用途如下：
-
FNC1- 结构化数据标志字符指示 GS1 和 AIM 格式 AND 组分隔符格式化字符等用途。
-
FNC2- 消息追加标志字符用于缓冲单次读取的符号组中的数据。
-
FNC3- 读者编程标志字符用于设备配置目的。
-
FNC4- 扩展 ASCII格式化字符用于对序数 128-255 的字符进行编码。
请注意，它们可能并非全部在某些条形码符号体系中可用，甚至可能以不同的、非典型的或重载的方式指定。
对符号内部数据中的 FNC 字符进行编码是通过编码软件特有的“转义机制”完成的。每个库都有不同的方式来接受输入中的这些非数据字符。例如，要在数据“(01)00312345678906(21)123456789012(30)0144”的典型 GS1 结构化数据角色中使用 FNC1，您可能会看到 FNC1 字符转义为{FNC1}这样输入看起来像{FNC1}010031234567890621123456789012{FNC1}300144.
有些库甚至会使用一组常规或扩展 ASCII 字符作为 FNC 字符的占位符，但这些是任意表示形式，将它们视为这些非数据字符的实际 ASCII 值是错误的。
扫描条形码时，符号的内部数据通常会被解码，然后通过基本通道（例如键盘楔）作为要根据 Latin-1 字符编码进行解释的字节序列传输到主机。 FNC 字符不能以这种方式表示并且被排除在数据流之外，但是它们格式化效果上的数据仍然存在。
例如，大多数符号体系的标准规定，当 FNC1 字符在符合 GS1 应用标识符标准格式的数据中用作字段分隔符时，应将其解码并作为 GS (ASCII 29) 传输。明确指出，格式化效果FNC1 字符用作 GS1 应用标识符分隔符的方法是将 GS 字符放置在可变长度字段的末尾。但在其他角色中（例如当FNC1用于“第一/第二位置”时作为标志字符对于非 GS1 格式的数据）有无格式化效果所携带的数据，因此在解码期间没有 ASCII 表示。
对数据具有格式化效果的特殊功能字符的另一个实例是使用 FNC4 将其范围从 7 位 ASCII 扩展到扩展 ASCII 的符号系统，如这个答案 https://stackoverflow.com/a/30308255/2568535.
一个微妙的技术点是，传输到主机的数据通常带有一个短符号指示符标头，称为“符号标识符”，表示从中读取数据的符号的类型和用法。这通常会因符号数据中存在其他不可见的标志字符而被修改，例如，以指示存在“FNC1 in first”的 GS1 格式数据，或者当 FNC3 出现在符号中的任何位置时指示阅读器编程模式。详细信息是特定于符号系统的。
旁白：除了 FNC 非数据字符之外，条形码符号系统还普遍支持其他非数据字符，这些字符没有直接的 ASCII 表示形式，但会影响整体消息。其中包括宏字符（将消息数据包装在数据字符“信封”中）和 ECI 指示符，这些指示符需要使用超出典型“基本通道”模式的传输协议，但允许使用扩展字符集以及其他增强功能。
