Un informático registró la matrícula 'NULL' para su coche y ahora debe miles de dólares en multas que le llegan por error

Muy raro sería que al intentar serializar un valor null a json o a xml en un lenguaje de programación lo hiciese como un string. Lo que puede ser es que el OCR que detecta la matricula esté alojado en otro servidor y al consultarlo mediante http devuelva null en la respuesta, en vez de devolver un error http con código conocido tipo 500. Entonces al tratar el valor de salida como un string el resultado es 'null'. Esto se ve mucho en apis y sistemas que en vez de usar las cabeceras http devuelven en la respuesta cosas como '200 Ok' directamente en el buffer de la respuesta.

No tiene nada de raro, si el campo se llama "matricula" y el objeto que la contiene la declara como un String (supongamos que hablamos de algún OOPL popular), al deserializar los datos transmitidos tienes que asignar el valor obtenido de matrícula al campo de tipo String "matricula". Y tienes varias opciones:
1. Si lo recibo vacío, ¿lo pongo como null (sin inicializar)? ¿O como cadena vacía?
2. Si quiero poder tener matriculas sin inicializar (por ejemplo, si tienes campos diferentes para diferentes tipos de matrícula y solo quieres inicializar una), ¿cómo señalizo que una en particular la quiero sin inicializar en lugar de vacía? Por ejemplo, eligiendo que la cadena "null" represente matrículas sin inicializar?

Pues bueno por raro que parezca son opciones por defecto en motores populares de serialización. Véase Google JSON (Gson), o los motores de Spring MVC.

Lo que comentas de la serialización y el parseado (o deserialización como dices) es correcto, pero creo que estás sacando las cosas del tema que nos ocupa.

Estamos hablando de una matrícula con la string "NULL" . Al serializar y parsear la string "NULL" ninguna librería parseadora lo va a interpretar como NULL sino como la string "NULL", otra cosa es que las bases de datos interpreten "" como NULL, pero al meter parsear una string "NULL" va a seguir siendo una string con la palabra null y se meterá en la base de datos como tal (acabo de probar por si no lo recordaba bien o no me había fijado pero efectivamente postgresql y mysql —que son las que he probado rápidamente— meten la string "NULL" como string y "" como NULL, pero "NULL" no lo meten como NULL bajo ningún concepto. De hecho es algo lógico, no he probado más bd por falta de tiempo pero es bastante probable que si ambas lo hacen ese sea el estándar y si hay alguna bd que no lo sigue sería poco predecible y en mi opinión incorrecto).

Entonces estamos hablando de que en la BD tienen como matrícula la string "NULL" (la suya) y a él supuestamente le están llegando multas de matrículas que por algún motivo tienen el campo como NULL y que de la misma forma al intentar validar un registro está interpretando su matrícula "NULL" como NULL. Es decir que supuestamente hay alguna consulta en algún sitio que al solicitar la matrícula = "NULL" está devolviendo también filas con matrícula = NULL, cosa que NO hace ninguna base de datos y es esto lo que estamos debatiendo.

Puede haber problemas de serialización/parseado que estén haciendo que una matrícula con la string "NULL" sea leída por el servidor como NULL? Puede ser, y lo que estamos diciendo precisamente es que esto es erróneo y está mal programado.

Lo que me lleva a pensar que:
1) Hay algún fallo en el servidor en su propio código que está interpretando o convirtiendo erróneamente "NULL" a NULL (muy probable)
2) Hay algún fallo en una librería (por ejemplo un parser) al parsear lo que viene del cliente que convierte "NULL" a NULL (poco probable al ser seguramente una librería open-source y utilizada por mucha gente)
3) El tipo hizo una simple broma y los periodistas de la sala o gente sin muchos conocimientos técnicos le dio más importancia de la que tenía, la malinterpretó e hizo una noticia sobre ello, a lo cual otros medios se han sumado y han copiado la nota. (muy probable)
4) El tipo ha exagerado una broma y la captura le devuelve matrícula inválida por algún otro motivo que nada tiene que ver con el tema de NULL (probable)

Un saludo.

Muy sencillo, algún listo tiene enalgún procedimiento algo parecido a "....matricula IS NULL OR UPPER(matricula) = 'NULL'..."

Estás hablando de cosas como json, XSS y bases de datos modernas, cuando muchos de estos sistemas probablemente estén hechos en cobol y los datos se serialicen de forma mucho más primitiva.

Esto que es evidente hoy no lo era tanto hace 20 años y no digamos en los 80.

No conozco Cobol, pero si no trabaja con nulos, trabajará con cadenas vacías sin necesidad de usar una palabrita "NULL".

No sé cuánto habréis programado vosotros en MVC y transmisión de datos, pero estáis profundamente equivocados. Es totalmente cierto que null != "null", pero parece que el concepto de variable inicializada o sin inicializar no lo tenéis muy claro. En datos no en tránsito puedes tener una variable sin inicializar y/o vacía, pero en datos en tránsito (streams) no existe esa diferenciación porque el concepto de punteros a objetos o punteros a variables no existe, solo existe una hilera de bytes.
Sin ir más lejos en Spring MVC, cuando programas un Controlador, hay dos opciones: 1. Que las variables vacías de dejen sin inicializar o 2. que se interpreten como cadenas vacías. He programado uno hace unos días. Y a veces NECESITAS DIFERENCIAR UN CASO DE OTRO, por ejemplo si usas un librería como DATATABLES que necesita que estén inicializadas a cadenas vacías en la deserialización pero hay otras librerías que exigen lo contrario.

Se me ocurren mil razones que daros para insistir en la diferencia de casos, pero no tengo tanto tiempo.

Y para que quede claro el ejemplo de serialización. Si queréis que un campo de un objeto Coche llamado Modelo se transmita vía JSON, lo hacemos así:
{ coche : { modelo : "Focus" }}
O si no hay modelo especificado:
{ coche : modelo : "" }}
Si quieres reconstruir el objeto en destino y no hay modelo, ¿lo dejas en null o una cadena vacía? Dependiendo de tu lógica de negocio te interesará una cosa u otra, pero en JSON no puede simplemente no poner nada ahí porque la cadena JSON es inválida. Así que, si por cuestiones de lógica de negocio, compatibilidad con diferentes librerías, validación etc. necesitas sabes si el modelo es "" o está sin inicializar, tienes que pensar en una estrategia para poder señalizar el caso sin inicializar y, en el motor de deserialización o parseo transformar esa señal en un NULL.

No tienes ni idea compañero.
En la vida una cadena con el valor "NULL" va a ser igual al objeto NULL. Si eso ocurre es que no sabes programar y los estas igualando tú a fuego, cosa que está mal.
Por lo tanto si es verdad lo que cuenta la historia más les vale contratar a algún buen programador que arregle esa chapuza.

Llevo años programando amigo, créeme que sé lo que digo. Te dejo una referencia para que leas:
https://www.google.com/amp/s/howtodoinjava.com/gson/serialize-null-values/amp/

Es la primera que sale con la búsqueda "serialize null values".

Como puedes ver al final, el JSON resultante tiene una cadena con el valor "null", un String. No tiene las comillas, pero si conoces JSON, no necesito explicarte nada más.

A ver compañero, no sé si sabes que {"myValue": null} y {"myValue": "null"} no son lo mismo en ningún caso. En un JSON puedes definir un valor como null (y no por la cadena "null"), que por otra parte es lo lógico. Échale un ojo a lo que dicen desde http: //www .json.org/ o mírate este hilo https: //stackoverflow.com/questions/21120999/representing-null-in-json.

Dicho lo cual, si aún así sigues queriendo igualar un valor a la cadena "null" deberás tratarlo al interpretar el JSON, porque trabajar con la cadena "null" sigue siendo una chapuza y más para el caso que nos ocupa.

Tu ortografía sí que es Null

Creo que tenéis un poco confundidos los conceptos. El "valor" null no es ningún valor sino una etiqueta hacia un punto inválido de memoria en un sistema en concreto - no tiene el mismo sentido hablando de datos en tránsito. No es algo que se pueda transmitir. Pero cuando serializas objetos para transmitirlos puede darse el caso de que quieras diferenciar entre cadenas inicializadas (que acaban en base de datos ocupando un hueco de cadena inicializada a ""), y cadenas sin inicializar (que en base de datos no se han inicializado y por tanto no tienen asignado aún un espacio y al consultarlos aparecen como NULL). Las estrategias de serialización y deserialización comunes suelen convertir bien las cadenas vacías a cadenas sin inicializar en los objetos reconstruidos o al revés, pero es legítimo tratar de cubrir ambos casos, por ejemplo para saber si un usuario ha querido dejar un campo vacío a propósito o si aún no ha tenido la oportunidad. Pero bueno, no voy a discutirlo.

Muy sencillo.En la serialización no tiene sentido escribir el texto NULL para un vacío. Primero porque ocupa espacio, máxime si tiramos de Unicode amplio.

Si por ejemplo se usan pipes o tuberías (|) como separador, ante un nulo nos encontraríamos con dos pipes pegados como "||" en que en medio de los dos hay un hermoso nulo, que ocupa cero bytes y no lleva a confusión.

Algún problema serio debe haber en los sistemas de tráfico en USA.

Me remito a lo escrito en otro comentaro hace 5 minutos. Tiene sentido si quieres distinguir ambos casos, que hay situaciones (usando librerías de terceros con diferentes requisitos por ejemplo) que requieren que los campos estén inicializados o no.
En JSON no tienes el concepto de NULL, por lo que sí debes señalizar que un campo está sin inicializar por cualquier motivo, lo quieres enviar de alguna manera que te permita saber la diferencia. Por ejemplo, no es lo mismo una contraseña vacía que una contraseña sin inicializar.

Lo mismo pensé.

«ni siquiera null != "null". »: quisiste decir que: «ni siquiera null == "null"». ¿?

Exacto, me has pillado jajaja. Me di cuenta de la doble negación tarde, debería haber usado ‘ hasta’ para enfatizarlo en vez de ‘ni siquiera’.

Tal vez el sistema esté hecho en algún lenguaje de tipado dinámico sin validación

http://chuletario.blogspot.com/2011/05/kill-null-killen-all.html?m=1

Es cierto un valor NULL no es un string NULL, no tiene nada que ver.

Mi impresión es que probablemente -muy probablemente- el campo matrícula sea una primary key dentro de la BBDD y por tanto no puede guardar NULL. El problema, en mi opinión, es que se quiere guardar la información de las multas en las que la matrícula del coche no está identificada y la solución que se adoptó es que si la matricula = NULL introducir "NULL" en la BBDD.

Siempre que no haya cámaras en juego...

Pero las multas le llegan, jugada maestra o no?

www.dmv.ca.gov

Él se imaginaba más bien lo contrario: que todas sus multas le iban a salir gratis.

😄

No creo que la empresa que gestiona las multas de parking use Linux, sera la típica subcontrata que usa Windows 7.

/dev/null no es exclusivo de GNU/Linux

Si tienes una empresa que opta a ese concurso sería una buena forma de demostrar que los anteriores son unos inútiles :P (y seguramente el funcionario que tome la decisión, y que tenga una multa en cada uno de sus coches gracias a eso no esté muy contento con ellos)

¿Tú sabes por dónde te sopla el viento?????

Seguro que allí es mucho más fácil recurrirlas.