smtp協(xié)議中有哪些字符替換

本篇內(nèi)容主要講解“smtp協(xié)議中有哪些字符替換”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“smtp協(xié)議中有哪些字符替換”吧!

互聯(lián)網(wǎng)電子郵件不是一個(gè)完美的系統(tǒng)。郵件可能會(huì)在郵遞到最終目的地的幾個(gè)階段中被損壞。具體來(lái)說(shuō)，通過(guò)互聯(lián)網(wǎng)發(fā)送的電子郵件可能會(huì)跨越許多網(wǎng)絡(luò)技術(shù)。許多網(wǎng)絡(luò)和郵件技術(shù)不支持SMTP傳輸中可能的全部功能環(huán)境。穿越這些系統(tǒng)的郵件很可能會(huì)被修改以便它可以運(yùn)輸。

互聯(lián)網(wǎng)上存在許多廣泛部署的不符合要求的MTA。這些MTA使用SMTP協(xié)議，可以隨時(shí)利用它們所在主機(jī)的內(nèi)部數(shù)據(jù)結(jié)構(gòu)實(shí)施更改消息，或者只是簡(jiǎn)單的中斷破壞。

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

（1）在某些情況下，用于數(shù)據(jù)的編碼可能作為普通網(wǎng)關(guān)或用戶代理操作的一部分進(jìn)行更改。特別是從base64轉(zhuǎn)換到Qp編碼，反之亦然可能是必要的。這個(gè)可能會(huì)導(dǎo)致CRLF序列與行混淆并在文本主體中斷開(kāi)。因此，CRLF永遠(yuǎn)不能被定義為的其他功能除了作為一行的結(jié)束符之外。

（2）許多系統(tǒng)可以選擇描述和存儲(chǔ)文本數(shù)據(jù)使用本地的新建約定。本地新建約定可能不符合RFC822的 CRLF約定 - 已知的系統(tǒng)使用普通CR、普通LF、CRLF或計(jì)數(shù)記錄。結(jié)果單獨(dú)的CR和LF字符通用性不好; 他們可能會(huì)在某些系統(tǒng)上丟失或轉(zhuǎn)換為分隔符，并且因此不能使用。

（3）NULs的傳輸（US-ASCII值0）是Internet郵件中存在問(wèn)題。（這在很大程度上是NUL被作為許多C語(yǔ)言的常用的標(biāo)準(zhǔn)運(yùn)行時(shí)庫(kù)的終止字符）。使用NUL作為終止字符的習(xí)慣如今已經(jīng)根深蒂固，郵件消息不應(yīng)該依賴(lài)于它們被保存。

（4）TAB（HT）字符可能會(huì)被誤解或可能被錯(cuò)誤的自動(dòng)轉(zhuǎn)換為可變數(shù)量的空格。這在某些環(huán)境中是不可避免的，特別是那些不基于US-ASCII字符集。這樣轉(zhuǎn)換是非常不贊成的，但它可能會(huì)發(fā)生，因此郵件格式不能長(zhǎng)久依賴(lài)于TAB（HT）           字符。

（5）長(zhǎng)度超過(guò)76個(gè)字符的行可能被包裹或在某些環(huán)境中截?cái)唷Q行或著郵件傳輸過(guò)程強(qiáng)行截?cái)嘈惺欠浅２毁澇傻?，但在某些情況下不可避免。需要長(zhǎng)行的應(yīng)用程序必須以某種方式區(qū)分行數(shù)據(jù)的軟和硬斷點(diǎn)。（一個(gè)簡(jiǎn)單的方法是使用quoted-printable編碼。）

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

（7）許多郵件域使用US-ASCII字符集的變種，或使用如其中包含大部分但不是全部US-ASCII字符的EBCDIC字符集。字符轉(zhuǎn)換網(wǎng)關(guān)不能依賴(lài)于不在“不變”集中的字符正確翻譯。例如，這個(gè)發(fā)送未解碼信息到BITNET(世界教育網(wǎng)路”比特網(wǎng)”)時(shí)就存在問(wèn)題，它是一個(gè)EBCDIC系統(tǒng)。類(lèi)似問(wèn)題無(wú)需穿越網(wǎng)關(guān)依然可能會(huì)發(fā)生，因?yàn)樵S多互聯(lián)網(wǎng)主機(jī)使用US-ASCII以外的字符集?？纱蛴∽址亩x在X.400中增加了一些特殊的限制案例。僅有字符在已知的所有網(wǎng)關(guān)中都是一致的，與大寫(xiě)和小寫(xiě)相對(duì)應(yīng)的字符字母A-Z和az-，10位數(shù)字0-9，和以下十一個(gè)特殊字符：

        “'”    （US-ASCII十進(jìn)制值39）

        “（” （US-ASCII十進(jìn)制值40）

        “）” （US-ASCII十進(jìn)制值41）

        “+”  （US-ASCII十進(jìn)制值43）

        “，” （US-ASCII十進(jìn)制值44）

        “ - ” （US-ASCII十進(jìn)制值45）

        “”    （US-ASCII十進(jìn)制值46）

        “/”   （US-ASCII十進(jìn)制值47）

        “：” （US-ASCII十進(jìn)制值58）

        “=”  （US-ASCII十進(jìn)制值61）

        “？”  （US-ASCII十進(jìn)制值63）

      一封最簡(jiǎn)易的郵件將限制本身在相對(duì)較短的文本行中，而這些文本和行的組成都             來(lái)自上面所述的73個(gè)字符集中。base64編碼遵循此規(guī)則。

（8）一些郵件傳輸代理會(huì)破壞包含某些字母的字符串的數(shù)據(jù) 。特別是，一行數(shù)據(jù)中目前已知會(huì)被一些SMTP服務(wù)器給損壞，和從五個(gè)字符“From ”（第五個(gè)字符是一個(gè)空格）開(kāi)始的一行數(shù)據(jù)也常常被破壞。一個(gè)嚴(yán)謹(jǐn)?shù)拇斫M織可以防止因?qū)?shù)據(jù)編碼而造成的數(shù)據(jù)損壞（例如，在QP編碼中使用“= 46rom”代替由“From ”開(kāi)頭的一行數(shù)據(jù)中“From ”，“= 2E”代替一行上的單獨(dú)句號(hào)(“.”)）。請(qǐng)注意，上面的列表不是MTAs推薦的列表的做法。RFC 821 中MTA禁止改變空白空格或著截?cái)嘁粋€(gè)比較長(zhǎng)的行數(shù)據(jù)。這些不好的習(xí)慣和做法在已經(jīng)建立的網(wǎng)絡(luò)上存在了，但是在處理它們可能導(dǎo)致的不良影響時(shí)，實(shí)現(xiàn)應(yīng)該是健壯的。

到此，相信大家對(duì)“smtp協(xié)議中有哪些字符替換”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！