Informacje o zgłoszeniu
-
#005485
-
Zrealizowano
-
2.4.1.10
-
3.0.0.53
-
2 - średnia
Potwierdzenia zgłoszenia
-
Tak (0)Nie (0)
http://i1.kwejk.pl/site_media/obrazki/2012/02/db28bb7c34a366c9ad3e1e2cdf33d186.jpg?1330436407
I nie chodzi tylko o Kwejka bo na wszystkich "kwejko-poodbnych" stronach jest tak samo, w wielu miejscach dodają jakieś durne końcówki. Usuwanie jej każdorazowo jest denerwujące. Mimo, że jest to link do obrazka to AQQ nie potrafi tego rozpoznać. A wszystko przez system rozpoznawania, który działa gdy na końcu linka jest graficzne rozszerzenie pliku. Problem rozwiąże lekka przebudowa filtra linków. Moge jedynie dodać (jeśli jest to jakiś argument) że najnowsze GG bez problemu potrafi wyświetlić obrazek z takiego linka (konkretnie jego miniaturke ale mniejsza).
Aktualizacja istotności do: 2 - przeciętna
Tego typu link nie może być jednoznacznie sklasyfikowany jako obrazek. Dlatego załącznik się nie wyświetla.
https://www.dropbox.com/s/nupsjj8c5ysxtv8/Aston%20Martin.jpgW AQQ jest kiszka bo tworzy sie załącznik i przy próbie rozwinięcia go dostajemy pusty kwadrat. Na pewno tak jest z Dropbox'em oraz z udostępnianiem zdjęć z dysku GG jak i pewnie z wielu innych stron/serwisów/chmur. Nie wiem jak ale AQQ powinno sprawdzać czy pod linkiem faktycznie jest obrazek, a nie lecieć po samym rozszerzeniu Tak samo powinno sprawdzać pod kątem graficznego rozszerzenia ciąg znaków po ostatnim slash'u w linku i w przypadku wykrycia graficznego rozszerzenia sprawdzać czy link prowadzi do obrazka taką samą metodą jak przy sprawdzaniu czy link z końcówką np. .jpg faktycznie jest obrazkiem.
Proszę przywrócić i wzywam jednocześnie Silvera do napisania tutaj posta - ponoć wie jak rozwiązać ten problem
Moje rozwiązanie nie spodobało się Oconnelowi. Polegało ono na mimo-wszystko-spróbowaniu zmuszenia IE do wyświetlenia obiektu o podanym adresie. Jeżeli da radę to zrobić, to odpali zdarzenie onLoad. Jeżeli nie - onError. Warto zauważyć, że nie trzeba pobrać całego pliku, aby IE było w stanie rozpoznać jego typ. Typ jest niemal zawsze umieszczony w pierwszych kilku bajtach, na podstawie których już można jednoznacznie określić typ. Dzięki temu przecież, IE wie już wcześniej również, jakie wymiary końcowe będzie miał obrazek. Może kogoś zainspiruje mój tok myślenia i wymyśli jeszcze inne, prostsze rozwiązanie, które zadowoli Oconnela.
Jeśli nikt nie wymyśli prostszego rozwiązania niż Twoje, to Oconnel albo je zastosuje, albo oleje sprawę. Ja bym jednak na jego miejscu przysiadł nad sprawą
Typ jest niemal zawsze umieszczony w pierwszych kilku bajtach, na podstawie których już można jednoznacznie określić typ.
//Ustalanie typu pliku graficznego (zmienne) struct TMagicWordInfo { BYTE Len; BYTE Off; char *cWord; wchar_t *wcName; }; static const int iTypes = 5; static const TMagicWordInfo cstMagicWords[iTypes] = { {6, 0, "\x47\x49\x46\x38\x39\x61", L"GIF89a"}, {6, 0, "\x47\x49\x46\x38\x37\x61", L"GIF87a"}, {4, 6, "\x4A\x46\x49\x46", L"JPEG/JFIF"}, {8, 0, "\211PNG\r\n\032\n", L"PNG"}, {2, 0, "BM", L"Bitmap"} }; //--------------------------------------------------------------------------- //Ustalanie typu pliku graficznego int GetFileType(wchar_t* wcPath) { FILE *fh; if(!(fh = _wfopen(wcPath, L"rb"))) { fclose(fh); return -1; } char cBuf[16]; fseek(fh, 0, 0); fread(cBuf, 16, 1, fh); TMagicWordInfo mwi; bool bRes; for(int i=0;i<iTypes;i++) { mwi = cstMagicWords[i]; bRes = true; for(int j=0;j<mwi.Len;j++) { bRes &= (cBuf[mwi.Off+j] == mwi.cWord[j]); } if(bRes) { fclose(fh); return i; } } fclose(fh); return -2; } //---------------------------------------------------------------------------
Użytkownicy przeglądający to zgłoszenie: 0
0 użytkowników, 0 gości, 0 anonimowych