Skończyłem pracę nad skryptem. Zaraz go omówię, ale najpierw wytłumaczę mój problem i prawdopodobnie lepsze jego rozwiązanie (Dla mnie już było za późno na nie, bo straciłem archiwum na telefonie, ale może ktoś nie powtórzy moich błędów).
Moje archiwum było takie pokiełbaszone, ponieważ powstawało w niejednolity sposób. Najpierw pojedynczo przenosiłem wiadomości z inbox i sent items do saved messages z poziomu telefonu i te wiadomości były w miarę ok. Gdy zaczęło przybywać ich zbyt dużo, zacząłem je przenosić z poziomu PC Suite i to był początek problemów. Potem przyszedł wymuszony update do Nokia Suite i jeszcze bardziej się wszystko pomieszało. Na końcu odkryłem, że telefon umie grupowo przerzucać zawartość katalogów (Mark all / Move marked) i archiwizowałem je z powrotem poprawnie.
W tym momencie miałem pokiełbaszone archiwum, ale jeszcze nie było strat. Drugim błędem było użycie OxyCube, który "kopiował" wiadomości w destrukcyjny sposób (a do tego nie wszystkie widział). W efekcie tego straciłem kilkadziesiąt wiadomości. Prawdopodobnie należało zamiast tego zrobić backup z poziomu telefonu, a zapisany tak pojedynczy plik na karcie rozbebeszać na PC. Zachowałbym wtedy archiwum na telefonie, a być może plik z backupem byłby bardziej poprawny, niż to, co zrzucił OxyCube (to tylko przypuszczenie na podstawie faktu, że telefon widział WSZYSTKIE wiadomości i to poprawnie).
Skrypt:Czyta on katalog plików z SMS zrzuconych przez OxyCube i eksportuje do jednego pliku .txt wszystkie wiadomości w formacie:
1. Numer porządkowy
2. Numer nadawcy/odbiorcy
3. Nazwa nadawcy/odbiorcy (może być inna niż na telefonie)
4. Data, godzina
5. Numer części SMS, liczba części SMS
6. Przychodzący/wychodzący
7. Treść
Wiadomości są posortowane chronologicznie.
Skrypt jest pisany w MATLABie. Odpala się go od skryptu start.m; pozostałe m-pliki to pomocnicze funkcje. Komentowałem swój kod, więc jak ktoś zna MATLABa, to szybko załapie o co chodzi, a jak nie umie, to niech się nauczy.

Nie rozgryzałem całego standardu (załączam potrzebną dokumentację - najważniejszy jest rozdział 9.2), tylko heurystycznie dochodziłem co jest gdzie. Część informacji się dubluje, więc używałem tych, które było wygodniej lub były bardziej niezawodne. Kod mam dosyć toporny, ale nie chciało mi się go szlifować do jednorazowego użytku. Część SMSów miałem poważnie uszkodzonych, więc musiałem je naprawiać. Kod za to odpowiedzialny zostawiłem, ale zakomentowałem.
Struktura pliku wiadomości:Tu zaczyna się Meksyk z trzech powodów. 1. Nokia olewa standardy i w dziki sposób zapisuje te wiadomości. 2. PC Suite przy przenoszeniu zniszczył część informacji, które musiałem jakoś odzyskiwać. 3. Nie czytałem dogłębnie standardu, więc nawet to, co jest zgodne, ja osiągam po omacku. Dość powiedzieć, że robiłem skrypty parsujące pliki z SMSami do innej, starszej Nokii i jeszcze starszego Siemensa i mimo doświadczenia, uporanie się z tym problemem było bez porównania trudniejsze.
Opiszę po kolei co skąd wydobyć, zaczynając od rzeczy najprostszych.
1. Data i godzina nadejścia/wysłania: po nazwie pliku - znaki 9-16 (licząc od 1) to zapisane heksem liczba sekund od 1.1.1980 (a nie 1970 jak w Unixach)
2. Wychodzący/przychodzący: po nazwie pliku - znak 27 == 2 -> wychodzący; znak 27 == 5 -> przychodzący
3. Numer części (dla podzielonych na fragmenty; dla pojedynczych jest 0 lub 1): po nazwie pliku - znak 37
4. Liczba części (dla podzielonych na fragmenty; dla pojedynczych jest 0 lub 1): po nazwie pliku - znak 35
5. Numer nadawcy/odbiorcy: zapisany pod offsetem 0x5E z kodowaniem UTF16. Czasami z +48, czasami bez. Czasami nie jest to numer, a nazwa nadawcy, który u operatora sobie załatwił takie podpisywanie (np. miałem SMSy od "Netia" albo "Play"). Dla wychodzących wiadomości rozgłoszeniowych (wielu odbiorców) są tam same 0. Wówczas wszyscy odbiorcy są zapisani (razem z nazwami) po treści "drugiego tekstu".
6. "Pierwszy tekst": Treść wiadomości kodowana septetami lub w UTF16 (polskie krzaczki).
-Dla kodowania septetami zaczyna się normalnie (gdy nadawca ma standardowy numer 9-cyfrowy) pod offsetem 0xC2 (wychodzące) lub 0xC3 (przychodzące) + 1 bit przesunięcia w obu przypadkach. Długość jest zapisana pod offsetem 0xC1 (wychodzące) lub 0xC2 (przychodzące). Maksymalnie wynosi 160 znaków.
-Dla kodowania UTF16 zaczyna się pod offsetem 0xC9. Maksymalnie wynosi 67 znaków. Jest terminowany zerem.
"Pierwszy tekst" występuje zawsze, ale miałem z nim sporo problemów. Niestandardowi nadawcy mieli poprzesuwane treści, część wiadomości miała uszkodzone dwa pierwsze znaki, część znaków była źle kodowana (w tym tak pospolite, jak: ^ _ ] ). Wówczas ratowałem się "drugim tekstem".
6. "Drugi tekst": Treść wiadomości kodowana zawsze w UTF16 niezależnie, czy były krzaczki, czy nie. Adres początku to wartość spod offsetu 0x7 + 0xF8. Treść jest terminowana znakiem 0x0004 (wychodzace) lub 0x0002 (przychodzące). Maksymalnie wynosi 110 znaków, więc jeśli w "pierwszym tekście" mieliśmy kodowanie UTF16, a wiadomość była wieloczęściowa, "drugi tekst" zawiera całą pierwszą i fragment drugiej wiadomości. "Drugi tekst" nigdy nie występuje w części drugiej i kolejnych w SMS-ach wieloczęściowych.
Link do kodu:
- Code: Select all
Please Login or Register, to see this Content