SH3D and JAR files are just ZIP files, compressed or not.

The main entry of a SH3D file is named [font=courier new]Home[/font] and contains a Java serialization of the Home class instance that describes the designed home. In old versions, this entry had to be the first one in a SH3D file.
From version 5.3, there’s also a copy of the designed home in a new entry named [font=courier new]Home.xml[/font] which respects SweetHome3D.dtd. This XML entry was added to be able to read and save SH3D files in JavaScript and other environments. This entry is read in priority when a SH3D file is opened and the [font=courier new]Home[/font] is stilll saved for compatibility with previous versions of Sweet Home 3D.

During a few more versions, I foresee to save [font=courier new]Home[/font] and [font=courier new]Home.xml[/font] in a SH3D file even if they contain similar data. This is to ensure a smooth transition with future files where [font=courier new]Home[/font] entry won’t be saved anymore. The extension of these future files will be .sh3x which is already associated with Sweet Home 3D application since version 5.3 too. Future versions will also be able to read SH3D files without a [font=courier new]Home.xml[/font] entry as long as Java deserialization will be possible with [font=courier new]Home[/font] entry.

The other entries of a SH3D file are the optional entry named [font=courier new]ContentDigests[/font] (added in version 4.4) which contains digests of home data to help repair a corrupted SH3D file, and numbered entries that contain images and 3D models used by a home.