Skip to main content
Download

From text to physical keystrokes for AI agents

Convert a text into deterministic AZERTY Global sequences, ready to adapt to your automation driver. The dataset covers more than 1,000 Unicode characters.

200 characters at most. No content is transmitted.

Ready to convert the sample text. No content is transmitted.

Reading the output

Each character of the text becomes one entry of the tokens list, in order. codePoint gives its Unicode identifier and supported says whether it is supported. steps lists the keys to send, in order: code is the physical key, modifiers the modifiers to hold (AltGr, Shift), and role is deadKey for a dead key, to be followed by the next key.

Example for “œ”:

{
  "index": 1,
  "codePoint": "U+0153",
  "character": "œ",
  "kind": "character",
  "supported": true,
  "method": {
    "kind": "direct",
    "preconditions": {
      "capsLock": "off"
    },
    "steps": [
      {
        "role": "character",
        "code": "KeyO",
        "modifiers": [
          "AltGr"
        ]
      }
    ],
    "recommendedForAutomation": true
  }
}

From intent to application

Robust keyboard automation keeps intent separate from the mechanics of the system that executes it.

  1. 1. Agent

    The agent states the goal: type a character, complete a field or invoke a command. It should not assume that the rendered character tells it which physical key to send.

  2. 2. Logical sequence

    The specification describes physical positions and logical modifiers in a portable order. This layer can be verified and logged, and is independent of the driver you choose.

  3. 3. Driver, then application

    The driver translates the logical sequence for the operating system or hardware. The application then receives the events: the installed and active layout determines the resulting text.

When to use this converter

Use it when a scenario must reproduce real typing on a machine configured with AZERTY Global: a computer-use agent, interface QA, an RPA robot, a demonstration station, a robotics test bench or a KVM. In all of these cases, the final text depends both on the active layout and on the driver that injects the events.

Do not use it as a substitute for a text field, a business API, the clipboard or a semantic text entry already supported by your tool. Keystroke automation is appropriate when the exact behavior of the keyboard is part of what you are testing or controlling; otherwise, direct text entry is simpler and less brittle.

The key model

The contract relies on KeyboardEvent.code: it identifies a physical position such as KeyA or Digit2, rather than deriving a key from the rendered character. Logical modifiers are explicit, including AltGr, and one sequence can contain several ordered steps.

Dead keys need particular care. They produce an intermediate state, then compose with the following key. The converter therefore keeps the complete order of the sequence instead of reducing the intent to a single character. This is essential for accents, symbols and languages that rely on composition.

The result is never universal: Windows, macOS, Linux, browsers, remote sessions, accessibility permissions and hardware drivers do not offer exactly the same injection capabilities. Always check the target OS, the installed layout and the currently active layout before running a critical scenario.

Specification v0.1

The versioned files are the reference for integrating or validating a driver. The dataset defines the AZERTY Global sequences; the schema lets you check the objects produced by your automation chain.

AZERTY Global dataset JSON schema Report an issue on GitHub