YAML Norway Sorunu ve Mühendislerin Bilmesi Gereken JSON ↔ YAML Farkları

Rutin bir Helm dağıtımıydı. Ekip, çok bölgeli bir yayın için values.yaml dosyasını ince ayar yapmak üzere iki gün harcamıştı. Chart, Norveç veri merkezleri için ülke kodu dahil yerel ayar meta verileri içeren bir Kubernetes ConfigMap şablonu oluşturuyordu. Biri country: NO yazıp işledi. CI pipeline yeşile döndü. Dağıtım gerçekleşti.

Ardından uyarılar geldi.

ConfigMap, country: "NO" yerine country: false içeriyordu. Ülke alanını okuyan her aşağı akış servisi, dize yerine boolean aldı. Dize karşılaştırması bozuldu. Yönlendirme mantığı varsayılana düştü. Norveç’te kalması gereken trafik, yanlış bölgesel endpoint tarafından işlendi.

Temel neden, YAML dosyasındaki tek bir tırnaksız dizeydi. YAML 1.1 — neredeyse tüm Kubernetes araçlarının kullandığı sürüm — NOyu boolean false olarak değerlendirir. YES, ON, OFF, Y, N, no, yes, on, off, y, n ve düzinelerce başka varyantı da aynı şekilde değerlendirir. Uyarı yok. Hata yok. Sessizce yanlış.

JSON’da bu sorun yoktur. {"country": "NO"} her zaman bir dizedir. YAML’ın örtük tür zorlaması hem en büyük kolaylığı hem de en tehlikeli tuzağıdır.

Bu kılavuz tüm tabloyu ele alır: Norway sorununun neden var olduğu, YAML 1.2’de neyin değiştiği (ve çoğu aracın neden bunu görmezden geldiği), doğru tırnak stratejilerinin nasıl yazılacağı, yeni başlayanları zorlayan girinti kuralları, sayı hassasiyet tuzakları ve Kubernetes manifest’lerinden Terraform planlarına kadar dört gerçek dünya dönüştürme senaryosu. Bir JSON değerini bu tuzak olmadan güvenle YAML’a dönüştürmeniz gerektiğinde, JSON’dan YAML’a dönüştürücümüz Norway sorunlu dizeleri otomatik olarak tırnak içine alır.

JSON ve YAML — Hangisini Ne Zaman Kullanmalı

Norway sorununa dalmadan önce, her formatın gerçekte ne için optimize edildiğini anlamak faydalıdır. Bunlar birbirinin yerine kullanılabilir değildir — her birinin belirli bağlamlarda daha iyi tercih haline getiren bir tasarım merkezi vardır.

Boyut	JSON	YAML
Sözdizimi	Katı — küme parantezleri, tırnaklar, virgüller zorunludur	Esnek — girintiye dayalı, minimum noktalama
Tür sistemi	Açık: dize, sayı, boolean, null, dizi, nesne	Örtük — YAML 1.1 türleri değer şeklinden çıkarır
İnsan okunabilirliği	Geliştirici dostu, makine tarafından doğrulanabilir	İnsan dostu, elle düzenlenmesi kolay
Tırnak zorunluluğu	Dizeler her zaman tırnak içinde	Çoğu skaler tırnaksız olabilir (Norway’ın kaynağı)
Yorumlar	Desteklenmiyor	`#` ile destekleniyor
Birincil kullanım	API’ler, veri değişimi, modern yapılandırma sistemleri	Kubernetes, Docker Compose, Ansible, CI pipeline’ları
Sürpriz ayrıştırmalar	Yok — katı ayrıştırma	Var — Norway, sekizlik, zaman damgası
Şema uygulaması	JSON Schema ekosistemi	YAML Schema (daha az araç)

JSON kazanır verileriniz sistem sınırlarını geçtiğinde — REST API’leri, mesaj kuyrukları, veritabanı serileştirmesi. Makineler ayrıştırır, makineler üretir ve katı sözdizimi doğrulamayı kolaylaştırır. Göndermeden önce yapıyı doğrulamak için JSON Biçimlendirici’yi kullanın.

YAML kazanır insanlar birincil yazar olduğunda. Kubernetes manifest’leri, GitHub Actions iş akışları, Helm chart’ları, Ansible playbook’ları — bunlar geliştiricilerin düzinelerce kez okuduğu ve düzenlediği dosyalardır. Azaltılmış noktalama ve yorumlar için destek, bunları JSON eşdeğerlerine kıyasla gerçekten daha sürdürülebilir kılar.

Sorun sınırda ortaya çıkar: bir araç JSON ürettiğinde (kubectl get deploy -o json veya terraform show -json gibi) ve bir insanın sonucu YAML olarak sürüm kontrol etmesi veya düzenlemesi gerektiğinde. Bu dönüştürme, Norway sorunun yaşandığı yerdir. Geri gitmek için YAML’dan JSON’a dönüştürücümüz ters yönü işler.

Norway Sorunu — Derinlemesine İnceleme

Norway sorunu bir hata değildir. Tam olarak tasarlandığı gibi davranan YAML 1.1 spesifikasyonunun bir özelliğidir. Neden bu şekilde tasarlandığını — ve pek çok sistemin neden hâlâ 1.1 uyguladığını — anlamak, bundan kaçınmanın anahtarıdır.

”no”, “yes”, “on”, “off”, “y”, “n” Neden Yanlış Ayrıştırılıyor

YAML 1.1 spesifikasyonu, insan dostu olmak amacıyla geniş bir boolean türü tanımladı. Aşağıdakilerin hepsini true veya false olarak tanıdı:

Doğru: y, Y, yes, Yes, YES, true, True, TRUE, on, On, ON

Yanlış: n, N, no, No, NO, false, False, FALSE, off, Off, OFF

Niyet iyiydi: yapılandırma dosyaları İngilizce’de true/false yerine sıklıkla yes/no kullanır ve YAML insanların yapılandırma yazma biçimini desteklemek istedi. Sorun şu ki yes, no, on, off, y ve n aynı zamanda çoğu uygulamada tamamen farklı bir anlam taşıyan mükemmel dize değerleridir.

İşte somut YAML’daki uyumsuzluk:

# YAML 1.1 (çoğu ayrıştırıcının uyguladığı)
country: NO        # şu şekilde ayrıştırılır: country: false   ← TEHLİKE
enabled: yes       # şu şekilde ayrıştırılır: enabled: true
restart: off       # şu şekilde ayrıştırılır: restart: false
language: y        # şu şekilde ayrıştırılır: language: true
shell: n           # şu şekilde ayrıştırılır: shell: false

# Doğru — açık dize tırnakları tür çıkarımını geçersiz kılar
country: "NO"      # şu şekilde ayrıştırılır: country: "NO"    ← güvenli
enabled: "yes"     # şu şekilde ayrıştırılır: enabled: "yes"
restart: "off"     # şu şekilde ayrıştırılır: restart: "off"
language: "y"      # şu şekilde ayrıştırılır: language: "y"
shell: "n"         # şu şekilde ayrıştırılır: shell: "n"

Ve JSON karşılaştırması:

{"country": "NO"}

JSON’da tırnak içindeki NO her zaman ve koşulsuz olarak bir dizedir. Örtük tür çıkarımı yoktur. JSON’u ayrıntılı hissettiren katılık aynı zamanda onu güvenli kılar.

Boolean zorlama ötesinde, YAML 1.1 şunları da örtük olarak dönüştürür:

123e4 → 1230000 sayısı (bilimsel gösterim)
0x1A → 26 sayısı (onaltılık)
0755 → 493 sayısı (sekizlik — bu, Unix dosya izin dizelerini bozar)
2024-05-04 → pek çok ayrıştırıcıda tarih nesnesi (yalnızca dize değil)
1_000_000 → 1000000 sayısı (alt çizgi ayırıcısı)

Norway sorunu aslında tüm bir YAML örtük tür zorlaması ailesinin en ünlü üyesidir.

YAML 1.1 ve 1.2 — Ne Değişti

YAML 1.2, YAML 1.1’den dört yıl sonra 2009’da yayımlandı. Temel amacı YAML’ı JSON ile sıkı bir uyuma getirmek (JSON aslında geçerli bir YAML 1.2 alt kümesidir) ve şaşırtıcı örtük tür dönüşümlerini azaltmaktı.

YAML 1.2’de:

Boolean, yalnızca true ve false ile (büyük/küçük harfe duyarlı) daraltıldı. Bu kadar. yes, no, on, off düz dizelerdir.
Sekizlik değişmez değerleri 0o öneki gerektirir (0o755) — eski 0755 formu bir dizedir.
Zaman damgaları örtük olarak ayrıştırılmaz — 2024-05-04, açıkça etiketlemediğiniz sürece dize olarak kalır.
Spesifikasyonun kendisi JSON üst kümesidir; yani her geçerli JSON belgesi geçerli YAML 1.2’dir.

Kağıt üzerinde YAML 1.2, Norway sorununu tamamen çözüyor. Pratikte ekosistem neredeyse hiç hareket etmedi.

Kütüphane	Varsayılan spesifikasyon	Norway riski
PyYAML (Python)	YAML 1.1	Evet — `yaml.safe_load` hâlâ `NO`yu `False` olarak ayrıştırıyor
ruamel.yaml (Python)	YAML 1.2 (isteğe bağlı)	Yapılandırılabilir — varsayılan olarak daha güvenli
js-yaml (Node.js)	YAML 1.1	Eski sürümlerde evet; daha yeni sürümlerde `FAILSAFE_SCHEMA` seçeneği var
eemeli/yaml (Node.js)	YAML 1.2	Hayır — varsayılan olarak 1.2 veya açıkça sürüm seçilebilir
gopkg.in/yaml.v2 (Go)	YAML 1.1	Evet
gopkg.in/yaml.v3 (Go)	YAML 1.2	Önemli ölçüde daha güvenli
Kubernetes / Helm	YAML 1.1 (Go yaml.v2 üzerinden)	Evet — tarihsel, taşıması çok güç
Ansible	YAML 1.1 (PyYAML üzerinden)	Evet

Geçişin yavaş olmasının nedeni geriye dönük uyumluluktur. On yıldır yes/nonun boolean olarak ayrıştırılmasına dayanan sistemler, mevcut yapılandırmaları bozmadan bu davranışı sessizce değiştiremez. Kubernetes özellikle YAML ayrıştırma semantiğini değiştirmenin küme genelinde kırıcı bir değişiklik olacağı devasa bir kurulu tabana sahiptir.

Pratik sonuç: Açıkça yapılandırmadığınız herhangi bir araçta YAML 1.1 semantiğini varsayın. Boolean, zaman damgası veya sayı olarak yanlış okunabilecek dizeleri her zaman tırnak içine alın.

Üretim Sistemleri Nasıl Yakalanıyor

Norveç ülke kodu, sezgisel olmadığı için en çok alıntılanan örnektir — NO açık bir kısaltma gibi görünür, boolean değil. Ancak bu kalıp birçok gerçek dünya senaryosunda tekrarlanır:

IATA havaalanı kodları. Norveç’in Harstad/Narvik havalimanının kodu EVE’dir. Güvenli. Oslo Gardermoen OSL’dir. O da güvenli. Ancak YAML’da bölgesel havaalanı kodları saklayan her uygulama, üretimdeki bir boolean false’dan yalnızca bir no rota kodu uzaklıktadır.

Ortam değişkeni adları. ON, bazı eski sistemlerde “etkin” anlamına gelen mükemmel geçerli bir ortam değişkeni değeridir. OFF ise karşılığıdır. Kabuk betiklerinden YAML’a yapılandırmaları bu değerleri tırnak içine almadan geçirmek sessiz tür zorlaması getirir.

E-posta kullanıcı alanları. Adı veya kullanıcı adı gerçekten n, y veya tetikleyici kelimelerden biri olan bir kullanıcı, uygulama uygun tırnaklama olmadan YAML döküyorsa yanlış serileşecektir. Bu, yalnızca bir kullanıcı alt kümesi için başarısız olduğundan özellikle sinsidir.

Docker Compose yeniden başlatma politikaları. restart_policy alanının "no" değeri “yeniden başlatma” anlamına gelir. Tırnaklarını bir YAML gidiş-dönüşünde kaybederse, değer false olur ve Docker Compose bunu “yeniden başlatma politikası belirtilmemiş” olarak yorumlayabilir veya doğrulama hatası fırlatabilir — her iki durumda da kapsayıcı yeniden başlatma davranışı yanlış olur.

GitHub Actions shell: alanı. Geçerli shell değerleri bash, pwsh, python, sh, cmd, powershell’dir. Bunların hiçbiri Norway kelimesi değildir. Ancak taslak düzenleme sırasında yer tutucu olarak shell: yes veya shell: on yazan biri, doğrulayıcı görmeden önce YAML’ın bunu boolean’a çevirmesiyle şaşırabilir.

Tüm durumlarda çözüm aynıdır: bir insan bunları anahtar kelime olarak tanısa da tanımasa da anlamsal olarak dize olan dizeleri tırnak içine alın. JSON’dan YAML’a dönüştürücümüz bunu otomatik olarak uygular — Norway kelime listesindeki her değer çıktıda tırnak içine alınır.

Dize Tırnak Stratejisi

Norway kelimelerinin neden uyumsuz olduğunu anladıktan sonra çözüm, kullanım durumunuz için doğru tırnak stratejisini seçmektir. YAML, her birinin farklı değiş tokuşları olan üç modu destekler.

Otomatik, Çift veya Tek

Otomatik tırnak (çoğu dönüştürme için önerilir), tırnak gerekli olduğunda kütüphanenin karar vermesine izin verir. Tırnaksız yanlış okunacak değerler — Norway kelimeleri, sayılar, zaman damgaları, YAML sözdizimi gibi görünen dizeler — otomatik olarak tırnak içine alınır. Diğer her şey düz skaler olarak kalır. Bu, güvenli kalırken en okunabilir çıktıyı üretir.

# Otomatik mod çıktısı
name: Alice          # düz — belirsizlik yok
country: "NO"        # tırnaklı — Norway kelimesi
age: 30              # düz — kesin sayı
created: "2024-05-04" # tırnaklı — aksi hâlde tarih olarak ayrıştırılır
port: "8080"         # kütüphaneye bağlı — bazıları sayısal görünen dizeleri tırnaklıyor

Çift tırnaklı dizeler tüm dize değerlerini çift tırnak içine sarar. Bu açık ve denetlenebilir — herhangi bir okuyucu, spesifikasyonu düşünmeden tüm bu değerlerin dize olduğunu görebilir. Değiş tokuş, özellikle derin iç içe yapılandırmalar için ayrıntılılık ve azalan insan okunabilirliğidir.

# Çift tırnak modu
name: "Alice"
country: "NO"
replicas: "3"         # sayılar bile dize olur — şema hatalarına yol açabilir

Dikkatli olun: hedef şemanız bir sayı bekliyorsa ve siz bunu tırnaklı dize olarak serileştirirseniz, YAML ayrıştırıcısı bunu doğru biçimde dize olarak tür belirleyecektir; ancak Kubernetes veya başka bir katı tüketici alanı yanlış tür olarak reddedebilir.

Tek tırnaklı dizeler yalnızca YAML’a özgü bir özelliktir — JSON’da tek tırnak sözdizimi yoktur. Tek tırnaklar değişmez değerdir: içlerinde kaçış dizisi bulunmaz. Tek özel durum, tek tırnaklı bir dize içindeki tek tırnağın iki kez yazılması gerektiğidir (''). Tek tırnaklar, çift tırnaklarda kaçış karakteri gerektiren ters eğik çizgiler veya özel karakterler içeren dizeler için idealdir.

# Tek tırnak modu
pattern: 'C:\Users\alice\Documents'  # kaçış gerekmez
regex: '\d+\.\d+'                    # ters eğik çizgiler değişmez

JSON’a geri dönüş yapacak JSON’dan YAML’a dönüştürmeler için Otomatik veya Çift modu tercih edin. Tek tırnaklı dizeler, geri dönerken YAML’ı bilen bir ayrıştırıcı gerektiren YAML’a özgü sözdizimi getirir.

Blok Skalerler (| ve >)

YAML’ın blok skaler sözdizimi, JSON’un \n kaçış dizileriyle hantal biçimde işlediği çok satırlı dizeler için gerçekten kullanışlıdır.

Değişmez blok skaler | yeni satırları tam olarak korur:

# Değişmez blok — yeni satırlar korunur
script: |
  #!/bin/bash
  set -euo pipefail
  echo "Starting deployment"
  kubectl apply -f manifest.yaml

# Eşdeğer JSON gösterimi (okunamaz)
# {"script": "#!/bin/bash\nset -euo pipefail\necho \"Starting deployment\"\nkubectl apply -f manifest.yaml\n"}

Katlı blok skaler > satırları boşluklarla birleştirir ve her yeni satırı boşluğa dönüştürür (boş satırlar hariç, bunlar yeni satır olur):

# Katlı blok — yeni satırlar boşluk olur
description: >
  This service handles authentication
  for the entire platform. It supports
  OAuth2, SAML, and API key authentication.

# Sonuç: "This service handles authentication for the entire platform. It supports OAuth2, SAML, and API key authentication.\n"

Blok skalerler, TLS sertifikalarını, çok satırlı kabuk betiklerini veya SQL sorgularını YAML yapılandırmalarına gömmek için mükemmeldir — JSON eşdeğerinin hiçbir insanın okuyamayacağı uzun, kaçışlı tek satırlar olduğu senaryolarda.

JSON’dan YAML’a dönüştürme yaparken, çoğu dönüştürücü (bizimki dahil) Otomatik modu kullanır ve gömülü yeni satır algılandığında çok satırlı dizeleri blok skalerlerle temsil eder. Tek satırlı dizeler akış skalerler (tırnaklı veya düz) alır. Bir manifest’e işlemeden önce çıktıyı görmek için JSON’dan YAML’a dönüştürücümüzü kullanın.

Girinti — 2 veya 4 Boşluk, Sekmeler Yasak

YAML’ın girinti kuralları göründüğünden daha katıdır. Spesifikasyonun bir mutlak kuralı ve ekosisteme göre değişen bir standardı vardır.

Mutlak kural: sekmeler yasaktır. Her girinti seviyesi boşluk kullanmalıdır. YAML dosyasındaki sekme karakteri, çoğu ayrıştırıcıda ayrıştırma hatasıdır:

# YANLIŞ — sekmeler ayrıştırma hatalarına yol açar
apiVersion: apps/v1
kind: Deployment
metadata:
	name: my-app     # ← burada sekme karakteri → ParseError

# DOĞRU — yalnızca boşluklar
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app      # ← iki boşluk

Gördüğünüz hata mesajı kütüphaneye göre değişir. Python’ın PyYAML’ında:

yaml.scanner.ScannerError: while scanning for the next token
found character '\t' that cannot start any token

Go’nun yaml.v3’ünde:

yaml: line 4: found character that cannot start any token

Düzenleyicinizi YAML dosyaları için sekmeleri boşluklara genişletecek biçimde yapılandırın. VS Code’da çalışma alanı ayarlarınıza şunu ekleyin: "[yaml]": { "editor.insertSpaces": true, "editor.tabSize": 2 }.

Standart: 2 veya 4 boşluk. Her ikisi de geçerlidir. Ekosistem standartları farklılık gösterir:

Ekosistem	Standart	Neden
Kubernetes manifest’leri	2 boşluk	Resmi belgeler ve örnekler 2 kullanıyor
Helm chart’ları	2 boşluk	K8s standardını izliyor
Docker Compose	2 boşluk	Resmi compose spec örnekleri
GitHub Actions	2 boşluk	Resmi iş akışı örnekleri
Ansible playbook’ları	2 boşluk	Resmi dokümantasyon
Geleneksel yapılandırmalar	4 boşluk	JSON güzelleştirme varsayılanıyla eşleşir

Kubernetes veya Docker Compose tarafından kullanılacak herhangi bir dosya için 2 boşluk kullanın. Yalnızca insanlar ve özel araçlar tarafından okunacak bağımsız yapılandırma dosyaları için her ikisi de işe yarar — yalnızca bir dosya içinde tutarlı olun. JSON’dan YAML’a dönüştürücümüz varsayılan olarak 2 boşluk girintisi kullanır ve bunu tercih eden projeler için 4’e geçmenize izin verir.

Bir kural daha: alt öğeler üst öğelerinden daha fazla girilmelidir; ancak ek boşluk sayısı herhangi bir pozitif tam sayı olabilir (1, 2, 3, 4…) — yalnızca bir blok içinde tutarlı olduğu sürece. Pratikte, okunabilirlik için her zaman 2 veya 4 kullanın.

JSON ↔ YAML Arasında Sayı İşleme

Her iki format da sayıları destekler; ancak sınır durumları üretim hatalarına neden olacak kadar farklıdır.

Büyük Sayılarda Hassasiyet Kaybı

JavaScript’in Number türü, 64 bitlik IEEE 754 kayan nokta değeridir. Tam sayıları 2^53 − 1 = 9.007.199.254.740.991’e kadar hassas biçimde temsil edebilir. Bunun ötesinde tam sayı hassasiyeti kaybolur:

// JavaScript hassasiyet kaybı — bu bir YAML sorunu değil, ama JSON ayrıştırmayı etkiliyor
JSON.parse('{"v": 9007199254740993}').v
// → 9007199254740992   (3, 2 oldu — bir bit kayboldu)

// Güvenli — 2^53 aralığında
JSON.parse('{"v": 9007199254740991}').v
// → 9007199254740991   (tam)

Bu, JavaScript ortamlarında JSON’dan YAML’a dönüştürme için önemlidir çünkü hassasiyet, YAML serileştirme başlamadan önce zaten kaybolmuştur. Kubernetes metadata.resourceVersion, kaynak sürümlerinin güvenli tam sayı aralığını aşabileceğini bilerek kasıtlı olarak dize alandır. observedGeneration, uid bileşenleri gibi küçük sayılara benzeyen diğer alanlar daha güvenlidir; ancak K8s yanıtındaki herhangi bir int64 alanı potansiyel olarak etkilenebilir.

Geçici çözümler:

Büyük sayılar içeren dönüştürme pipeline’ları için Python veya Go kullanın — her ikisi de tam sayıları yerel olarak sonsuz hassasiyetle işler.
Node.js’de BigInt destekleyen bir JSON ayrıştırıcısı kullanın: JSON.parse(text, (_, v) => typeof v === 'number' && !Number.isSafeInteger(v) ? BigInt(v) : v).
Kayıpsız gidiş-dönüş yapması gereken alanlar için bunları kaynakta dize olarak serileştirin.
Dönüştürülmüş YAML’ı incelerken resourceVersion, generation ve zaman damgasından türetilen değer gibi alanları arayın.

Sekizlik ve Onaltılık Tuhaflıklar

YAML 1.1, belirli sayıya benzer dizeleri ondalık olmayan tam sayılar olarak değerlendirir:

# YAML 1.1 ayrıştırma sürprizleri
permissions: 0755   # sekizlik 493 olarak ayrıştırılır, ondalık 755 değil
value: 0x1A         # onaltılık 26 olarak ayrıştırılır, "0x1A" dizesi değil

# YAML 1.2 davranışı
permissions: 0755   # tam sayı 755 olarak kalır (ondalık) — sekizlik 0o öneki gerektirir
permissions: 0o755  # her iki sürümde de sekizlik 493 olarak ayrıştırılır

# Her iki spesifikasyon için güvenli — baştaki sıfır içeren her değeri tırnak içine alın
permissions: "0755"  # her zaman "0755" dizesi

Sekizlik tuzak, Unix dosya izinleri, baştaki sıfırlar içeren IP adresi bileşenleri (bazı ağ aygıtları) ve dolgu için baştaki sıfır kullanan herhangi bir sayısal kod (posta kodları, ürün kodları) için özellikle tehlikelidir. YAML’ı elle yazarken bu değerleri her zaman tırnak içine alın veya dönüştürücünüzün onları tırnaklamasını sağlayın — JSON’dan YAML’a dönüştürücümüz JSON’dan sayısal dizeleri algılar ve dize türlerini korur.

Gerçek Dünya Dönüştürmeleri

Norway sorunu ve tırnak stratejileri, gerçek dönüştürme senaryolarına uygulandığında somutlaşır.

JSON’dan Kubernetes Manifest’i

Kanonik iş akışı: kubectl get deploy my-app -o json size canlı nesneyi JSON olarak verir. Temizlemek ( status, creationTimestamp, yönetilen alanları kaldırmak) ve YAML manifest olarak git’e işlemek istiyorsunuz.

Kaynak JSON (kısaltılmış):

{
  "apiVersion": "apps/v1",
  "kind": "Deployment",
  "metadata": {
    "name": "my-app",
    "namespace": "production",
    "labels": {
      "app": "my-app",
      "region": "NO"
    }
  },
  "spec": {
    "replicas": 3,
    "selector": {
      "matchLabels": { "app": "my-app" }
    },
    "template": {
      "spec": {
        "containers": [{
          "name": "app",
          "image": "registry.example.com/my-app:v1.2.3",
          "env": [
            { "name": "REGION", "value": "NO" },
            { "name": "ENABLE_FEATURE", "value": "yes" }
          ]
        }]
      }
    }
  }
}

Beklenen YAML çıktısı (Norway korumasıyla):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: production
  labels:
    app: my-app
    region: "NO"          # tırnaklı — Norway kelimesi
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    spec:
      containers:
        - name: app
          image: registry.example.com/my-app:v1.2.3
          env:
            - name: REGION
              value: "NO"           # tırnaklı — Norway kelimesi
            - name: ENABLE_FEATURE
              value: "yes"          # tırnaklı — Norway kelimesi

replicas: 3’ün tırnaksız bırakıldığına dikkat edin — Kubernetes’in sayı olarak beklediği geçerli bir tam sayıdır. labels ve env değerlerindeki Norway kelimeleri tırnaklıdır. YAML 1.1 boolean’larını işlemeyen naif bir dönüştürücü sessizce region: false ve value: false üretirdi.

Dönüştürdükten sonra şununla doğrulayın: kubectl apply --dry-run=client -f manifest.yaml. Bu, kümeye dokunmadan şema hatalarını yakalar.

Dönüştürmeyi JSON’dan YAML’a dönüştürücümüzde deneyin — yukarıdaki JSON’u yapıştırın ve Norway güvenli çıktıyı anında görün. Gidiş-dönüşü doğrulamak için YAML’dan JSON’a dönüştürücümüzü kullanın.

JSON’dan Docker Compose

CI/CD pipeline’ları bazen JSON yapılandırma deposundan programlı olarak Docker Compose yapılandırmaları oluşturur ve geliştiricilerin okuması için bunları disk üzerine YAML olarak yazar.

Kritik tuzak — yeniden başlatma politikası:

{"restart_policy": "no"}

Compose’da restart_policy: "no", “kapsayıcıyı hiç yeniden başlatma” anlamına gelen geçerli bir değerdir. YAML’da tırnaklar olmadan bu, Docker Compose’un aynı semantiği (yanlış = yeniden başlatma yok) veya tür doğrulama hatası ile reddetme olarak değerlendirebileceği restart_policy: false olur — davranış Compose sürümüne göre değişir. Tırnak zorunludur.

Ayrıca dikkat edin: Compose v3 deploy.restart_policy.condition: "on-failure" — on-failure değeri on kelimesini içerir; ancak kısa çizgi ile ayrılmıştır ve tetikleyici listesinde değildir, bu nedenle aslında güvenlidir. Ancak condition: on (-failure olmadan) uyumsuz olurdu. Norway kelimeleri olabilecekleri durumlarda environment: bloğundaki ortam değişkeni değerlerini tırnak içine alın.

Dönüştürmeden sonra Compose dosyalarını doğrulayın: docker-compose config kanonik formu ayrıştırıp yeniden çıkararak tür hatalarını ortaya koyar.

GitHub Actions İş Akışı

GitHub Actions iş akışları, geliştiriciler tarafından elle düzenlenen YAML dosyalarıdır. En yaygın dönüştürme senaryosu, GitHub API’sinden (JSON döndüren) iş akışı verilerini okumak ve düzenlemek için yerel bir YAML dosyasına dönüştürmektir.

Dikkat edilmesi gereken önemli alanlar:

# GÜVENLİ — standart GitHub Actions'da Norway kelimesi yok
on:                        # "on" burada bir değer değil, YAML anahtarı — farklı işleniyor
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: |
          npm install
          npm test
        env:
          NODE_ENV: production   # güvenli — Norway kelimesi değil
          DEBUG: "off"           # değerde Norway kelimesi — tırnak gerekiyor

Not: Bir YAML anahtarı olarak on: özeldir — Norway sorunu değerlere uygulanır, anahtarlara değil. Ancak on değer olarak (örneğin DEBUG: on) zorlamayı tetikler. env: bloğu özellikle incelenmeli çünkü ortam değişkeni değerleri dize, ancak birçoğu Norway kelimeleriyle çakışabilecek kısa bayraklardır.

shell: belirtimi içeren iş akışları için geçerli değerler (bash, pwsh, sh, python) Norway zorlamasından güvenlidir. Özel değerler proaktif biçimde tırnak içine alınmalıdır.

Terraform JSON Planından YAML’a

terraform show -json tfplan > plan.json, Terraform’un ne oluşturmayı, değiştirmeyi veya yok etmeyi planladığının ayrıntılı JSON gösterimini çıkarır. Bunu YAML’a dönüştürmek, pull request incelemeleri ve uyumluluk denetimleri için daha okunabilir hale getirir.

terraform plan -out=tfplan
terraform show -json tfplan > plan.json
# Ardından aracımızla veya kütüphaneyle dönüştürün

Terraform plan JSON’ı karmaşık ve derindir. Dönüştürürken önemli endişeler:

Büyük tam sayı ID’leri. Bulut kaynak ID’leri (AWS hesap ID’leri, GCP proje numaraları) ve hesaplanan öznitelik değerleri büyük sayılar olabilir. float64 hassasiyet kaybını önlemek için Python veya Go üzerinden dönüştürün.
Sürüm kısıtlaması dizeleri. Terraform, sağlayıcı sürüm kısıtlamalarında ~>, >=, <= kullanır. Bunlar Norway kelimeleri olmadığı sürece YAML’ın doğru biçimde işlediği dize değerleridir — ve ~> güvenlidir.
Sağlayıcı yapılandırma değerleri. Terraform plan çıktıları kaynaklar için yapılandırma değerleri içerebilir. Bazı sağlayıcı şemasında "no" olarak temsil edilen false varsayılanına sahip bir boolean alan varsa, YAML’a geri dönerken Norway riski oluşur.
.sensitive_values bloğu. Hassas değerler, plan JSON’ında true boolean olarak düzenlenir. Bunlar dönüşümden temiz geçer çünkü true her iki YAML sürümünde de Norway kelimesi değildir.

Terraform’dan YAML’a dönüşüm öncelikle insan incelemesi içindir, Terraform’a geri besleme için değildir. YAML manifest’lerini Terraform girişi olarak kullanmayın — Terraform’un yerel formatı HCL’dir ve JSON giriş formatı ayrı olarak belgelenmiştir.

Kod Örnekleri — 4 Dil

Node.js (eemeli/yaml + js-yaml)

Node.js ekosistemi, anlamlı ölçüde farklı Norway işlemesiyle iki baskın YAML kütüphanesine sahiptir:

// eemeli/yaml — önerilen, varsayılan olarak YAML 1.2, Norway güvenli
import { stringify } from 'yaml';
import { readFileSync } from 'fs';

const jsonInput = readFileSync('input.json', 'utf8');
const data = JSON.parse(jsonInput);

// Varsayılan: YAML 1.2 — "NO" "NO" olarak kalır, boolean zorlaması yok
const yamlOutput = stringify(data);
console.log(yamlOutput);
// region: NO      ← 1.2'de güvenli, ama maksimum uyumluluk için açıkça tırnak ekleyin

// YAML 1.1 davranışını zorlayın (1.1 ayrıştıran K8s/Helm ortamları için)
const yamlForK8s = stringify(data, { version: '1.1' });
// region: 'NO'    ← 1.1'in NO'yu false olarak ayrıştıracağından otomatik tırnaklı
console.log(yamlForK8s);

// js-yaml — yaygın, ancak YAML 1.1 semantiği, dikkat edilmezse Norway riskli
import yaml from 'js-yaml';
import { readFileSync } from 'fs';

const data = JSON.parse(readFileSync('input.json', 'utf8'));

// Varsayılan döküm — Norway kelimeleri tırnaklı olmayabilir
const unsafe = yaml.dump(data);
// region: NO    ← 1.1 ayrıştırıcısı tarafından yeniden okunursa false olarak ayrıştırılacak!

// Daha güvenli: özel şema veya zorlamalı tırnak kullanın
const safer = yaml.dump(data, {
  schema: yaml.JSON_SCHEMA,   // JSON uyumlu türlerle sınırlar
  noCompatMode: false,
  lineWidth: -1,
  quotingType: '"',
  forceQuotes: false,         // yalnızca JSON şemasına göre gerektiğinde tırnak ekler
});

Yeni projeler için eemeli/yaml’ı tercih edin. YAML 1.2 varsayılanı daha güvenlidir, Document API’si tırkaklama üzerinde ince ayarlı kontrol sağlar ve gidiş-dönüş sadakatini daha iyi işler. Zaten js-yaml kullanan projeler için, JSON güvenli türlerle sınırlandırmak üzere JSON_SCHEMA seçeneğini kullanın. JSON’u dönüştürmeden önce filtreleme ve dönüştürme konusunda daha derin bir bakış için, ön işleme kalıpları için jq komut satırı hızlı başvuru kılavuzuna bakın.

Python (PyYAML + ruamel.yaml)

Python, Kubernetes araçları, Ansible ve veri mühendisliği pipeline’ları için baskın dildir — hepsi yoğun YAML kullanıcılarıdır.

import json
import yaml
import sys

# PyYAML — basit, standart, ancak varsayılan olarak YAML 1.1
with open('input.json') as f:
    data = json.load(f)

output = yaml.dump(data, default_flow_style=False, allow_unicode=True)
# country: 'NO'   ← PyYAML aslında Norway kelimelerini otomatik tırnaklayacak kadar akıllı
# Ama 'yes', 'no' (küçük harf) tüm yapılandırmalarda tırnak içine almayabilir:
# enabled: 'yes'   ← tırnaklı
# tag: y           ← sürüme bağlı olarak tırnaklı olabilir veya olmayabilir

print(output)

import json
import sys
from ruamel.yaml import YAML

# ruamel.yaml — gidiş-dönüş sadakati, YAML 1.2'yi destekler, üretim için önerilir
yaml_rt = YAML()
yaml_rt.default_flow_style = False
yaml_rt.width = 4096              # istenmeyen satır kaydırmayı önle
yaml_rt.best_map_flow_style = False

with open('input.json') as f:
    data = json.load(f)

yaml_rt.dump(data, sys.stdout)
# Anahtar sırası korunur, Norway kelimeleri doğru işlenir, gidiş-dönüşte çapaları destekler

JSON API yanıtlarını YAML manifest’lerine dönüştürdüğünüz Ansible ve Kubernetes otomasyon betikleri için ruamel.yaml daha güvenli tercihtir. PyYAML, girdi verilerini kontrol ettiğiniz ve Norway kelimelerinin görünmediğini doğruladığınız basit betikler için uygundur.

Dönüştürmeden önce JSON5 veya JSONC yapılandırma dosyaları (yorumlu) kullanıyorsanız, önce uzantıları temizleyin — uyumlu ayrıştırıcılar için JSON5 ve JSONC biçimlendirme kılavuzuna bakın.

Go (gopkg.in/yaml.v3)

Go, Kubernetes ekosisteminin kendisinin dilidir — kubectl, Helm, Argo, Flux ve çoğu K8s operatörü Go ile yazılmıştır.

package main

import (
    "encoding/json"
    "fmt"
    "os"

    "gopkg.in/yaml.v3"
)

func main() {
    // JSON girişini oku
    jsonBytes, err := os.ReadFile("input.json")
    if err != nil {
        panic(err)
    }

    // JSON'u genel map'e ayrıştır
    var data map[string]interface{}
    if err := json.Unmarshal(jsonBytes, &data); err != nil {
        panic(err)
    }

    // YAML'a seri hale getir — yaml.v3, YAML 1.2 semantiğini kullanır
    yamlBytes, err := yaml.Marshal(data)
    if err != nil {
        panic(err)
    }

    fmt.Println(string(yamlBytes))
    // country: "NO"     ← yaml.v3, Norway kelimelerini doğru şekilde tırnaklıyor
    // replicas: 3       ← tam sayılar tam sayı kalıyor
    // enabled: true     ← boolean'lar boolean kalıyor
}

yaml.v3, Norway güvenliği açısından yaml.v2’ye göre önemli bir iyileştirmedir. v2 kütüphanesi YAML 1.1’i izler ve NOyu tırnaksız yazardı; v3 belirsiz değerleri doğru biçimde tırnaklıyor. v2 kullanan eski bir Go projesi sürdürüyorsanız, v3’e yükseltin — API büyük ölçüde uyumludur ve güvenlik iyileştirmesi geçişe değer.

Go struct’larıyla tür güvenli dönüştürme için (map[string]interface{} yerine), struct etiketleri kullanın:

type DeploymentLabels struct {
    App    string `yaml:"app" json:"app"`
    Region string `yaml:"region" json:"region"`
}
// "NO" içeren bir struct alanında yaml.Marshal, v3'te onu doğru biçimde tırnaklayacak

Bash CLI (yq + jq)

Kabuk betikleri ve hızlı tek seferlik dönüştürmeler için yq (Mike Farah’ın sürümü, mikefarah/yq) tek bir komutla JSON’u YAML’a dönüştürür:

# yq'yu yükle
brew install yq                         # macOS
sudo wget -qO /usr/local/bin/yq \
  https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64
chmod +x /usr/local/bin/yq              # Linux

# JSON dosyasını YAML'a dönüştür
yq -P < input.json > output.yaml

# kubectl JSON çıktısından dönüştür
kubectl get deploy my-app -o json | yq -P > manifest.yaml

# Önce jq üzerinden filtrele/dönüştür, ardından YAML'a dönüştür
kubectl get deploy my-app -o json \
  | jq 'del(.status, .metadata.creationTimestamp, .metadata.managedFields)' \
  | yq -P > clean-manifest.yaml

jq | yq pipeline’ı güçlü bir kalıptır: JSON manipülasyonu (alanları filtreleme, yapıyı yeniden şekillendirme, değerleri sorgulama) için jq kullanın ve son YAML serileştirici olarak yq -P kullanın. jq kalıpları için, kubectl ve aws entegrasyonları dahil 30 gerçek dünya kalıbı için jq komut satırı hızlı başvuru kılavuzuna bakın.

yq ile Norway uyarısı: yq (mikefarah), JSON’dan giriş türüne saygı gösterir — girişte "NO" JSON dizesi, tırnaklı YAML dizesi olarak serileştirilir. Ancak yq’yu doğrudan (JSON girişinden değil) YAML oluşturmak için kullanıyorsanız, Norway kelimesi değerlerini açıkça tırnak içine almalısınız. yq çıktısından sonra gidiş-dönüşü doğrulamak için YAML’dan JSON’a dönüştürücümüzü kullanın.

Sınır Durumları ve Tuzaklar

Norway sorununun ötesinde, JSON ↔ YAML dönüştürmesinin deneyimli mühendisleri bile tökezleten çeşitli sınır durumları vardır:

Çok belgeli YAML (--- ayırıcı). Tek bir YAML dosyası --- ile ayrılmış birden fazla belge içerebilir. JSON’da eşdeğer kavram yoktur. Çok belgeli YAML’ı JSON’a dönüştürürken, çoğu araç ya yalnızca ilk belgeyi alır, tüm belgeleri bir dizide birleştirir ya da hata verir. JSON’dan YAML’a dönüştürürken, tek bir --- belge başlığı kurala göre eklenir. Çok belgeli dosyalarla karşılaşabilecek pipeline’lar için davranışınızı açıkça belirleyin ve belgeleyin.
YAML çapaları ve takma adları. YAML, DRY yapılandırmalar için &anchor tanımlarını ve *alias referanslarını destekler. YAML’ı JSON’a dönüştürürken çapalar genişletilmelidir — elde edilen JSON, kaynak YAML’dan çok daha büyük olabilir. JSON’dan YAML’a dönüştürürken, dönüştürücü orijinal YAML’da var olmayan çapaları yeniden oluşturamaz. Takma adlar yalnızca YAML’a özgü bir özelliktir.
Zaman damgası örtük ayrıştırması. YAML 1.1 ayrıştırıcıları, 2024-05-04 ve 2024-05-04T12:00:00Z değerlerini dize değil, dile özgü tarih nesnelerine dönüştürür. Bu tarih nesnesi JSON’a geri serileştirildiğinde, çıktı kütüphaneye bağlıdır: bazıları ISO dizesi çıkarır, bazıları Unix zaman damgası, bazıları null. Tarihleri açık dize tırnaklama ("2024-05-04") olmadan YAML üzerinden gidiş-dönüş yapmak, formatı sessizce değiştirebilir.
!!binary etiketi. YAML, !!binary etiketi ile base64 kodlu ikili veri gömebilir. JSON’da ikili tür yoktur — ikili değer bir base64 dizesi olmalıdır. !!binary alanları içeren YAML’ı JSON’a dönüştürürken, base64 dizesine çözün. Geri dönüştürürken, şemayı bilmeden ikili etiketi yeniden oluşturamazsınız. Kubernetes bazı secret değerler için !!binary kullanır.
Anahtar tür çakışmaları. JSON, nesne anahtarlarının dize olmasını gerektirir. YAML, herhangi bir türde anahtara izin verir — tam sayı anahtarlar, boolean anahtarlar, hatta karmaşık nesne anahtarları. true: value veya 1: value gibi anahtarlara sahip bir YAML dosyası JSON’da sadakatle temsil edilemez. Çoğu dönüştürücü anahtarları dizeye çevirir; ancak semantik değişir.
Null gösterim varyansı. YAML’da null, ~, Null, NULL ve boş değerin hepsi null anlamına gelir. JSON’da yalnızca null null’dır. YAML’ı JSON’a dönüştürürken, bunların hepsi null’a normalize olur. Ancak JSON’u YAML’a geri dönüştürürken null gösterim tercihi önemlidir — ~ daha kompakt, null daha açıktır. Birini seçin ve ona sadık kalın.
Sıralama düzeni değişiklikleri. JSON nesnelerinin teknik olarak tanımlı anahtar sırası yoktur (çoğu ayrıştırıcı ekleme sırasını korumakla birlikte). YAML eşlemeleri de benzer biçimde zorunlu sıra gerektirmez. Ancak bazı YAML kütüphaneleri serileştirme sırasında anahtarları varsayılan olarak alfabetik sıralar. Bu, kaynak JSON farklı bir sıra kullandıysa sürüm kontrolünde büyük diff’lere yol açabilir. PyYAML’da sort_keys=False değerini yapılandırın (default_flow_style=False tek başına sıralamayı önlemez) ve diğer kütüphanelerde eşdeğer seçenekleri kullanın.

Ne Zaman Dönüştürmemelidir

Dönüştürme her zaman doğru cevap değildir. Orijinal formatta kalmanın daha iyi tercih olduğu senaryolar şunlardır:

İş mantığını belgeleyen yorumlar içeren YAML’ı JSON’a dönüştürmeyin. YAML yorumları, veri modelinin parçası değildir — JSON’a herhangi bir serileştirmede kaybolurlar. Bir Kubernetes manifest’i, belirli bir kaynak sınırının neden seçildiğini veya neden güvenlik politikası istisnası yapıldığını açıklayan yorumlar içeriyorsa, JSON’a dönüştürmek bu belgeleri yok eder. YAML’ı saklayın.

CI pipeline’larında gidiş-dönüş testleri olmadan otomatik dönüştürme yapmayın. Pipeline’ınız JSON’dan YAML’a dönüştürüp ardından YAML’ı bir cluster’a uyguluyorsa, gidiş-dönüş doğrulama adımı ekleyin: YAML’dan JSON’a geri, ardından orijinalle karşılaştırın. Bu, üretimi etkilemeden önce tür zorlaması sürprizlerini yakalar.

Yalnızca bir araç JSON çıkardığı için dönüştürmeyin. kubectl, aws, terraform ve docker inspect’in hepsi JSON çıkarır; ancak bu araçların çoğu aynı zamanda giriş olarak YAML’ı kabul eder. Bir dönüştürme adımı oluşturmadan önce, hedef aracın YAML girişini doğrudan kabul edip edemeyeceğini kontrol edin — çoğu modern DevOps aracı kabul edebilir. YAML’dan JSON’a dönüştürücümüz, özellikle YAML’ı kabul etmeyen bir araç için JSON’a ihtiyaç duyduğunuzda en kullanışlıdır.

Şemalar farklıysa dönüştürmeyin. JSON’unuz camelCase anahtarlar kullanıyor ve YAML tüketiciniz snake_case bekliyorsa (veya tam tersi), format dönüştürmesine ek olarak bir dönüştürme adımına ihtiyacınız var. Düz bir format dönüştürmesi sözdizimsel olarak doğru ancak semantik olarak yanlış YAML üretecektir. Şema eşlemesini açıkça ele alın.

Her iki formatı manuel olarak senkronize tutmaya çalışmayın. Eşdeğer olması gereken bir config.json ve config.yaml sürdürüyorsanız, zamanla ayrışacaklardır. Tek bir kanonik format seçin ve diğerini otomatik olarak türetin — ya da daha iyisi, tek bir format seçin ve tekrarı ortadan kaldırın.

SSS

YAML Norway sorunu hâlâ modern sistemleri etkiliyor mu?

Evet — ekosistemde yaygındır. Kubernetes ve Helm, kod tabanlarının önemli bölümlerinde Go’nun yaml.v2 kütüphanesini (YAML 1.1 semantiği) kullanır. Ansible, PyYAML (YAML 1.1) kullanır. GitHub Actions iş akışları, GitHub’ın kendi davranışı olan dahili YAML ayrıştırıcısı tarafından ayrıştırılır. Kullanımda olan YAML CI/CD dosyalarının çoğu, YAML 1.1 ayrıştırıcıları tarafından işlenir. Aksi takdirde doğrulamadığınız sürece 1.1 semantiğini varsayın.

YAML’ın ayrıştırılması daha zorsa neden JSON’u YAML’a dönüştüreyim?

Dönüştürme, ayrıştırıcı güçlüğüyle ilgili değil — insan düzenlenebilirliğiyle ilgilidir. JSON makineler için idealdir; YAML, yapılandırma dosyalarını okuması, düzenlemesi ve incelemesi gereken insanlar için idealdir. Git’e işlenen, pull request’lerde incelenen ve mühendisler tarafından ince ayar yapılan bir Kubernetes manifest’i YAML olmalıdır. Programlı işleme için API’den alınan aynı manifest ise JSON olmalıdır. JSON’dan YAML’a dönüştürücümüz ikisi arasında köprü kurar.

JSON ↔ YAML arasında kayıpsız gidiş-dönüş yapabilir miyim?

Saklılar olmakla birlikte evet — JSON uyumlu veriler için. JSON, YAML 1.2’nin bir alt kümesidir; bu nedenle herhangi bir geçerli JSON belgesi geçerli YAML 1.2’dir. JSON → YAML → JSON gidiş-dönüşü, örtük tür zorlaması olmayan herhangi bir veri için kayıpsız olmalıdır. Norway sorunu, "NO" JSON dizesinin yalnızca dönüştürücü onu tırnaklıyorsa ileri geçişi atlatabildiği ve ardından yalnızca YAML ayrıştırıcısı tırnaklara saygı gösteriyorsa dönüş geçişini atlatabildiği anlamına gelir. Kayıpsız gidiş-dönüş garantisi için her iki yönde YAML 1.2 kütüphanesi kullanın.

Üretim için en güvenli YAML kütüphanesi hangisi?

Python için: YAML 1.2 yapılandırmalı ruamel.yaml. Node.js için: eemeli/yaml (npm’de yaml paketi). Go için: gopkg.in/yaml.v3. Her üçü de YAML 1.2 semantiğini uygular veya açık YAML 1.2 modlarına sahiptir ve Norway kelimelerini doğru biçimde işler. Yeni projelerde YAML 1.1 kütüphanelerinden kaçının. Uyumluluk nedenleriyle 1.1 kütüphanesi (PyYAML, js-yaml, yaml.v2) kullanmak zorundaysanız, Norway sorunlu dizeleri her zaman açıkça tırnak içine alın.

JSON dönüşümünden sonra Kubernetes manifest YAML’ı yorumları destekliyor mu?

Hayır — yorumlar JSON’dan kurtarılamaz. JSON’un yorum sözdizimi yoktur; dolayısıyla dönüştürülecek bir şey yoktur. kubectl get deploy -o json çalıştırıp çıktıyı git depolaması için YAML’a dönüştürdüğünüzde, elde edilen YAML’da yorum bulunmayacaktır. Kubernetes manifest’indeki yorumlar, dönüştürmeden sonra bir insan tarafından yazılmalıdır. Bu nedenle el yazısı YAML’ı kanonik kaynak olarak saklamak, JSON API’si üzerinden gidiş-dönüş yapmaktan çoğu zaman daha tercih edilir.

resourceVersion veya nanosaniye zaman damgaları gibi büyük tam sayıları nasıl ele alırım?

Kubernetes metadata.resourceVersion, JavaScript ve diğer float64 tabanlı çalışma zamanlarındaki JSON ayrıştırıcılarının büyük tam sayılarda hassasiyet kaybedeceğini bilen Kubernetes ekibi tarafından kasıtlı olarak dize alandır. Her zaman dize olarak değerlendirin. Gerçek anlamda büyük tam sayılar için (bazı izleme sistemlerinde nanosaniye epoch zaman damgaları gibi), Python’ın int türü, Go’nun int64’ü veya Node.js BigInt kullanın. JavaScript’te özel reviver işlevi olmadan JSON.parse() üzerinden geçirmeyin. YAML’a dönüştürürken, bu büyük tam sayılar güvenlidir — YAML’ın tam sayılar için hassasiyet sınırı yoktur. Tehlike, JavaScript’in JSON ayrıştırıcısı üzerinden gidiş-dönüştedir.

YAML 1.2 yaygın olarak benimsendi mi?

Eşit olmayan biçimde. Büyük dil kütüphaneleri göç ediyordu: Go’nun yaml.v3’ü, Python’ın ruamel.yaml’ı ve Node.js’nin eemeli/yaml’ı hepsi YAML 1.2’yi destekliyor veya varsayılan olarak kullanıyor. Ancak Kubernetes, Ansible ve DevOps ekosisteminin büyük bölümü, geriye dönük uyumluluk maliyeti nedeniyle hâlâ YAML 1.1 ayrıştırıcıları üzerinde çalışıyor. Yeni projelerde YAML 1.2 benimsenmesi önerilir; ancak kendiniz yapılandırmadığınız herhangi bir sistem için 1.1’i varsayın.

Ekibimiz yapılandırmalar için JSON veya YAML’ı mı standart olarak benimsemeli?

Formata göre değil, amaca göre standart belirleyin. Kod tarafından tüketilen yapılandırmalar için JSON kullanın (API istek gövdeleri, SDK yapılandırma dosyaları, programlı araçlar). İnsanlar tarafından tüketilen yapılandırmalar için YAML kullanın (Kubernetes manifest’leri, CI pipeline’ları, dağıtım yapılandırmaları, Ansible playbook’ları). Aynı yapılandırma için ikisini karıştırmaktan kaçının — her yapılandırma türü için tek bir gösterim seçin ve her ikisine de ihtiyaç duyuyorsanız dönüştürmeyi otomatikleştirin. Dönüştürmeniz gerektiğinde, hem JSON’dan YAML’a hem de YAML’dan JSON’a dönüştürücülerimiz tamamen tarayıcınızda çalışır — verileriniz cihazınızdan ayrılmaz.

Şimdi Deneyin

Gerçek bir dosyayı dönüştürmeye hazır mısınız? JSON’u güvenli Kubernetes YAML’ına dönüştürmek için JSON’dan YAML’a dönüştürücümüzü deneyin — Norway kelimelerini (NO, yes, on, off ve YAML 1.1 boolean listesinin tamamı) otomatik olarak tırnak içine alır ve 2 boşluk veya 4 boşluk girintisi seçmenize izin verir. Ters yön için YAML’dan JSON’a dönüştürücümüz çapaları, takma adları ve çok belgeli YAML’ı işler. Her iki araç da tamamen tarayıcınızda çalışır — verileriniz cihazınızdan asla ayrılmaz; bu, hassas kaynak yapılandırmaları içeren üretim Kubernetes manifest’leri veya Terraform planlarıyla çalışırken önemlidir.

YAML Norway Sorunu ve JSON-YAML Farkları: Geliştirici Rehberi