Jorge Serrano
  • Home

Cannot get the value of a token type ‘Number’ as a string con System.Text.Json

  • By jorge
  • Mar-18-2020
  • .NET 5, .NET Core 3.0, .NET Core 3.1
  • 0 Comments.

Introducción

Una de las tareas que debemos empezar a plantear dentro de nuestros desarrollos de .NET Core, sino lo hemos hecho ya (y dentro de poco con .NET 5 y posteriores), es la migración de Newtonsoft.Json a System.Text.Json.

Dentro de las tareas de migración, es posible que nos encontremos con situaciones especiales que nos den algún que otro quebradero de cabeza.
Situaciones que no esperábamos y que debemos sortear y resolver.

En esta entrada, voy a exponer una de esas situaciones con la que me he encontrado, y cómo la he resuelto.

Se trata de partir de la base de un JSON que deserializaba correctamente con Newtonsoft, pero que al deserializarlo con System.Text.Json, obtengo un error:
Cannot get the value of a token type ‘Number’ as a string

 

Poniendo en contexto el problema

Un JSON debe estar bien formado, algo que doy por hecho.
Un JSON debe tener un formato acorde con la entidad que lo va a consumir, algo que no siempre es así, ya que puede ocurrir que el JSON tenga unas propiedades diferentes a las que se espera en la entidad que lo va a deserializar, u otras circunstancias.

Así que imaginemos que partimos de una entidad Student que tiene dos propiedades.

Id => string
Name => string

public class Student
{
    public string Id { get; set; }

    public string Name { get; set; }
}

Lo natural es recibir un JSON cuyas propiedades cuadren perfectamente con las propiedades de la entidad, como por ejemplo:

{"Id": "123", "Name": "John"}

Ahora bien, como digo, no siempre es así.
De hecho, pensemos en que lo que recibimos es realmente algo como:

{"studentId": "123", "Name": "John"}

Nuestra clase en este caso, debería tener en consideración que al deserializar el JSON, el valor de studentId debería ser asignado a Id.
Por lo que en este caso, nuestra clase debería tener el siguiente aspecto para Newtonsoft:

public class Student
{
    [Newtonsoft.Json.JsonProperty(PropertyName = "studentId")]
    public string Id { get; set; }

    public string Name { get; set; }
}

De esta manera, le estaremos indicando a Newtonsoft, que la propiedad studentId del JSON debe ser mapeada a Id.

Si deserializamos de acuerdo a este ejemplo, obtendremos los datos como queríamos:

var studentJson = "{\"studentId\":\"123\", \"Name\":\"Jorge\"}";
var studentWithNewtonSoft = Newtonsoft.Json.JsonConvert.DeserializeObject<Student>(studentJson);

Y lo mismo sucede en el caso de usar System.Text.Json en lugar de Newtonsoft.

Nuestra clase deberá tener en este caso el siguiente aspecto:

public class Student
{
    [System.Text.Json.Serialization.JsonPropertyName("studentId")]
    [Newtonsoft.Json.JsonProperty(PropertyName = "studentId")]
    public string Id { get; set; }

    public string Name { get; set; }
}

Y la forma en la que deserializaremos la información será de la siguiente forma:

var studentJson = "{\"studentId\":\"123\", \"Name\":\"Jorge\"}";
var studentWithNewtonSoft = Newtonsoft.Json.JsonConvert.DeserializeObject<Student>(studentJson);
var studentWithNetCore = System.Text.Json.JsonSerializer.Deserialize<Student>(studentJson);

Hasta aquí todo correcto.

Ahora bien, vamos a suponer que el JSON no tiene porqué asumir ni tener en cuenta que el valor de studentId sea realmente un valor string, y lo que nos viene es un int.

Sé que dirás que no es lo esperado, pero a veces, puede pasar.

¿Que sucedería en este caso?.

Lo que por defecto Newtonsoft se traga, no se lo traga System.Text.Json

Partiremos entonces del siguiente JSON:

{"studentId": 123, "Name": "John"}

¿Qué sucederá en el ejemplo anterior?.

Si ejecutamos este código:

var studentJson = "{\"studentId\": 123, \"Name\":\"Jorge\"}";
var studentWithNewtonSoft = Newtonsoft.Json.JsonConvert.DeserializeObject<Student>(studentJson);
var studentWithNetCore = System.Text.Json.JsonSerializer.Deserialize<Student>(studentJson);

Se producirá un error con el siguiente mensaje:

System.Text.Json.JsonException: 'The JSON value could not be converted to 
System.String. Path: $.studentId | LineNumber: 0 | BytePositionInLine: 17.'
InvalidOperationException: Cannot get the value of a token type 'Number' as a string.

Así que lo que inicialmente y por defecto, se traga Newtonsoft, System.Text.Json devuelve una excepción.

El motivo es que está esperando un dato de tipo string y por el contrario, en el JSON viene un int.

¿Cómo resolver este problema?.

 

Resolviendo el problema

System.Text.Json es muy sensible y restrictivo.

Muchos desarrolladores se quejan en Internet de él, ya que están habituados a la flexibilidad (a veces anarquía) que puede llegar a ofrece Newtonsoft, sin embargo, estoy de acuerdo con el «purismo» de System.Text.Json.

De hecho, si somos estrictos, el JSON que indico no debería ser un valor válido de entrada/formato para nuestro sistema.

Pero evitando entrar ahora en esa discusión, System.Text.Json nos ofrece alternativas para revertir el problema.

Una de las particularidades de System.Text.Json es la posibilidad de extender la propia librería de Microsoft.

En nuestro caso, resolveremos el problema a través de una conversión.

Podemos crear nuestro Converter heredando de JsonConverter y personalizando la conversión.

Un sencillo ejemplo de conversión para el problema planteado, podría ser la siguiente clase de conversión para System.Text.Json:

public class LongToStringJsonConverter : JsonConverter<string>
{
    public LongToStringJsonConverter() { }

    public override string Read(ref Utf8JsonReader reader, Type type, JsonSerializerOptions options)
    {
        if (reader.TokenType != JsonTokenType.Number && 
            type == typeof(String))
            return reader.GetString();

        var span = reader.HasValueSequence ? reader.ValueSequence.ToArray() : reader.ValueSpan;

        if (Utf8Parser.TryParse(span, out long number, out var bytesConsumed) && span.Length == bytesConsumed)
            return number.ToString();

        var data = reader.GetString();

        throw new InvalidOperationException($"'{data}' is not a correct expected value!")
        {
            Source = "LongToStringJsonConverter"
        };
    }

    public override void Write(Utf8JsonWriter writer, string value, JsonSerializerOptions options)
    {
        writer.WriteStringValue(value.ToString());
    }
}

En este caso, nuestro código utilizando el conversor y resolviendo el problema anterior quedaría de la siguiente forma:

var options = new System.Text.Json.JsonSerializerOptions();
options.Converters.Add(new LongToStringJsonConverter());

var studentJson = "{\"studentId\": 123, \"Name\":\"Jorge\"}";
var studentWithNewtonSoft = Newtonsoft.Json.JsonConvert.DeserializeObject<Student>(studentJson);
var studentWithNetCore = System.Text.Json.JsonSerializer.Deserialize<Student>(studentJson, options);

Si ejecutamos nuestro código, veremos que ahora sí, System.Text.Json trata correctamente el dato convirtiéndolo en string y evitando el problema que estábamos obteniendo.

 

Mejorando el rendimiento

Ahora bien, dentro de System.Text.Json y del conversor que hemos preparado, tenemos la posibilidad de mejorar aún más el problema de deserialización.

El conversor se va a lanzar por todas y cada una de nuestras propiedades dentro del JSON.
Esto puede estar bien, pero podría no ser necesario.

De hecho, supongamos que sabemos que sólo el campo studentId es el «problemático».
¿Tiene sentido que el conversor se lance por todas las propiedades, o sólo por las propiedades que sabemos que pueden llegarnos en un formato diferente?.

Pues bien, eso es posible también.

De hecho, nuestra entidad tendría en este caso un aspecto similar al siguiente:

public class Student
{
    [System.Text.Json.Serialization.JsonPropertyName("studentId")]
    [System.Text.Json.Serialization.JsonConverter(typeof(LongToStringJsonConverter))]
    [Newtonsoft.Json.JsonProperty(PropertyName = "studentId")]
    public string Id { get; set; }

    public string Name { get; set; }
}

En este caso, el código de nuestro deserializador quedaría de la siguiente forma:

var studentJson = "{\"studentId\": 123, \"Name\":\"Jorge\"}";
var studentWithNewtonSoft = Newtonsoft.Json.JsonConvert.DeserializeObject<Student>(studentJson);
var studentWithNetCore = System.Text.Json.JsonSerializer.Deserialize<Student>(studentJson);

Pero el conversor, sólo se lanzaría para la propiedad studentId que es la que sabemos que nos da el problema.

 

Otras circunstancias

En este ejemplo, parto de la premisa que studentId es string o int.
En el caso de que viniera en el JSON un valor como 1.23, tal y como está preparado el conversor, daría una excepción.
En estos casos, deberíamos «fortalecer» el conversor para asumir ese tipo de valores o bien, deberíamos entender que el valor que viene en el JSON no es válido, algo que en este caso y para mí sería lo correcto, ya que 1.23 debería venir como «1.23».

Pero aquí entraríamos más en una discusión funcional.

Lo que es claro es que el conversor en ese caso debería ser modificado para que cubriese esta situación.

Happy Coding!

Comments

Deja un comentario Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

← Previous Post Next Post →

Jorge Serrano

MVP Reconnect


¡Subscríbete a mi canal!
YouTube

Donaciones
Donation

Entradas recientes

  • Go – Arrays
  • Go – Operators
  • Go – Constants
  • Go – Tipos de Datos
  • Go – Variables
  • Hello Go-rld!
  • Introducción a Go o Golang
  • JSON Patch en ASP.NET Core 5 Web API
  • Null Checking en C#
  • ¿Porqué mi página web por defecto de ASP.NET Core no se vé en mi Azure Web App y me da un 404?

Categorías

  • .NET 5
  • .NET Core
  • .NET Core 3.0
  • .NET Core 3.1
  • .NET Framework 2.0
  • .NET Framework 3.0
  • .NET Framework 3.5
  • .NET Framework 4.0
  • .NET Framework 4.5
  • .NET Framework 4.6
  • .NET Framework 4.7
  • .NET Framework 4.8
  • .NET Standard 2.0
  • .NET Standard 2.1
  • AMQP
  • Android
  • Angular
  • API REST
  • Apple
  • Apple iOS
  • Apple macOs
  • Arquitectura
  • ASP.NET
  • ASP.NET Core
  • ASP.NET Core 3
  • ASP.NET Core 5
  • AWS
  • Azure App Service
  • Azure Application Insights
  • Azure Cosmos DB
  • Azure Database Migration Service
  • Azure Databricks
  • Azure DevOps
  • Azure Event Grid
  • Azure Functions
  • Azure IoT
  • Azure Portal
  • Azure PowerShell
  • Azure Queue Storage
  • Azure SQL
  • Azure Storage
  • Azure Virtual Datacenter
  • Azure WebApps
  • Big Data
  • Bing
  • Blazor
  • Blog
  • Bots
  • C#
  • C# 7.0
  • C# 7.1
  • C# 7.2
  • C# 7.3
  • C# 8.0
  • C# 9.0
  • Channel 9
  • Codeplex
  • Codespaces
  • Containers
  • Debugging
  • DevOps
  • Docker
  • Electron
  • Entity Framework
  • Entity Framework Core
  • Entity Framework Core 3.0
  • Entity Framework Core 5
  • Eventos
  • F#
  • FaaS
  • FeatureFlags
  • FeatureToggles
  • Feeds
  • Fluent Assertions
  • General
  • GIMP
  • Git
  • GitHub
  • Go
  • Google
  • Google Analytics
  • Gradle
  • gRPC
  • GSA
  • Historia de la Informática
  • HoloLens
  • HtmlAgilityPack
  • IdentityServer4
  • Inkscape
  • Ionic
  • iOS
  • IoT
  • Java
  • JavaScript
  • JDBC
  • JSON
  • Kubernetes
  • Lenguajes de Programación
  • Libros y Cursos
  • LINQ
  • Linux
  • LiteDB
  • Machine Learning
  • macOS
  • Microservices
  • Microsoft
  • Microsoft .NET Framework 4.5
  • Microsoft 365
  • Microsoft Azure
  • Microsoft Build
  • Microsoft Ignite
  • Microsoft Learn
  • Microsoft Orleans
  • Microsoft Surface Go
  • Microsoft Teams
  • ML.NET
  • MQTT
  • MRO
  • MS-DOS
  • MsCoders Madrid
  • MVP
  • NancyFx
  • Node.js
  • NoSQL
  • NuGet
  • NUnit
  • OData
  • ODP.NET Core
  • Office 2007
  • Office 2010
  • Office 2013
  • Office 2016
  • Office 2019
  • Office 365
  • Open Source
  • Open XML SDK
  • Opinión
  • Orchard CMS
  • OT
  • PaaS
  • Patterns
  • PdfSharpCore
  • Performance
  • PHP
  • Postman
  • Power BI
  • PowerShell
  • PowerShell Core
  • Productividad
  • Project Server 2019
  • R
  • Rendimiento
  • Scala
  • Scraper
  • Security
  • Serverless
  • Service Fabric
  • SharePoint Server 2019
  • SignalR
  • Sin categoría
  • Sistemas Distribuidos
  • Skype
  • Skype for Business Server 2019
  • Small Basic Online
  • SQL Server 2005
  • SQL Server 2008
  • SQL Server 2012
  • SQL Server 2014
  • SQL Server 2016
  • SQL Server 2017
  • SQL Server 2019
  • STOMP
  • Swagger
  • Testing
  • TFS 2017
  • TFS 2018
  • Tools
  • TypeScript
  • Unity
  • UWP
  • UX
  • Visio
  • Visual Basic
  • Visual Studio 2010
  • Visual Studio 2012
  • Visual Studio 2013
  • Visual Studio 2015
  • Visual Studio 2017
  • Visual Studio 2017 for Mac
  • Visual Studio 2019
  • Visual Studio 2019 for Mac
  • Visual Studio App Center
  • Visual Studio Code
  • Visual Studio IntelliCode
  • Visual Studio Live Share
  • Visual Studio Live Share Audio
  • Visual Studio Online
  • VS Anywhere
  • Vue.js
  • Web API
  • WebAssembly
  • WinDbg
  • Windows
  • Windows 10
  • Windows Compatibility Pack
  • Windows Phone 10
  • Windows Phone 7
  • Windows Phone 8
  • Windows Server 2008
  • Windows Server 2012
  • Windows Server 2016
  • Windows Server 2019
  • Windows Service
  • WinForms
  • WinUI
  • WPF
  • Xamarin
  • Xbox
  • Xcode
  • Xiaomi Mi Band 2
  • xUnit
  • YAML

Archivos

  • enero 2021
  • diciembre 2020
  • noviembre 2020
  • octubre 2020
  • septiembre 2020
  • agosto 2020
  • julio 2020
  • junio 2020
  • mayo 2020
  • abril 2020
  • marzo 2020
  • febrero 2020
  • enero 2020
  • diciembre 2019
  • noviembre 2019
  • octubre 2019
  • septiembre 2019
  • agosto 2019
  • julio 2019
  • junio 2019
  • mayo 2019
  • abril 2019
  • marzo 2019
  • febrero 2019
  • enero 2019
  • diciembre 2018
  • noviembre 2018
  • octubre 2018
  • septiembre 2018
  • agosto 2018
  • julio 2018
  • junio 2018
  • mayo 2018
  • abril 2018
  • marzo 2018
  • febrero 2018
  • enero 2018
  • diciembre 2017
  • noviembre 2017
  • octubre 2017
  • septiembre 2017
  • agosto 2017
  • julio 2017
  • junio 2017
  • febrero 2015
  • octubre 2014
  • junio 2014
  • marzo 2014
  • febrero 2014
  • enero 2014
  • diciembre 2013
  • septiembre 2013
  • agosto 2013
  • julio 2013
  • junio 2013
  • abril 2013
  • febrero 2013
  • enero 2013
  • diciembre 2012
  • noviembre 2012
  • septiembre 2012
  • agosto 2012
  • junio 2012
  • mayo 2012
  • abril 2012
  • marzo 2012
  • febrero 2012
  • enero 2012
  • diciembre 2011
  • noviembre 2011
  • octubre 2011
  • septiembre 2011
  • agosto 2011
  • julio 2011
  • junio 2011
  • mayo 2011
  • abril 2011
  • marzo 2011
  • enero 2011
  • diciembre 2010
  • noviembre 2010
  • octubre 2010
  • septiembre 2010
  • agosto 2010
  • julio 2010
  • junio 2010
  • mayo 2010
  • abril 2010
  • marzo 2010
  • febrero 2010
  • enero 2010
  • diciembre 2009
  • noviembre 2009
  • octubre 2009
  • septiembre 2009
  • agosto 2009
  • julio 2009
  • junio 2009
  • mayo 2009
  • abril 2009
  • marzo 2009
  • febrero 2009
  • enero 2009
  • diciembre 2008
  • noviembre 2008
  • octubre 2008
  • septiembre 2008
  • agosto 2008
  • julio 2008
  • junio 2008
  • mayo 2008
  • abril 2008
  • marzo 2008
  • febrero 2008
  • enero 2008
  • diciembre 2007
  • noviembre 2007
  • octubre 2007
  • septiembre 2007
  • agosto 2007
  • julio 2007
  • junio 2007
  • mayo 2007
  • abril 2007
  • marzo 2007
  • febrero 2007
  • enero 2007
  • diciembre 2006
  • noviembre 2006
  • octubre 2006
  • septiembre 2006
  • agosto 2006
  • julio 2006
  • junio 2006
  • mayo 2006
About This Site

A cras tincidunt, ut tellus et. Gravida scel ipsum sed iaculis, nunc non nam. Placerat sed phase llus, purus purus elit.

Archives Widget
  • January 2010
  • December 2009
  • November 2009
  • October 2009
Categories
  • Entertainment
  • Technology
  • Sports & Recreation
  • Jobs & Lifestyle
Search
  • twitter

Powered by WordPress  |  Business Directory by InkThemes.

This site uses cookies: Find out more.