3 回答

TA貢獻(xiàn)1786條經(jīng)驗(yàn) 獲得超13個(gè)贊
標(biāo)題只表示內(nèi)容的編碼內(nèi)容。不一定可以從內(nèi)容本身推斷內(nèi)容的類型,即您不一定只看內(nèi)容并知道如何處理它。這就是HTTP標(biāo)頭的用途,它們告訴收件人他們(應(yīng)該)正在處理什么樣的內(nèi)容。
Content-type: application/json; charset=utf-8
將內(nèi)容指定為JSON格式,以UTF-8字符編碼進(jìn)行編碼。對(duì)于JSON來(lái)說(shuō),指定編碼有點(diǎn)多余,因?yàn)镴SON的默認(rèn)(僅?)編碼是UTF-8。因此,在這種情況下,接收服務(wù)器顯然很高興知道它正在處理JSON并且假設(shè)默認(rèn)情況下編碼是UTF-8,這就是它使用或不使用標(biāo)頭的原因。
此編碼是否限制可以在郵件正文中的字符?
不可以。你可以在標(biāo)題和正文中發(fā)送任何你想要的東西。但是,如果兩者不匹配,您可能會(huì)得到錯(cuò)誤的結(jié)果。如果您在標(biāo)頭中指定內(nèi)容是UTF-8編碼但實(shí)際上您正在發(fā)送Latin1編碼內(nèi)容,則接收方可能會(huì)生成垃圾數(shù)據(jù),嘗試將Latin1編碼數(shù)據(jù)解釋為UTF-8。當(dāng)然,如果您指定發(fā)送Latin1編碼數(shù)據(jù)并且實(shí)際上是在執(zhí)行此操作,那么是的,您可以限制為可以在Latin1中編碼的256個(gè)字符。

TA貢獻(xiàn)1795條經(jīng)驗(yàn) 獲得超7個(gè)贊
為了證實(shí)聲稱默認(rèn)的JSON編碼是UTF-8 ...
來(lái)自IETF RFC4627:
JSON文本應(yīng)以Unicode編碼。默認(rèn)編碼為UTF-8。
由于JSON文本的前兩個(gè)字符將始終為ASCII字符[RFC0020],因此可以確定八位字節(jié)流是UTF-8,UTF-16(BE或LE)還是UTF-32(BE或LE)通過查看前四個(gè)八位字節(jié)中的空值模式。
00 00 00 xx UTF-32BE 00 xx 00 xx UTF-16BE xx 00 00 00 UTF-32LE xx 00 xx 00 UTF-16LE xx xx xx xx UTF-8

TA貢獻(xiàn)2003條經(jīng)驗(yàn) 獲得超2個(gè)贊
請(qǐng)注意,IETF RFC4627已被IETF RFC7158取代。在[8.1]節(jié)中,它撤回了@Drew引用的文字:
Implementations MUST NOT add a byte order mark to the beginning of a JSON text.
添加回答
舉報(bào)