字符集根据用于一种或多种语言书写的字母表中包含的符号来定义。国际标准化组织（International Standards Organization - ISO）通过 ISO-8859 标准标准化了几个这样的集合，标识为 ISO-8859-x，其中 x 对应于特定的字母表。ISO-8859 集合使用 8 位来表示每个字符，这允许 256 个信号的范围（值从零到 255）。在每个集合中，代码零到 127 对应于 ASCII 集合（American Standard Code for Information Interchange），代码 160 到 255 用于国家字符。
对于葡萄牙语，建议使用 ISO-8859-1 集合，它包含拉丁字母和西欧及美洲语言使用的重音字母。此字符集也常被称为 Latin-1 或 ISO Latin-1。
更新的标准是 Unicode，由 ISO-10646 标准定义，它允许定义字符，这些字符在计算机中的内部表示使用多个字节（或 ISO 命名法中的八位字节）。所有最新版本的 Unix 系统都支持 Unicode（或者至少他们的制造商声称支持）。
除了字母数字字符和重音符号外，还可以生成半图形符号来绘制线条和边框。这些符号可以利用官方集合未使用的代码，从而使其不可移植。
Linux 在内部设计时考虑了易于配置和运行时扩展，键盘和字符字体的处理也不例外。它拥有 Unicode 标准的``级别 1''实现。更多详细信息可以在 Linux 手册中找到，可以使用以下命令读取
man unicode
man utf-8
man iso_8859_1
man ascii
但在那之前，请确保 man 已正确配置，如 Man, groff, troff 部分所示。
一些操作系统，例如 MacOS、Microsoft Windows 和 NeXT，拥有自己的图形界面。在 Linux 中，以及大多数与 Unix 兼容的系统中，通常使用为``跨平台''创建的图形环境：X 窗口系统，它也被设计为支持各种字符集、语言和键盘格式，但仍然不完全支持 Unicode 标准，而是 ISO-8859 的扩展。
严格来说，X 窗口系统不是用户图形界面，而是与应用程序接口（API）通信协议的组合，在其之上构建了多个图形界面。协议和窗口系统都定义了一组机制而不是策略（用户图形界面策略的特征元素是菜单、按钮和对话框）。术语``XWindows''是不正确的，应避免使用，而应优先使用通用名称``X''。
两个环境之间存在许多相似之处。两者都基于定义字符集的国际标准。在 X 和 Linux 控制台中，都可以定义一个名为 Compose 的键，按下该键后跟另外两个键将生成相应的字符。因此，按下 compose-,-c 序列将生成一个带软音符的 c。
控制台的处理由操作系统直接完成，普通应用程序不参与键盘扫描代码的处理，而是在每次按下键时接收一个字符或字符序列，这样，如果键盘和字符字体配置正确，则无需再做任何操作。
X 具有非常不同的架构：键盘和屏幕（可能有多个屏幕）都由一个名为 X 服务器的特殊应用程序控制。按下键会生成一条消息（称为事件），该消息由 X 服务器传递给客户端应用程序。有一个非常有用的程序叫做 xev，它允许观察传输给它的每个事件。客户端和服务器通过网络使用一组称为 X 协议的规则进行通信，并且可以在不同的机器上运行。运行服务器的机器称为工作站或 X 终端，运行应用程序（客户端程序）的机器也称为客户端。
更深入地讨论 X 中的事件处理超出了本文的范围。有关更多信息，建议查阅 推荐读物 部分中提到的文档，但重要的是要澄清服务器发送给客户端的事件不包含键的数字代码，在 X 术语中称为 keycode。相反，发送的是一个符号，称为 keysymbol 或 keysym，通过查询服务器内存中维护的转换表获得。此表可以随时通过 X 协议中定义的请求完全或部分修改。
有一个名为 xmodmap 的程序，能够读取包含 keycode-->keysym 转换表的文件，并以 X 协议中消息的形式将其发送到服务器。客户端而不是服务器负责解释 keysym，这意味着应用程序应该知道在接收到“死键”时再等待一个字符以组成一个重音字母。
自 X 修订版 5 以来，函数库（Xlib）中存在一种复杂的机制，用于支持以各种代码生成字符。早期版本中已经存在的文本输入处理函数 XLookupString，但是，并没有以对应用程序透明的方式处理重音和字母序列。相反，包含了一种使用输入上下文的组合方法，通过函数 XmbLookupString 和 XwcLookupString，即使对于 Compose 键，其使用也是应用程序（或更确切地说，是其程序员）的责任。这是因为 X Consortium 得出的结论是，按键映射系统无法令人满意地处理世界各地书写的各种语言。因此，决定将与键盘管理相关的``权重''转移到 X 应用程序，这在使用那些不使用新方法的旧应用程序时会造成困难。
由于这些原因，通常更难在 X 下运行的应用程序中添加对生成重音字符的支持，尤其是在没有源代码的情况下。仅在文本模式下运行的应用程序，例如 vi 和 minicom，将完全依赖于在 X 窗口中运行时使用的终端仿真器的资源。如果使用当前版本的 xterm 或 rxvt，则仿真器将正确处理重音。
法国人 Thomas Quinot 厌倦了等待更好的 X 重音问题解决方案，决定为 André D. Balsa 提出的 Xlib 修改实现，该修改添加了直接重音支持，如 绕过 X 的限制 部分所示。这允许使用 xfig 或 xedit 等应用程序，而无需更改它们。这个技巧似乎仅适用于 ISO-8859-1 代码的字符，但对于葡萄牙语和其他语言来说已经足够了。正如 Balsa 所观察到的，从长远来看，所有程序都应该被修改为使用 X 的新功能，但由于从长远来看我们都会死掉，Quinot 的短期解决方案变得非常有吸引力...