كيف يمكنك تحرير XML صالح في صفحة ويب؟

StackOverflow https://stackoverflow.com/questions/244285

سؤال

يجب أن أحصل على محرر تكوين سريع وقذر. يتدفق التدفق مثل هذا:

التكوين (POCOS على الخادم) يتم تسلسله إلى XML.
تم تشكيل XML بشكل جيد في هذه المرحلة. يتم إرسال التكوين إلى خادم الويب في XElements.
على خادم الويب ، يتم إلقاء XML (نعم ، كل ذلك) في نص للتحرير.
يقوم المستخدم بتحرير XML مباشرة في صفحة الويب والنقرات إرسال.
في الاستجابة ، أسترجع النص المعدل لتكوين XML. في هذه المرحلة ، تم إعادة جميع الهروب من خلال عملية عرضها في صفحة ويب.
أحاول تحميل السلسلة إلى كائن XML (Xmlelement ، xelement ، أيا كان). kaboom.

المشكلة هي أن التسلسل يهرب من سلاسل السمات ، ولكن هذا يضيع في الترجمة على طول الطريق.

على سبيل المثال ، دعنا نقول أن لدي كائن لديه regex. إليك التكوين لأنه يتعلق بخادم الويب:

<Configuration>
  <Validator Expression="[^&lt;]" />
</Configuration>

لذا ، أضع هذا في نص ، حيث يبدو ذلك للمستخدم:

<Configuration>
  <Validator Expression="[^<]" />
</Configuration>

لذلك يقوم المستخدم بإجراء تعديل طفيف ويقدم التغييرات مرة أخرى. على خادم الويب ، تبدو سلسلة الاستجابة مثل:

<Configuration>
  <Validator Expression="[^<]" />
  <Validator Expression="[^&]" />
</Configuration>

لذلك ، أضاف المستخدم مدقق آخر ، والآن لديهما سمات مع شخصيات غير قانونية. إذا حاولت تحميل هذا في أي كائن XML ، فإنه يلقي استثناءً لأن <و & غير صالح في سلسلة نصية. لا أستطيع أن لا أستطيع استخدام أي نوع من وظائف الترميز ، لأنه يشفر الشيء الدموي بأكمله:

var result = server.httpencode (editedConfig) ؛

النتائج في 

&lt;Configuration&gt;
  &lt;Validator Expression="[^&lt;]" /&gt;
  &lt;Validator Expression="[^&amp;]" /&gt;
&lt;/Configuration&gt;

هذا غير صالح XML. إذا حاولت تحميل هذا في عنصر XML من أي نوع ، فسوف أصابني من السندان السقوط. أنا لا أحب الوقوع في السندان.

لذا ، يبقى السؤال ... هل الطريقة الوحيدة التي يمكنني بها جعل هذه السلسلة XML جاهزة للحلية في كائن XML هي باستخدام Regex استبدال؟ هل هناك أي طريقة "لإيقاف القيود" عند تحميلها؟ كيف تحصل حول هذا؟؟؟

استجابة أخيرة ثم wiki-mord هذا ، حيث لا أعتقد أن هناك إجابة صالحة.

XML I Place in the Textarea صالح ، هرب XML. عملية 1) وضعها في منطقة النص 2) إرسالها إلى العميل 3) عرضه على العميل 4) إرسال النموذج في 5) إعادة إرساله إلى الخادم و 6) استرداد القيمة من النموذج أي وجميع يهرب.

اسمحوا لي أن أقول هذا مرة أخرى: أنا لا أتعامل مع أي شيء. مجرد عرضه في المتصفح يفعل هذا!

الأشياء التي يجب التفكير فيها: هل هناك وسيلة لمنع حدوث هذا عدم الحدوث في المقام الأول؟ هل هناك طريقة لأخذ XML تقريبًا و "تنظيفها" بطريقة آمنة؟

هذا السؤال الآن لديه مكافأة عليه. لجمع المكافأة ، يمكنك توضيح كيفية تحرير XML صالح في نافذة المتصفح دون أداة طرف ثالثة/مفتوح المصدر لا تتطلب مني استخدام Regex للهروب من قيم السمات يدويًا ، وهذا لا يتطلب من المستخدمين الهروب من سماتهم ، وهذا لا يفشل عندما يكون مستديرًا (& amp ؛ amp ؛ amp ؛ etc ؛)

هل كانت مفيدة؟

المحلول

erm ...كيف هل تسلسل؟ عادة ، يجب ألا ينتج جهاز Serializer XML XML غير صالح.

/تحرير ردًا على التحديث الخاص بك: افعل ليس عرض XML غير صالح للمستخدم الخاص بك لتحرير! بدلاً من ذلك ، قم بعرض XML هرب بشكل صحيح في مربع النص. إصلاح XML المكسور ليس ممتعًا ولا أرى أي سبب لعدم عرض/تحرير XML في شكل صالح ، هرب.

مرة أخرى يمكنني أن أسأل: كيف هل تعرض XML في مربع النص؟ يبدو أنك غير قصد عن قصد XML في مرحلة ما.

/تحرير استجابةً لآخر تعليقك: حسنًا ، من الواضح ، لأنه يمكن أن يحتوي على HTML. تحتاج إلى الهروب من XML بشكل صحيح قبل كتابتها إلى صفحة HTML. مع ذلك ، أعني كامل XML. إذا هذا:

<foo mean-attribute="&lt;">

يصبح هذا:

&lt;foo mean-attribute="&amp;&lt;"&gt;

نصائح أخرى

بالطبع عندما تضع مراجع الكيان داخل نص يخرجون دون تكييف. Textareas ليس سحريًا ، يجب عليك الهروب ؛ كل ما تضعه فيها تمامًا مثل كل عنصر آخر. قد المتصفحات عرض الخام '<' في نص ، ولكن فقط لأنهم يحاولون تنظيف أخطائك.

لذا ، إذا كنت تضع XML القابلة للتحرير في Textarea ، فأنت بحاجة إلى الهروب من قيمة السمة مرة واحدة لجعلها صالحة XML ، ثم عليك الهروب من XML بالكامل مرة أخرى لجعلها صالحة HTML. المصدر النهائي الذي تريد ظهوره في الصفحة سيكون:

<textarea name="somexml">
    &lt;Configuration&gt;
        &lt;Validator Expression="[^&amp;lt;]" /&gt;
        &lt;Validator Expression="[^&amp;amp;]" /&gt;
    &lt;/Configuration&gt;
</textarea>

يعتمد السؤال على سوء فهم لنموذج المحتوى الخاص بعنصر Textarea - كان من الممكن أن يلتقط المدقق المشكلة على الفور.

eta re التعليق: حسنًا ، ما هي المشكلة التي تبقى؟ هذه هي القضية على جانب التسلسل. كل ما تبقى هو تحليله مرة أخرى ، ولهذا يجب أن تفترض أن المستخدم يمكنه إنشاء XML جيد الشكل.

إن محاولة تحليل XML غير المصنفة غير البئر ، من أجل السماح بأخطاء مثل وجود "<" أو "و" غير معبأة في قيمة السمة ، خسارة ، تمامًا مقابل كيفية عمل XML. إذا لم تتمكن من الوثوق بمستخدميك لكتابة XML المتماثل جيدًا ، فامنحهم واجهة غير أسهل غير XML ، مثل قائمة سلاسل REGEXP التي تم فصلها عن خط جديد بسيط.

كما تقول ، يجب على المسلسل الطبيعي الهروب من كل شيء من أجلك.

المشكلة ، إذن ، هي كتلة النص: تحتاج إلى التعامل مع أي شيء تم تمريره عبر Textblock بنفسك.

قد تجرب httputily.htmlencode () ، لكنني أعتقد أن أبسط طريقة هي مجرد تثبيت أي شيء تمرره عبر كتلة النص في قسم CDATA.

عادةً ما أرغب في هروب كل شيء بشكل صحيح بدلاً من الاعتماد على "عكاز" CDATA ، لكنني أرغب أيضًا في استخدام الأدوات المدمجة للقيام بالهروب. بالنسبة لشيء تم تحريره في حالة "سبات" من قبل مستخدم ، أعتقد أن CDATA قد يكون الطريق للذهاب.

انظر أيضًا هذا السؤال السابق:
أفضل طريقة لترميز البيانات النصية لـ XML

تحديث
استنادًا إلى تعليق على استجابة أخرى ، أدركت أنك تُظهر للمستخدمين الترميز ، وليس فقط المحتويات. محللون XML ، حسنا ، صعب الإرضاء. أعتقد أن أفضل شيء يمكنك القيام به في هذه الحالة هو التحقق من التكوين الجيد قبل قبول XML المحرر.

ربما حاول تلقائيًا لتصحيح أنواع معينة من الأخطاء (مثل ampersands السيئة من سؤالي المرتبط) ، ولكن بعد ذلك احصل على رقم السطر ورقم العمود لخطأ التحقق من الصحة الأول من محلل .NET XML واستخدامه لإظهار المستخدمين أينما كان خطأهم حتى حتى حتى يعطونك شيئًا مقبولًا. نقاط المكافأة إذا قمت أيضًا بالتحقق من صحة المخطط.

يمكنك إلقاء نظرة على شيء مثل tinymce, ، والذي يسمح لك بتحرير HTML في مربع نص غني. إذا لم تتمكن من تكوينه للقيام بما تريد بالضبط ، فيمكنك استخدامه كمصدر إلهام.

ملاحظة: Firefox (في الاختبار) لا يلفت الانتباه في مناطق النص كما تصف. على وجه التحديد ، هذا الرمز:

<textarea cols="80" rows="10" id="1"></textarea>

<script>
elem = document.getElementById("1");

elem.value = '\
<Configuration>\n\
  <Validator Expression="[^&lt;]" />\n\
</Configuration>\
'
alert(elem.value);
</script>

يتم تنبيهه وعرضه على المستخدم دون تغيير, ، كما:

<Configuration>
  <Validator Expression="[^&lt;]" />
</Configuration>

لذلك ربما يكون أحد الحلول (غير قابل للحياة؟) هو استخدام المستخدمين Firefox.

يبدو أنه تم الكشف عن جزأين لسؤالك:

1 XML الذي تعرضه هو الحصول على تكوين.

فمثلا، "&lt;"لا يتسم بتكوين" <". ولكن بما أن" <"لا يتم تشكيله أيضًا على أنه" <"، تُفقد المعلومات ولا يمكنك استعادتها.

حل واحد هو أن تفلت من كل ""&"شخصيات ، لذلك"&lt;"يصبح"&amp;lt;". هذا سيتم بعد ذلك تكوينه بواسطة Textarea كما"&lt;". عندما تقرأها مرة أخرى ، سيكون الأمر كما كان في المقام الأول. (أفترض أن النص يغير السلسلة فعليًا ، لكن Firefox لا يتصرف أثناء الإبلاغ ، لذلك لا يمكنني التحقق من هذا)

حل آخر (المذكور بالفعل) هو إنشاء/شراء/استعارة منطقة نص مخصصة (ليست سيئة إذا كانت بسيطة ، ولكن هناك جميع مفاتيح التحرير ، CTRL-C ، CTRL-THIFT-LEFT وما إلى ذلك).

2 تود ألا يضطر المستخدمون إلى الاهتمام بالهروب.

أنت في هيل هيل:

سيعمل استبدال Regex في الغالب ... ولكن كيف يمكنك اكتشاف اقتباس النهاية بشكل موثوق (") ، عندما يكون المستخدم (بشكل شرعي ، ضمن الشروط التي قدمتها) تدخل:

<Configuration>
  <Validator Expression="[^"<]" />
</Configuration>

بالنظر إليه من وجهة نظر بناء جملة Regex ، لا يمكن أيضًا معرفة ما إذا كان النهائي "جزءًا من regex ، أو نهايته. عادةً ما يحل بناء جملة Regex هذه المشكلة باستخدام Terminator الصريح على سبيل المثال:

/[^"<]/

إذا استخدم المستخدمون هذا بناء الجملة (مع Terminator) ، وكتبت محللًا لذلك ، فيمكنك تحديد متى انتهى Regex ، وبالتالي فإن الشخصية التالية "ليست جزءًا من Regex ، ولكن جزءًا من XML ، و لذلك فإن الأجزاء التي يجب الهروب منها. أنا لا أقول أنه يجب عليك هذا! أنا أقول إنه ممكن من الناحية النظرية. إنه بعيد جدًا عن سريع وقذر.

راجع للشغل: تنشأ نفس المشكلة للنص داخل عنصر. ما يلي شرعي ، ضمن الشروط التي قدمتها ، ولكن لديها نفس مشاكل التحليل:

<Configuration>
  <Expression></Expression></Expression>
</Configuration>

القاعدة الأساسية في بناء جملة تسمح "أي نص" هي أن المحدد يجب يتم هروبها ، (على سبيل المثال "أو <) ، بحيث يمكن التعرف على النهاية. معظم بناء الجملة يهرب أيضًا من مجموعة من الأشياء الأخرى ، للراحة/الإزعاج. (تعديل سوف تحتاج إلى الهروب من أجل شخصية الهروب نفسها: بالنسبة لـ XML ، إنها "&"، والتي عندما يتم هروب الحرفي كما"&amp;"بالنسبة إلى Regex ، إنه أسلوب C/Unix"\"، والتي عندما يتم هروب الحرفي كما"\\").

بناء جملة العش ، وأنت في هيل هيل.

حل واحد بسيط بالنسبة لك هو إخبار المستخدمين: هذا أ سريع و متسخ محرر التكوين ، لذلك لا تحصل على أي "لا حاجة للهروب" Mamby-Pamby:

  • سرد الأحرف والهروب بجوار منطقة النص ، على سبيل المثال: "<" AS "&lt".
  • بالنسبة إلى XML الذي لن يتحقق من صحة ، أظهر لهم القائمة مرة أخرى.

إذا نظرنا إلى الوراء ، أرى بوبنس أعطى نفس الإجابة الأساسية أمامي.

من شأن إدخال CDATA حول كل النص أن يمنحك آلية هروب أخرى من شأنها أن تنقذ المستخدمين من الهروب يدويًا ، و (2) تمكين النص الذي لم يتم تشكيله تلقائيًا بواسطة Textarea ليتم قراءته بشكل صحيح.

 <Configuration>
   <Validator Expression="<![CDATA[  [^<]   ]]>" />
 </Configuration>

:-)

يجب استبدال هذه الشخصية الخاصة - "<" - بأحرف أخرى بحيث تكون XML صالحة. تحقق من هذا الرابط لأحرف XML الخاصة:

http://en.wikipedia.org/wiki/list_of_xml_and_html_character_entity_references

حاول أيضًا تشفير محتوى TextBlock الخاص بك قبل إرساله إلى Deserializer:

HttpServerUtility utility = new HttpServerUtility();
string encodedText = utility.HtmlEncode(text);

هل هذا حقا خياري الوحيد؟ أليس هذه مشكلة شائعة بما فيه الكفاية أن لديها حل في مكان ما في الإطار؟

private string EscapeAttributes(string configuration)
{
    var lt = @"(?<=\w+\s*=\s*""[^""]*)<(?=[^""]*"")";
    configuration = Regex.Replace(configuration, lt, "&lt;");

    return configuration;
}

(تحرير: استبدال Ampersand المحذوف لأنه يسبب مشاكل مستديرة)

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top