Tickets :: Comment on [#11073] Charset is not set for the "View Source"

* Your Email Address
* Spam protection	Enter the letters below: .__..___. .__..___ \| \|[__ \| \| \|[__ \|__\[___\|___\|__\|\|
Comment	> 1)The difference b/w patched and unpatched version is only to use > charset from headers of message (Not from mime-part cludge inside > message as you put on 2-3 example!) instead of charset that Apache > will put by default. That is ALL/ > 2) For your examples: for the first there will be no visible changes, > I suppose (as base64 enconding means only 7 bit chars). Anyway it > will not be worse than default charset put by webserver. > With second and third examples patch will not alter content type, as > I scan only rfc-822 headers (before first empty line) and these > charset are out of scope- these are mime's! > > >> Again, no. Here's a message that will be completely broken in the display: >> >> Content-Type: text/plain; charset=iso-2022-jp >> Content-Transfer-Encoding: base64 >> >> The output message will be garbage >> >> Here's another message that will be completely broken: >> >> Content-Type: multipart/mixed; boundary=1 >> >> --1 >> Content-Type: text/plain; charset=iso-8859-1 >> >> [Text] >> >> --1 >> Content-Type: text/plain; charset=utf-8 >> >> [Text] >> >> --1-- >> >> >> Again, if you want a quick display of the part's contents THAT MAY >> NOT BE 100% ACCURATE, you can use View Source. If you need the >> EXACT CONTENTS, you MUST use save as. >> >> We do NOT guarantee that View Source outputs an accurate >> representation of the data. Because that is impossible to do in the >> browser (or, for that matter, any text editor). That's because MIME >> messages are NOT designed to be viewed as a single file! A MIME >> message != a discrete file as is commonly used in an OS. >
Attachment
Watch this ticket

Saved Queries