本篇內(nèi)容主要講解“smtp協(xié)議中有哪些字符替換”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“smtp協(xié)議中有哪些字符替換”吧!
互聯(lián)網(wǎng)電子郵件不是一個完美的系統(tǒng)。郵件可能會在郵遞到最終目的地的幾個階段中被損壞。具體來說，通過互聯(lián)網(wǎng)發(fā)送的電子郵件可能會跨越許多網(wǎng)絡技術。許多網(wǎng)絡和郵件技術不支持SMTP傳輸中可能的全部功能環(huán)境。穿越這些系統(tǒng)的郵件很可能會被修改以便它可以運輸。
互聯(lián)網(wǎng)上存在許多廣泛部署的不符合要求的MTA。這些MTA使用SMTP協(xié)議，可以隨時利用它們所在主機的內(nèi)部數(shù)據(jù)結構實施更改消息，或者只是簡單的中斷破壞。
以下指南可能對更改數(shù)據(jù)格式（媒體類型）的所有人都有用，該數(shù)據(jù)格式應該能夠承受最廣泛網(wǎng)絡技術和已知的損壞的MTA。注意以任何base64方式編碼的內(nèi)容都將滿足這些規(guī)則，但是一些眾所周知的機制，特別是UNIX uuencode工具，將不會。還要注意任何以Quoted-Printable方式編碼的內(nèi)容要在大多數(shù)網(wǎng)關上保證無損，但可能有一些網(wǎng)關不會連接到使用EBCDIC字符集的系統(tǒng)。
（1）在某些情況下，用于數(shù)據(jù)的編碼可能作為普通網(wǎng)關或用戶代理操作的一部分進行更改。特別是從base64轉換到Qp編碼，反之亦然可能是必要的。這個可能會導致CRLF序列與行混淆并在文本主體中斷開。因此，CRLF永遠不能被定義為的其他功能除了作為一行的結束符之外。
（2）許多系統(tǒng)可以選擇描述和存儲文本數(shù)據(jù)使用本地的新建約定。本地新建約定可能不符合RFC822的 CRLF約定 - 已知的系統(tǒng)使用普通CR、普通LF、CRLF或計數(shù)記錄。結果單獨的CR和LF字符通用性不好; 他們可能會在某些系統(tǒng)上丟失或轉換為分隔符，并且因此不能使用。
（3）NULs的傳輸（US-ASCII值0）是Internet郵件中存在問題。（這在很大程度上是NUL被作為許多C語言的常用的標準運行時庫的終止字符）。使用NUL作為終止字符的習慣如今已經(jīng)根深蒂固，郵件消息不應該依賴于它們被保存。
（4）TAB（HT）字符可能會被誤解或可能被錯誤的自動轉換為可變數(shù)量的空格。這在某些環(huán)境中是不可避免的，特別是那些不基于US-ASCII字符集。這樣轉換是非常不贊成的，但它可能會發(fā)生，因此郵件格式不能長久依賴于TAB（HT） 字符。
（5）長度超過76個字符的行可能被包裹或在某些環(huán)境中截斷。換行或著郵件傳輸過程強行截斷行是非常不贊成的，但在某些情況下不可避免。需要長行的應用程序必須以某種方式區(qū)分行數(shù)據(jù)的軟和硬斷點。（一個簡單的方法是使用quoted-printable編碼。）
（6）在一行數(shù)據(jù)上使用“空白空格”字符（空格，TAB（HT））可能會被傳輸代理丟棄，而其他傳輸代理可能會用這些字符來填充這些行數(shù)據(jù)，以便郵件文件中的所有行都是等長。因此，后面的空白空格的持久性，必須不能依賴。
（7）許多郵件域使用US-ASCII字符集的變種，或使用如其中包含大部分但不是全部US-ASCII字符的EBCDIC字符集。字符轉換網(wǎng)關不能依賴于不在“不變”集中的字符正確翻譯。例如，這個發(fā)送未解碼信息到BITNET(世界教育網(wǎng)路”比特網(wǎng)”)時就存在問題，它是一個EBCDIC系統(tǒng)。類似問題無需穿越網(wǎng)關依然可能會發(fā)生，因為許多互聯(lián)網(wǎng)主機使用US-ASCII以外的字符集?？纱蛴∽址亩x在X.400中增加了一些特殊的限制案例。僅有字符在已知的所有網(wǎng)關中都是一致的，與大寫和小寫相對應的字符字母A-Z和az-，10位數(shù)字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編碼遵循此規(guī)則。
（8）一些郵件傳輸代理會破壞包含某些字母的字符串的數(shù)據(jù) 。特別是，一行數(shù)據(jù)中目前已知會被一些SMTP服務器給損壞，和從五個字符“From ”（第五個字符是一個空格）開始的一行數(shù)據(jù)也常常被破壞。一個嚴謹?shù)拇斫M織可以防止因對數(shù)據(jù)編碼而造成的數(shù)據(jù)損壞（例如，在QP編碼中使用“= 46rom”代替由“From ”開頭的一行數(shù)據(jù)中“From ”，“= 2E”代替一行上的單獨句號(“.”)）。請注意，上面的列表不是MTAs推薦的列表的做法。RFC 821 中MTA禁止改變空白空格或著截斷一個比較長的行數(shù)據(jù)。這些不好的習慣和做法在已經(jīng)建立的網(wǎng)絡上存在了，但是在處理它們可能導致的不良影響時，實現(xiàn)應該是健壯的。
到此，相信大家對“smtp協(xié)議中有哪些字符替換”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關內(nèi)容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！
重慶分公司
重慶分公司
