Czy istnieje sposób na uniknięcie tokena końcowego CDATA w XML?

Zastanawiałem się, czy istnieje sposób na uniknięcie tokena końcowego CDATA ( ]]>) w sekcji CDATA w dokumencie xml. Lub, bardziej ogólnie, jeśli istnieje jakaś sekwencja ucieczki do użycia w CDATA (ale jeśli istnieje, myślę, że prawdopodobnie i tak miałaby sens tylko ucieczka od tokenów początku lub końca).

Zasadniczo, czy możesz mieć token początku lub końca osadzony w CDATA i powiedzieć parserowi, aby go nie interpretował, ale traktował jako kolejną sekwencję znaków.

Prawdopodobnie powinieneś po prostu refaktoryzować swoją strukturę xml lub kod, jeśli próbujesz to zrobić, ale mimo że pracuję z xml na co dzień przez ostatnie 3 lata i nigdy nie miałem tego problemu, Zastanawiałem się, czy to możliwe. Z czystej ciekawości.

Edytować:

Poza kodowaniem html ...

Oczywiście to pytanie jest czysto akademickie. Na szczęście ma bardzo określoną odpowiedź.

Nie można uciec przed sekwencją końcową CDATA. Reguła produkcji 20 specyfikacji XML jest dość jasna:

[20]    CData      ::=      (Char* - (Char* ']]>' Char*))

EDYCJA: Ta reguła iloczynu dosłownie oznacza „Sekcja CData może zawierać wszystko, co chcesz, ALE sekwencja ']]>'. Bez wyjątku.”.

EDYCJA2: ta sama sekcja czyta również:

W sekcji CDATA tylko łańcuch CDEnd jest rozpoznawany jako znacznik, więc lewe nawiasy ostre i ampersandy mogą występować w ich dosłownej formie; nie trzeba (i nie można) przed nimi uciec za pomocą " <" i "& ”. Sekcje CDATA nie mogą zagnieżdżać się.

Innymi słowy, nie jest możliwe użycie odwołania do encji, znaczników ani żadnej innej formy interpretowanej składni. Jedyny przeanalizowany tekst w sekcji CDATA to]]> i kończy sekcję.

Dlatego nie można uciec ]]> z sekcji CDATA.

EDYCJA3: ta sama sekcja czyta również:

2.7 Sekcje CDATA

[Definicja: Sekcje CDATA mogą występować wszędzie tam, gdzie mogą wystąpić dane znakowe; służą do zmiany znaczenia bloków tekstu zawierających znaki, które w innym przypadku zostałyby rozpoznane jako znaczniki. Sekcje CDATA zaczynają się od ciągu „<! [CDATA [” i kończą się ciągiem „]]>”:]

Wtedy może istnieć sekcja CDATA wszędzie tam, gdzie mogą wystąpić dane znakowe, w tym wiele sąsiednich sekcji CDATA zamiast jednej sekcji CDATA. Dzięki temu możliwe jest podzielenie ]]>tokena i umieszczenie jego dwóch części w sąsiednich sekcjach CDATA.

dawny:

<![CDATA[Certain tokens like ]]> can be difficult and <invalid>]]> 

należy zapisać jako

<![CDATA[Certain tokens like ]]]]><![CDATA[> can be difficult and <valid>]]> 

Musisz rozbić swoje dane na części, aby ukryć ]]> .

Oto cała sprawa:

<![CDATA[]]]]><![CDATA[>]]>

Pierwsza <![CDATA[]]]]>ma ]]. Drugi <![CDATA[>]]>ma >.

Nie uciec ]]>, ale można uciec >po ]]wstawiając ]]><![CDATA[przed >, myśleć o tym po prostu jak \w C / Java / PHP / Perl ciąg ale potrzebne tylko przed >i po ]].

BTW,

Odpowiedź S. Lotta jest taka sama, tylko inaczej sformułowana.

Odpowiedź S. Lotta jest prawidłowa: nie kodujesz znacznika końcowego, dzielisz go na wiele sekcji CDATA.

Jak rozwiązać ten problem w prawdziwym świecie: używając edytora XML do stworzenia dokumentu XML, który zostanie wprowadzony do systemu zarządzania treścią, spróbuj napisać artykuł o sekcjach CDATA. Twoja zwykła sztuczka polegająca na osadzaniu próbek kodu w sekcji CDATA zawiedzie Cię tutaj. Możesz sobie wyobrazić, jak się tego nauczyłem.

Ale w większości przypadków nie napotkasz tego, a oto dlaczego: jeśli chcesz przechowywać (powiedzmy) tekst dokumentu XML jako zawartość elementu XML, prawdopodobnie użyjesz metody DOM, np:

XmlElement elm = doc.CreateElement("foo");
elm.InnerText = "<[CDATA[[Is this a problem?]]>";

A DOM całkiem rozsądnie wymyka się znakom <i>, co oznacza, że ​​nieumyślnie nie osadziłeś sekcji CDATA w swoim dokumencie.

Aha, i to jest interesujące:

XmlDocument doc = new XmlDocument();

XmlElement elm = doc.CreateElement("doc");
doc.AppendChild(elm);

string data = "<![[CDATA[This is an embedded CDATA section]]>";
XmlCDataSection cdata = doc.CreateCDataSection(data);
elm.AppendChild(cdata);

Jest to prawdopodobnie przypadek ideologii .NET DOM, ale nie stanowi to wyjątku. Wyjątek zostanie zgłoszony tutaj:

Console.Write(doc.OuterXml);

Domyślam się, że to, co dzieje się pod maską, polega na tym, że XmlDocument używa XmlWriter do tworzenia swoich danych wyjściowych, a XmlWriter sprawdza, czy podczas pisania jest poprawna.

po prostu zastąpić ]]>z]]]]><![CDATA[>

Oto kolejny przypadek, w którym ]]>należy uciec. Załóżmy, że musimy zapisać doskonale poprawny dokument HTML wewnątrz bloku CDATA dokumentu XML, a tak się składa, że ​​źródło HTML ma swój własny blok CDATA. Na przykład:

<htmlSource><![CDATA[ 
    ... html ...
    <script type="text/javascript">
        /* <![CDATA[ */
        -- some working javascript --
        /* ]]> */
    </script>
    ... html ...
]]></htmlSource>

skomentowany sufiks CDATA należy zmienić na:

        /* ]]]]><![CDATA[> *//

ponieważ parser XML nie będzie wiedział, jak obsługiwać bloki komentarzy javascript

W PHP: '<![CDATA['.implode(explode(']]>', $string), ']]]]><![CDATA[>').']]>'

Czystszy sposób w PHP:

   function safeCData($string)
   {
      return '<![CDATA[' . str_replace(']]>', ']]]]><![CDATA[>', $string) . ']]>';
   }

Nie zapomnij użyć wielobajtowego bezpiecznego str_replace, jeśli jest to wymagane (inne niż latin1 $string):

   function mb_str_replace($search, $replace, $subject, &$count = 0)
   {
      if (!is_array($subject))
      {
         $searches = is_array($search) ? array_values($search) : array ($search);
         $replacements = is_array($replace) ? array_values($replace) : array ($replace);
         $replacements = array_pad($replacements, count($searches), '');
         foreach ($searches as $key => $search)
         {
            $parts = mb_split(preg_quote($search), $subject);
            $count += count($parts) - 1;
            $subject = implode($replacements[$key], $parts);
         }
      }
      else
      {
         foreach ($subject as $key => $value)
         {
            $subject[$key] = mb_str_replace($search, $replace, $value, $count);
         }
      }
      return $subject;
   }

Nie sądzę, aby przerywanie CDATA było dobrym rozwiązaniem. Oto moja alternatywa ...

Użyj ]dla sekwencji ucieczki, po której następuje wartość szesnastkowa twojej postaci. Jak w &#xhhhh;=>]<unicode value>;

W ten sposób, jeśli spróbujesz nagrać ]]>swoje kodowanie, fn da, ]005D;]005D;]003E;co jest w porządku w CDATA.

Jest to lepsze niż ucieczka przez nazwę jednostki, ponieważ nie są one dekodowane za każdym razem w aplikacji i możesz mieć inne priorytety ucieczki jednostek za pomocą znaku ampersand i ucieczki przed niektórymi innymi znakami / sekwencjami. W rezultacie masz większą kontrolę nad zawartością CDATA.

Zobacz tę strukturę:

<![CDATA[
   <![CDATA[
      <div>Hello World</div>
   ]]]]><![CDATA[>
]]>

W przypadku wewnętrznych znaczników CDATA należy zamknąć za pomocą ]]]]><![CDATA[>zamiast ]]>. Proste.