Hiperłącze Excel nie przekierowuje poprawnie (błąd?)

Mam problem z hiperłączem Excela: klikam, powiedzmy A1, kopiuję w nim link ( http://www.godaddy.com/domains/searchresults.aspx?ci=54814), klikam hiperłącze prawym przyciskiem myszy i kopiuję ten sam URL jako link (jeśli nie zostanie automatycznie wykryty i zmieniony).

Kiedy idę na niego kliknąć, następuje przekierowanie do http://www.godaddy.com/domains/search.aspx?ci=53972.

Jeśli skopiuję i wkleję link bezpośrednio do przeglądarki, działa dobrze (tzn. Nie jestem przekierowywany na inny adres URL).

Czy ktoś wie, co się dzieje?

Używany adres URL potrzebuje więcej informacji z pliku cookie, aby wyświetlić wyniki wyszukiwania, a nie stronę wyszukiwania. Wklej adres URL do innej przeglądarki (lub usuń pliki cookie), a otrzymasz te same wyniki.

Kliknięcie adresu URL w programie Excel wydaje się otwierać go w domyślnej przeglądarce. Ale to nie do końca prawda. Przed otwarciem w przeglądarce Excel najpierw uruchamia wykrywanie protokołu Microsoft Office . Korzysta ze składnika Windows / Internet Explorer w celu ustalenia, czy adres URL działa. (Nie identyfikuje się jako Internet Explorer, ale jako „User Agent: Microsoft Office Existence Discovery”). A jeśli wyniki są (jakoś) w porządku, to otworzy wynik tego sprawdzenia w domyślnej przeglądarce.

Brak plików cookie (a dokładniej: brak sesji ) powoduje, że GoDaddy przekierowuje komponent programu Internet Explorer . A wynik tego zostanie otwarty w domyślnej przeglądarce. To jest adres URL, który widzisz.

Najprawdopodobniej domyślną przeglądarką nie jest Internet Explorer? Następnie wklejenie adresu URL bezpośrednio w IE i kliknięcie go, aby uzyskać pliki cookie, może również sprawić, że link będzie działał w programie Excel. (Tylko do testowania; nie jest to trwałe rozwiązanie).

Będziesz mieć więcej szczęścia, używając adresu URL, który nie opiera się na niektórych ukrytych informacjach z pliku cookie, takich jak http://www.godaddy.com/domains/search.aspx?domainToCheck=superuser.com

To wina Excela. Jeśli wkleisz link w wiadomości e-mail programu Outlook lub WordPad i stamtąd otworzysz link, będzie on działał poprawnie.

Excel nigdy nie powinien tworzyć ukrytej sesji w celu weryfikacji hiperłącza. jaki jest tego sens. Musi tylko to otworzyć, nic więcej. Używają tej samej logiki w MS Word. Stamtąd też nie działa. Gdy Excel próbuje zweryfikować łącze w tle, tworzona jest nowa sesja, która nie jest uwierzytelniona, więc zostaje przekierowana na stronę logowania lub coś takiego. Następnie zamiast otwierać oryginalny adres URL w przeglądarce, program Excel otwiera adres przekierowania. Naprawdę wiedzą, jak skomplikować prostą rzecz.

Jest to znany błąd firmy Microsoft, w którym hiperłącza są przekierowywane na inną stronę, jeśli:

• Używasz przeglądarki Microsoft Internet Explorer:
  • z serwerem proxy
  • podczas korzystania z zapory ogniowej, która nie zezwala na żądania HTTP w sieci lokalnej
• Internet Explorer nie jest domyślną przeglądarką.
• ForceShellExecuteKlucz rejestru nie występuje lub nie jest ustawiony na 1

Możesz zastosować poprawkę tutaj:

http://support.microsoft.com/kb/218153

Obawiam się, że jest tu zbyt wiele, aby dodać jako komentarz.

Początkowy link zwraca kod stanu 302

Ze standardów w3c :

Żądany zasób znajduje się tymczasowo pod innym identyfikatorem URI. Ponieważ przekierowanie może być czasami zmieniane, klient POWINIEN nadal używać URI żądania dla przyszłych żądań. Ta odpowiedź jest buforowana tylko wtedy, gdy jest wskazana w polu nagłówka Kontrola pamięci podręcznej lub Wygasa.

Tymczasowy URI POWINIEN być podany w polu Lokalizacja w odpowiedzi. O ile metoda żądania nie była HEAD, encja odpowiedzi POWINNA zawierać krótką notatkę hipertekstową z hiperłączem do nowego identyfikatora URI.

Jeśli kod stanu 302 zostanie odebrany w odpowiedzi na żądanie inne niż GET lub HEAD, agent użytkownika NIE MOŻE automatycznie przekierować żądania, chyba że może to zostać potwierdzone przez użytkownika, ponieważ może to zmienić warunki, w których żądanie zostało wydane.

  Note: RFC 1945 and RFC 2068 specify that the client is not allowed
  to change the method on the redirected request.  However, most
  existing user agent implementations treat 302 as if it were a 303
  response, performing a GET on the Location field-value regardless
  of the original request method. The status codes 303 and 307 have
  been added for servers that wish to make unambiguously clear which
  kind of reaction is expected of the client.

Tak jak stwierdził @xlm, to GoDaddy dokonuje tymczasowego przekierowania.

Wydaje się, że po wywołaniu z Excela przekierowanie nie zawsze jest honorowane.

Zauważyłem, że ten problem pojawia się, gdy docelowy adres URL jest bezpieczną witryną wymagającą logowania. Mimo że jestem zalogowany już w innym oknie, nie będzie działać poprawnie. Jeśli wytnę i wkleję adres URL w nowej karcie lub oknie, Chrome jest wystarczająco inteligentny, aby stwierdzić, że już się uwierzytelniłem i poprawnie otwiera nową stronę. Jeśli jednak nie zaloguję się na stronie, zostaniesz przekierowany na stronę logowania, zgodnie z oczekiwaniami.
Ale po kliknięciu dokładnie tego samego adresu URL w programie Excel, na tych samych warunkach, albo dostaję tylko stronę logowania, albo moja zdalna witryna po prostu informuje mnie, że jest to nieobsługiwana przeglądarka.
Problem wyraźnie wynika z Excela, ponieważ jeśli wezmę ten dokładny arkusz kalkulacyjny, zapisz go jako plik PDF, hiperłącza wyświetlane w pliku PDF działają idealnie dobrze po kliknięciu.
Oprócz naprawienia tej oczywiście niezamierzonej „funkcji” programu Excel / Office próbującej zweryfikować łącza w miarę publikowania przez innych, jedynym obejściem, które znalazłem, było utworzenie lokalnej strony przekierowania, która mogłaby wziąć moje unikalne parametry w adresie URL i otworzyć nowe okno jako następuje (dzięki innym za kod JavaScript) Przekieruj, zmieniając hiperłącze programu Excel na coś takiego jak http://mylocaldomain.com/redirect.html?ID=12345 , gdzie strona przekierowania znajduje się na lokalnym serwerze, który kontrolujesz, i parametr 12345 sprawia, że ​​adres URL przekierowuje do określonego wymaganego wpisu. Dla mojego SS z około 10000 linków to działa dobrze.

Redirect.html wygląda następująco.

<!DOCTYPE html>
<html>
<script>
function getUrlVars() {
    var vars = {};
    var parts = window.location.href.replace(/[?&]+([^=&]+)=([^&]*)/gi,    
    function(m,key,value) {
      vars[key] = value;
    });
    return vars;
  }
    document.getElementById("demo").innerHTML=getUrlVars()["type"];
    var varbaseurl=[put your base url here]
    window.location = varbaseURL  + getUrlVars()["type"]
</script>
<body> 
redirecting to: <p id=demo></p>

To zdecydowanie denerwujące. Jednym obejściem jest utworzenie łącza do pliku lokalnego, który przekierowuje do hiperłącza. Na przykład coś takiego:

<HTML>
<HEAD>
<TITLE>Redirect</TITLE>
<META HTTP-EQUIV="refresh" CONTENT="0;URL=http://www.google.com">
</HEAD>
<BODY>
Redirecting...
</BODY>
</HTML>

Nie wiem dużo o HTML, ale byłoby miło móc przekazać argument (tj. Adres URL) do tego lokalnego pliku HTML.

Mogę powtórzyć twój problem, ale nie jest to problem z Excelem. W rzeczywistości to Godaddy przekierowuje cię do drugiego linku. Spróbuj wkleić ten link do przeglądarki, a zobaczysz, że przekierowuje do drugiego.

Uwagi: Przetestowano w programie Excel 2007, Firefox 13.0.1

Miałem ten sam problem tylko z witryną, którą zamierzałem uwzględnić w przetwarzaniu i pobieraniu bazy danych na datowniku. Skopiowałbym adres URL do nowej komórki. zmień datę kliknij nowy adres URL, ALE zdobądź stary adres URL.

Jednakże, jeśli kliknę ctl na nową komórkę url, przejdź do okna wyświetlania komórki, kliknij kursor w dowolnym miejscu tego okna, a następnie kliknij inną komórkę, zmieniają się wartości daty url i kliknięcie adresu URL zapewnia mi właściwe dane.

Wszystko to w IE.

Wygląda na to, że po skopiowaniu adresu URL zawiera on informacje o stronie adresu URL. Nie jestem pewien, co się dzieje z magią, gdy otwieram komórkę i nie zmieniam jej, ale zmienia ona adres URL po nałożeniu na nią wskaźnika. Jestem stałym magnesem dla tego rodzaju rzeczy w Excelu. Prawdopodobnie dlatego nie ufam.

Rozwiązałem ten problem, przeprowadzając wyszukiwanie w Google na adresie URL i używając adresu URL strony wyników wyszukiwania Google dla hiperłącza

np. dla sweettoothrewards.com Użyłem https://www.google.ca/?gfe_rd=cr&ei=xwK5VY-LG8KC8QeGn4LoDw&gws_rd=ssl#q=+sweettoothrewards.com W przeglądarce operowej ze mną nie zalogowanym.

Byłem w stanie zbadać to dalej, próbując uzyskać skoroszyt programu Excel, aby połączyć się z moim własnym serwerem internetowym. Zauważyłem, że kliknięcie łącza w programie Excel spowodowało wygenerowanie trzech zapytań do serwera.

1. GET HEAD (z sesją tymczasową)
2. GET (z sesją tymczasową)
3. GET (z prawdziwą sesją)

Ale jeśli połączona strona przekierowała użytkownika, nie widziałem trzeciego GET. Zamiast tego drugi GET został przekierowany na nową stronę, a sesja pozostała tymczasowa. Co oznacza, że ​​jeśli strona docelowa wymaga uwierzytelnienia, użytkownik zostanie przekierowany na stronę logowania, nawet jeśli faktycznie jest już uwierzytelniony.

To doprowadziło mnie do pomysłu stworzenia strony docelowej, która przekierowuje użytkownika na stronę docelową, jeśli użytkownik jest uwierzytelniony. I to działa. Po otrzymaniu trzeciego GET serwer informuje, że użytkownik jest uwierzytelniony i przekierowuje na stronę docelową. W przypadku nieuwierzytelnionego użytkownika strona docelowa zawiera link do strony docelowej. A kiedy użytkownik kliknie link, zostanie przekierowany do strony logowania.

Udaje nam się odtworzyć problem, a nasze ustalenia programistów wskazują, kiedy wklejasz łącze do Microsoft Excel, Excel zastępuje link znakiem bajtu zamówienia (BOM). Gdy ten link jest załadowany do przeglądarki, nie usuwa BOM z adresu URL.

Po załadowaniu adresu URL przeglądarka przeprowadza kilka testów, aby sprawdzić, czy połączenie jest bezpieczne (https) i nie udaje się to z powodu błędnego zestawienia komponentów. To ostatecznie powoduje błąd stanu przekaźnika, ponieważ ten parametr musi być przesłany bezpiecznym kanałem.

Możesz odtworzyć ten problem, kopiując komórkę i wklejając ją bezpośrednio do Firefoksa, usuwając w ten sposób program Excel z obrazu. To również się nie udaje (czasami w nieco inny sposób), ale cierpi z powodu tego samego problemu z korzeniem. Jeśli usuniesz „https” z wklejonego adresu URL i po prostu go przepiszesz, zauważysz, że link działa teraz poprawnie.

Jest to ograniczenie polegające na tym, że Excel przechowuje BOM w adresie URL, oraz sposób, w jaki przeglądarka nie może zinterpretować BOM.

W tej chwili jedynym obejściem, jakie możemy wymyślić, jest skopiowanie linku URL i wklejenie go do przeglądarki i uzyskanie dostępu do strony.

Ponadto osobiście sugeruję, abyś podniósł zgłoszenie do pomocy technicznej w firmie Microsoft i uważam, że mogliby lepiej zrozumieć ten problem, aby pomóc ci w tej sprawie.

Aby rozwiązać ten problem w niektórych witrynach, po prostu tworzę plik HTML, który przekierowuje do danej witryny, a następnie wskazuję hiperłącze w programie Excel do tego pliku i działa świetnie.

próba:

<HTML>
<HEAD>
<TITLE>Redirect</TITLE>
<META HTTP-EQUIV="refresh" CONTENT="0; URL=https://citiretailservices.citibankonline.com/RSnextgen/svc/launch/index.action?siteId=PLCN_GOODYEAR&langId=en_US#signon">
</HEAD>
<BODY>
Custom Redirect by Jason...
</BODY>
</HTML>

Ostatnio miałem ten problem, w którym funkcja hiperłącza w programie Excel wskazywała na przekierowanie 301 w witrynie WordPress. Zaktualizowałem 301, aby wskazywał na nowy dokument, ale łącze w Excelu nadal wyświetlało stary dokument. Udało mi się to rozwiązać tylko przez wyczyszczenie pamięci podręcznej dokumentów w przeglądarce IE, mimo że korzystam z programu Excel 2016 na komputerze z systemem Windows 10. Mam nadzieję że to pomoże.