MIME Multipart boundary

also ich will ja nicht meckern, aber wenn ich pech hab, läuft die schleife ewig

triptop schrieb:

also ich will ja nicht meckern, aber wenn ich pech hab, läuft die schleife ewig

nein, da täusch ich mich... sie läuft höchstens text länge/boundary länge...

kann mir jmd. einen besserern algo als den von Mechanics anbieten

triptop schrieb:

triptop schrieb:

also ich will ja nicht meckern, aber wenn ich pech hab, läuft die schleife ewig

nein, da täusch ich mich... sie läuft höchstens text länge/boundary länge...

auch das stimmt nicht, evtl. ist die zahl zu klein aber was solls, ich hätt gern etwas wo ich genau weiß wie lang das braucht...

Mechanics schrieb:

Ja, aber du kannst es doch überprüfen. Pseudocode:

string boundary = createBoundary();
while (myTextBlock.contains(boundary))
boundary = createBoundary();

und sie kann doch ewig laufen

Mechanics

Ja, sie kann theoretisch ewig laufen. Mach halt noch eine Abbruchbedingung rein, die nach 10 Versuchen abbricht und dann eine Fehlermeldung ausgibt. Es ist aber extrem unwahrscheinlich, dass sowas passiert. Eine Boundary ist ja schon so aufgebaut, dass es in normalen Texten nicht vorkommt, wenn du da noch was zufälliges einbaust, dann ist die Wahrscheinlichkeit, dass es in deinem Block vorkommt, sehr gering, und dass 10 zufällige Boundaries alle in dem Block vorkommen noch viel geringer.
Was anderes wirst du nicht finden. Es gibt keine Möglichkeit, eine Boundary zu finden, die garantiert nicht in dem Text vorkommt, ohne sie in dem Text zu suchen.

okay, es wird noch schlimmer, mit einem längen limit (rfc2046), befinden wir uns in einer mission impossible... http ist total fuc*** up

The only mandatory global parameter for the "multipart" media type is
   the boundary parameter, which consists of 1 to 70 characters from a
   set of characters known to be very robust through mail gateways, and
   NOT ending with white space. (If a boundary delimiter line appears to
   end with white space, the white space must be presumed to have been
   added by a gateway, and must be deleted.)  It is formally specified
   by the following BNF:

     boundary := 0*69<bchars> bcharsnospace

     bchars := bcharsnospace / " "

     bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
                      "+" / "_" / "," / "-" / "." /
                      "/" / ":" / "=" / "?"

Mechanics schrieb:

...wenn du da noch was zufälliges einbaust, dann ist die Wahrscheinlichkeit, dass es in deinem Block vorkommt, sehr gering, und dass 10 zufällige Boundaries alle in dem Block vorkommen noch viel geringer.

ja, bleibt mir nichts anderes übrig, als mich bei dateiübertragungen auf wahrscheinlichkeiten zu verlassen, traurig für ein 'elite' protokoll, welches den katakomben des cern entsprungen ist

Mechanics schrieb:

Es gibt keine Möglichkeit, eine Boundary zu finden, die garantiert nicht in dem Text vorkommt, ohne sie in dem Text zu suchen.

leider ists nicht mal mit suchen drin, traurig

Mechanics

Mit "suchen" meinte ich nachträglich vergleichen, ob die von dir generierte Boundary im Text vorkommt.
Ich weiß nicht, was du für Probleme hast. HTTP ist sicher kein Elite Protokoll, das hat schon mehr Probleme, allein schon, dass das Encoding der Anfrage nicht definiert ist. Aber das mit den Boundaries ist jetzt halt so wild, dasselbe Problem gibts bei zig anderen Protokollen, damit kann man leben. Machs einfach und vergiss es.

ich liebe nike

tntnet

Wenn ich 70 Zeichen habe und bei jedem Zeichen 6 Bit zur Verfügung habe, habe ich insgesamt 420 Bits, die ich frei vergeben darf um ein Boundary zu definieren, welches in dem Mime-parts nicht vor kommt. Unmöglich ist das, wenn meine Daten eine Größe von mindestens 2^420 Bits haben. Und das passt momentan wahrscheinlich nicht auf alle Festplatten, die jemals hier auf unserer Erde bisher hergestellt wurden. Also damit kann man schon mal sagen, dass die Unmöglichkeit eher akademischen Wert hat.

Die nächste Aufgabe ist es, einen geeigneten Boundary zu finden. Ein einfacher Algorithmus wäre, eine beliebige 420-bittige Zahl zu nehmen und zu prüfen, ob diese in den Daten vor kommt. Wenn ja, dann erhöhe ich die Zahl um 1. Das wiederhole ich, bis ich das Boundary nicht finde. Das ist nur eine Endlosschleife, wenn die obere akademische Bedingung erfüllt ist.

Noch zum Hintergrund, wie ich auf 6 Bit komme: Das Boundary soll aus Zeichen bestehen, die "known to be very robust" sind. Da fallen mir zunächst die Zeichen a-z und A-Z ein. Das sind schon mal 52 Zeichen. Das kann ich leicht durch 12 geeignete Sonderzeichen ergänzen. Damit habe ich 64 Ausprägungen in einem Byte und das sind 6 Bit Nutzdaten.

Eine einfache Möglichkeit, eine beliebige binäre Zahl in so ein geeignetes Format zu packen, wäre base-64 encoding. Also noch mal im Pseudocode:

startvalue = 12345678;
while(true)
{
  boundary = base64(startvalue);
  if (boundary not found in data)
    break;  // success
  startvalue = startvalue + 1;
}

_--

tntnet schrieb:

Wenn ich 70 Zeichen habe und bei jedem Zeichen 6 Bit zur Verfügung habe, habe ich insgesamt 420 Bits, die ich frei vergeben darf um ein Boundary zu definieren, welches in dem Mime-parts nicht vor kommt. Unmöglich ist das, wenn meine Daten eine Größe von mindestens 2^420 Bits haben. Und das passt momentan wahrscheinlich nicht auf alle Festplatten, die jemals hier auf unserer Erde bisher hergestellt wurden. Also damit kann man schon mal sagen, dass die Unmöglichkeit eher akademischen Wert hat.

allein schon der umstand, dass man vorher diese zeichenkette suchen muss... naja, so ist das eben bei sachen, die sich iwie vllt. auch nur auf grund ihrer herkunft durchsetzen.

_--

"Programming is similar to sex. If you make a mistake, you have to support it for the rest of your life." ich belasse es mit diesem satz dabei!

Mechanics

_-- schrieb:

"Programming is similar to sex. If you make a mistake, you have to support it for the rest of your life." ich belasse es mit diesem satz dabei!

Eigentlich ist es ja noch schlimmer. Wenn jemand einen Fehler macht, der sich durchsetzt, müssen das alle supporten