You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of iOS 15.4, an audio message doesn't have a "mime_type" value("mime_type" column is empty), but it does have a "uti" value which is "com.apple.coreaudio-format".
Suggestion: use "uti" column to determine whether an attachment is really an attachment or an audio message, like this:
Line 254 may replace not only the '~' characters at the beginning of path strings, but also those in the original filenames at the end of it, resulting in errors when copying attachments
Suggestion: It might be better to ensure that only the first '~' character is replaced:
return format!("{}{}", &home(), &path[1..]);
"chat_recoverable_message_join" table did not exist until iOS 16(at least not for iOS 15.4), but iMessage reply feature is supported since iOS 14.
(SELECT COUNT(*) FROM {MESSAGE_ATTACHMENT_JOIN} a WHERE m.ROWID = a.message_id) as num_attachments,
(SELECT NULL) as deleted_from,
(SELECT 0) as num_replies
FROM
message as m
LEFT JOIN {CHAT_MESSAGE_JOIN} as c ON m.ROWID = c.message_id
ORDER BY
m.date;
"
)).map_err(TableError::Messages)?)
This fallback SQL ignores the "message" table altogether, causing html outputs of iOS 14/15 backup not to show any reply signs at all.
Suggestion: adding another fallback SQL statement to the function below(and also the "stream_rows" function under it) would be good:
.unwrap_or(db.prepare(&format!(
"SELECT
*,
c.chat_id,
(SELECT COUNT(*) FROM {MESSAGE_ATTACHMENT_JOIN} a WHERE m.ROWID = a.message_id) as num_attachments,
(SELECT NULL) as deleted_from,
(SELECT COUNT(*) FROM {MESSAGE} m2 WHERE m2.thread_originator_guid = m.guid) as num_replies
FROM
message as m
LEFT JOIN {CHAT_MESSAGE_JOIN} as c ON m.ROWID = c.message_id
ORDER BY
m.date;
"
))
"href" attributes of anchors for attachments may not work if a relative path to the backup is specified on the command line, causing attachments failed to display or be downloaded in html pages
Suggestion: consider removing "file://" substring. Browsers can handle it well.
A pure suggestion: It's very easy to get it running directly on jailbroken iOS devices. The logic is literally the same as on Mac's, just change the path to the database. I've made a fork and managed to get it working flawlessly on my iPhone: imessage-exporter for iOS
It would be nice if you make it officially supported!
This discussion was converted from issue #150 on August 04, 2023 19:00.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
imessage-exporter/imessage-database/src/tables/attachment.rs
Lines 100 to 119 in c73bc4d
As of iOS 15.4, an audio message doesn't have a "mime_type" value("mime_type" column is empty), but it does have a "uti" value which is "com.apple.coreaudio-format".
Suggestion: use "uti" column to determine whether an attachment is really an attachment or an audio message, like this:
imessage-exporter/imessage-database/src/tables/attachment.rs
Lines 251 to 257 in c73bc4d
Line 254 may replace not only the '~' characters at the beginning of path strings, but also those in the original filenames at the end of it, resulting in errors when copying attachments
Suggestion: It might be better to ensure that only the first '~' character is replaced:
imessage-exporter/imessage-database/src/tables/table.rs
Line 79 in c73bc4d
imessage-exporter/imessage-database/src/tables/messages.rs
Lines 151 to 164 in c73bc4d
This fallback SQL ignores the "message" table altogether, causing html outputs of iOS 14/15 backup not to show any reply signs at all.
Suggestion: adding another fallback SQL statement to the function below(and also the "stream_rows" function under it) would be good:
"href" attributes of anchors for attachments may not work if a relative path to the backup is specified on the command line, causing attachments failed to display or be downloaded in html pages
imessage-exporter/imessage-exporter/src/exporters/html.rs
Lines 439 to 451 in c73bc4d
Suggestion: consider removing "file://" substring. Browsers can handle it well.
A pure suggestion: It's very easy to get it running directly on jailbroken iOS devices. The logic is literally the same as on Mac's, just change the path to the database. I've made a fork and managed to get it working flawlessly on my iPhone:
imessage-exporter for iOS
It would be nice if you make it officially supported!
Beta Was this translation helpful? Give feedback.
All reactions