Normalizador Unicode NFKC
file ㎞ ① pasa a file km 1: las ligaduras, las letras de ancho completo, los dígitos en círculo y otras variantes de estilo se pliegan a texto simple y luego los acentos se recomponen, así las copias de un mismo nombre coinciden al buscar. Gratis en su navegador.
- Gratis
- Funciona en su navegador
- Sin registro
- Sus datos no salen de su equipo
Ejecutar — gratis
Ejemplo resuelto
- Texto
- file ㎞ ①
- Resultado
- file km 1
- Forma
- NFKC
- Longitud de entrada
- 7
- Longitud de salida
- 9
Este normalizador Unicode NFKC toma cualquier cadena Unicode y devuelve su resultado en Normalization Form KC: descomposición de compatibilidad seguida de composición canónica según el Anexo 15 del estándar Unicode. Ese camino pliega formas de presentación que se ven distintas en almacenamiento pero deben coincidir en búsqueda, indexación y comprobaciones de identidad: las ligaduras fi pasan a f e i simples, las letras latinas de ancho completo a ASCII A–Z, los dígitos en círculo a números ordinarios, las letras góticas y matemáticas estilizadas se reducen hacia la base, y secuencias como e más acento agudo combinante se componen en un único carácter precompuesto cuando existe. Los desarrolladores usan NFKC al construir claves de deduplicación, pipelines de slugs de URL y búsqueda de catálogo para que variantes de compatibilidad visualmente equivalentes no aparezcan como registros separados. Use la ruta gratuita del navegador para inspeccionar los pliegues antes de integrar el algoritmo idéntico en automatización.
Qué hace NFKC y en qué se diferencia de NFC
Unicode define cuatro formas de normalización. NFC y NFD operan solo sobre equivalencia canónica: recomponen o descomponen caracteres que el estándar trata como el mismo carácter abstracto, por ejemplo é precompuesto frente a e más acento agudo combinante. NFKC y NFKD van más allá aplicando primero mapeos de compatibilidad.
Esos mapeos descartan a propósito distinciones de presentación útiles para tipografía pero no para emparejar: la ligadura fi de un solo punto de código pasa a f e i; dígitos y letras latinas de ancho completo se mapean a sus contrapartes ASCII de medio ancho; superíndices y subíndices se pliegan a dígitos ordinarios; fracciones se expanden a secuencias con barra de fracción; y muchas formas de letra encerradas o estilizadas se reducen hacia una base más simple.
Tras esa descomposición de compatibilidad, NFKC ejecuta el mismo paso de composición que NFC, de modo que la cadena final queda plegada por compatibilidad y canónicamente compuesta. Elija NFC cuando deba preservar ligaduras y estilo de ancho completo como glifos distintos para fidelidad visual. Elija NFKC cuando igualdad, búsqueda y hash deban tratar esas variantes como el mismo texto.
Esta capacidad aplica siempre NFKC y etiqueta la forma en la respuesta para que el cliente no adivine el algoritmo.
Dónde un normalizador NFKC aporta valor en pipelines reales
Los sistemas de búsqueda y catálogo normalizan títulos de producto y nombres introducidos por el usuario con NFKC antes de indexar, de modo que una marca de ancho completo y su gemela ASCII caigan en el mismo token. Los pipelines de contenido que generan slugs de URL aplican NFKC primero para que ligaduras y símbolos de compatibilidad no produzcan después sorpresas opacas con codificación percent.
Los trabajos de calidad de datos comparan registros tras NFKC para detectar casi duplicados que solo difieren por variantes Unicode estilizadas copiadas de PDF o documentos de oficina. Las comprobaciones de seguridad e identidad a veces normalizan nombres de usuario o etiquetas con NFKC antes de la igualdad, reduciendo formas de compatibilidad parecidas que no son ataques homógrafos reales pero sí rompen puertas de coincidencia exacta.
Los ingenieros de localización usan la herramienta gratuita del navegador en esta página para confirmar cómo se pliega una frase de muestra antes de fijar la misma forma en pruebas de aceptación.
Qué puede hacer con ella
Deduplicación en búsqueda y catálogo
Normalice títulos y nombres con NFKC antes de indexar para que ligaduras, letras de ancho completo y dígitos de compatibilidad compartan las mismas claves de búsqueda.
Pipelines de slugs y URL
Pliegue caracteres de compatibilidad antes de generar el slug para que el Unicode estilizado del portapapeles no produzca segmentos de ruta inesperados.
Preguntas frecuentes
¿Qué es la normalización Unicode NFKC?
NFKC es Normalization Form Compatibility Composition de UAX #15: descomposición de compatibilidad de formas de presentación y luego composición canónica. Pliega ligaduras y caracteres estilizados a una cadena compuesta estable para emparejar y buscar.
¿En qué se diferencia NFKC de NFC?
NFC solo trata la equivalencia canónica (por ejemplo componer e más agudo en é). NFKC también aplica mapeos de compatibilidad como fi→fi y ancho completo Ａ→A antes de componer, lo cual conviene más a igualdad e indexación.
¿En qué se diferencia NFKC de NFKD?
Ambas aplican primero el mismo plegado de compatibilidad. NFKD se detiene ahí y deja los acentos como marcas sueltas, mientras que NFKC los recompone, de modo que una e seguida de un acento agudo combinante termina siendo la letra é.
¿Cuándo conviene no usar NFKC?
Cuando las ligaduras, las formas de ancho completo o las letras estilizadas deben verse tal cual, por ejemplo en un texto maquetado. NFKC borra esas diferencias a propósito: use NFC para mostrar el texto y NFKC para comparar, buscar o detectar duplicados.
¿Qué pasa con las letras de ancho completo y los superíndices?
Se pliegan a su forma corriente: las letras latinas de ancho completo pasan a la A–Z normal, los dígitos en superíndice o subíndice a dígitos comunes y las fracciones se despliegan en dígitos con barra de fracción. Así el texto copiado de un PDF coincide con lo que se teclea.
Herramientas relacionadas
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/enc/unicode-nfkc \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"file ㎞ ①"}'const res = await fetch("https://api.kit.forhosting.com/enc/unicode-nfkc", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "file ㎞ ①"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/unicode-nfkc",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "file ㎞ ①"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/unicode-nfkc", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"file ㎞ ①"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"file ㎞ ①"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/unicode-nfkc", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"text": "file ㎞ ①"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.unicode_nfkc",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
Notas técnicas
El endpoint es trabajo parse puro: la misma entrada siempre produce la misma salida, sin llamadas de red, sin tokens de modelo y sin comportamiento dependiente de la fecha. La validación fallida devuelve invalid_input y no se factura; las llamadas correctas cuestan el precio base publicado $0.002.
Qué hace NFKC y en qué se diferencia de NFC
El campo result es la cadena normalizada; text repite la entrada; input_length y output_length informan longitudes JavaScript antes y después; changed es true cuando la salida difiere de la entrada carácter a carácter; y standard nombra UAX 15 para alinear documentación y auditorías con la especificación Unicode y no con una tabla ad hoc.
Contrato de entrada, forma de respuesta y errores
Si falta text, falla con un mensaje claro de campo ausente. Las cadenas vacías son válidas y se normalizan a vacío con changed false. Como la implementación usa la ruta normalize de ECMAScript del host para la forma NFKC, los goldens y producción comparten el mismo mapeo determinista para cada escalar admitido por el motor. Envíe por POST un objeto JSON con el campo obligatorio text que contiene la cadena Unicode a normalizar. Se aceptan los alias input, value, s y data para que formularios, ayudas de consulta y clientes SDK reutilicen nombres familiares sin renombrar columnas. El valor debe ser una cadena; números finitos y booleanos se convierten a su forma decimal o true/false por comodidad en shells de scripting, mientras que objetos, arrays, un cuerpo null sin campo, NaN e Infinity fallan con invalid_input y un mensaje que nombra el problema. Cadenas de más de 65536 caracteres se rechazan para mantener predecible la memoria del Worker. En éxito el cuerpo incluye siempre result, el text eco, form fijado a la cadena NFKC, input_length, output_length, un booleano changed y una etiqueta standard que apunta a la composición de compatibilidad Unicode NFKC. Combine este endpoint con un convertidor de puntos de código cuando necesite inspeccionar tokens U-plus antes y después del pliegue, o con herramientas de case-folding cuando la búsqueda exija NFKC y también insensibilidad a mayúsculas. Las solicitudes inválidas no se cobran; solo las normalizaciones correctas consumen el precio por ítem de $0.002.
Dónde un normalizador NFKC aporta valor en pipelines reales
Como la capacidad es parse puro de nivel A, cada llamada correcta cuesta $0.002, no sale a la red y coincide byte a byte con la ruta interactiva gratuita en el mismo módulo. Mantenga las cargas bajo el límite de longitud, trate invalid_input como un error de cliente a corregir y no como un error de servidor reintentable, y documente que eligió NFKC a propósito cuando NFC, pensado para preservar la visualización, habría sido el valor por defecto incorrecto para emparejar.
Casos de integración
Pruebas golden de identidad de texto
Fije salidas NFKC de ligaduras, marcas combinantes y cuadrados de compatibilidad en CI para que las bibliotecas no cambien el pliegue en silencio.
Preguntas técnicas
¿Qué entrada acepta el normalizador Unicode NFKC?
Envíe un objeto JSON con el campo de cadena obligatorio text (alias input, value, s, data). Si falta text, hay objetos o arrays no cadena, números no finitos o cadenas de más de 65536 caracteres, se devuelve invalid_input.
¿Qué incluye la respuesta?
result es la cadena NFKC; text repite la entrada; form es siempre NFKC; input_length y output_length son longitudes de caracteres; changed es true si la normalización alteró la cadena; standard nombra UAX #15.
¿Cuánto cuesta el normalizador Unicode NFKC?
La herramienta del navegador es gratuita. Las solicitudes API usan saldo KIT prepago a $0.002 por llamada correcta; la entrada inválida no se factura.