XML إلى JSON

السمات لا مكان طبيعيًا لها

يرسم XML خطًا فاصلًا حازمًا بين السمات والعناصر الفرعية. <user id="7"><name>Ada</name></user> يقول شيئًا مختلفًا عن <user><id>7</id><name>Ada</name></user>، رغم أن معظم التطبيقات تعاملهما بشكل متطابق. لا يوجد في JSON تمييز مكافئ، لذا يجب على المحول إما التخلص من السمات أو ابتكار مكان لها.

الاصطلاح المستخدم على نطاق واسع، والمطبق هنا، هو إضافة بادئة @ لمفاتيح السمات وتخزين نص العنصر تحت #text عندما يحمل العنصر سماتًا ومحتوى معًا. لذا يصبح المثال الأول {"user": {"@id": "7", "name": "Ada"}}. البادئة ليست جزءًا من أي معيار، لكنها شائعة بما يكفي ليتعرف عليها معظم الكود النهائي، وتحافظ على قابلية عكس التحويل. إيقاف تشغيل السمات ينتج ناتجًا أنظف عندما تعرف أن السمات بيانات وصفية لا تحتاجها.

عنصر واحد أم قائمة من عنصر واحد؟

هذه هي المشكلة التي لا إجابة صحيحة لها. في XML، يبدو الأصل الذي لديه طفل <item> واحد والأصل الذي لديه خمسة متشابهين بنيويًا، لكن يجب أن يصبحا كائنًا واحدًا ومصفوفة على الترتيب — ولا شيء في المستند يخبرك بأيهما قصد المخطط. أداة بلا مخطط عليها أن تخمّن مما تراه.

القاعدة هنا هي جمع أسماء العناصر الشقيقة المتكررة في مصفوفة وترك العنصر المنفرد قيمة واحدة. هذا يطابق البديهة عند القراءة، لكنه يعني أن الكود الذي يستهلك الناتج يجب أن يتعامل مع الشكلين، لأن قائمة تصادف وجود إدخال واحد فيها اليوم ستنتج كائنًا لا مصفوفة من عنصر واحد. عندما تتحكم في المستهلك، طبع بـ[].concat(value) قبل التكرار.

كل شيء في XML سلسلة

لا توجد أنواع في مستند XML دون مخطط. <count>42</count> و<sku>0042</sku> كلاهما مجرد نص، وحدها إنسان أو مخطط XSD يعرف أن أحدهما رقم والآخر معرّف يجب أن يحتفظ بأصفاره.

لهذا يكون تحويل الأنواع خانة اختيار وليس الافتراضي. عندما يكون مفعّلاً، تُحوَّل القيم فقط عندما تكون رحلة الذهاب والعودة دقيقة — تتحول السلسلة الرقمية إلى رقم فقط إذا أعاد تنسيقها النص المطابق تمامًا، وهو ما يحمي 0042 و+7 و1e999. تصبح true وfalse والعناصر الفارغة قيمًا منطقية وقيمًا فارغة. عندما يكون متوقفًا، تبقى كل قيمة سلسلة، وهو الخيار الأكثر أمانًا للمعرّفات وأرقام الهواتف والرموز البريدية وأي عدد صحيح يتجاوز 2^53 حيث ستُفسد دقة رقم JavaScript القيمة بصمت.