witam,
pobieram załączniki z serwera pocztowego netart który został wysłany przez bzwbk, technika pobierania php & imap_*
po odebraniu załącznika jest 2 razy więcej linijek niż powinno być, format pliku jest rozwalony :/ gdzieś po drodze widocznie jest jakiś znak który powoduje załamanie lini
jak zaloguję się na ich panel i pobiorę załącznik to jest ok, to samo jak klient poczty pobierze mi wiadomość (evolution) to też jest ok.
i teraz najlepsze,
problem jest tyko przy pobieraniu z serwerów netart, z wp, o2 czy az.pl wszytko jest ok, załącznik pobrany poprzez skrypt ma prawidłowy format i wygląd
ktoś wie może co piszczy w trawie ?
W dniu 2013-04-19 20:51, Sylwester Kondracki pisze:
witam,
pobieram załączniki z serwera pocztowego netart który został wysłany przez bzwbk, technika pobierania php & imap_*
po odebraniu załącznika jest 2 razy więcej linijek niż powinno być, format pliku jest rozwalony :/ gdzieś po drodze widocznie jest jakiś znak który powoduje załamanie lini
jak zaloguję się na ich panel i pobiorę załącznik to jest ok, to samo jak klient poczty pobierze mi wiadomość (evolution) to też jest ok.
i teraz najlepsze,
problem jest tyko przy pobieraniu z serwerów netart, z wp, o2 czy az.pl wszytko jest ok, załącznik pobrany poprzez skrypt ma prawidłowy format i wygląd
ktoś wie może co piszczy w trawie ?
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Nie wiem jaki bank, ale milenium pobieram z netart i jest ok.
W dniu 19.04.2013 20:51, Sylwester Kondracki napisał(a):
witam,
Witam,
pobieram załączniki z serwera pocztowego netart który został wysłany przez bzwbk, technika pobierania php & imap_*
po odebraniu załącznika jest 2 razy więcej linijek niż powinno być, format pliku jest rozwalony gdzieś po drodze widocznie jest jakiś znak który powoduje załamanie lini
jak zaloguję się na ich panel i pobiorę załącznik to jest ok, to samo jak klient poczty pobierze mi wiadomość (evolution) to też jest ok.
i teraz najlepsze,
problem jest tyko przy pobieraniu z serwerów netart, z wp, o2 czy az.pl wszytko jest ok, załącznik pobrany poprzez skrypt ma prawidłowy format i wygląd
ktoś wie może co piszczy w trawie ?
Czy ten plik nie koduje czasem nowych wierszy dosowo czyli \r\n? Upewnij się co do tego.
Dnia 2013-04-19, pią o godzinie 23:17 +0200, Tomasz Chiliński pisze:
W dniu 19.04.2013 20:51, Sylwester Kondracki napisał(a):
witam,
Witam,
pobieram załączniki z serwera pocztowego netart który został wysłany przez bzwbk, technika pobierania php & imap_*
po odebraniu załącznika jest 2 razy więcej linijek niż powinno być, format pliku jest rozwalony gdzieś po drodze widocznie jest jakiś znak który powoduje załamanie lini
jak zaloguję się na ich panel i pobiorę załącznik to jest ok, to samo jak klient poczty pobierze mi wiadomość (evolution) to też jest ok.
i teraz najlepsze,
problem jest tyko przy pobieraniu z serwerów netart, z wp, o2 czy az.pl wszytko jest ok, załącznik pobrany poprzez skrypt ma prawidłowy format i wygląd
ktoś wie może co piszczy w trawie ?
Czy ten plik nie koduje czasem nowych wierszy dosowo czyli \r\n? Upewnij się co do tego.
więc tak :
z serwerem poczty muszę się łączyć w ten sposób :
imap_open("{mojadomena.pl:995/pop3/ssl/novalidate-cert}INBOX",user,haselko);
próba innego sposobu nawiązania połączenia kończy się fiaskiem
część tablicy z wynikiem :
[1] => stdClass Object ( [type] => 0 [encoding] => 4 [ifsubtype] => 1 [subtype] => PLAIN [ifdescription] => 0 [ifid] => 0 [lines] => 35 [bytes] => 2240 [ifdisposition] => 1 [disposition] => ATTACHMENT [ifdparameters] => 1 [dparameters] => Array ( [0] => stdClass Object ( [attribute] => FILENAME [value] => wyciag.txt )
)
[ifparameters] => 1 [parameters] => Array ( [0] => stdClass Object ( [attribute] => NAME [value] => wyciag.txt )
[1] => stdClass Object ( [attribute] => CHARSET [value] => UTF-8 )
)
)
mamy info że lini jest 35, gdzie faktycznie w pliku (oryginalnym) jest ich 14
jest też zmiana pl, np. Ż -> =AF, Ś -> =8C , Ę -> =CA
następne ciekawe zjawisko, długość wiersza ma max 72 znaki potem jest =^M (jeżeli linia została złamana), lub tylko ^M jeżeli linia oryginalnie miała mniej niż 72 znaki
i takie coś jest tylko wtedy jak wyciąg przechodzi przez skrzynkę pocztową netart'u
załamanie linijek rozwiązanie $msg = str_replace("=\r\n","",$msg);
jest jeszcze jeden mały problem, 1 - skrypt nie oznacza mi na skrzynce netart że wiadomość została odczytana, 2 - pobiera wszystkie wiadomości , odczytanie i nieodczytane mimo że mam : $post = imap_search($mail,'UNSEEN');
W dniu 20 kwietnia 2013 08:36 użytkownik Sylwester Kondracki < sylwester.kondracki@gmail.com> napisał:
** Dnia 2013-04-19, pią o godzinie 23:17 +0200, Tomasz Chiliński pisze:
W dniu 19.04.2013 20:51, Sylwester Kondracki napisał(a):
witam,
Witam,
pobieram załączniki z serwera pocztowego netart który został wysłany przez bzwbk, technika pobierania php & imap_*
po odebraniu załącznika jest 2 razy więcej linijek niż powinno być, format pliku jest rozwalony gdzieś po drodze widocznie jest jakiś znak który powoduje załamanie lini
jak zaloguję się na ich panel i pobiorę załącznik to jest ok, to samo jak klient poczty pobierze mi wiadomość (evolution) to też jest ok.
i teraz najlepsze,
problem jest tyko przy pobieraniu z serwerów netart, z wp, o2 czy az.pl wszytko jest ok, załącznik pobrany poprzez skrypt ma prawidłowy format i wygląd
ktoś wie może co piszczy w trawie ?
Czy ten plik nie koduje czasem nowych wierszy dosowo czyli \r\n? Upewnij się co do tego.
więc tak :
z serwerem poczty muszę się łączyć w ten sposób :
imap_open("{mojadomena.pl:995/pop3/ssl/novalidate-cert}INBOXhttp://mojadomena.pl:995/pop3/ssl/novalidate-cert%7DINBOX ",user,haselko);
próba innego sposobu nawiązania połączenia kończy się fiaskiem
część tablicy z wynikiem :
[1] => stdClass Object ( [type] => 0 [encoding] => 4 [ifsubtype] => 1 [subtype] => PLAIN [ifdescription] => 0 [ifid] => 0 [lines] => 35 [bytes] => 2240 [ifdisposition] => 1 [disposition] => ATTACHMENT [ifdparameters] => 1 [dparameters] => Array ( [0] => stdClass Object ( [attribute] => FILENAME [value] => wyciag.txt ) ) [ifparameters] => 1 [parameters] => Array ( [0] => stdClass Object ( [attribute] => NAME [value] => wyciag.txt ) [1] => stdClass Object ( [attribute] => CHARSET [value] => UTF-8 ) ) )mamy info że lini jest 35, gdzie faktycznie w pliku (oryginalnym) jest ich 14
jest też zmiana pl, np. Ż -> =AF, Ś -> =8C , Ę -> =CA
następne ciekawe zjawisko, długość wiersza ma max 72 znaki potem jest =^M (jeżeli linia została złamana), lub tylko ^M jeżeli linia oryginalnie miała mniej niż 72 znaki
i takie coś jest tylko wtedy jak wyciąg przechodzi przez skrzynkę pocztową netart'u
W dniu 20.04.2013 09:35, Sylwester Kondracki napisał(a):
załamanie linijek rozwiązanie $msg = str_replace("=rn","",$msg);
jest jeszcze jeden mały problem, 1 - skrypt nie oznacza mi na skrzynce netart że wiadomość została odczytana, 2 - pobiera wszystkie wiadomości , odczytanie i nieodczytane mimo że mam : $post = imap_search($mail,'UNSEEN');
Możliwe, że serwer imap netartu załatwia oznaczenia przeczytania inną flagą niż Seen: imap_setflag_full($ih, $postid, "\Seen"); Może Alek przez przypadek przeczyta ten list i będzie miał jakąś sugestię odnośnie niezawodnego oznaczania postów przez imap jako przeczytane ;-)
W dniu 20.04.2013 11:04, Tomasz Chiliński napisał(a):
W dniu 20.04.2013 09:35, Sylwester Kondracki napisał(a): załamanie linijek rozwiązanie $msg = str_replace("=rn","",$msg);
A możesz pokazać jak wygląda fragment pliku w postaci binarnej? Kilka przykładowych wierszy...
Dnia 2013-04-20, sob o godzinie 11:04 +0200, Tomasz Chiliński pisze:
W dniu 20.04.2013 09:35, Sylwester Kondracki napisał(a):
załamanie linijek rozwiązanie $msg = str_replace("=rn","",$msg);
jest jeszcze jeden mały problem, 1 - skrypt nie oznacza mi na skrzynce netart że wiadomość została odczytana, 2 - pobiera wszystkie wiadomości , odczytanie i nieodczytane mimo że mam : $post = imap_search($mail,'UNSEEN');
Możliwe, że serwer imap netartu załatwia oznaczenia przeczytania inną flagą niż Seen: imap_setflag_full($ih, $postid, "\Seen"); Może Alek przez przypadek przeczyta ten list i będzie miał jakąś sugestię odnośnie niezawodnego oznaczania postów przez imap jako przeczytane ;-)
więc, skrypt oznacza na netart że wiadomość została już odczytana, i jest użyty ten sposób jak zrobiłeś w innych skryptach, przez Seen
ale pobiera mi wszystkie wiadomości za każdym razem, nie ma znaczenia czy wiadomość ma już status przeczytanej
W dniu 20.04.2013 11:26, Sylwester Kondracki napisał(a):
Dnia 2013-04-20, sob o godzinie 11:04 +0200, Tomasz Chiliński pisze:
W dniu 20.04.2013 09:35, Sylwester Kondracki napisał(a): załamanie linijek rozwiązanie $msg = str_replace("=rn","",$msg);
jest jeszcze jeden mały problem, 1 - skrypt nie oznacza mi na skrzynce netart że wiadomość została odczytana, 2 - pobiera wszystkie wiadomości , odczytanie i nieodczytane mimo że mam : $post = imap_search($mail,'UNSEEN');
Możliwe, że serwer imap netartu załatwia oznaczenia przeczytania inną flagą niż Seen: imap_setflag_full($ih, $postid, "\Seen"); Może Alek przez przypadek przeczyta ten list i będzie miał jakąś sugestię odnośnie niezawodnego oznaczania postów przez imap jako przeczytane ;-)
więc, skrypt oznacza na netart że wiadomość została już odczytana, i jest użyty ten sposób jak zrobiłeś w innych skryptach, przez Seen
ale pobiera mi wszystkie wiadomości za każdym razem, nie ma znaczenia czy wiadomość ma już status przeczytanej
Wypróbuj propozycję Alka tj. NOT SEEN.
On 04/20/2013 11:04 AM, Tomasz Chiliński wrote:
Możliwe, że serwer imap netartu załatwia oznaczenia przeczytania inną flagą niż Seen: imap_setflag_full($ih, $postid, "\Seen"); Może Alek przez przypadek przeczyta ten list i będzie miał jakąś sugestię odnośnie niezawodnego oznaczania postów przez imap jako przeczytane ;-)
Innym sposobem jest FETCH BODY[], zamiast BODY.PEEK[], ale nie wiem jak to się ma do tego modułu perla który tam używacie.
Jeśli ten moduł na debug protokołu możnaby sprawdzić co zwraca w PERMANENTFLAGS w odpowiedzi na komendę SELECT INBOX oraz jak w rzeczywistości wygląda komenda SEARCH.
Dnia 2013-04-20, sob o godzinie 11:32 +0200, A.L.E.C pisze:
On 04/20/2013 11:04 AM, Tomasz Chiliński wrote:
Możliwe, że serwer imap netartu załatwia oznaczenia przeczytania inną flagą niż Seen: imap_setflag_full($ih, $postid, "\Seen"); Może Alek przez przypadek przeczyta ten list i będzie miał jakąś sugestię odnośnie niezawodnego oznaczania postów przez imap jako przeczytane ;-)
Innym sposobem jest FETCH BODY[], zamiast BODY.PEEK[], ale nie wiem jak to się ma do tego modułu perla który tam używacie.
Jeśli ten moduł na debug protokołu możnaby sprawdzić co zwraca w PERMANENTFLAGS w odpowiedzi na komendę SELECT INBOX oraz jak w rzeczywistości wygląda komenda SEARCH.
pośpieszyłem się z info że skrypt nie oznacza wiadomości jako przeczytanej,
po dokładnym sprawdzeniu oznacza ją prawidłowo,
skrypt jest w php
ale , wyszukiwanie wiadomości nie przeczytanych jest tak zrobione :
$post = imap_search($mail,'UNSEEN');
niestety pobiera nam wszystkie wiadomości, przeczytane i nie przeczytane
On 04/20/2013 11:36 AM, Sylwester Kondracki wrote:
skrypt jest w php
aha
ale , wyszukiwanie wiadomości nie przeczytanych jest tak zrobione :
$post = imap_search($mail,'UNSEEN');
niestety pobiera nam wszystkie wiadomości, przeczytane i nie przeczytane
Można spróbować "NOT SEEN" zamiast "UNSEEN". A oprócz tego można sprawdzić flagi pobranej wiadomości, pewnie tutaj jest odpowiedź jak http://pl1.php.net/manual/en/function.imap-headerinfo.php.
Dnia 2013-04-20, sob o godzinie 11:46 +0200, A.L.E.C pisze:
On 04/20/2013 11:36 AM, Sylwester Kondracki wrote:
skrypt jest w php
aha
ale , wyszukiwanie wiadomości nie przeczytanych jest tak zrobione :
$post = imap_search($mail,'UNSEEN');
niestety pobiera nam wszystkie wiadomości, przeczytane i nie przeczytane
Można spróbować "NOT SEEN" zamiast "UNSEEN". A oprócz tego można sprawdzić flagi pobranej wiadomości, pewnie tutaj jest odpowiedź jak http://pl1.php.net/manual/en/function.imap-headerinfo.php.
problem rozwiązany, NOT SEEN zadziałało,
dzięki :D
W dniu 20.04.2013 11:51, Sylwester Kondracki napisał(a):
Dnia 2013-04-20, sob o godzinie 11:46 +0200, A.L.E.C pisze:
On 04/20/2013 11:36 AM, Sylwester Kondracki wrote: skrypt jest w php
aha
ale , wyszukiwanie wiadomości nie przeczytanych jest tak zrobione :
$post = imap_search($mail,'UNSEEN');
niestety pobiera nam wszystkie wiadomości, przeczytane i nie przeczytane
Można spróbować "NOT SEEN" zamiast "UNSEEN". A oprócz tego można sprawdzić flagi pobranej wiadomości, pewnie tutaj jest odpowiedź jak http://pl1.php.net/manual/en/function.imap-headerinfo.php [1].
problem rozwiązany, NOT SEEN zadziałało,
To jeśli NOT SEEN by działało z innymi serwerami pocztowymi to można byłoby przełączyć się na to domyślnie. Inni może potwierdzą, że im też działa NOT SEEN?
W dniu 20.04.2013 11:32, A.L.E.C napisał(a):
On 04/20/2013 11:04 AM, Tomasz Chiliński wrote: Możliwe, że serwer imap netartu załatwia oznaczenia przeczytania inną flagą niż Seen: imap_setflag_full($ih, $postid, "\Seen"); Może Alek przez przypadek przeczyta ten list i będzie miał jakąś sugestię odnośnie niezawodnego oznaczania postów przez imap jako przeczytane ;-)
Innym sposobem jest FETCH BODY[], zamiast BODY.PEEK[], ale nie wiem jak to się ma do tego modułu perla który tam używacie.
Nie używamy perla (z mego punktu widzenia za duże koszty utrzymywania tego typu rozwiązań wg mnie zwłaszcza, że potem debianowcy tego używają). Aktualnie robię to tak w php: imap_setflag_full($ih, $postid, "\Seen");
Jeśli ten moduł na debug protokołu możnaby sprawdzić co zwraca w PERMANENTFLAGS w odpowiedzi na komendę SELECT INBOX oraz jak w rzeczywistości wygląda komenda SEARCH.
Chodzi o to jakie feature-y protokołu imap obsługuje netart czy o coś innego?
On 04/20/2013 11:49 AM, Tomasz Chiliński wrote:
Jeśli ten moduł na debug protokołu możnaby sprawdzić co zwraca w PERMANENTFLAGS w odpowiedzi na komendę SELECT INBOX oraz jak w rzeczywistości wygląda komenda SEARCH.
Chodzi o to jakie feature-y protokołu imap obsługuje netart czy o coś innego?
Nie, to wszystko objęte jest podstawową wersją standardu, żadne rozszerzenia. No ale wygląda na błąd (może w PHP albo w netarcie), dlatego zaproponowałem trochę inne sposoby.
W dniu 20.04.2013 11:52, A.L.E.C napisał(a):
On 04/20/2013 11:49 AM, Tomasz Chiliński wrote:
Jeśli ten moduł na debug protokołu możnaby sprawdzić co zwraca w PERMANENTFLAGS w odpowiedzi na komendę SELECT INBOX oraz jak w rzeczywistości wygląda komenda SEARCH.
Chodzi o to jakie feature-y protokołu imap obsługuje netart czy o coś innego?
Nie, to wszystko objęte jest podstawową wersją standardu, żadne rozszerzenia. No ale wygląda na błąd (może w PHP albo w netarcie), dlatego zaproponowałem trochę inne sposoby.
Zobaczymy czy ludziom zadziała przez NOT SEEN na inny serwerach imap przez nich używanych (o ile komuś będzie chciało się o tym poinformować, albo w ogóle to sprawdzać na własną rękę).
Dnia 2013-04-20, sob o godzinie 11:55 +0200, Tomasz Chiliński pisze:
W dniu 20.04.2013 11:52, A.L.E.C napisał(a):
On 04/20/2013 11:49 AM, Tomasz Chiliński wrote:
Jeśli ten moduł na debug protokołu możnaby sprawdzić co zwraca w PERMANENTFLAGS w odpowiedzi na komendę SELECT INBOX oraz jak w rzeczywistości wygląda komenda SEARCH.
Chodzi o to jakie feature-y protokołu imap obsługuje netart czy o coś innego?
Nie, to wszystko objęte jest podstawową wersją standardu, żadne rozszerzenia. No ale wygląda na błąd (może w PHP albo w netarcie), dlatego zaproponowałem trochę inne sposoby.
Zobaczymy czy ludziom zadziała przez NOT SEEN na inny serwerach imap przez nich używanych (o ile komuś będzie chciało się o tym poinformować, albo w ogóle to sprawdzać na własną rękę).
dla serwerów pocztowych z az.pl musi byc UNSEEN przy NOT SEEN nie pobiera żadnych wiadomości
W dniu 20.04.2013 12:03, Sylwester Kondracki napisał(a):
Dnia 2013-04-20, sob o godzinie 11:55 +0200, Tomasz Chiliński pisze:
W dniu 20.04.2013 11:52, A.L.E.C napisał(a): On 04/20/2013 11:49 AM, Tomasz Chiliński wrote:
Jeśli ten moduł na debug protokołu możnaby sprawdzić co zwraca w PERMANENTFLAGS w odpowiedzi na komendę SELECT INBOX oraz jak w rzeczywistości wygląda komenda SEARCH.
Chodzi o to jakie feature-y protokołu imap obsługuje netart czy o coś innego?
Nie, to wszystko objęte jest podstawową wersją standardu, żadne rozszerzenia. No ale wygląda na błąd (może w PHP albo w netarcie), dlatego zaproponowałem trochę inne sposoby.
Zobaczymy czy ludziom zadziała przez NOT SEEN na inny serwerach imap przez nich używanych (o ile komuś będzie chciało się o tym poinformować, albo w ogóle to sprawdzać na własną rękę).
dla serwerów pocztowych z az.pl musi byc UNSEEN przy NOT SEEN nie pobiera żadnych wiadomości
To można byłoby wprowadzić ustawienie skryptu jakieś o nazwie powiedzmy cashimport/unseen_check_flag.
Dnia 2013-04-20, sob o godzinie 12:10 +0200, Tomasz Chiliński pisze:
W dniu 20.04.2013 12:03, Sylwester Kondracki napisał(a):
Dnia 2013-04-20, sob o godzinie 11:55 +0200, Tomasz Chiliński pisze:
W dniu 20.04.2013 11:52, A.L.E.C napisał(a): On 04/20/2013 11:49 AM, Tomasz Chiliński wrote:
Jeśli ten moduł na debug protokołu możnaby sprawdzić co zwraca w PERMANENTFLAGS w odpowiedzi na komendę SELECT INBOX oraz jak w rzeczywistości wygląda komenda SEARCH.
Chodzi o to jakie feature-y protokołu imap obsługuje netart czy o coś innego?
Nie, to wszystko objęte jest podstawową wersją standardu, żadne rozszerzenia. No ale wygląda na błąd (może w PHP albo w netarcie), dlatego zaproponowałem trochę inne sposoby.
Zobaczymy czy ludziom zadziała przez NOT SEEN na inny serwerach imap przez nich używanych (o ile komuś będzie chciało się o tym poinformować, albo w ogóle to sprawdzać na własną rękę).
dla serwerów pocztowych z az.pl musi byc UNSEEN przy NOT SEEN nie pobiera żadnych wiadomości
To można byłoby wprowadzić ustawienie skryptu jakieś o nazwie powiedzmy cashimport/unseen_check_flag.
albo w samym skrypcie dać żeby najpierw czesał skrzynkę za pomocą NOT SEEN, jak nic nie znajdzie to wtedy ponownie ale już przez UNSEEN
W dniu 20.04.2013 12:17, Sylwester Kondracki napisał(a):
Dnia 2013-04-20, sob o godzinie 12:10 +0200, Tomasz Chiliński pisze:
W dniu 20.04.2013 12:03, Sylwester Kondracki napisał(a): Dnia 2013-04-20, sob o godzinie 11:55 +0200, Tomasz Chiliński pisze:
W dniu 20.04.2013 11:52, A.L.E.C napisał(a): On 04/20/2013 11:49 AM, Tomasz Chiliński wrote:
Jeśli ten moduł na debug protokołu możnaby sprawdzić co zwraca w PERMANENTFLAGS w odpowiedzi na komendę SELECT INBOX oraz jak w rzeczywistości wygląda komenda SEARCH.
Chodzi o to jakie feature-y protokołu imap obsługuje netart czy o coś innego?
Nie, to wszystko objęte jest podstawową wersją standardu, żadne rozszerzenia. No ale wygląda na błąd (może w PHP albo w netarcie), dlatego zaproponowałem trochę inne sposoby.
Zobaczymy czy ludziom zadziała przez NOT SEEN na inny serwerach imap przez nich używanych (o ile komuś będzie chciało się o tym poinformować, albo w ogóle to sprawdzać na własną rękę).
dla serwerów pocztowych z az.pl musi byc UNSEEN przy NOT SEEN nie pobiera żadnych wiadomości
To można byłoby wprowadzić ustawienie skryptu jakieś o nazwie powiedzmy cashimport/unseen_check_flag.
albo w samym skrypcie dać żeby najpierw czesał skrzynkę za pomocą NOT SEEN, jak nic nie znajdzie to wtedy ponownie ale już przez UNSEEN
A jeśli przy NOT SEEN po prostu nic nie znajduje to tak warto.
On 04/20/2013 12:21 PM, Tomasz Chiliński wrote:
albo w samym skrypcie dać żeby najpierw czesał skrzynkę za pomocą NOT SEEN, jak nic nie znajdzie to wtedy ponownie ale już przez UNSEEN
A jeśli przy NOT SEEN po prostu nic nie znajduje to tak warto.
No nie bardzo, bo w przypadku gdy skrzynka nie posiada nowych wiadomości, uruchomisz "zapytanie" które zwróci wszystkie (na netarcie).
W dniu 20.04.2013 12:26, A.L.E.C napisał(a):
On 04/20/2013 12:21 PM, Tomasz Chiliński wrote:
albo w samym skrypcie dać żeby najpierw czesał skrzynkę za pomocą NOT SEEN, jak nic nie znajdzie to wtedy ponownie ale już przez UNSEEN
A jeśli przy NOT SEEN po prostu nic nie znajduje to tak warto.
No nie bardzo, bo w przypadku gdy skrzynka nie posiada nowych wiadomości, uruchomisz "zapytanie" które zwróci wszystkie (na netarcie).
Chcesz powiedzieć, że jeśli dam NOT SEEN to jeśli nie ma żadnych nowych wiadomości to imap zwraca po prostu wszystkie?
Dnia 2013-04-20, sob o godzinie 12:31 +0200, Tomasz Chiliński pisze:
W dniu 20.04.2013 12:26, A.L.E.C napisał(a):
On 04/20/2013 12:21 PM, Tomasz Chiliński wrote:
albo w samym skrypcie dać żeby najpierw czesał skrzynkę za pomocą NOT SEEN, jak nic nie znajdzie to wtedy ponownie ale już przez UNSEEN
A jeśli przy NOT SEEN po prostu nic nie znajduje to tak warto.
No nie bardzo, bo w przypadku gdy skrzynka nie posiada nowych wiadomości, uruchomisz "zapytanie" które zwróci wszystkie (na netarcie).
Chcesz powiedzieć, że jeśli dam NOT SEEN to jeśli nie ma żadnych nowych wiadomości to imap zwraca po prostu wszystkie?
można inaczej to zrobić
w lms.ini [cashimport] dodać opcje seenflag , a w skryptach wpisać że dafault dla konfigu to UNSEEN
On 04/20/2013 12:31 PM, Tomasz Chiliński wrote:
albo w samym skrypcie dać żeby najpierw czesał skrzynkę za pomocą NOT SEEN, jak nic nie znajdzie to wtedy ponownie ale już przez UNSEEN
A jeśli przy NOT SEEN po prostu nic nie znajduje to tak warto.
No nie bardzo, bo w przypadku gdy skrzynka nie posiada nowych wiadomości, uruchomisz "zapytanie" które zwróci wszystkie (na netarcie).
Chcesz powiedzieć, że jeśli dam NOT SEEN to jeśli nie ma żadnych nowych wiadomości to imap zwraca po prostu wszystkie?
Nie, odniosłem się do problemu postawionego w tym wątku i twojej propozycji
albo w samym skrypcie dać żeby najpierw czesał skrzynkę za pomocą NOT SEEN, jak nic nie znajdzie to wtedy ponownie ale już przez UNSEEN
Na serwerze, na którym nie ma nowych wiadomości pierwsze zapytanie zwróci zero wyników, jeśli teraz wykonasz drugie zapytanie to dostaniesz wszystkie wiadomości (na serwerze netart).
W dniu 20.04.2013 17:00, A.L.E.C napisał(a):
On 04/20/2013 12:31 PM, Tomasz Chiliński wrote: albo w samym skrypcie dać żeby najpierw czesał skrzynkę za pomocą NOT SEEN, jak nic nie znajdzie to wtedy ponownie ale już przez UNSEEN
A jeśli przy NOT SEEN po prostu nic nie znajduje to tak warto.
No nie bardzo, bo w przypadku gdy skrzynka nie posiada nowych wiadomości, uruchomisz "zapytanie" które zwróci wszystkie (na netarcie).
Chcesz powiedzieć, że jeśli dam NOT SEEN to jeśli nie ma żadnych nowych wiadomości to imap zwraca po prostu wszystkie?
Nie, odniosłem się do problemu postawionego w tym wątku i twojej propozycji
albo w samym skrypcie dać żeby najpierw czesał skrzynkę za pomocą NOT SEEN, jak nic nie znajdzie to wtedy ponownie ale już przez UNSEEN
Na serwerze, na którym nie ma nowych wiadomości pierwsze zapytanie zwróci zero wyników, jeśli teraz wykonasz drugie zapytanie to dostaniesz wszystkie wiadomości (na serwerze netart).
Doprecyzowuję co teraz robię: https://github.com/lmsgit/lms/commit/afc99ae9b600d2611492e42b98dae20bd26e09e...
Czyli teraz, jeśli w ogóle używam ustawienia konfiguracyjnego załączającego sprawdzanie obejrzenia wiadomości czy nie, to najpierw robię sprawdzenie wiadomości NOT SEEN (podobno dla netart zwraca to co potrzebujemy, a dla innych serwerów pocztowych zwraca pusty wynik). Następnie, gdy wynik z NOT SEEN jest pusty, to robię sprawdzenie wiadomości UNSEEN.
On 04/20/2013 05:09 PM, Tomasz Chiliński wrote:
Doprecyzowuję co teraz robię: https://github.com/lmsgit/lms/commit/afc99ae9b600d2611492e42b98dae20bd26e09e...
Tomku, no nie może tak być. Na serwerze netart UNSEEN zwraca wszystkie wiadomości i nie może być wykonywane jako fallback, gdyż "NOT SEEN" czasami prawidłowo zwraca pusty wynik.
W dniu 20.04.2013 17:20, A.L.E.C napisał(a):
On 04/20/2013 05:09 PM, Tomasz Chiliński wrote:
Doprecyzowuję co teraz robię: https://github.com/lmsgit/lms/commit/afc99ae9b600d2611492e42b98dae20bd26e09e...
Tomku, no nie może tak być. Na serwerze netart UNSEEN zwraca wszystkie wiadomości i nie może być wykonywane jako fallback, gdyż "NOT SEEN" czasami prawidłowo zwraca pusty wynik.
Rozumiem teraz o co Ci chodziło. Popatrzę jeszcze czy istnieje sposób "niedestrukcyjny", żeby sprawdzać które z flag NOT SEEN i UNSEEN są obsługiwane przez serwer imap.
On 04/20/2013 05:25 PM, Tomasz Chiliński wrote:
Rozumiem teraz o co Ci chodziło. Popatrzę jeszcze czy istnieje sposób "niedestrukcyjny", żeby sprawdzać które z flag NOT SEEN i UNSEEN są obsługiwane przez serwer imap.
Nie da się, bo to jest ta sama flaga tylko inaczej zapytanie zadane. RFC3501 6.4.4. Możesz sprawdzać flagę każdej wiadomości z osobna (taki postfiltering).
W dniu 20.04.2013 17:35, A.L.E.C napisał(a):
On 04/20/2013 05:25 PM, Tomasz Chiliński wrote:
Rozumiem teraz o co Ci chodziło. Popatrzę jeszcze czy istnieje sposób "niedestrukcyjny", żeby sprawdzać które z flag NOT SEEN i UNSEEN są obsługiwane przez serwer imap.
Nie da się, bo to jest ta sama flaga tylko inaczej zapytanie zadane. RFC3501 6.4.4. Możesz sprawdzać flagę każdej wiadomości z osobna (taki postfiltering).
Np. tak: $count = imap_num_msg($ih); for($postid = 1; $postid <= $count; $postid++) { $headers = imap_headerinfo($ih, $postid); if($headers->Unseen == 'U') { ... } }
Ciekawe czy netart dla imap_headerinfo zwróci w $headers pole Unseen o sensownej wartości... Może ktoś ze skrzynką na netart to przetestuje.
uczestnicy (5)
-
A.L.E.C -
Admin - Dar.Net -
Sylwester Kondracki -
Tomasz Chiliński -
Tomasz Chiliński