smtp協議中有哪些字符替換

本篇內容主要講解“smtp協議中有哪些字符替換”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“smtp協議中有哪些字符替換”吧!

互聯網電子郵件不是一個完美的系統。郵件可能會在郵遞到最終目的地的幾個階段中被損壞。具體來說，通過互聯網發送的電子郵件可能會跨越許多網絡技術。許多網絡和郵件技術不支持SMTP傳輸中可能的全部功能環境。穿越這些系統的郵件很可能會被修改以便它可以運輸。

互聯網上存在許多廣泛部署的不符合要求的MTA。這些MTA使用SMTP協議，可以隨時利用它們所在主機的內部數據結構實施更改消息，或者只是簡單的中斷破壞。

以下指南可能對更改數據格式（媒體類型）的所有人都有用，該數據格式應該能夠承受最廣泛網絡技術和已知的損壞的MTA。注意以任何base64方式編碼的內容都將滿足這些規則，但是一些眾所周知的機制，特別是UNIX uuencode工具，將不會。還要注意任何以Quoted-Printable方式編碼的內容要在大多數網關上保證無損，但可能有一些網關不會連接到使用EBCDIC字符集的系統。

（1）在某些情況下，用于數據的編碼可能作為普通網關或用戶代理操作的一部分進行更改。特別是從base64轉換到Qp編碼，反之亦然可能是必要的。這個可能會導致CRLF序列與行混淆并在文本主體中斷開。因此，CRLF永遠不能被定義為的其他功能除了作為一行的結束符之外。

（2）許多系統可以選擇描述和存儲文本數據使用本地的新建約定。本地新建約定可能不符合RFC822的 CRLF約定 - 已知的系統使用普通CR、普通LF、CRLF或計數記錄。結果單獨的CR和LF字符通用性不好; 他們可能會在某些系統上丟失或轉換為分隔符，并且因此不能使用。

（3）NULs的傳輸（US-ASCII值0）是Internet郵件中存在問題。（這在很大程度上是NUL被作為許多C語言的常用的標準運行時庫的終止字符）。使用NUL作為終止字符的習慣如今已經根深蒂固，郵件消息不應該依賴于它們被保存。

（4）TAB（HT）字符可能會被誤解或可能被錯誤的自動轉換為可變數量的空格。這在某些環境中是不可避免的，特別是那些不基于US-ASCII字符集。這樣轉換是非常不贊成的，但它可能會發生，因此郵件格式不能長久依賴于TAB（HT）           字符。

（5）長度超過76個字符的行可能被包裹或在某些環境中截斷。換行或著郵件傳輸過程強行截斷行是非常不贊成的，但在某些情況下不可避免。需要長行的應用程序必須以某種方式區分行數據的軟和硬斷點。（一個簡單的方法是使用quoted-printable編碼。）

（6）在一行數據上使用“空白空格”字符（空格，TAB（HT））可能會被傳輸代理丟棄，而其他傳輸代理可能會用這些字符來填充這些行數據，以便郵件文件中的所有行都是等長。因此，后面的空白空格的持久性，必須不能依賴。

（7）許多郵件域使用US-ASCII字符集的變種，或使用如其中包含大部分但不是全部US-ASCII字符的EBCDIC字符集。字符轉換網關不能依賴于不在“不變”集中的字符正確翻譯。例如，這個發送未解碼信息到BITNET(世界教育網路”比特網”)時就存在問題，它是一個EBCDIC系統。類似問題無需穿越網關依然可能會發生，因為許多互聯網主機使用US-ASCII以外的字符集。可打印字符串的定義在X.400中增加了一些特殊的限制案例。僅有字符在已知的所有網關中都是一致的，與大寫和小寫相對應的字符字母A-Z和az-，10位數字0-9，和以下十一個特殊字符：

        “'”    （US-ASCII十進制值39）

        “（” （US-ASCII十進制值40）

        “）” （US-ASCII十進制值41）

        “+”  （US-ASCII十進制值43）

        “，” （US-ASCII十進制值44）

        “ - ” （US-ASCII十進制值45）

        “”    （US-ASCII十進制值46）

        “/”   （US-ASCII十進制值47）

        “：” （US-ASCII十進制值58）

        “=”  （US-ASCII十進制值61）

        “？”  （US-ASCII十進制值63）

      一封最簡易的郵件將限制本身在相對較短的文本行中，而這些文本和行的組成都             來自上面所述的73個字符集中。base64編碼遵循此規則。

（8）一些郵件傳輸代理會破壞包含某些字母的字符串的數據 。特別是，一行數據中目前已知會被一些SMTP服務器給損壞，和從五個字符“From ”（第五個字符是一個空格）開始的一行數據也常常被破壞。一個嚴謹的代理組織可以防止因對數據編碼而造成的數據損壞（例如，在QP編碼中使用“= 46rom”代替由“From ”開頭的一行數據中“From ”，“= 2E”代替一行上的單獨句號(“.”)）。請注意，上面的列表不是MTAs推薦的列表的做法。RFC 821 中MTA禁止改變空白空格或著截斷一個比較長的行數據。這些不好的習慣和做法在已經建立的網絡上存在了，但是在處理它們可能導致的不良影響時，實現應該是健壯的。

到此，相信大家對“smtp協議中有哪些字符替換”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！