bubble: Maskierungssequenzen in String "anwenden"

Gegeben sei als Beispiel eine XML-Datei:

<?xml version="1.0" encoding="UTF-8"?>  
<config>  
    <something>{date} {time} {tags}:\r\n{message}\r\n{stacktrace}\r\n</something>  
</config>

Wenn ich den Inhalt vom something-Element auslese stehen die eigentlichen Maskierungssequenzen \r und \n als ganz normale Zeichen im String.

Gibt es eine Standard-Möglichkeit dies dann wieder anzuwenden? Also so dass statt dem \r\n dann die Zeichen (char)13 und (char)10 wieder enthalten sind? Wenns nur um den Zeilenumbruch ginge wäre das kein Thema, allerdings werden teilweise auch Unicode- (\uXXXX) oder Oktal-Maskierungen (\nnn) gebraucht.

Dass ich da mit einem regulären Ausdruck 'rüber rauschen kann und ersetzen kann weiß ich, aber das gefällt mir nicht so ganz.

MfG
bubble

--
If "god" had intended us to drink beer, he would have given us stomachs. - David Daye
  1. Gegeben sei als Beispiel eine XML-Datei:

    <?xml version="1.0" encoding="UTF-8"?>

    <config>
        <something>{date} {time} {tags}:\r\n{message}\r\n{stacktrace}\r\n</something>
    </config>

    
    >   
    > Wenn ich den Inhalt vom something-Element auslese stehen die eigentlichen Maskierungssequenzen \r und \n als ganz normale Zeichen im String.  
      
      
    Warum überträgst Du Deine Texte nicht einfach so wie sie sind, also ohne vorher an den Zeilenumbrüchen herumzudoktern? Und wenn, dann kannst Du das auch ganz genauso wieder rückgängig machen.  
      
    MfG
    
    1. Warum überträgst Du Deine Texte nicht einfach so wie sie sind, also ohne vorher an den Zeilenumbrüchen herumzudoktern? Und wenn, dann kannst Du das auch ganz genauso wieder rückgängig machen.

      XML war nur ein Beispiel-Format, bei INI-Datein wird es z.B. dann schwer zu Unterscheiden, wann ein neuer Datensatz entstanden ist oder ob es noch zum Template gehöhrt.

      Beispiel in XML (auf den Knoten reduziert):
      <bla>{datetime}\r\nthread = {thread}</bla>

      Wenn ich das "Reinformat" dann in einer INI-Datei hätte, würde es in sowas enden:

      [bla]  
      bla = {datetime}  
      thread = {thread}
      

      Und nach INI-Spezifikation wären dass dann 2 verschiedene Einträge.

      Gewünsth wäre im INI-Format eigentlich:

      [bla]  
      bla = {datetime}\r\nthread = {thread}
      

      (Der Bezeichner der Sektion ist für das Beispiel irrelevant)

      MfG
      bubble

      --
      If "god" had intended us to drink beer, he would have given us stomachs. - David Daye
      1. Warum überträgst Du Deine Texte nicht einfach so wie sie sind, also ohne vorher an den Zeilenumbrüchen herumzudoktern? Und wenn, dann kannst Du das auch ganz genauso wieder rückgängig machen.

        XML war nur ein Beispiel-Format, bei INI-Datein wird es z.B. dann schwer zu Unterscheiden, wann ein neuer Datensatz entstanden ist oder ob es noch zum Template gehöhrt.

        Ah, Du könntest also ein anderes Dateiformat verwenden, das ist gut!

        Die ini kennt den Heredoc-Syntax, zumindest in Perl

          
        [section]  
        text=<<TOKEN;  
        mehrzeilger  
        Text  
        Zeile xy  
        TOKEN  
        
        

        In Perl ergeben die Mehrzeiler ein Array mit den Zeilen.

        Außer einer ini: Java hat mit Sicherheit eigene Serializer zum erzeugen von Sequenzen in denen beliebige Daten transportsicher (binsafe) verpackt werden können. Da würde ich mich mal umschauen, ggf. was Eigenes schaffen.

        MfG

        1. Warum überträgst Du Deine Texte nicht einfach so wie sie sind, also ohne vorher an den Zeilenumbrüchen herumzudoktern? Und wenn, dann kannst Du das auch ganz genauso wieder rückgängig machen.

          XML war nur ein Beispiel-Format, bei INI-Datein wird es z.B. dann schwer zu Unterscheiden, wann ein neuer Datensatz entstanden ist oder ob es noch zum Template gehöhrt.

          Ah, Du könntest also ein anderes Dateiformat verwenden, das ist gut!

          Falls es von der PL unabhängig sein soll und Du nur Texte hast und die Daten zyklisch sind, Beispiel Datenstruktur in Perl:

            
          $objects = {  
            addr1 => {  
              name => 'Hugo',  
              anschr => qq(Mehrzeiliger Text),  
            },  
            addr2 => {  
              name => 'Viktor',  
              anschr => qq(  
               Straße, Hausnummer  
               Adresszusatz  
               PLZ Ort  
              ),  
            },  
          };  
          
          

          guck Dir mal cEAV an, was das Ding macht, habe ich hier beschrieben, und dieser Parser ist auch in anderen PLs leicht umzusetzen. Er ist nicht binsafe, aber wenns nur um Texte geht, z.B. für einen Datenaustausch zwischen Perl und JavaScript, da ist das Teil bestens geeignet.

          PS: binary safe

          1. Also für INI-Dateien hat sich das Problem erledigt, da die Properties-Klasse automatisch das Escaping berücksichtigt.

            Das EAV-Modell werd ich wohl auch reinpopeln, sollte ja nicht all zu schwer werden.

            Erstmal wird die Anwendung rein in Java sein und auch die Module also hat sich die Geschichte mit einer binär-sicheren Serialisierung auch erledigt.

            Das Escaping werd ich wohl für XML und EAV dann wohl selbst schreiben müssen.

            MfG
            bubble

            --
            If "god" had intended us to drink beer, he would have given us stomachs. - David Daye
            1. Also für INI-Dateien hat sich das Problem erledigt, da die Properties-Klasse automatisch das Escaping berücksichtigt.

              Das EAV-Modell werd ich wohl auch reinpopeln, sollte ja nicht all zu schwer werden.

              Alles nüschd neues, wir kennen's schon lange :)

              $hunt->{addr}->{name}
              $hunt['addr']['name']
              hunt.addr.name

              usw.

              Und wenn ein Attribut parent möglich ist, kannst Du damit auch beliebig tief geschachtelte Hierarchien aufbauen.

              In vielen meiner Anwendungen nutze ich einen Data Abstraction Layer, den ich für MySQL (plus ORM) hier beschrieben habe.

              Alles EAV: persistente Daten (Datei oder MySQL oder egal), Ajax-Datenübertragung, Forum, Forumarchiv, WebSite-Doc-Structure, Content-Management per Webservice usw.

              MfG