Fullwidth to Halfwidth Character Normalization Prompt

This prompt is for internationalization engineers and platform developers who receive model-generated text containing mixed fullwidth and halfwidth characters. The core job-to-be-done is converting fullwidth characters (e.g., 'Ａ', '９', '！') to their halfwidth equivalents (e.g., 'A', '9', '!') to ensure consistent text alignment, search indexing, string comparison, and downstream system compatibility. This is not a general text cleanup prompt—it targets the specific encoding mismatch that occurs when models trained on multilingual corpora output CJK fullwidth forms in contexts that require ASCII-compatible halfwidth characters.

Use this prompt when your application must normalize text for systems that treat fullwidth and halfwidth characters as distinct code points—breaking SQL queries, search indexes, regex patterns, log parsers, or fixed-width display fields. The prompt is designed for post-generation repair: you receive a model output that is structurally valid but contains character-width inconsistencies, and you need a deterministic normalization pass before the text enters your application logic. The ideal user has a clear target script (Latin, digits, punctuation) and knows whether they need fullwidth-to-halfwidth conversion, halfwidth-to-fullwidth conversion, or bidirectional normalization. Required context includes the target character set, any characters that must be preserved in their original width, and the expected output encoding.

Do not use this prompt for general Unicode normalization (NFC/NFD/NFKC/NFKD), which handles canonical equivalence but does not specifically address character width. Do not use it when the distinction between fullwidth and halfwidth forms carries semantic meaning in the target domain—for example, in Japanese typography where fullwidth characters are intentional, or in legacy systems that require fullwidth forms for display. This prompt is also inappropriate for handling emoji width, combining characters, or bidirectional text layout issues. Before applying this prompt, verify that your downstream system actually requires width normalization; many modern systems handle fullwidth characters correctly, and unnecessary normalization can introduce data loss. For high-risk contexts such as financial identifiers, legal document text, or medical records, always implement a human review step after normalization to confirm that no semantically significant characters were altered.

This prompt template is designed to be copied directly into your application or evaluation harness. It instructs the model to convert fullwidth characters—common in CJK text environments—into their standard halfwidth equivalents. The template uses square-bracket placeholders for all dynamic inputs, making it safe to wrap in your own string formatting or template engine without conflicting with the model's native token syntax.

textCopy
You are a text normalization engine. Your task is to convert all fullwidth characters in the provided [INPUT_TEXT] to their standard halfwidth equivalents.

Follow these rules strictly:
1. Convert fullwidth alphanumeric characters (U+FF10-U+FF19, U+FF21-U+FF3A, U+FF41-U+FF5A) to standard ASCII alphanumerics.
2. Convert fullwidth punctuation and symbols to their halfwidth equivalents where unambiguous mappings exist. Do not convert characters that lack a standard halfwidth counterpart.
3. Preserve all other characters exactly as they appear, including CJK ideographs, kana, and hangul.
4. Do not alter whitespace, line breaks, or the structural layout of the text.
5. Return ONLY the normalized text. Do not add explanations, notes, or markdown formatting.

[INPUT_TEXT]:
[USER_INPUT]

To adapt this template, replace [USER_INPUT] with the text requiring normalization. If your target system requires fullwidth output instead of halfwidth, reverse the instruction. For high-risk pipelines—such as financial record processing or legal document ingestion—add a [CONSTRAINTS] block specifying characters that must never be converted, and always validate the output against a known-character allowlist before ingestion. For CJK-specific edge cases, extend the rules to handle fullwidth currency symbols (¥ to ¥), fullwidth parentheses, or the fullwidth space (U+3000) to halfwidth space conversion based on your system's requirements.

This prompt is designed to be a post-processing step in a text pipeline, not a standalone interactive tool. It should be called after a primary model generates text that may contain mixed fullwidth and halfwidth characters. The typical integration point is inside a validation or repair layer that sits between the primary model's output and the downstream consumer (a search index, a database, a UI component, or a comparison function). The harness should treat this normalization as a deterministic cleanup operation, but because it relies on an LLM, it must be wrapped with the same rigor as any other model call: idempotency checks, retry logic, and output validation.

To wire this into an application, start by defining a clear contract. The input to the harness should be a string ([INPUT]) and a target normalization rule ([TARGET], e.g., 'halfwidth' or 'fullwidth'). The harness should first perform a fast, pre-flight check using a Unicode character class regex. If the input already matches the target (e.g., no fullwidth characters are detected when halfwidth is requested), skip the LLM call entirely and return the original string. This saves cost and latency. If the LLM is called, the output must be validated: check that the character length is preserved (unless the normalization rule explicitly changes it), and verify that no illegal character classes remain. For CJK text, a critical validation step is to ensure that characters which do not have a halfwidth equivalent (such as most Kanji) are left untouched. A post-validation script should flag any output where the ratio of fullwidth to halfwidth characters hasn't shifted in the expected direction.

For retry logic, implement a maximum of two retries with exponential backoff. The most common failure mode is the model applying the rule too broadly (e.g., converting Latin letters but not digits, or vice versa) or too narrowly (missing some fullwidth punctuation). On the first retry, append the validation error message to the prompt as additional [CONSTRAINTS]. On the second failure, log the input, the failed outputs, and the validation errors as a structured event, then fall back to a deterministic, rule-based normalizer (such as Python's unicodedata.normalize with NFKC followed by a character mapping table). This hybrid approach ensures that the system remains reliable even when the model behaves unexpectedly. Never retry indefinitely; a rule-based fallback is always the final safety net for this deterministic task.

Model choice matters less for this task than for generative work, but consistency does. A smaller, faster, and cheaper model is often sufficient. Test the prompt against a golden dataset of 100+ mixed-encoding strings, including edge cases like fullwidth spaces (U+3000), fullwidth digits inside otherwise halfwidth text, and strings with combining characters. Record the exact model version and configuration. Before any model upgrade, rerun this golden set to detect normalization drift. Finally, ensure all inputs and outputs are logged in a structured format that includes the pre-flight check result, the model's raw response, the validation result, and the final output. This trace is essential for debugging silent corruption in downstream systems.