Tecnología · GUÍA PRÁCTICA
¿jq conserva el ID hasta ejecutar el filtro? Compruebe la ruta real antes de añadir BigInt
El filtro de identidad puede pasar mientras la aritmética cambia el último dígito. Compare salidas sin procesar para localizar la pérdida antes de que el reviver posterior la oculte.
Si cambia el último dígito del ID, conserve la salida sin procesar de cada etapa antes de cambiar el analizador. Una prueba de identidad correcta no demuestra que el filtro aritmético real conserve todos los dígitos.
Ocho pruebas locales distinguen el texto de origen, la salida de jq y el análisis en Node. Las expectativas de tipo cadena comprueban los dígitos completos.
1. Mantenga el ID esperado fuera de Number
Empiece por el texto JSON literal {"id":9007199254740993,"count":42} y guarde el ID esperado como la cadena "9007199254740993". No lo escriba como un literal numérico de JavaScript para comparar dos Number: el propio valor esperado puede haberse redondeado. Antes de cambiar los datos, anote los ejecutables exactos de jq y Node, sus versiones y el filtro de producción.
RFC8259 permite límites de implementación e identifica el intervalo de enteros interoperables hasta una magnitud de 2^53−1. Fuera de ese intervalo algunos enteros siguen siendo representables; no todos los valores grandes cambian. Un identificador opaco necesita sus dígitos exactos. Analizar correctamente o ver un registro aparentemente razonable no constituye una prueba de aceptación.
2. Compare la identidad con el filtro real
Nuestras ocho pruebas locales en Linux usaron jq1.7 y Nodev24.22.1. Con el ejemplo anterior, jq -c '.' emitió el token original ...993. El filtro .id += 0 emitió ...992. El manual de la versión1.7 distingue los literales conservados sin modificar de la aritmética de doble precisión. Pasar la prueba de identidad solo acredita esa operación, no la seguridad de cualquier filtro.
Capture el texto emitido inmediatamente antes y después de cada transformación. En este ejecutable, .id |= tostring produjo "9007199254740993"; .id += 0 | .id |= tostring produjo "9007199254740992". Convertir a texto antes y después son controles diferentes. Repita las pruebas con el filtro y la compilación de producción: estos resultados no certifican otras implementaciones ni versiones de jq.
3. Demuestre qué recibió realmente el reviver
JSON.parse normal seguido de id.toString() produjo ...992. Aplicar BigInt a ese valor ya analizado también produjo ...992. Un reviver limitado a una clave que lee BigInt(context.source) recuperó ...993 desde el ejemplo original y desde la salida del filtro de identidad. Tras la aritmética de jq, el mismo reviver produjo ...992: el token de entrada ya había cambiado.
Para el ID numérico de esquema conocido, el callback de prueba fue (k,v,c)=>k==='id'&&typeof v==='number'?BigInt(c.source):v. Sirve para el ejemplo, no como validador general. Compruebe la compatibilidad con context.source en el entorno real y valide la ruta del campo y la gramática del token entero. Los decimales y exponentes requieren un contrato aparte; convertir toda cadena que parezca numérica también cambiaría campos que deben seguir siendo texto.
4. Cierre la comprobación de ida y vuelta
Si controla la API, acuerde con el receptor un ID de tipo cadena antes de migrar. En la octava prueba serializamos explícitamente el BigInt recuperado como id.toString(), analizamos el mensaje conforme a ese contrato de cadena y obtuvimos todos los dígitos originales. Esto acredita la ida y vuelta del ejemplo, no la compatibilidad con un esquema numérico sin modificar. No cambie silenciosamente cantidades, importes decimales ni campos ajenos.
Acepte la reparación solo cuando coincidan el token original capturado, cada transferencia prevista y la comparación final de cadenas conforme al esquema. Conserve la regresión del filtro real junto al control de identidad, incluidos ...993 frente a ...992 y el primer límite que cambió. Corregir el reviver posterior no restaura información perdida antes. Usamos ejemplos locales, no una pasarela en producción ni un navegador; repita la prueba en cada límite real entre productor y consumidor.
