2013-03-25 12 views
19

Ich verwende derzeit Python imaplib, um E-Mail-Text zu verarbeiten.Wie wird das Gleichheitszeichen '=' in IMAP-E-Mail-Text verstanden?

Ich benutze Fetch-Befehl, um die Rohdaten E-Mail von GMail-Server zu holen. Allerdings fand ich eine Sache wirklich schwierig - das Gleichheitszeichen '='. Es ist kein normales Gleichheitszeichen, sondern ein spezielles Symbol.

Zum Beispiel:

  1. ‚=‘ manchmal fungiert als Trennzeichen am Ende der Textzeile:

    Depending upon your module selections, course lecturers may also contact yo= 
    u with preparatory work over the next few weeks. It would be wise to start = 
    reviewing the preparatory reading lists provided on the module syllabi now = 
    
  2. Manchmal wirkt es als Fluchtzeichen ähnlich zu ‚% ‘, zum Beispiel:

    a=20b ist eigentlich a<SPACE>b
    =46rom here Akt ual From here

Ich bin total verwirrt über solche seltsame Notation. Ich denke, dass es eine Anleitung geben muss, um damit umzugehen, weil GMail so etwas in ihren Apps richtig handhaben kann.

Ich sehe, dass dies mit HTML-Codierung verwandt ist, genau wie '%' codiert wird. Aber das Problem ist, alles, was ich von der IMAP-Antwort bekomme, ist eine Zeichenkette, die dieses "=" Symbol enthält. Wie soll ich damit umgehen? Regulären Ausdruck verwenden?

+4

Der Begriff, den Sie suchen, ist "quoted-printable", das ist der Name dieser Formatierung (und sollte in den MIME-Kopfzeilen der Nachricht vermerkt werden). Googeln dafür sollten Sie alle Informationen erhalten, die Sie brauchen. – kindall

+0

@kindall Danke für dieses Schlüsselwort! Ich werde es überprüfen – JXITC

Antwort

19

Kurz gesagt, ein Gleichheitszeichen am Ende einer Zeile zeigt einen weichen Zeilenumbruch an. Ein Gleichheitszeichen gefolgt von zwei hexadezimalen Zeichen (0-9, A-F) codiert ein einzelnes Oktett (Byte).

Dieses Kodierungsschema heißt "zitierte, druckbare" und ist in Abschnitt 6.7 von RFC 2045 definiert. Siehe insbesondere Punkte (1) und (5).

6.7. Quoted-Printable Content-Transfer-Encoding 

    The Quoted-Printable encoding is intended to represent data that 
    largely consists of octets that correspond to printable characters in 
    the US-ASCII character set. It encodes the data in such a way that 
    the resulting octets are unlikely to be modified by mail transport. 
    If the data being encoded are mostly US-ASCII text, the encoded form 
    of the data remains largely recognizable by humans. A body which is 
    entirely US-ASCII may also be encoded in Quoted-Printable to ensure 
    the integrity of the data should the message pass through a 
    character-translating, and/or line-wrapping gateway. 

    In this encoding, octets are to be represented as determined by the 
    following rules: 

    (1) (General 8bit representation) Any octet, except a CR or 
      LF that is part of a CRLF line break of the canonical 
      (standard) form of the data being encoded, may be 
      represented by an "=" followed by a two digit 
      hexadecimal representation of the octet's value. The 
      digits of the hexadecimal alphabet, for this purpose, 
      are "ABCDEF". Uppercase letters must be 
      used; lowercase letters are not allowed. Thus, for 
      example, the decimal value 12 (US-ASCII form feed) can 
      be represented by "=0C", and the decimal value 61 (US- 
      ASCII EQUAL SIGN) can be represented by "=3D". This 
      rule must be followed except when the following rules 
      allow an alternative encoding. 

    (2) (Literal representation) Octets with decimal values of 
      33 through 60 inclusive, and 62 through 126, inclusive, 
      MAY be represented as the US-ASCII characters which 
      correspond to those octets (EXCLAMATION POINT through 
      LESS THAN, and GREATER THAN through TILDE, 
      respectively). 

    (3) (White Space) Octets with values of 9 and 32 MAY be 
      represented as US-ASCII TAB (HT) and SPACE characters, 

      respectively, but MUST NOT be so represented at the end 
      of an encoded line. Any TAB (HT) or SPACE characters 
      on an encoded line MUST thus be followed on that line 
      by a printable character. In particular, an "=" at the 
      end of an encoded line, indicating a soft line break 
      (see rule #5) may follow one or more TAB (HT) or SPACE 
      characters. It follows that an octet with decimal 
      value 9 or 32 appearing at the end of an encoded line 
      must be represented according to Rule #1. This rule is 
      necessary because some MTAs (Message Transport Agents, 
      programs which transport messages from one user to 
      another, or perform a portion of such transfers) are 
      known to pad lines of text with SPACEs, and others are 
      known to remove "white space" characters from the end 
      of a line. Therefore, when decoding a Quoted-Printable 
      body, any trailing white space on a line must be 
      deleted, as it will necessarily have been added by 
      intermediate transport agents. 

    (4) (Line Breaks) A line break in a text body, represented 
      as a CRLF sequence in the text canonical form, must be 
      represented by a (RFC 822) line break, which is also a 
      CRLF sequence, in the Quoted-Printable encoding. Since 
      the canonical representation of media types other than 
      text do not generally include the representation of 
      line breaks as CRLF sequences, no hard line breaks 
      (i.e. line breaks that are intended to be meaningful 
      and to be displayed to the user) can occur in the 
      quoted-printable encoding of such types. Sequences 
      like "=0D", "=0A", "=0A=0D" and "=0D=0A" will routinely 
      appear in non-text data represented in quoted- 
      printable, of course. 

      Note that many implementations may elect to encode the 
      local representation of various content types directly 
      rather than converting to canonical form first, 
      encoding, and then converting back to local 
      representation. In particular, this may apply to plain 
      text material on systems that use newline conventions 
      other than a CRLF terminator sequence. Such an 
      implementation optimization is permissible, but only 
      when the combined canonicalization-encoding step is 
      equivalent to performing the three steps separately. 

    (5) (Soft Line Breaks) The Quoted-Printable encoding 
      REQUIRES that encoded lines be no more than 76 
      characters long. If longer lines are to be encoded 
      with the Quoted-Printable encoding, "soft" line breaks 
      must be used. An equal sign as the last character on a 
      encoded line indicates such a non-significant ("soft") 
      line break in the encoded text. 
+0

Vielen Dank für die Antwort !! Was ist die beste Vorgehensweise, um damit umzugehen? Sollte ich reguläre Ausdrücke wie '= $' und '= [0-9A-Z] {2,2}' verwenden, um diese speziellen einzufangen? – JXITC

+5

Sie sollten das 'quopri' Modul verwenden, um damit umzugehen. http://docs.python.org/2/library/quopri.html – kindall

+0

@kindall Cool! Du weißt genau was ich will :) – JXITC