Planteamiento y contexto
Un repositorio permite identificadores no ASCII y comentarios multilingües. Un cambio contiene controles bidi o identificadores visualmente confusables, pero un visor de texto plano renderiza un orden engañoso. Diseña un escáner que detecte el riesgo sin rechazar comentarios y cadenas legítimos en árabe, hebreo u otros idiomas multilingües.
Qué evalúa el entrevistador
- Si el análisis léxico, el renderizado bidireccional y los diagnósticos de seguridad son etapas separadas.
- Si comprendes los átomos de código fuente léxico de UTS #55 y su semántica de visualización HL4.
- Si utilizas las reglas de confusables y de restricción de UTS #39 en lugar de tratar cada carácter no ASCII como hostil.
- Si manejas versiones de datos de Unicode, escaneos incrementales, hallazgos explicables y políticas de falsos positivos.
Preguntas de clarificación para hacer
Primero confirma el lenguaje de destino, la versión del compilador, los alfabetos (scripts) de identificadores permitidos y los idiomas de los comentarios; identifica si el escáner se ejecuta en un editor, en CI o en una plataforma de alojamiento de código. Luego aclara si los hallazgos advierten, bloquean el envío o requieren revisión, y si se deben seguir admitiendo datos antiguos de Unicode o código que no se pueda analizar sintácticamente.
Respuesta de 30 segundos
Utilizaría el analizador léxico (lexer) del lenguaje de destino para obtener tokens, identificadores, cadenas y comentarios, registrando luego los puntos de código originales, los controles direccionales y los scripts para cada átomo. La visualización del código fuente sigue la estructura léxica de UTS #55 en lugar de tratar el archivo como un único párrafo ordinario. Los diagnósticos combinan datos de restricción y confusables de UTS #39, informando posiciones, reglas, versiones y diferencias renderizadas. Los hallazgos pueden advertir de forma predeterminada y bloquear según la política del repositorio; el texto original se conserva para que el texto RTL válido no se confunda con un ataque.
Análisis detallado paso a paso
1. Establecer primero los límites léxicos
No apliques el procesamiento bidi de párrafo ordinario carácter por carácter. Los literales numéricos, identificadores, cadenas de una sola línea y el contenido de comentarios forman átomos; los lenguajes anidados necesitan límites de la gramática externa. Reutiliza los rangos de tokens de un compilador o parser maduro, y degrada explícitamente a diagnósticos conservadores cuando el análisis sintáctico falle.
2. Marcar controles bidi y caracteres ignorables por defecto
Para cada átomo, registra controles como RLO, LRO, PDF, RLI, LRI, FSI y PDI con sus alcances (scopes). Los informes deben mostrar puntos de código escapados y posiciones originales, evitando que una terminal o página web aplique los controles nuevamente. No los elimines a ciegas porque el diseño legítimo puede necesitar controles direccionales.
3. Organizar la visualización del código fuente con UTS #55
UTS #55 recomienda aplicar el protocolo de nivel superior HL4 a la estructura léxica: el orden de los tokens sigue la sintaxis del lenguaje, mientras que las cadenas, identificadores y comentarios son átomos indivisibles renderizados con sus propiedades direccionales. Esto preserva el texto RTL legible y la estructura de código auditable al mismo tiempo.
4. Aplicar reglas de identificadores y confusables
Aplica la normalización permitida por el lenguaje, el uso de mayúsculas/minúsculas y el perfil UAX #31 a los identificadores, luego utiliza UTS #39 para diagnósticos de alfabetos mixtos y confusables. No conviertas un skeleton en el identificador en sí; es un valor de comparación intermedio para una versión de datos de Unicode y es útil para encontrar posibles colisiones.
5. Escribir el flujo de escaneo más pequeño
El pseudocódigo siguiente muestra únicamente los límites de las etapas; el código de producción aún necesita el lexer del lenguaje de destino y los archivos de datos de Unicode:
type Atom = { kind: string; start: number; end: number; text: string };
type Finding = { code: string; start: number; end: number; detail: string };
function diagnose(source: string, atoms: Atom[], unicodeVersion: string): Finding[] {
const findings: Finding[] = [];
for (const atom of atoms) {
findings.push(...scanBidiControls(atom));
if (atom.kind === "identifier") {
findings.push(...scanIdentifierConfusables(atom, unicodeVersion));
}
}
return findings;
}scanBidiControls debe preservar los puntos de código de control y los alcances; scanIdentifierConfusables debe devolver hallazgos de alfabetos mixtos, nivel de restricción o colisión de identificadores existentes. La etapa de diagnóstico no debe reescribir el código fuente.
6. Gestionar versiones, cachés y escaneos incrementales
Escribe la versión de datos de Unicode, la versión del lexer del lenguaje y la configuración de reglas en cada informe. Almacena en caché los resultados de los tokens por contenido de archivo y versión del lexer; una compilación incremental vuelve a escanear los tokens e identificadores afectados en el mismo ámbito. Después de una actualización de datos de Unicode, vuelve a calcular los skeletons y conjuntos de colisiones en lugar de reutilizar entradas de caché antiguas.
7. Separar los hallazgos de la política
Cada hallazgo debe incluir archivo, línea y columna, código de regla, puntos de código originales, renderizado visible y una sugerencia de remediación. Una capa de política elige advertencia, bloqueo, revisión o permiso; el mismo hallazgo puede tener diferentes políticas en un editor, CI o interfaz de usuario de alojamiento de código. Los registros nunca deben renderizar controles no escapados directamente.
Respuesta de muestra de alta calidad
Dividiría la implementación en lexer, análisis de Unicode, vista previa de renderizado e informe de políticas. El lexer devuelve rangos exactos para tokens, identificadores, cadenas y comentarios; una región no analizable se marca como incierta en lugar de asignarle límites de caracteres. El análisis de Unicode registra Bidi_Control, conjuntos de alfabetos, perfil de normalización y resultados de confusables de UTS #39 para cada átomo. La vista previa mantiene el orden sintáctico de los tokens utilizando el enfoque UTS #55 HL4, aplica reglas bidi dentro de cada átomo y muestra puntos de código escapados junto con el renderizado. Los informes llevan la versión de datos de Unicode, versión del lexer, código de regla y ubicación; la política elige advertencia o bloqueo según el riesgo del campo. Un skeleton de la misma versión puede ayudar a encontrar colisiones de identificadores, pero no es un nombre de usuario ni un hash estable. Las claves de caché incluyen contenido del archivo, versión del lenguaje y versión de Unicode, y las actualizaciones activan un recálculo por lotes. Las pruebas cubren comentarios RTL, controles dentro de cadenas, lenguajes anidados, identificadores de alfabetos mixtos, fallos de análisis sintáctico, ediciones incrementales y diferencias entre renderizadores de terminal y web.
Errores comunes y enfoques fallidos
- Renderizar cada carácter de izquierda a derecha, haciendo ilegibles los comentarios y cadenas RTL válidos.
- Bloquear cada carácter no ASCII y romper lenguajes legítimos e identificadores internacionales.
- Reemplazar un lexer con expresiones regulares, perdiendo el contexto de si un control está en una cadena, comentario o identificador.
- Conservar solo texto limpio y perder los puntos de código originales y las posiciones de auditoría.
- Comparar skeletons producidos por diferentes versiones de Unicode sin un plan de migración.
Preguntas de seguimiento y respuestas
¿Por qué no eliminar todos los caracteres Bidi_Control?
Algunos textos legítimos necesitan controles direccionales, y la eliminación altera lo que ven los usuarios. Bloquéalos o escápalos en el código fuente según la política del lenguaje; informa el contexto y conserva el original en comentarios y cadenas.
¿Qué debe hacer el escáner cuando falla el análisis léxico?
Devolver un rango incierto explícito, ejecutar diagnósticos conservadores de controles y puntos de código, y no afirmar que la región es segura. CI puede requerir revisión hasta que un parser admita el lenguaje con precisión.
¿Cómo demuestras que el código multilingüe no se marca falsamente?
Utiliza comentarios RTL válidos, cadenas e identificadores permitidos como casos positivos, y RLO/LRO, alfabetos mixtos y colisiones de confusables como casos negativos. Compara el orden lógico, el orden visible y las ubicaciones de los informes en múltiples editores, terminales y renderizadores web.