If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#91
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In message , Mayayana
writes: "J. P. Gilliver (John)" wrote | You seem to just make things up on the spot. There | are not "many" ways to send attachments in email. | | Yes there are. | | Indeed. Some of which most modern email/news software doesn't know | about: for example, I can embed an attachment at any point within an | email, and someone else using the same software will see what I sent, | but someone using most other software will see the text I typed before | the attachment, then two attachments - the one I embedded being one, and | the text that came after being the other. [Most modern softwares | _always_ put attachments at the end, perhaps putting a _link_ (often | "cid:") in the body if they want to make it _appear_ that the attachment | isn't at the end.] You're describing the two versions of the same thing: Inline and attachment. If the recipient doesn't enable Nope. What I mean is that if I place an image (or any other attachment) _in the middle of an email/post_, and examine the raw text of my email, then it had the (UU or Mime/64) block _in the middle of the email_, i. e. the text after the attachment actually _is_ after the attachment. If you drop me an email with your email, I'll send you and example. (Can't post one as this is a text-only 'group.) HTML email then they should see an inline image as an attachment. Otherwise they'll see it where you put it in the message. Both are base64-encoded text sections in the email. There's no difference in that. Nope: nothing to do with HTML. If I send a truly inline image, _in the middle of an email/post_, most other clients will see the image _and the text that follows it_ as two attachments. As you noted, the "cid:" ID will point to a Content-ID in another content section to specify the image that should be rendered. If it's meant to be an attachment it will have Content-Disposition: attachment. That's all specified in the MIME standard. I'm not aware of any other formats in use for email. https://en.wikipedia.org/wiki/MIME Maybe 30 years ago old guys like you and Fred Flinstone sent uuencoded pictures. I _think_ that's a separate matter, of how attachments (including pictures) are encoded (UU or Mime/64). 3 -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf "Eastenders" is like being punched repeatedly in the face for half an hour. - Stephen Mangan, in Radio Times 5-11 May 2012 |
Ads |
#92
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In article , Alan Baker
wrote: | Then you've put the metadata inside the file, which is even worse. It | should be part of the file system. This is the problem with mixing Mac and Windows discussions. As I understand it, Mac stores file data separately as a "resource fork". No, you have it back to front. File data went in the data fork, metadata went in the resource fork. no it didn't. metadata was kept in the file system. Ummmm... ...no. Some metadata was COPIED to the desktop database, et al. in other words, yes. |
#93
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
"J. P. Gilliver (John)" wrote
| HTML email then they should see an inline image as an | attachment. Otherwise they'll see it where you put | it in the message. Both are base64-encoded text | sections in the email. There's no difference in that. | | Nope: nothing to do with HTML. If I send a truly inline image, _in the | middle of an email/post_, most other clients will see the image _and the | text that follows it_ as two attachments. If you add an inline image that is HTML. If you look at the raw code of the email you should see the email specified as multi-part. A unique boundary string will separate text/html/binaries. You can only add an inline image in an HTML section, and that image data can only go in a separate boundaried content section. I wonder if maybe this has to do with how you're using the client software itself. In theory there's no reason that an image can't come before text, but it still has to be in a different content section with a boundary, because only one type of content goes in a section. And I've never seen it done. In virtually all cases, an email is done in plain text, followed by HTML, followed by any base64-encoded files. A plain text email would skip the HTML section. Maybe you're trying to put inline images in a plain text email and the software is "humoring you"? ______________________________ plain text with attachments ______________________________ from to date subject Message-ID MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOUNDARY_STRING_1" X-Mailer: [your program name here] # --BOUNDARY_STRING_1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit # (email text here) # --BOUNDARY_STRING_1 Content-Type: image/jpeg; name="earth_sm.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="earth_sm.jpg" # (base 64 here) # --BOUNDARY_STRING_1-- _________________________ HTML with pictures _________________________ from to subject date Message-ID MIME-Version: 1.0 Content-Type: multipart/related; boundary="BOUNDARY_STRING_1"; type="multipart/alternative" X-Mailer: [your program name here] # --BOUNDARY_STRING_1 Content-Type: multipart/alternative; boundary="BOUNDARY_STRING_2" # --BOUNDARY_STRING_2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable # (default text for non-html email readers) # --BOUNDARY_STRING_2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable # (html body here....... IMG SRC=3D"cidic.gif" ......) # --BOUNDARY_STRING_2-- (end of alternative boundary.) # --BOUNDARY_STRING_1 Content-Type: image/gif; (or image/jpg, etc.) name="pic.gif" Content-Transfer-Encoding: base64 Content-ID: pic.gif # (base 64 here) # (repeat for other pics if present: space, boundary, content, space, base64, space) --BOUNDARY_STRING_1-- |
#94
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
"Tim Streater" wrote |
| Content Disposition | *can* be used to send creation/modification date. | I've never actually seen it done. It's certainly not | required. | | I never said it was required. I added it to my email client because I'd | seen those fields arriving in some content-disposition headers. | That's very different from the idea that an email client is "rubbish" if it doesn't do it. I have OE and TBird here. Neither one sets to mod date. Not that I'd mind if they did, but I can't say I'd ever noticed one way or the other. If someone sends me a photo of their new baby it's not particularly relevant to me what day they took the photo. | And sending creation date would make | no sense. Your copy is created when you get it, | just as a file copied across partitions has a creation | date corresponding to when it was copied. | | No it doesn't. I just copied a file to my desktop from another Mac on | the local LAN (by drag and drop), and the copy on my desktop has the | same creation date as the original. Which is what I'd expect any | sensible system to do. | And it's a copy, not a link? Maybe that's the Mac standard. On Windows a copy has the same modification date but a different creation date. To give it the same creation time is to say that both files are the same file; that there are no actual copies and therefore the copy was never actually created. Thus it's only an alternate manifestation of the same, exact item. Sounds like some pretty funky, existential hocus pocus to me. |
#95
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In article , Mayayana
wrote: | And sending creation date would make | no sense. Your copy is created when you get it, | just as a file copied across partitions has a creation | date corresponding to when it was copied. | | No it doesn't. I just copied a file to my desktop from another Mac on | the local LAN (by drag and drop), and the copy on my desktop has the | same creation date as the original. Which is what I'd expect any | sensible system to do. | And it's a copy, not a link? Maybe that's the Mac standard. On Windows a copy has the same modification date but a different creation date. To give it the same creation time is to say that both files are the same file; a copy of something means both are *the* *same*. if *anything* is different, then it's not a copy. |
#96
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
"Tim Streater" wrote | You seem to just make things up on the spot. There | are not "many" ways to send attachments in email. | There's a format. All attachments are base64 encoded. | | No they aren't. Plain ASCII text and quoted-printable are also | possible, and the sender has to declare which it is using the | content-transfer-encoding: header, so that the receiver knows how to | decode it. | I'm not sure all this nitpicking is getting anywhere. There seems to be a lot of difference in how terms are used. You call metadata any info about a file. That's not technically wrong, but usually when people are talking about metadata they're talking about data embedded in the file header, such a author of a JPG or artist for a music file. Here you seem to be using different terminology again. Most people think of an email attachment as a separate file that goes along with the email. Those are always base64-encoded. ASCII and quoted printable are not used for attachments. They're specifying the text encoding. Maybe you're confused by the term "encoding". Text encoding refers to how the text is interpreted. For instance, ASCII vs UTF-8. But it's still text. Base-64 is an ASCII encoding of bytes, used to package binary files in an ASCII medium. One reads like this. The other reads like: hAiY1fTYddQJhLjnf+auTeCYAQAiG+u1TNA The characters are not representing any kind of text. Each is representing 6 bits of data that could be anything. You say you wrote an email client and you keep referring to RFC docs. Surely you must know the difference between plain text, html and attached files in an email. Do you just like to be difficult? |
#97
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In article , Wolf K
wrote: [...] The internet works because the necessary data for routing the data packets are inside the data packet, not external. That principle should apply to all forms of data. Including programs, but that's a another issue. mime headers say otherwise. I don't see the relevance of your remark. you mangled the quoting and you don't understand the issues. AIUI, each data packet includes an ID to ensure that the intended recipient computer can snag it from the data stream, and assemble the packets in correct order, including the MIME header at the start of the data. If you want to quibble about whether the ID data is inside the packet or not, go ahead, quibble. Anything to keep you happy. the mime headers are *not* part of the actual data. they *describe* the data that is sent. Dear, dear, tsk, tsk, more misreading. But then I knew you would. there's no misreading whatsoever. the mime headers describe the data that follows. that's why they're called headers. Even MIME headers are sent as data packets. Everything that's sent over the internet is sent as data packets. It's the only way to do it. Otherwise everyone would receive everything. Which would be a humongous mess, which would take several lifetimes of the universe to sort out. true, but completely irrelevant. Have a nice quibbly, nit-picky day. you too. |
#98
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
"Wolf K" wrote
| HEIF is not proprietary. No. But the compression is that Apple is using, and the compression efficiency of that method seems to be what's appealing. In looking this up I didn't see any examples of a high quality image file using HEIF that's not using patented compression. |
#99
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
On Fri, 15 Dec 2017 08:47:47 -0000 (UTC), Lewis
wrote: In message Char Jackson wrote: On Thu, 14 Dec 2017 17:24:34 -0000 (UTC), Lewis wrote: In message Paul wrote: Wolf K wrote: On 2017-12-14 00:24, Your Name wrote: On 2017-12-14 03:16:11 +0000, Wolf K said: On 2017-12-13 19:37, Your Name wrote: [...] ... you can't rely on the OS to do that since a JPEG image file can actually be opened in a text editor as the file's data, even if it's rarely useful to do so. That's what Open With is for. Open With is near useless if you don't know what the file actually is. You'd have to Open With with every app you have until you found one that could open it properly. If we're talking about user convenience, I agree, showing a file's type as part of the filename is very useful. (But IMO a three-letter extension is too limited). There are many other useful conventions, eg, in icon design. These are converging on a common standard. If we're talking about choosing a program to open a file, extenions aren't needed. It would be easy to ensure that Open With offers only programs that can open a given file without reference to an extension. Just standardise metadata (eg, as a series of slots, some which must be filled, others for dev or user options). Easy peasy. Have a good day, Windows is not limited to 8.3. Might not be in Windows 10 (though I think it is) Nope. I can't remember what happened before XP, but at least with XP through 10 you can create a filename with 200+ characters in the extension, as long as you don't exceed the total number of characters allowed. Please reread what I said, that file will have an 8.3 representation in the filesystem. This was true in XP and in Windows 7 and in Windows 8 (Hmm. now I'm not positive about Windows 8). Let's try again. Windows filenames are not limited to 8.3. Not in Win 10, not in 8.x, not in 7, not in Vista, not in XP. I'll stop there because I don't personally remember when Long Filename (LFN) support was introduced, but it was somewhere before that, possibly in Win 95. If you think that Windows filenames *are* limited to 8.3, then you're probably confusing 'long' filenames with 'short' filenames. I'm not confusing them at all, I am pointing out taht both still exist, and that the 8.3 name is required. No. See above. -- Char Jackson |
#100
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
On 2017-12-14 4:31 PM, Your Name wrote:
On 2017-12-14 20:28:16 +0000, Andre G. Isaak said: In article , Wolf K wrote: On 2017-12-14 10:18, nospam wrote: In article , Tim Streater wrote: | The type of a file and which app you'd like it to open with are | items | of file metadata and have no business being part of the filename. | Many files have such type-identifiers included. E.g., a JPG file | begins | with JFIF, a WordPerfect file includes WPC in the first line, an MS | .doc | Then you've put the metadata inside the file, which is even worse. It | should be part of the file system. This is the problem with mixing Mac and Windows discussions. As I understand it, Mac stores file data separately as a "resource fork". No, you have it back to front. File data went in the data fork, metadata went in the resource fork. no it didn't. metadata was kept in the file system. the resource fork (which was optional, as was the data fork) held various resources. it was basically a miniature database. a zero-length file would have an empty data *and* resource fork. rare, but possible. Unfortunately Apple has abandoned this idea and settled for the lowest-common-denominator approach, and w're all the worse off for it. yep. Educate me. What's the advantage of the "forks"? As described, it looks like metadata with a fancy name, apparently conceived as attached to or pointed to by the file. Presumably it's stored separately from the file. Resource Forks are completely unrelated to metadata. The 2-fork architecture was inherited from Classic Mac OS, and, while still supported by mac OS X, it is used much less frequently. In Classic Mac OS, every file consisted of two separate forks (either of which could be empty). snip Wrong. Purely data files, such as a JPEG image or Word document, did not have any resource fork at all, not even an empty one. They didn't need one because there are no resources. That's why if you try to open a data file in ResEdit it says there is no resource fork and asks if you want to add one. (An optional add-on did allow ResEdit to open the data fork). Mainly it was only applications that had resource forks. Many people confuse the Finder's information as being part of the resource fork, but they are different. The Finder's information is not stored inside the file at all. Would you care to explain, then, how the Finder knows what information to apply to which file? |
#101
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In article , Wolf K
wrote: On 2017-12-14 19:31, Your Name wrote: Purely data files, such as a JPEG image or Word document, did not have any resource fork at all, not even an empty one. They didn't need one because there are no resources. That's why if you try to open a data file in ResEdit it says there is no resource fork and asks if you want to add one. (An optional add-on did allow ResEdit to open the data fork). Mainly it was only applications that had resource forks. Many people confuse the Finder's information as being part of the resource fork, but they are different. The Finder's information is not stored inside the file at all. Thank you. be aware that the first part is completely wrong, as i said yesterday. *every* files had *both* a resource *and* data fork (either or both of which could be empty), including what he calls 'purely data files', otherwise known as documents. inside mac, volume i, page 105-6: https://i.imgur.com/88pKuDl.jpg https://i.imgur.com/ESsqRji.jpg documents used the data fork, resource fork or both, depending on what worked best for that particular app. for example, text editors would put the text in the data fork (and compatible with non-mac systems), but might also include a custom font or scroll position in the resource fork. preference files often used only the resource fork. applications had code & assets in the resource fork, with the data fork often used for personalization (name, serial#, etc.) but could also be used for many other things or could be empty. |
#102
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
On 2017-12-16 00:10:04 +0000, Alan Baker said:
On 2017-12-14 4:31 PM, Your Name wrote: On 2017-12-14 20:28:16 +0000, Andre G. Isaak said: In article , Wolf K wrote: On 2017-12-14 10:18, nospam wrote: In article , Tim Streater wrote: | The type of a file and which app you'd like it to open with are | items | of file metadata and have no business being part of the filename. | Many files have such type-identifiers included. E.g., a JPG file | begins | with JFIF, a WordPerfect file includes WPC in the first line, an MS | .doc | Then you've put the metadata inside the file, which is even worse. It | should be part of the file system. This is the problem with mixing Mac and Windows discussions. As I understand it, Mac stores file data separately as a "resource fork". No, you have it back to front. File data went in the data fork, metadata went in the resource fork. no it didn't. metadata was kept in the file system. the resource fork (which was optional, as was the data fork) held various resources. it was basically a miniature database. a zero-length file would have an empty data *and* resource fork. rare, but possible. Unfortunately Apple has abandoned this idea and settled for the lowest-common-denominator approach, and w're all the worse off for it. yep. Educate me. What's the advantage of the "forks"? As described, it looks like metadata with a fancy name, apparently conceived as attached to or pointed to by the file. Presumably it's stored separately from the file. Resource Forks are completely unrelated to metadata. The 2-fork architecture was inherited from Classic Mac OS, and, while still supported by mac OS X, it is used much less frequently. In Classic Mac OS, every file consisted of two separate forks (either of which could be empty). snip Wrong. Purely data files, such as a JPEG image or Word document, did not have any resource fork at all, not even an empty one. They didn't need one because there are no resources. That's why if you try to open a data file in ResEdit it says there is no resource fork and asks if you want to add one. (An optional add-on did allow ResEdit to open the data fork). Mainly it was only applications that had resource forks. Many people confuse the Finder's information as being part of the resource fork, but they are different. The Finder's information is not stored inside the file at all. Would you care to explain, then, how the Finder knows what information to apply to which file? The Classic MacOS uses information stored within the Finder's own invisible information files to understand what application to use with each document file, the three usual ones being "Desktop DB", "Desktop DF", and "TheVolumeSettingsFolder". These show up under Windows, which was another cause of confusion for some users. This is why rebuilding the database was sometimes necessary to fix minor quirks (such as incorrect icons, especially when creating custom icons). MacOS X works in a similar way and has its Finder has different set of invisible information files to keep track of such things. |
#103
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
On 2017-12-15 4:30 PM, Your Name wrote:
On 2017-12-16 00:10:04 +0000, Alan Baker said: On 2017-12-14 4:31 PM, Your Name wrote: On 2017-12-14 20:28:16 +0000, Andre G. Isaak said: In article , Wolf K wrote: On 2017-12-14 10:18, nospam wrote: In article , Tim Streater wrote: | The type of a file and which app you'd like it to open with are | items | of file metadata and have no business being part of the filename. | Many files have such type-identifiers included. E.g., a JPG file | begins | with JFIF, a WordPerfect file includes WPC in the first line, an MS | .doc | Then you've put the metadata inside the file, which is even worse. It | should be part of the file system. This is the problem with mixing Mac and Windows discussions. As I understand it, Mac stores file data separately as a "resource fork". No, you have it back to front. File data went in the data fork, metadata went in the resource fork. no it didn't. metadata was kept in the file system. the resource fork (which was optional, as was the data fork) held various resources. it was basically a miniature database. a zero-length file would have an empty data *and* resource fork. rare, but possible. Unfortunately Apple has abandoned this idea and settled for the lowest-common-denominator approach, and w're all the worse off for it. yep. Educate me. What's the advantage of the "forks"? As described, it looks like metadata with a fancy name, apparently conceived as attached to or pointed to by the file. Presumably it's stored separately from the file. Resource Forks are completely unrelated to metadata. The 2-fork architecture was inherited from Classic Mac OS, and, while still supported by mac OS X, it is used much less frequently. In Classic Mac OS, every file consisted of two separate forks (either of which could be empty). snip Wrong. Purely data files, such as a JPEG image or Word document, did not have any resource fork at all, not even an empty one. They didn't need one because there are no resources. That's why if you try to open a data file in ResEdit it says there is no resource fork and asks if you want to add one. (An optional add-on did allow ResEdit to open the data fork). Mainly it was only applications that had resource forks. Many people confuse the Finder's information as being part of the resource fork, but they are different. The Finder's information is not stored inside the file at all. Would you care to explain, then, how the Finder knows what information to apply to which file? The Classic MacOS uses information stored within the Finder's own invisible information files to understand what application to use with each document file, the three usual ones being "Desktop DB", "Desktop DF", and "TheVolumeSettingsFolder". These show up under Windows, which was another cause of confusion for some users. Yes, yes, yes... .....I understand that very well. But what is the SOURCE for the information in the first place? And do you imagine that the Desktop DB, Desktop DF, etc. had individual entries for EVERY FILE on a hard drive? If not, then each FILE has to contain information about what KIND of file it is. This is why rebuilding the database was sometimes necessary to fix minor quirks (such as incorrect icons, especially when creating custom icons). MacOS X works in a similar way and has its Finder has different set of invisible information files to keep track of such things. |
#104
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In article , Your Name
wrote: Many people confuse the Finder's information as being part of the resource fork, but they are different. The Finder's information is not stored inside the file at all. Would you care to explain, then, how the Finder knows what information to apply to which file? The Classic MacOS uses information stored within the Finder's own invisible information files to understand what application to use with each document file, the three usual ones being "Desktop DB", "Desktop DF", and "TheVolumeSettingsFolder". These show up under Windows, which was another cause of confusion for some users. This is why rebuilding the database was sometimes necessary to fix minor quirks (such as incorrect icons, especially when creating custom icons). somewhat correct. TheVolumeSettingsFolder was unrelated and appeared long after classic mac os first came out. MacOS X works in a similar way and has its Finder has different set of invisible information files to keep track of such things. no, mac os x definitely does not work in a similar way. |
#105
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In message , Mayayana
writes: "J. P. Gilliver (John)" wrote | HTML email then they should see an inline image as an | attachment. Otherwise they'll see it where you put | it in the message. Both are base64-encoded text | sections in the email. There's no difference in that. | | Nope: nothing to do with HTML. If I send a truly inline image, _in the | middle of an email/post_, most other clients will see the image _and the | text that follows it_ as two attachments. If you add an inline image that is HTML. If you No. look at the raw code of the email you should see the email specified as multi-part. A unique boundary string will separate text/html/binaries. You can only True, there will be a boundary string before and after any embedded attachment (image or otherwise). But I can send an email that goes text attachment more text .. If I examine the raw code of the email, it'll have (headers) text boundary string encoded attachment boundary string more text add an inline image in an HTML section, and that No HTML. image data can only go in a separate boundaried content section. Yes, it will be in a "separate boundaries content section". But it _doesn't_ have to be at the end. If you give me an email address (use a throwaway one if you're paranoid), I'll send you an example. I wonder if maybe this has to do with how you're using the client software itself. In theory there's no reason that an image can't come before text, but it still has to be in a different content section with a boundary, because only one type of content goes in a section. Yes, obviously, encoded data has to be delimited from plain text. And I've never seen it done. In virtually all cases, an email is done in plain text, followed by HTML, followed by any base64-encoded files. A plain text email would skip the HTML section. No, I'm not talking about two-version emails, where the entire email is repeated twice, once in plain text and once in HTML. Maybe you're trying to put inline images in a plain text email and the software is "humoring you"? No, I've looked at (even edited, occasionally) the raw data form of emails, and there's no HTML - or any other tag - in them. ______________________________ plain text with attachments ______________________________ from to date subject Message-ID MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOUNDARY_STRING_1" X-Mailer: [your program name here] # --BOUNDARY_STRING_1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit # (email text here) # --BOUNDARY_STRING_1 Content-Type: image/jpeg; name="earth_sm.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="earth_sm.jpg" # (base 64 here) # --BOUNDARY_STRING_1-- Something like that, but my client can add more plain text after the image. _________________________ HTML with pictures _________________________ from to subject date Message-ID MIME-Version: 1.0 Content-Type: multipart/related; boundary="BOUNDARY_STRING_1"; type="multipart/alternative" X-Mailer: [your program name here] # --BOUNDARY_STRING_1 Content-Type: multipart/alternative; boundary="BOUNDARY_STRING_2" # --BOUNDARY_STRING_2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable # (default text for non-html email readers) # --BOUNDARY_STRING_2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable # (html body here....... IMG SRC=3D"cidic.gif" ......) # --BOUNDARY_STRING_2-- (end of alternative boundary.) # --BOUNDARY_STRING_1 Content-Type: image/gif; (or image/jpg, etc.) name="pic.gif" Content-Transfer-Encoding: base64 Content-ID: pic.gif # (base 64 here) # (repeat for other pics if present: space, boundary, content, space, base64, space) --BOUNDARY_STRING_1-- Well, that's a dual-part email, since you included the plain text "for non-html readers" as well. (I'm pretty sure I've seen emails without the plain text version, i. e. HTML only.) I can believe that maybe HTML messages can only have the images at the end with a pointer to them in the text. -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf If it ain't broke, don't download updates. - Al Drake in alt.windows7.general, 2015-4-4 |
Thread Tools | |
Display Modes | Rate This Thread |
|
|