ฉันควรใช้การเข้ารหัสอักขระใดสำหรับส่วนหัว HTTP

122

ฉันใช้อักขระพิเศษ HTML (✰) "สนุก" (ดูข้อมูลเพิ่มเติมที่http://html5boilerplate.com/ ) สำหรับServerส่วนหัว HTTP และฉันสงสัยว่า "อนุญาต" ตามข้อกำหนดหรือไม่

การใช้แท็บเครือข่ายในเครื่องมือ dev ใน Chrome บน Windows Xp Pro SP 3 ฉันเห็นว่าใช้ได้ดี
ใน IE8 ✰ แสดงผลไม่ถูกต้อง
โปรแกรมตรวจสอบ HTML ของ w3.org แสดงผลไม่ถูกต้อง (แสดง " â°" แทน)

ตอนนี้ฉันไม่ค่อยสนใจการเข้ารหัสตัวอักษรมากเกินไป ... และตรงไปตรงมาฉันไม่ค่อยสนใจพวกเขามากเกินไป ฉันแค่ใช้ UTF-8 cus แบบสุ่มสี่สุ่มห้า :-)

ความเหลื่อมล้ำเกิดจากข้อบกพร่องในตัววิเคราะห์ / การเรียกดู / เครื่องมือต่างๆ / (สิ่งที่เรียกว่าอะไรก็ตาม) หรือไม่?

มีข้อกำหนดสำหรับสิ่งนี้หรืออาจเป็นรายการอักขระที่อนุญาตสำหรับ "ค่า" ส่วนหัว HTTP?

http-headers

— เดวิดเมอร์ด็อก
แหล่งที่มา

คำถามนี้น่าจะถามได้ดีกว่าโดยทั่วไป: "อักขระใดที่ได้รับอนุญาตในค่าส่วนหัว http"

— Akrikos

ที่เกี่ยวข้อง: ฉันควรใช้การเข้ารหัสอะไรสำหรับ HTTP Basic Authentication

— Hawkeye Parker

"ตอนนี้ฉันไม่ค่อยสนใจการเข้ารหัสอักขระมากนัก ... และตามตรงไปตรงมาฉันไม่ค่อยสนใจพวกเขามากนักฉันแค่ใช้ UTF-8 cus ที่ฉันบอกไปแบบสุ่มสี่สุ่มห้า :-)" <--- - ลิงก์บังคับไปที่ joelonsoftware.com/2003/10/08/…

— d4nyll

คำตอบ:

124

กล่าวโดยย่อ: รับประกันเฉพาะ ASCII เท่านั้นที่ทำงานได้ ไบต์ที่ไม่ใช่ ASCII บางตัวได้รับอนุญาตสำหรับความเข้ากันได้แบบย้อนหลัง แต่ไม่ควรแสดงได้

HTTPbis ยอมแพ้และระบุว่าในส่วนหัวไม่มีการเข้ารหัสที่เป็นประโยชน์นอกจาก ASCII:

ในอดีต HTTP อนุญาตเนื้อหาฟิลด์ที่มีข้อความในชุดอักขระ ISO-8859-1 [ISO-8859-1] ซึ่งสนับสนุนชุดอักขระอื่น ๆ โดยใช้การเข้ารหัส [RFC2047] เท่านั้น ในทางปฏิบัติค่าฟิลด์ส่วนหัว HTTP ส่วนใหญ่จะใช้เฉพาะชุดย่อยของชุดอักขระ US-ASCII [USASCII] ฟิลด์ส่วนหัวที่กำหนดใหม่ควร จำกัด ค่าฟิลด์ไว้ที่ US-ASCII octets ผู้รับควรถือว่าอ็อกเท็ตอื่น ๆ ในเนื้อหาฟิลด์ (obs-text) เป็นข้อมูลทึบแสง

ก่อนหน้านี้ RFC 2616 จากปี 2542 ได้กำหนดสิ่งนี้:

คำของ * TEXT MAY มีอักขระจากชุดอักขระอื่นที่ไม่ใช่ ISO- 8859-1 [22] เฉพาะเมื่อเข้ารหัสตามกฎของ RFC 2047 [14]

และ RFC 2047 คือการเข้ารหัส MIMEดังนั้นจึงควรเป็น:

=?UTF-8?Q?=E2=9C=B0?=

แต่ฉันไม่คิดว่ามีลูกค้าจำนวนมาก (ถ้ามี) สนับสนุน

— คอร์เนล
แหล่งที่มา

แล้วนั่นหมายความว่าอย่างไร? "✰" ถูกต้อง / อนุญาตหรือไม่

— David Murdoch

หากต้องการขยายคำตอบที่มีประโยชน์มากขึ้นเล็กน้อย: "UTF-8" คือชุดอักขระและ "Q" หมายความว่าค่าจะเป็น "quoted-printable" นอกจากนี้ยังสามารถใช้ "B" ได้หากคุณต้องการเข้ารหัส BASE64

— GargantuChet

@porneL "ข้อมูลทึบแสง" หมายความว่าอย่างไร สิ่งที่ว่าผู้รับ HTTP ควรทำเมื่อได้รับ "ข้อมูลที่ทึบแสง" เหล่านี้หรือไม่

— Pacerier

@Pacerier "ข้อมูลทึบแสง" หมายความว่าเป็นกล่องดำที่มีไบต์จำนวนมากซึ่งแอปพลิเคชันไม่ควรพยายามแสดงหรือตีความ (เช่นข้อมูลไบนารี) สิ่งที่เกิดขึ้นจะขึ้นอยู่กับส่วนหัวอาจมีตั้งแต่ "ไม่มีอะไร" ไปจนถึง "ทิ้ง"

— Kornel

@ Kornel, Btw ทำไมคุณถึงเปลี่ยนชื่อผู้ใช้ของคุณเป็น kornel?

— Pacerier

โปรดอ่านความคิดเห็นก่อนคำตอบนี้อาจมีข้อสรุปที่ไม่ถูกต้องจากแหล่งข้อมูลที่ถูกต้องจำเป็นต้องแก้ไข

คุณสามารถใช้อักขระ ASCII ที่พิมพ์ได้และไม่มีอักขระพิเศษเช่น✰ (ซึ่งไม่ใช่ASCII )

เคล็ดลับ : คุณสามารถเข้ารหัสอะไรก็ได้ใน JSON

แก้ไข : อาจไม่ชัดเจนในตอนแรกการเข้ารหัสอักขระที่กำหนดไว้ในส่วนหัวจะใช้กับเนื้อหาการตอบสนองเท่านั้นไม่ใช่สำหรับส่วนหัว (เพราะจะทำให้ไก่ - & - ไข่มีปัญหา)

ฉันต้องการสรุปคำจำกัดความที่เกี่ยวข้องทั้งหมดตามข้อมูลจำเพาะที่เชื่อมโยงโดย Penchant

message-header = field-name ":" [ field-value ]
field-name     = token
field-value    = *( field-content | LWS )

ดังนั้นเรามีอยู่หลังจากที่ข้อมูลที่มีมูลค่า

LWS            = [CRLF] 1*( SP | HT )
CRLF           = CR LF
CR             = <US-ASCII CR, carriage return (13)>
LF             = <US-ASCII LF, linefeed (10)>
SP             = <US-ASCII SP, space (32)>
HT             = <US-ASCII HT, horizontal-tab (9)>

LWS ย่อมาจาก Linear White Space โดยพื้นฐานแล้ว LWS คือ Space หรือ Tab แต่คุณสามารถแบ่งค่าฟิลด์ของคุณออกเป็นหลาย ๆ บรรทัดได้โดยเริ่มบรรทัดใหม่ก่อน Space หรือ Tab

มาทำให้มันง่ายขึ้น:

field-value    = <any field-content or Space or Tab>

ตอนนี้เรามีอยู่หลังจากที่ข้อมูลเนื้อหา

field-content  = <the OCTETs making up the field-value
                 and consisting of either *TEXT or combinations
                 of token, separators, and quoted-string>
OCTET          = <any 8-bit sequence of data>
TEXT           = <any OCTET except CTLs,
                 but including LWS>
CTL            = <any US-ASCII control character
                 (octets 0 - 31) and DEL (127)>
token          = 1*<any CHAR except CTLs or separators>
separators     = "(" | ")" | "<" | ">" | "@"
                 | "," | ";" | ":" | "\" | <">
                 | "/" | "[" | "]" | "?" | "="
                 | "{" | "}" | SP | HT

TEXT เป็นข้อความทั่วไปที่สุดและรวมถึงส่วนที่เหลือทั้งหมดดังนั้นอย่าลืมเกี่ยวกับส่วนที่เหลือ - นี่คือชุดอักขระ US-ASCII (= ASCII)

อย่างที่คุณเห็นอนุญาตให้ใช้อักขระ ASCII ที่พิมพ์ได้ทั้งหมด

— Zupa
แหล่งที่มา

คุณกำลังขัดแย้งกับข้อความที่คุณยกมา ทำไมคุณถึงพูดว่า "และไม่มีตัวอักษรพิเศษเช่น✰"? อักขระพิเศษเป็นเพียงOCTETs และตั้งแต่TEXTใด ๆOCTETยกเว้น0 - 31, ที่นี้หมายถึงว่าทุกOCTETs จาก32การที่ได้รับอนุญาต255 octets ของ✰มี226, 156และ176และทั้งสามของพวกเขาจะได้รับอนุญาตจึง✰ที่ได้รับอนุญาตตามทางเดินที่คุณยกมา

— Pacerier

@Pacerier คุณดูเหมือนถูกต้องสมบูรณ์ฉันไม่เห็นว่าทำไมฉันถึงสรุปว่าฉันทำ

— zupa

@Pacerier ยังไม่พร้อมที่จะแก้ไขเพราะต้องตรวจสอบ spec อีกครั้ง ฉันเกรงว่ารายละเอียดเพิ่มเติมจะ จำกัด เฉพาะชุดอักขระ US-ASCII ซึ่งจะสนับสนุนข้อสรุป แต่ให้เหตุผลไม่เพียงพอ

— zupa

การพูดว่า "คุณสามารถเข้ารหัสอะไรก็ได้ใน JSON" อาจทำให้เข้าใจผิดได้เล็กน้อย JSON อนุญาตให้ใช้อักขระ Unicode ในขณะที่ส่วนหัว HTTP ควรเป็น US-ASCII อักขระ Unicode จะถือว่าเป็นข้อมูล "ทึบแสง" ดังนั้นลักษณะการทำงานจึงไม่ถูกกำหนดโดยข้อกำหนด HTTP ดังที่กล่าวไว้ JSON สามารถทำให้ปลอดภัยสำหรับการรวมไว้ในส่วนหัว HTTP โดยการหลีกเลี่ยงอักขระ Unicode ผ่านลำดับการหลีกเลี่ยง \ uXXXX

— เจ

@zupa อีกประเด็นคือ ... " ยกเว้นCTLs " หมายความว่าอย่างไร? ไม่ได้หมายถึงตัวละครCR, LFได้รับอนุญาต? หรือหมายถึงอนุญาตเฉพาะลำดับต่อเนื่อง " CR LF SP/ HT" เท่านั้น? (ในคำอื่น ๆ สามารถส่วนหัวมีค่าเดียวCRหรือLFหรือHTCan ค่าส่วนหัวมีตัวอักษรหรือไม่CR, LFและHTในลำดับใด ๆ และจำนวนเงิน?)

— Pacerier