それにしても、これらの等号は一体どうなっているのでしょうか？ – ランダムな考え

どういうわけか、ここ数日間、人々が古いメールの抜粋を Twitter に大量に投稿しています。誰もが自問する最も重要な質問は、「これらの等号は一体どうなっているのか?」ということです。

そして、それは私がある程度専門家であることです。つまり、メールリーダーなどを作成したことがあります。カリブ海の島々に行ったことがあるからではありません。

これはコードであるとか、スキャンして OCR を使用した結果だと自信を持って主張する人を見たことがありますが、どちらでもありません。単に、これらのメールを読み取り可能な形式に変換した人がバカだっただけです。

何言ってるの？ 「変換？！ きっとメールなんてただの文字だよ！！」石器時代 (つまり 80 年代) に住んでいた人なら、ほとんどがそうでしたが、当時は人々が「長い行」や「岩のドット」などを発明し、コンピューターは送信する前にメールを「エンコード」する必要がありました。

ここで見られるアーティファクトは、と呼ばれるものです。 「印刷可能な引用文」、または、それが導入されたときに私たちが呼んでいたように、「引用符が読めません」。

最初の行に進みます。これを書いた人は、メール リーダーに次のように入力しました。

we talked about designing a pig with different non- cloven hoofs in order  to make kosher bacon

かなり長い行であることがわかります。メール サーバーはこれを好まないため、メール ソフトウェアは次のように 2 行に分割します。

we talked about designing a pig with different non- =
cloven hoofs in order  to make kosher bacon

見る？等号があるよ！はい、等号は「本来は 1 行にする必要がありますが、メール サーバーに怒られないように 2 行に分割しました」ということを示すために使用されます。

ただし、ここでの正式な定義は重要なので、ここでは少し専門的になる必要があります。「これは継続行である」と言うには、等号、キャリッジ リターン、ライン フィードの順に挿入します。

または、

=CRLF

合計 3 文字、つまり :

... non- =CRLF
cloven hoofs...

これを表示するときに、これら 3 文字をすべて削除すると、
と：

... non- cloven hoofs...

それで、ここで何が起こったのでしょうか？そうですね、これらの電子メールを最初に収集した人は、CRLF (「Windows」の行末コーディングとも呼ばれますが、SMTP 標準では標準の行末コーディングです) から「NL」 (つまり、「Unix」の行末コーディング) に変換しました。電子メールを扱う場合、これはごく普通のことです。ただし、その場合は 1 バイト減ります。

... non- =NL
cloven hoofs...

これをデコードするためのアルゴリズムが、愚かにも「行末の等号を見つけて 2 文字削除し、最後に等号を削除する」ものである場合、最終的には次のようになります。

... non- loven hoofs...

つまり、「c」が失われます。これはほぼここで起こったことですが、完全ではありません。なぜ等号がまだ残っているのでしょうか?

これ スタックオーバーフロー 14年前の投稿では、この現象について次のように説明されています。

明らかに、クライアントは = の後に適切な CR LF シーケンスが続いていないことに気づき、これがソフト改行ではなく、2 つの 16 進数でエンコードされた文字であると想定し、次の 2 バイトを読み取ります。次の 2 バイトが有効な 16 進数ではないため、動作も間違っていることに気づくはずですが、その時点では有用なものを表示する機会がないことを認めなければなりません。彼らは、ガベージイン、ガベージアウトのアプローチを選択しました。

つまり、等号は長い行を折り返す以外にも他の用途に使用されており、それについてはこの投稿の後半で説明します。

   =C2   please note

等号が行末にない場合は、「ロックドット」で使用するような「面白い文字」をエンコードするために使用されます。 =C2 は 194 で、これは UTF-8 シーケンスの最初の文字であり、次の文字は =A0 である可能性が高くなります。 =C2=A0 は「改行禁止スペース」で、テキストをインデントするためによく使用されます (「ご注意ください」はインデントされます)。また、これらの電子メールの他の多くの場所で =A0 が表示されます。

私の推測では、この部分を実行した人は、適切なデコーダを使用する代わりに、=C2 および/または =A0 の検索置換を行っただけだと思われますが、他の説明も確かに可能です。何かアイデアはありますか？

とにかく、これが等号の意味です。1) 「それは技術的です」、2) 「それはバグのある継続行のデコードの組み合わせです」 そして 「バグのある非 ASCII デコード」、および 3) 「これらのメールを処理した人は無能である」。この時点では、2) はそれほど驚くべきことではないと思いますね。

(後で少し編集します: ここで少し指摘します: 標準 が書かれた当時、人々は主に、quoted-printable コンテンツのトランスポート エンコーディングが受信時に巻き戻され (「トランスポート」に注意)、受信後にディスク上に「クリーン テキスト」が残るだろうと想像していました。これは実際には起こらなかったので、すべての「実際の」実装は単一文字 (つまり、「エンコードされていない」) 改行を正しく処理します。例えば：

(quoted-printable-decode-string "he=nllo")
=> "hello"

このため、行展開を行うために通常 SMTP サーバー コンテキストで実行されるアルゴを再利用したのではないかと考えられます。そのコンテキストでは、行末が CRLF であると想定しても問題ありません。そして偶然ですが、このアルゴリズムは Windows ベースのファイルを操作している場合には正常に動作しますが、Unix ベースのファイルの場合は失敗します。)