What's a decent XML editor specifically for editing/viewing SMS messages copied from Android to Windows?

Q1: What's a decent XML editor specifically for editing/viewing SMS messages
archived from Android to Windows (in the XML text archive format).
https://i.postimg.cc/L5WsCrNq/xml01.jpg
Q2: Why do these SMS backup programs use XML anyway?

Other than while graphically layout out Hello-World simple apps in
Android Studio freeware, I've never had to deal with XML on Windows.'
https://groups.google.com/d/msg/comp.mobile.android/aW64zYeBtF0/1b5h3r3PBAAJ

I need help figuring out _what_ is in a bunch of newly created XML files.
o What free editor/viewer would you recommend for my generic needs below?

What's the problem set?
1. Someone asked on comp.mobile.android how to copy SMS/MMS from Android to Windows.
https://groups.google.com/forum/#!topic/comp.mobile.android/d0Y8CqDTaog
https://groups.google.com/forum/#!topic/comp.mobile.android/xwX8S7XW-p0
2. I tested these free apps, both of which created XML files.
o *SMS Backup & Restore*, by SyncTech Pty Ltd
https://play.google.com/store/apps/details?id=com.riteshsahu.SMSBackupRestore
"backs up and restores your phone's SMS and MMS messages and call logs."
o *Super Backup & Restore*, by MobileIdea Studio
https://play.google.com/store/apps/details?id=com.idea.backup.smscontacts
"You can backup applications, contacts, text messages, call history,
bookmarks, calendars to your SD card, Gmail, or Google Drive"
(some functions require root)
3. I copied the XML results to Windows.
\sms_backup_and_restore\calls-20200421011403.xml
\sms_backup_and_restore\sms-20200421011403.xml
\super_backup_and_restore\sms\sms_20200421012301.x ml
\super_backup_and_restore\logs\calllogs_2020042101 2328.xml

Now what?
o How can we best view/edit these SMS XML files on Windows?

Obvious I doubleclicked on them, which brought up the XML tagged results in
Windows Internet Explorer (of all things). Obviously I googled and installed
what seems to be the canonical XML freeware editor, from Microsoft...
o *XML Notepad 2007*
https://www.microsoft.com/en-us/download/details.aspx?id=7973
Name: XmlNotepad.msi
Size: 1917440 bytes (1872 KiB)
SHA256: 7420A936C167ACAFDC9421181B579FE8ECFF6D43937EDCEF93 E2A1321F8141FF

Unfortunately, it required more stuff from Microsoft...
o .NET Framework 3.5
https://dotnet.microsoft.com/download/dotnet-framework/net35-sp1
Name: dotnetfx35.exe
Size: 242743296 bytes (231 MiB)
SHA256: 0582515BDE321E072F8673E829E175ED2E7A53E803127C5025 3AF76528E66BC1
Which, when clicked, _still_ tried to download more stuff from the net.

Finally, when I was able to read the XML file, the question may have
been partially mooted (mootified?) simply because the contents the backup
contained are rather uninspiring.

Nonetheless, the question arises as to what's a good free Windows XML editor?
And, why do these freeware SMS backup programs choose XML format anyway?
https://i.postimg.cc/L5WsCrNq/xml01.jpg
--
Together we can accomplish far more than any one of us can alone.

Arlen Holder wrote:
Q1: What's a decent XML editor specifically for editing/viewing SMS
messages
archived from Android to Windows (in the XML text archive format).
https://i.postimg.cc/L5WsCrNq/xml01.jpg
Q2: Why do these SMS backup programs use XML anyway?

Other than while graphically layout out Hello-World simple apps in
Android Studio freeware, I've never had to deal with XML on Windows.'
https://groups.google.com/d/msg/comp.mobile.android/aW64zYeBtF0/1b5h3r3PBAAJ


I need help figuring out _what_ is in a bunch of newly created XML files.
o What free editor/viewer would you recommend for my generic needs below?

What's the problem set?
1. Someone asked on comp.mobile.android how to copy SMS/MMS from Android
to Windows.
https://groups.google.com/forum/#!topic/comp.mobile.android/d0Y8CqDTaog
https://groups.google.com/forum/#!topic/comp.mobile.android/xwX8S7XW-p0
2. I tested these free apps, both of which created XML files. o *SMS
Backup & Restore*, by SyncTech Pty Ltd

https://play.google.com/store/apps/details?id=com.riteshsahu.SMSBackupRestore

"backs up and restores your phone's SMS and MMS messages and call
logs."
o *Super Backup & Restore*, by MobileIdea Studio

https://play.google.com/store/apps/details?id=com.idea.backup.smscontacts
"You can backup applications, contacts, text messages, call history,
bookmarks, calendars to your SD card, Gmail, or Google Drive"
(some functions require root)
3. I copied the XML results to Windows.
\sms_backup_and_restore\calls-20200421011403.xml
\sms_backup_and_restore\sms-20200421011403.xml
\super_backup_and_restore\sms\sms_20200421012301.x ml
\super_backup_and_restore\logs\calllogs_2020042101 2328.xml

Now what?
o How can we best view/edit these SMS XML files on Windows?

Obvious I doubleclicked on them, which brought up the XML tagged results
in Windows Internet Explorer (of all things). Obviously I googled and
installed what seems to be the canonical XML freeware editor, from
Microsoft...
o *XML Notepad 2007*
https://www.microsoft.com/en-us/download/details.aspx?id=7973
Name: XmlNotepad.msi
Size: 1917440 bytes (1872 KiB)
SHA256: 7420A936C167ACAFDC9421181B579FE8ECFF6D43937EDCEF93 E2A1321F8141FF

Unfortunately, it required more stuff from Microsoft...
o .NET Framework 3.5
https://dotnet.microsoft.com/download/dotnet-framework/net35-sp1
Name: dotnetfx35.exe
Size: 242743296 bytes (231 MiB)
SHA256: 0582515BDE321E072F8673E829E175ED2E7A53E803127C5025 3AF76528E66BC1
Which, when clicked, _still_ tried to download more stuff from the net.

Finally, when I was able to read the XML file, the question may have
been partially mooted (mootified?) simply because the contents the
backup contained are rather uninspiring.

Nonetheless, the question arises as to what's a good free Windows XML
editor?
And, why do these freeware SMS backup programs choose XML format anyway?
https://i.postimg.cc/L5WsCrNq/xml01.jpg

OK, so I seen in the question a mention of "SMS Backup & Restore",
which implies someone wants to make a storage format for their works,
one which can be parsed later using one of the available parsers.
You can prepare "databases" if you want, as XML has name:value pairs.
If they instead used a database format, it likely wouldn't be
crossplatform, and the people on some platform, would feel "ignored".

It doesn't necessarily suggest that people go around editing
the content of the files. If it's for backup and restore.

Perhaps a customer would like a "conversion" process, for converting
the payload section of the backup, into some other format. That
can be done with text processing languages and/or scripts. PERL
being an example.

If the bog-standard XML files need to be "pretty", a web site
like jsbeautifier.org loads some javascript in the browser
which does *local* processing of presented pasted materials.
The materials are not sent to the website for server processing.
Just the browser does the transformation. This would add things
like indentation to an improperly indented XML. If the damage
is severe enough (maybe no line endings), the javascript isn't
clever enough to resolve all issues of that type. But it can
improve the appearance, if you don't like what you see.

If I need to edit an XML for VirtualBox or VPC2007 or the like,
I just use Notepad for the couple lines needing modification.

Paul

There are SMS converters out there that will reformat the messages to whatever
host email app is going to view (or import) them. Google is your friend here!

Otherwise, XML parsing gets complicated depending on what results you want and
so forth. Thus, an SMS conversion utility is the way to go. Chances are, your
Windows email app can import directly from your device!

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

In response to what Paul wrote :

OK, so I seen in the question a mention of "SMS Backup & Restore",
which implies someone wants to make a storage format for their works,
one which can be parsed later using one of the available parsers.

Hi Paul,

Thanks for explaining why they use XML format for SMS/MMS backup.
o *My hope is to see images from MMS messages, in the Windows XML editor.*

Regarding why these MMS/SMS backup programs chose XML as their storage
format, I think you're almost certainly correct - as it's a standard
non-proprietary cross-platform 'storage format' that can be easily parsed.

Bear in mind what I was _really_ after, were the MMS pictures, since the
photos sent to me by my kids and grandkids and relatives are the only
things I really care about in SMS/MMS archives.

To be clear, I _already_ autoarchive those photos outside of the MMS
message in which it was contained (the PulseSMS freeware app has a setting
that does just that) - but still - if you're gonna archive MMS/SMS
messages, then I was hoping the _photos_ were inside that XML archive.

When I said the results in Microsoft XML Notepad 2007 were "uninspiring",
what I was _hoping_ to see inside the XML archives in the Windows XML
editor, were those MMS photos, but I didn't see them (I was expecting a
mime-encoded inclusion, for example).

I _still_ don't know if those MMS photos are inside the archive or not, but
if I read the blurb on the tools, they "claim" to archive MMS messages (but
they don't specifically mention the photos).

https://play.google.com/store/apps/details?id=com.riteshsahu.SMSBackupRestore
"SMS Backup & Restore is a simple Android app that backs up and
restores your phone's SMS and *MMS* messages and call logs."
"Backup SMS (text) messages, *MMS* and call logs in XML format."

https://play.google.com/store/apps/details?id=com.idea.backup.smscontacts
"READ YOUR TEXT MESSAGES (SMS OR *MMS*)/EDIT YOUR TEXT MESSAGES
(SMS OR *MMS*)
These permissions are used to backup & restore your SMS"

My main reason for wanting the XML editor was to "see" those MMS images!

In short, I was "hoping" the Windows XML editor would display the MMS
images, but, so far, I don't know if MMS images are even there or not.
--
When testing software for the first time, basic confusion often results.

Arlen Holder wrote:
In response to what Paul wrote :

OK, so I seen in the question a mention of "SMS Backup & Restore",
which implies someone wants to make a storage format for their works,
one which can be parsed later using one of the available parsers.

Hi Paul,

Thanks for explaining why they use XML format for SMS/MMS backup.
o *My hope is to see images from MMS messages, in the Windows XML editor.*

Regarding why these MMS/SMS backup programs chose XML as their storage
format, I think you're almost certainly correct - as it's a standard
non-proprietary cross-platform 'storage format' that can be easily parsed.

Bear in mind what I was _really_ after, were the MMS pictures, since the
photos sent to me by my kids and grandkids and relatives are the only
things I really care about in SMS/MMS archives.

To be clear, I _already_ autoarchive those photos outside of the MMS
message in which it was contained (the PulseSMS freeware app has a setting
that does just that) - but still - if you're gonna archive MMS/SMS
messages, then I was hoping the _photos_ were inside that XML archive.

When I said the results in Microsoft XML Notepad 2007 were
"uninspiring", what I was _hoping_ to see inside the XML archives in the
Windows XML
editor, were those MMS photos, but I didn't see them (I was expecting a
mime-encoded inclusion, for example).
I _still_ don't know if those MMS photos are inside the archive or not, but
if I read the blurb on the tools, they "claim" to archive MMS messages (but
they don't specifically mention the photos).

https://play.google.com/store/apps/details?id=com.riteshsahu.SMSBackupRestore

"SMS Backup & Restore is a simple Android app that backs up and
restores your phone's SMS and *MMS* messages and call logs."
"Backup SMS (text) messages, *MMS* and call logs in XML format."

https://play.google.com/store/apps/details?id=com.idea.backup.smscontacts
"READ YOUR TEXT MESSAGES (SMS OR *MMS*)/EDIT YOUR TEXT MESSAGES
(SMS OR *MMS*)
These permissions are used to backup & restore your SMS"

My main reason for wanting the XML editor was to "see" those MMS images!

In short, I was "hoping" the Windows XML editor would display the MMS
images, but, so far, I don't know if MMS images are even there or not.

If an image was present, it must take space. Storage space.
Have a look around for something suspiciously big looking
inside the set of files.

If a provider somehow provides a cloud service, and only
a URL inside the XML files points to a file stored elsewhere,
then you have your answer as to where your picture went.
It could be an Evil Cloud got it.

Paul

In response to what Paul wrote :

If an image was present, it must take space. Storage space.
Have a look around for something suspiciously big looking
inside the set of files.

Hi Paul,
You're maybe on to something with respect to size...

The interesting thing is that both apps were used to back up the SMS/MMS
but one app backed up ten times as many SMS "bits" as did the other app:
o SMS Backup & Restore SMS log = 384MB
o Super Backup SMS log = 335KB
https://i.postimg.cc/dtDwkn3V/xml02.jpg

That same app backed up only twice as many bits of the call log:
o SMS Backup & Restore call log = 64KB
o Super Backup call log = 23KB
https://i.postimg.cc/MpdL7JLk/xml03.jpg

If a provider somehow provides a cloud service, and only
a URL inside the XML files points to a file stored elsewhere,
then you have your answer as to where your picture went.
It could be an Evil Cloud got it.

If they're both supposedly of the same SMS/MMS texts, there's a ten-fold
size difference, which implies the pictures might be the difference.

Maybe there's a reference link to the MMS pictures; or maybe one is just
more efficient at their storage format than the other; or, maybe one is
backing up more stuff than is the other... or ...

This is kind of why I wanted a good solid XML Editor/Viewer on Windows.
--
The first time we look at such things, the results are confusing.

Arlen Holder wrote:
In response to what Paul wrote :

If an image was present, it must take space. Storage space.
Have a look around for something suspiciously big looking
inside the set of files.

Hi Paul,
You're maybe on to something with respect to size...

The interesting thing is that both apps were used to back up the SMS/MMS
but one app backed up ten times as many SMS "bits" as did the other app:
o SMS Backup & Restore SMS log = 384MB
o Super Backup SMS log = 335KB
https://i.postimg.cc/dtDwkn3V/xml02.jpg

That same app backed up only twice as many bits of the call log:
o SMS Backup & Restore call log = 64KB
o Super Backup call log = 23KB
https://i.postimg.cc/MpdL7JLk/xml03.jpg

If a provider somehow provides a cloud service, and only
a URL inside the XML files points to a file stored elsewhere,
then you have your answer as to where your picture went.
It could be an Evil Cloud got it.

If they're both supposedly of the same SMS/MMS texts, there's a ten-fold
size difference, which implies the pictures might be the difference.

Maybe there's a reference link to the MMS pictures; or maybe one is just
more efficient at their storage format than the other; or, maybe one is
backing up more stuff than is the other... or ...
This is kind of why I wanted a good solid XML Editor/Viewer on Windows.

If you have a 384MB file of unknown type, you can pop it into HxD for a look.

https://mh-nexus.de/en/hxd/

There's all sorts of things they could do to it to obfuscate.

Using the hex editor first, is just to see if it's binary before
throwing it into a text editor.

Paul

In response to what Paul wrote :

If you have a 384MB file of unknown type, you can pop it into HxD for a look.

https://mh-nexus.de/en/hxd/

Hi Paul,

Thanks for the hex editor suggestion.

I popped the XML file into hxd which shows pretty clearly there is ASCII
and binary, where the binary is surrounded by partsxxx/parts tags in
some instances.
https://i.postimg.cc/26LJtdmC/xml04.jpg

It "could" be text plus images, where nothing I saw didn't indicate that to
be the case, but of course, I'm reading hex code to determine that.
https://i.postimg.cc/kXLV3qx9/xml05.jpg

I was hoping a good XML editor would parse out the photos.
o Maybe I just need a _better_ XML editor for Windows?

However, one slightly indirect option to figure out if the archive contains
images is to delete all the SMS texts on the phone and then try to restore
them, which would be a pain, but it would definitively answer the question
of whether the backed up XML archives contain MMS images.

But that's why I asked for an XML editor to read the XML archive file!
o I'm assuming a good XML editor would be able to parse the XML file.
--
There are so many ways to back up Android to Windows that it's confusing.

Arlen Holder wrote:
In response to what Paul wrote :

If you have a 384MB file of unknown type, you can pop it into HxD for
a look.

https://mh-nexus.de/en/hxd/

Hi Paul,

Thanks for the hex editor suggestion.

I popped the XML file into hxd which shows pretty clearly there is ASCII
and binary, where the binary is surrounded by partsxxx/parts tags in
some instances. https://i.postimg.cc/26LJtdmC/xml04.jpg

It "could" be text plus images, where nothing I saw didn't indicate that to
be the case, but of course, I'm reading hex code to determine that.
https://i.postimg.cc/kXLV3qx9/xml05.jpg

I was hoping a good XML editor would parse out the photos.
o Maybe I just need a _better_ XML editor for Windows?

However, one slightly indirect option to figure out if the archive contains
images is to delete all the SMS texts on the phone and then try to restore
them, which would be a pain, but it would definitively answer the question
of whether the backed up XML archives contain MMS images.

But that's why I asked for an XML editor to read the XML archive file! o
I'm assuming a good XML editor would be able to parse the XML file.

The stuff before the /parts is BASE64 or ASCII85.

Converting it from the textual encoding evident in your picture,
to its original binary form, that wouldn't work well in a text editor.

Should an "editor" recognize every multimedia type in existence,
like the 500+ things the Linux "file" command recognizes ? Once the
ASCII85 is converted back to binary format, now we'd have to recognize
what it was by signature.

I'm not even sure that XML is intended for this kind of encapsulation.
Normally the XML files I've seen, they contain configuration information,
single lines with filenames or the like. To pour binary into the file
in a less efficient BASE64 or ASCII85 format, seems a bit on the silly side.
Maybe it succeeds at making the result "portable".

An editor that in any way thought it was dealing with text, would
suffer from the "Notepad problem". Where the average text editor
designer, cannot seem to handle memory management worth a damn,
and there's always an artificially low limit to the file size.
Currently on the best of days now, Notepad is still less than
around 1GB or so. At least Notepad (on Windows 10), doesn't
suck like it used to. You can do find and replace now, and it
actually works.

Paul

In response to what Paul wrote :

The stuff before the /parts is BASE64 or ASCII85.

Hi Paul,
https://i.postimg.cc/wj0n4P9D/xml06.jpg

*PLAN A:*
Thanks for your helpful advice on the fact I'd need a pretty high end XML
editor that would be able to figure out it's images that are encoded in the
XML backup file.

I think the evidence points to the fact that it's highly likely pictures
from MMS _are_ encoded in that XML file, where PLAN A was that I was hoping
to find an XML Editor on Windows that would prove that to be the case.

Converting it from the textual encoding evident in your picture,
to its original binary form, that wouldn't work well in a text editor.

*PLAN B:*
I decided on PLAN B, which was restore the XML file but use a _different_
SMS app to restore it to so I could see if the pictures were also restored.
https://i.postimg.cc/wj0n4P9D/xml06.jpg

The restore procedure is interestingly unexpected:
1. On Android, I pressed the RESTORE button in "SMS Backup & Restore"
2. It asked to be set to the default SMS app temporarily.
3. It gave the option to "Restore pictures, media, & group messages (MMS)".
4. Once it finished, it said to choose the "real" SMS app as the default.
5. I installed a different (new) SMS app to make the default SMS app.
6. Once I set it to the default SMS app, the photos showed up inside it.

In summary, my PLAN A was to try to "edit" or "view" the XML backup of my
SMS/MMS texts on Windows (where that XML backup almost certainly contains
binary "images" that were sent to me).

Once I gave up on finding a good XML editor that will show the embedded
images, I simply restored the backup, where that restoration process
"appears" to have brought back the images that were in my MMS messages.

There's a bit of a doubt because I never deleted the images from the third
SMS app, but I'm gonna run with this theory as I was only testing the
software to help others who asked for a good freeware Android SMS/MMS
backup to Windows.

Given the resulting XML file is ten times larger with one backup program
over the other, my recommendation, moving forward, is:
o *SMS Backup & Restore*, by SyncTech Pty Ltd
https://play.google.com/store/apps/details?id=com.riteshsahu.SMSBackupRestore
"backs up and restores your phone's SMS and MMS messages and call logs."

Thanks for your kind help and advice, where I think I'll just give up on
the XML editor unless someone suggests one that will work with embedded
images in the XML file.
--
The beauty of helping others on Usenet is we all learn more together.

"Paul" wrote

| I'm not even sure that XML is intended for this kind of encapsulation.

It won't matter. XML is bloated, overused crap with one
advantage: You can mark the beginning and end of data
uniquely. It's really just customizable HTML. (Thus the X,
for extensible.) Like JSON, it's a pain in the neck and gross
overkill in most cases. Both are more fashion than tool.

But the format does make order extensible. So there's no
reason it can't hold Base64. HTML and MIME both store it
just fine. Personally I've never seen a text message package
so I have no idea whether it *does* hold Base64.

"Paul" wrote

I'm not even sure that XML is intended for this kind of encapsulation.

It won't matter. XML is bloated, overused crap with one
advantage: You can mark the beginning and end of data
uniquely. It's really just customizable HTML. (Thus the X,
for extensible.) Like JSON, it's a pain in the neck and gross
overkill in most cases. Both are more fashion than tool.

But the format does make order extensible. So there's no
reason it can't hold Base64. HTML and MIME both store it
just fine. Personally I've never seen a text message package
so I have no idea whether it *does* hold Base64.

Base64 IS plain text. The problem with using it in email is, depending on how
the body text is converted, character case may be lost where all UCase becomes
LCase. Best to convert B64 to Hex for email use, IMO!

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

"GS" wrote

| But the format does make order extensible. So there's no
| reason it can't hold Base64. HTML and MIME both store it
| just fine. Personally I've never seen a text message package
| so I have no idea whether it *does* hold Base64.
|
| Base64 IS plain text. The problem with using it in email is, depending on
how
| the body text is converted, character case may be lost where all UCase
becomes
| LCase. Best to convert B64 to Hex for email use, IMO!
|
I meant I've never seen the actual content of a text
message. SMS. Email and HTML and Base64 are plain
text, yes. I only meant that their formatting allows Base64
data to be stored easily. Multipart MIME format and "data
uri" formatting in HTML make it simple with no risk of
mixup. It can also be simple in XML:
Data64 ....any length text here.../Data64

In other words, they all have protocols for storing Base64
data that can be identified as Base64.

I don't know what you mean about converting Base64
to hex. Binary? The whole point of Base64 is that HTML
and email can't have binary data. If the Base64
gets ucased then there's something wrong with the
email structure.

"GS" wrote

But the format does make order extensible. So there's no
reason it can't hold Base64. HTML and MIME both store it
just fine. Personally I've never seen a text message package
so I have no idea whether it *does* hold Base64.

Base64 IS plain text. The problem with using it in email is, depending on
how the body text is converted, character case may be lost where all UCase
becomes LCase. Best to convert B64 to Hex for email use, IMO!

I meant I've never seen the actual content of a text
message. SMS. Email and HTML and Base64 are plain
text, yes. I only meant that their formatting allows Base64
data to be stored easily. Multipart MIME format and "data
uri" formatting in HTML make it simple with no risk of
mixup. It can also be simple in XML:
Data64 ....any length text here.../Data64

In other words, they all have protocols for storing Base64
data that can be identified as Base64.

I don't know what you mean about converting Base64
to hex. Binary? The whole point of Base64 is that HTML
and email can't have binary data. If the Base64
gets ucased then there's something wrong with the
email structure.

I've had instances where writing B64 email body text with VB displays correctly
in the new msg window, but arrives w/all UCase converted to LCase. My solution
to preserve the original B64 is to convert each character to its Hex equivalent
as follows:

Garry
R2Fycnk=
52324679636E6B3D

...which all are plain text strings. Otherwise the B64 string arrives as
"r2fycnk="! The reason for the need is because the B64 string is the result of
encrypting a license profile and outputting the result (byte data) in B64 so it
behaves like a string when being processed as a plain text file.

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

"GS" wrote

| Garry
| R2Fycnk=
| 52324679636E6B3D
|
| ..which all are plain text strings. Otherwise the B64 string arrives as
| "r2fycnk="! The reason for the need is because the B64 string is the
result of
| encrypting a license profile and outputting the result (byte data) in B64
so it
| behaves like a string when being processed as a plain text file.
|
I see what you mean. The problem there is that you're
sending it in the plain text section. If you want it treated
as Base64 it needs to be demarcated. Though it still shouldn't
lcase. Maybe you're using spellcheck? Your method is probably
best for a short string. If you want to actually send base64 you
need to use multi-part format and do it like so:

--UNIQUE_BOUNDARY_STRING_HERE
Content-Type: image/jpeg;
name="pic.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="pic.jpg"

Then you put the base64, followed by another
boundary marker. Otherwise there's no way for
the client to know you intend it to be interpreted
as base64.

You can see samples if you look at an email with
attachments.