始终使用【字节顺序标记】的Unicode纯文本文件前缀。因为Unicode纯文本是16位代码的序列，所以对写入文本时使用的字节顺序很敏感。
字节顺序标记不是选择文本的字节顺序的控制字符;它只是通知接收文件的应用程序该文件是字节排序的。
理想情况下，所有的Unicode文本只能遵循一组字节顺序规则。然而，这是不可能的，因为微处理器在最低有效字节的位置不同：Intel和MIPS处理器首先具有最低有效字节;摩托罗拉处理器（和【字节反转】 Unicode文件）最后一次。仅使用一组字节排序规则，即使文件从未传输到另一个系统，也不会将文件从不传送到另一个系统，所以一种类型的微处理器的用户每次从纯文本文件读取或写入时都将被迫交换字节顺序一个不同的微处理器。
指定字节顺序的首选位置在文件头中，但文本文件没有标题。因此，Unicode已将字符（0xFEFF）和非字符（0xFFFE）定义为字节顺序标记。它们是彼此的镜像字节图像。
由于序列0xFEFF在常规非Unicode文本文件开头非常罕见，因此可以作为隐式标记或签名将文件标识为Unicode文件。用于读取Unicode和非Unicode文本文件的应用程序应使用此序列的存在作为接近特定的指示符，文件是Unicode文件。（将此技术与使用MS-DOS EOF标记进行比较以终止文本文件。）
当应用程序在文本文件的开头找到0xFEFF时，它通常会将该文件处理为一个Unicode文件，尽管它也可以执行进一步的启发式检查来验证这是否为真。这样的检查可以像对低位字节的变化是否高于高阶字节的变化的测试一样简单。例如，如果将ASCII文本转换为Unicode文本，则每第二个字节为零。此外，检查换行符和回车符（0x000A和0x000D）以及偶数或奇数文件大小可以提供文件性质的强指标。
当应用程序在文本文件的开头找到0xFFFE时，它会将其解释为文件是一个字节反转的Unicode文件。应用程序可以交换字节的顺序，也可以提醒用户发生错误。
在任何代码页中都没有找到Unicode字节顺序标记字符，所以如果数据被转换为ANSI，它就会消失。与其他Unicode字符不同，它在转换时不会被默认字符替换。如果在文件中间找到字节顺序标记，则不会将其解释为Unicode字符，对文本输出没有影响。
Unicode值0xFFFF在纯文本文件中是非法的，不能在Windows函数之间传递。0xFFFF值用于应用程序的私人使用。
