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

創(chuàng)新互聯(lián)公司為客戶提供專業(yè)的網(wǎng)站制作、成都做網(wǎng)站、程序、域名、空間一條龍服務(wù)，提供基于WEB的系統(tǒng)開發(fā). 服務(wù)項目涵蓋了網(wǎng)頁設(shè)計、網(wǎng)站程序開發(fā)、WEB系統(tǒng)開發(fā)、微信二次開發(fā)、成都做手機網(wǎng)站等網(wǎng)站方面業(yè)務(wù)。

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

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

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

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

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

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

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

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

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

（7）許多郵件域使用US-ASCII字符集的變種，或使用如其中包含大部分但不是全部US-ASCII字符的EBCDIC字符集。字符轉(zhuǎn)換網(wǎng)關(guān)不能依賴于不在“不變”集中的字符正確翻譯。例如，這個發(fā)送未解碼信息到BITNET(世界教育網(wǎng)路”比特網(wǎng)”)時就存在問題，它是一個EBCDIC系統(tǒng)。類似問題無需穿越網(wǎng)關(guān)依然可能會發(fā)生，因為許多互聯(lián)網(wǎng)主機使用US-ASCII以外的字符集。可打印字符串的定義在X.400中增加了一些特殊的限制案例。僅有字符在已知的所有網(wǎng)關(guān)中都是一致的，與大寫和小寫相對應(yī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服務(wù)器給損壞，和從五個字符“From ”（第五個字符是一個空格）開始的一行數(shù)據(jù)也常常被破壞。一個嚴謹?shù)拇斫M織可以防止因?qū)?shù)據(jù)編碼而造成的數(shù)據(jù)損壞（例如，在QP編碼中使用“= 46rom”代替由“From ”開頭的一行數(shù)據(jù)中“From ”，“= 2E”代替一行上的單獨句號(“.”)）。請注意，上面的列表不是MTAs推薦的列表的做法。RFC 821 中MTA禁止改變空白空格或著截斷一個比較長的行數(shù)據(jù)。這些不好的習(xí)慣和做法在已經(jīng)建立的網(wǎng)絡(luò)上存在了，但是在處理它們可能導(dǎo)致的不良影響時，實現(xiàn)應(yīng)該是健壯的。

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

本文名稱：smtp協(xié)議中有哪些字符替換-創(chuàng)新互聯(lián)
文章網(wǎng)址：http://www.rwnh.cn/article40/ijjeo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站建設(shè)、品牌網(wǎng)站制作、Google、企業(yè)建站、網(wǎng)站營銷、ChatGPT

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)