YAML: ¿Necesito comillas para cadenas en YAML?

Resuelto Alexander Popov asked hace 10 años • 8 respuestas

Estoy intentando escribir un diccionario YAML para la internacionalización de un proyecto Rails. Sin embargo, estoy un poco confundido, ya que en algunos archivos veo cadenas entre comillas dobles y en otros sin ellas. Algunos puntos a considerar:

  • ejemplo 1 : todas las cadenas utilizan comillas dobles;
  • ejemplo 2 : ninguna cadena (excepto las dos últimas) utiliza comillas;
  • el libro de cocina YAML dice: Encerrar cadenas entre comillas dobles le permite utilizar el sistema de escape para representar caracteres ASCII y Unicode. ¿Significa esto que necesito usar comillas dobles sólo cuando quiero escapar de algunos caracteres? En caso afirmativo, ¿por qué utilizan comillas dobles en todas partes en el primer ejemplo, sólo por razones de unidad/estilísticas?
  • Las dos últimas líneas del ejemplo 2 usan !la etiqueta no específica, mientras que las dos últimas líneas del primer ejemplo no, y ambas funcionan.

Mi pregunta es: ¿cuáles son las reglas para usar los diferentes tipos de comillas en YAML?

¿Podría decirse que:

  • en general, no necesitas comillas;
  • si desea escapar de los caracteres, utilice comillas dobles;
  • utilizar !con comillas simples, cuando...?!?
Alexander Popov avatar Oct 01 '13 14:10 Alexander Popov
Aceptado

Después de una breve revisión del libro de cocina YAML citado en la pregunta y algunas pruebas, aquí está mi interpretación:

  • En general, no necesitas comillas.
  • Utilice comillas para forzar una cadena, por ejemplo, si su clave o valor es 10pero desea que devuelva una cadena y no un Fixnum, escriba '10'o "10".
  • Utilice comillas si su valor incluye caracteres especiales (por ejemplo :, {, }, [, ], ,, &, *, #, ?, |, -, <, >, =, !, %, @, \).
  • Las comillas simples le permiten poner casi cualquier carácter en su cadena y no intentarán analizar códigos de escape. '\n'sería devuelto como la cadena \n.
  • Las comillas dobles analizan los códigos de escape. "\n"se devolvería como un carácter de avance de línea.
  • El signo de exclamación introduce un método, por ejemplo, !ruby/sympara devolver un símbolo Ruby.

Me parece que el mejor enfoque sería no usar comillas a menos que sea necesario y luego usar comillas simples a menos que desee procesar códigos de escape específicamente.

Actualizar

"Sí" y "No" deben estar entre comillas (simples o dobles) o, de lo contrario, se interpretarán como valores TrueClass y FalseClass:

en:
  yesno:
    'yes': 'Yes'
    'no': 'No'
Mark Berry avatar Mar 06 '2014 20:03 Mark Berry

Si bien la respuesta de Mark resume muy bien cuándo se necesitan las comillas de acuerdo con las reglas del lenguaje YAML, creo que lo que muchos de los desarrolladores/administradores se preguntan, cuando trabajan con cadenas en YAML, es "¿cuál debería ser mi regla general para manejar las cadenas?". ?"

Puede sonar subjetivo, pero la cantidad de reglas que debes recordar, si deseas usar las comillas solo cuando sean realmente necesarias según las especificaciones del idioma , es algo excesiva para algo tan simple como especificar uno de los tipos de datos más comunes. . No me malinterpretes, eventualmente los recordarás cuando trabajes con YAML regularmente, pero ¿qué pasa si lo usas ocasionalmente y no desarrollaste el automatismo para escribir YAML? ¿Realmente quieres dedicar tiempo a recordar todas las reglas sólo para especificar la cadena correctamente?

El objetivo de la "regla general" es ahorrar el recurso cognitivo y realizar una tarea común sin pensar en ella. Podría decirse que nuestro tiempo de "CPU" se puede utilizar para algo más útil que manejar las cadenas correctamente.

Desde esta perspectiva, puramente práctica, creo que la mejor regla general es poner las cadenas entre comillas simples. La razón detrás de esto:

  • Las cadenas entre comillas simples funcionan en todos los escenarios, excepto cuando es necesario utilizar secuencias de escape.
  • El único carácter especial que debe manejar dentro de una cadena entre comillas simples es la propia comilla simple.

Estas son sólo dos reglas que algún usuario ocasional de YAML debe recordar, minimizando el esfuerzo cognitivo.

wombatonfire avatar May 14 '2021 14:05 wombatonfire

Ha habido algunas respuestas excelentes a esta pregunta. Sin embargo, me gustaría ampliarlos y proporcionar algo de contexto de la nueva especificación oficial YAML v1.2.2 (lanzada el 1 de octubre de 2021), que es la "fuente verdadera" de todo lo relacionado con YAML.

Hay tres estilos diferentes que se pueden usar para representar cadenas, cada uno de ellos con sus propias (des)ventajas:

YAML proporciona tres estilos escalares de flujo: entre comillas dobles, entre comillas simples y simples (sin comillas). Cada uno ofrece un equilibrio diferente entre legibilidad y poder expresivo.

Estilo de comillas dobles :

  • El estilo entre comillas dobles se especifica mediante "indicadores circundantes. Este es el único estilo capaz de expresar cadenas arbitrarias mediante el uso \de secuencias de escape. Esto tiene el costo de tener que escapar de los personajes \y ".

Estilo de comillas simples :

  • El estilo de comillas simples se especifica mediante 'indicadores circundantes. Por lo tanto, dentro de un escalar de comillas simples, dichos caracteres deben repetirse. Esta es la única forma de escape realizada en escalares entre comillas simples. En particular, los caracteres \y "podrán utilizarse libremente. Esto restringe los escalares entre comillas simples a caracteres imprimibles. Además, sólo es posible dividir una línea larga entre comillas simples donde un carácter de espacio está rodeado por espacios que no son espacios.

Estilo simple (sin comillas) :

  • El estilo simple (sin comillas) no tiene indicadores de identificación y no proporciona ninguna forma de escapar. Por lo tanto, es el estilo más legible, más limitado y más sensible al contexto. Además de un conjunto de caracteres restringido, un escalar simple no debe estar vacío ni contener espacios en blanco iniciales o finales. Sólo es posible romper una línea larga y sencilla donde un carácter de espacio está rodeado por espacios que no son espacios. Los escalares simples no deben comenzar con la mayoría de los indicadores, ya que esto causaría ambigüedad con otras construcciones YAML. :Sin embargo , los indicadores ?y -se pueden utilizar como primer carácter si van seguidos de un carácter "seguro" que no sea un espacio, ya que esto no causa ambigüedad.

TL;DR

Dicho esto, según la especificación oficial YAML uno debería :

  • Siempre que corresponda, utilice el estilo sin comillas, ya que es el más legible.
  • Utilice el estilo de comillas simples ( ) si se utilizan 'caracteres como "y dentro de la cadena para evitar escapar de ellos y, por lo tanto, mejorar la legibilidad.\
  • Utilice el estilo de comillas dobles ( ") cuando las dos primeras opciones no sean suficientes, es decir, en escenarios donde se requieren saltos de línea más complejos o caracteres no imprimibles.
F1ko avatar Nov 05 '2021 08:11 F1ko

Las cadenas en yaml solo necesitan comillas si (el comienzo de) el valor puede malinterpretarse como un tipo de datos o si el valor contiene un ":" (porque podría malinterpretarse como una clave).

Por ejemplo

foo: '{{ bar }}'

necesita comillas, porque puede malinterpretarse como tipo de datos dict, pero

foo: barbaz{{ bam }}

no lo hace, ya que no comienza con un carácter crítico . Próximo,

foo: '123'

necesita comillas, porque puede malinterpretarse como tipo de datos int, pero

foo: bar1baz234
bar: 123baz

No, porque no puede malinterpretarse comoint

foo: 'yes'

necesita comillas, porque puede malinterpretarse como tipo de datosbool

foo: "bar:baz:bam"

necesita comillas, porque el valor puede malinterpretarse como clave.

Estos son sólo ejemplos. El uso yamllintayuda a evitar iniciar valores con un token incorrecto

foo@bar:/tmp$ yamllint test.yaml 
test.yaml
  3:4       error    syntax error: found character '@' that cannot start any token (syntax)

y es imprescindible si se trabaja productivamente con yaml.

Citar todas las cadenas, como algunos sugieren, es como usar corchetes en Python. Es una mala práctica, perjudica la legibilidad y desecha la hermosa característica de no tener que citar cadenas.

 avatar Mar 19 '2021 09:03