Convertir JSON a Ruby Hash Online

Depende del contexto de uso en tu código Ruby. Las claves symbol (:nombre, :edad) son el patrón dominante en Ruby idiomático por varias razones: los symbols son inmutables y únicos en memoria (Ruby mantiene una tabla global de symbols, por lo que :nombre siempre es el mismo objeto en toda la sesión), lo que los hace más eficientes para claves de Hash que se usan repetidamente. La sintaxis moderna de Ruby (desde 1.9) con { nombre: valor } (colon syntax) es más limpia y legible que la hashrocket { :nombre => valor }. Los frameworks como Rails usan symbols en todas sus APIs internas (params[:user_id], session[:user], flash[:notice]). Por otro lado, las claves string ('nombre', 'edad') son útiles cuando los datos vienen de JSON externo y se manipulan sin conversión, cuando las claves contienen caracteres no válidos para symbols (guiones, espacios, puntos), o cuando se usa HashWithIndifferentAccess de ActiveSupport que acepta ambos tipos de clave indistintamente.

Hash es la estructura de datos más flexible y la elección predeterminada para datos JSON en Ruby. Un Hash no tiene un esquema fijo: puedes añadir y eliminar claves dinámicamente. Es ideal para datos de configuración, respuestas de API con estructura variable, y cualquier dato que varíe en estructura. Struct.new(:campo1, :campo2) crea una clase con atributos fijos y acceso mediante métodos (objeto.campo1 en lugar de objeto[:campo1]). Los Struct son más rápidos que OpenStruct, consumen menos memoria, son comparables por valor (dos Struct con los mismos valores son iguales), y son una buena elección cuando conoces exactamente la estructura de los datos en tiempo de diseño. OpenStruct (de la biblioteca estándar ostruct) acepta atributos dinámicos como un Hash pero con sintaxis de acceso por método. Es conveniente para prototipado rápido pero tiene penalizaciones de rendimiento significativas: en benchmarks, OpenStruct es 10-50x más lento que Hash para acceso a atributos en Ruby 2.x, aunque Ruby 3.x mejoró significativamente su implementación.

Ruby incluye la biblioteca json en su biblioteca estándar desde Ruby 1.9 (2007). No requiere instalar ninguna gema adicional. El uso básico es: require 'json'; datos = JSON.parse(json_string). Por defecto, JSON.parse devuelve un Hash con claves string (las mismas que en el JSON original). Para obtener claves symbol, usa JSON.parse(json_string, symbolize_names: true). La opción symbolize_names convierte recursivamente todas las claves string en symbols, incluyendo claves en objetos anidados. Para generar JSON desde Ruby: JSON.generate(objeto) o objeto.to_json (método añadido por la biblioteca json a Hash, Array y los tipos primitivos). La gema json_pure es la implementación pura en Ruby; la gema json (incluida por defecto en MRI Ruby/CRuby) usa una extensión C para mayor rendimiento. En JRuby y TruffleRuby, la implementación de JSON usa el runtime Java subyacente.

Sí, y son importantes para código de producción. OpenStruct tiene tres penalizaciones de rendimiento principales: (1) Creación: crear una instancia de OpenStruct es más costoso que crear un Hash porque define métodos de acceso dinámicamente para cada atributo usando define_method. (2) Acceso: acceder a un atributo de OpenStruct (objeto.nombre) es más lento que acceder a un Hash (hash[:nombre]) porque pasa por method_missing o los métodos definidos dinámicamente, añadiendo overhead de despacho de métodos. (3) Memoria: cada instancia de OpenStruct tiene overhead adicional sobre Hash. En Ruby 2.7 y anteriores, los benchmarks mostraban OpenStruct 10-50x más lento que Hash. Ruby 3.0 introdujo mejoras significativas en OpenStruct (implementación reescrita en C en lugar de Ruby puro) reduciendo la brecha, pero OpenStruct sigue siendo más lento que Hash y Struct para acceso intensivo. La recomendación oficial de Ruby 3.x es: preferir Struct sobre OpenStruct cuando el esquema es conocido. Si necesitas acceso por método con esquema fijo y buen rendimiento, usa Struct; si necesitas flexibilidad para prototipado, usa OpenStruct con plena conciencia del coste de rendimiento.

ActiveSupport::HashWithIndifferentAccess (HWIA) es una subclase de Hash incluida en Rails (y disponible como gema activeSupport sin Rails completo) que permite acceder a claves indistintamente por string o symbol. Es el tipo que Rails usa para params: params[:user_id] y params['user_id'] devuelven el mismo valor. Para cargar JSON externo en Rails con acceso indistinto: json_data = JSON.parse(response_body).with_indifferent_access. El método with_indifferent_access está disponible en Hash a través de ActiveSupport. La conversión es recursiva para hashes anidados cuando se usa HashWithIndifferentAccess.new(hash) pero no cuando se usa .with_indifferent_access directamente en hashes anidados (hay que usar deep_symbolize_keys o similar para la conversión profunda). En Rails 7.x, ActionController::Parameters (el objeto params) implementa una semántica similar a HWIA pero con restricciones de seguridad adicionales (requires y permits para Strong Parameters).

Ruby 2.3 introdujo el pragma # frozen_string_literal: true que congela todos los string literals del archivo, haciendo que sean inmutables y compartidos en memoria (similar a como los symbols son únicos). Ruby 3.x continúa promoviendo esta práctica y en el roadmap de Ruby 4.0 se discute habilitarla por defecto. El impacto en código generado con claves string para Hash es: con frozen_string_literal activo, las claves string son congeladas automáticamente, lo que es eficiente para memoria (el mismo string 'nombre' en múltiples hashes puede apuntar al mismo objeto si es un string literal). Sin embargo, si el código intenta mutar una clave string (concatenar, gsub!, etc.) en un archivo con frozen_string_literal, se producirá un FrozenError en tiempo de ejecución. Para código que procesa JSON con claves string en archivos con frozen_string_literal, esto raramente es un problema porque las claves de Hash típicamente no se mutan. La recomendación para proyectos modernos en Ruby 3.x es incluir # frozen_string_literal: true en todos los archivos y usar claves symbol en Hashes de código propio para máxima eficiencia.