Så öppnas dokument från en webbplats i Office 2003

Artikelöversättning Artikelöversättning
Artikel-id: 838028 - Visa produkter som artikeln gäller.
Visa alla | Dölj alla

På den här sidan

INLEDNING

I den här artikeln beskrivs hur Microsoft Office Word 2003-dokument, Microsoft Office Excel 2003-kalkylblad och Microsoft Office PowerPoint 2003-presentationer öppnas i Microsoft Office 2003 med hjälp av hyperlänkar eller webbmappar i Microsoft Internet Explorer. I processen ingår flera tillägg för bättre webbsamarbete. Dessa tillägg kan påverka befintliga webblösningar som bygger på tidigare Office-funktioner. Informationen är avsedd för webbutvecklare som vill veta mer om den tekniska processen som används i Office för att hantera hämtning av dokument och redigering från en HTTP-resurs.

Mer Information

Office 2003 är gjort för att skapa en arbetsyta med mer samarbete. Därför har flera ändringar gjorts i behandlingen av webbinnehåll i Office 2003. Dessa ändringar bidrar till att skapa webblösningar som gör Office-dokument helt kompatibla med Office 2003-systemet. I den här artikeln beskrivs ändringarna ur ett tekniskt perspektiv. Ändringarna ger bättre redigeringsfunktioner för följande webbservrar som stöder Office 2003:
  • Microsoft Windows SharePoint Services
  • Microsoft SharePoint Portal Server
  • Microsoft Exchange Web Store
Obs! Termen "Office" avser följande produkter:
  • Microsoft Office Word 2003
  • Microsoft Office Excel 2003
  • Microsoft Office PowerPoint 2003
Termen "dokument" avser varje fil eller mall som kan öppnas i Word 2003, Excel 2003 eller PowerPoint 2003, oberoende av filformat.

Hyperlänkar i Office 2003 med hjälp av HLINK och URLMON

Liksom i tidigare Office-versioner implementeras hyperlänkfunktioner i Office 2003 med hjälp av de offentligt exponerade OLE-gränssnitten i URL Moniker-komponenten (Urlmon.dll) från Internet Explorer. Genom API:n från URLMON kan alla URL-resurser behandlas i Office på samma sätt som alla OLE-länkkällor behandlas i Office. Dessutom ger URLMON-API:n möjligheter till asynkron navigering, omdirigering och delning av innehåll mellan processer.

För hantering av navigeringshistorik och bakåtfunktioner används i Office de offentliga gränssnitten i Microsoft-hyperlänkbiblioteket (Hlink.dll) för att skapa hyperlänkar, binda till hyperlänkar och flytta till hyperlänkar. HLINK är ett högnivågränssnitt för funktionerna som exponeras av URLMON. HLINK ger Office-programmen en gemensam ram för hantering av de grundläggande uppgifterna i samband med hyperlänkfunktioner.

Öppna ett Office-dokument från Internet Explorer

När du klickar på en hyperlänk till ett Office-dokument från en webbsida i Internet Explorer navigerar värdramen till hyperlänkresursen med hjälp av URLMON. URLMON hämtar filinnehållet med hjälp av ett HTTP GET-kommando. När resursen har kommit till URLMON görs ett försök att identifiera innehållstypen på en av följande tre platser:
  • Den associerade MIME-typen som anges i HTTP-huvudet
  • CLSID som det är sparat i ett strukturerat lagringsdokument
  • Filnamnstillägget, om det finns i URL-strängen
Om typen är associerad med ett Office-program skapas en OLE-instans av målprogrammet. I URLMON uppmanas OLE-instansen att ladda innehållet med hjälp av IPersistMoniker-gränssnittet för OLE-objektet. URL-monikern som skapas av URLMON för resursen överförs till Office. I Office infogas sedan URL-monikern i ett nytt HLINK-objekt. När URL-monikern har bundits till HLINK-objektet kan filen laddas i Office och visas för användaren.

Hela processen med laddning från en moniker och användning av HLINK och URLMON för bindning till webbinnehåll ligger utom ramarna för den här artikeln. Mer information om programmeringsaspekterna av den här processen finns i dokumentationen för Microsoft Developer Network.

Om du vill veta mer klickar du på artikelnumret nedan och läser artikeln i Microsoft Knowledge Base:
178853 HLINKAXD visar ett aktivt hyperlänkningsdokument
Det finns en kritisk nackdel med den här metoden. URL-monikers från Internet Explorer är normalt skrivskyddade. Du kan öppna och ändra innehållet, men du kan inte spara innehåll på servern igen. När du sparar tillbaka innehåll på lagringsplatsen som monikern ger tillgång till, utförs ändringarna på innehållet i Temporary Internet Files-cachen i Internet Explorer. Ändringarna tillämpas emellertid inte på innehållet på webbservern. För att det här problemet ska undvikas har publiceringsmoniker införts i Office 2000 och senare.

Ge en URL-moniker läs- och skrivbehörighet med hjälp av MSDAIPP

Genom införandet av Office 2000 utökas funktionerna i URLMON så att de stöder fullständig skrivbehörighet på en publiceringsserver som stöder FrontPage Server Extensions (FPSE) eller HTTP 1.1-kommandotilläggen för Web-DAV (Distributed Authoring and Versioning).

Stöd för full skrivbehörighet fås med hjälp av ett protokollprovidertillägg till URLMON. Detta tillåter bindning genom en komponent med beteckningen Microsoft OLE DB Provider for Internet Publishing Provider (Msdaipp.dll). Med hjälp av en uppsättning flaggor för URLMON kan en värd begära bindning med hjälp av en särskild URL-monikertyp för MSDAIPP. I Office kallas detta en publiceringsmoniker. I publiceringsmonikern används MSDAIPP för att öppna och spara innehållet direkt på servern. Detta är ett viktigt steg för att utöka funktionerna i URLMON.

Det finns emellertid en nackdel. I MSDAIPP-komponenten används komponentens egen session av WININET-API:n (Windows Internet), inte sessionen som används av Internet Explorer. Därför är icke-beständig sessionsinformation, t.ex. servercookies, inte tillgänglig i MSDAIPP-begäranden. Detta medför att vissa servrar kräver omautentisering eller åternavigering till URL-adressen för att MSDAIPP ska kommunicera med servrarna. För att inaktuella data som kan ha ändrats av en annan användare inte ska användas, hämtar MSDAIPP webbinnehållet igen efter att ha låst det för skrivåtkomst. Detta orsakar en andra HTTP GET-begäran eller en andra FPSE POST-begäran till webbservern för dokumentinnehållet.

I Office 2000 Service Release 1 införs en annorlunda metod för att undvika det här problemet. I stället för att bindningen sker med hjälp av en publiceringsmoniker vid laddningen, binds Office till dokumentet med hjälp av den vanliga skrivskyddade URL-monikern som tillhandahålls av Internet Explorer. När du vill spara filen görs ett försök att växla till publiceringsmonikern för att spara tillbaka till servern, om servern stöder webbpublicering. Om det behövs en återautentisering på grund av sessionsändringen efterfrågas identifieringsinformation när filen sparas i stället för när den öppnas. Om du vill läsa filen utan att spara den undviks den kostbara kontextväxlingen till en publiceringsmoniker. Dessutom används ett serverlås på resursen. Detta är en kompromisslösning.

Om du vill veta mer om vissa ändringar av Office 2000 Service Release 1 för att mildra effekterna av att webbdokument öppnas med hjälp av publiceringsmonikerns kontext, klickar du på följande artikelnummer och läser artiklarna i Microsoft Knowledge Base:
185978 Dubbla GET-begäranden och cookies går förlorade med Word 2000 eller Excel 2000
266263 PROGRAMFEL: Word 2000 och Excel 2000 visar ASP-källa när MIME-typ används för att sända data i jämn ström
247318 PROGRAMFEL: Word 2000 och Excel 2000 dirigeras inte om på rätt sätt vid användning av Response.Redirect
264143 KORRIGERING: Tomma ASP-sessionsvariabler när MIME-typer för Office 2000 MIME sänds i jämn ström med Internet Explorer

Nackdelar med metoder i tidigare Office-versioner

Kompromisslösningen som används i Office 2000 Service Release 1 och Office XP är väl lämpad för att bläddra i dokument och för att spara dokumenten på servern. Kompromisslösningen har emellertid sina nackdelar, som blir mer uppenbara när webbutvecklare skapar mer avancerade webbaserade dokumenthanteringssystem för problemfri integration med Microsoft Office.

Den viktigaste nackdelen är att kontextväxlingen fördröjs tills en användare har försökt spara eller utföra någon åtgärd som kräver skrivåtkomst. Dokumentresursen är inte låst och kan ändras av en annan användare eller process medan den första användaren har filen öppen. Om den första användaren sedan försöker spara går den andra användarens ändringar förlorade. Alternativt måste den första användaren ignorera ändringarna utan att veta vad den andra användaren har ändrat.

En annan nackdel beror på att användarens redigeringsbehörighet är okänd tills kontextväxlingen inträffar. Användaren meddelas inte om att behörighet att spara filen saknas förrän användaren begär att filen ska sparas. Användare måste meddelas att de saknar behörighet att spara filen innan den har öppnats för redigering. Denna nackdel ledde till lösningen i Office 2000 Service Release 1.

Identifiera ändringar av hyperlänkprocessen för Office 2003

Det finns ett växande antal användare som använder Office som klientprogram för dokumentsamarbete via HTTP-intranät. Därför är nackdelarna med den tidigare metoden akuta. Ändringar krävs för att skillnaden mellan ett delat och ett visat dokument ska kunna identifieras. I Office 2003 introduceras nya funktioner i hyperlänkprocessen för att nackdelarna ska undvikas.

Förstå protokollupptäckt i Microsoft Office

När ett Office-program får en begäran att öppna en webbresurs måste följande beslut om öppnandet av webbresursen fattas:
  • Öppna resursen som skrivskyddad från innehållet som hämtas av Internet Explorer. Det här innehållet öppnas i webbläsningsläge.
  • Öppna resursen som läsning/skrivning med ett dokumentlås på servern för exklusiv åtkomst. Det här innehållet öppnas i redigeringsläge.
Beslutet om hur webbresursen ska öppnas fattas genom en undersökning av mappsökvägen till platsen som dokumentet kommer från och en undersökning av funktionerna på servern som hanterar sökvägen. För att funktionerna som servern stöder ska identifieras utfärdas ett HTTP 1.1-standard-OPTIONS-kommando från Office 2003. Genom OPTIONS-kommandot skickas en begäran om att servern ska ange vilka kommandon och metoder som servern stöder för mappen där dokumentet finns. Servern lämnar uppgifterna enligt reglerna i RFC 2616. En HTTP 1.1-kompatibel webbserver svarar på OPTIONS-begäran med en lista över metoder som stöds för URI:n (Uniform Resource Identifier). Svaret utvärderas i Office och därifrån söks sedan följande:
  • Webbredigeringsprotokoll

    Om serversvaret innehåller ett MS-AUTHOR-VIA-huvudvärde eller en lista över metoder som överensstämmer med Distributed Authoring and Versioning, beslutas i Office att dokumentet kan sparas tillbaka på webbservern med hjälp av angivet protokoll.

    För närvarande är protokollen WEC (Web Extender Client) och WebDAV tillgängliga. Om servern inte tillhandahåller ett protokoll betraktas filen som skrivskyddad. På klienten kan en SaveAs-åtgärd utföras för att spara en kopia lokalt. En kopia kan emellertid inte sparas tillbaka på mappen som filen kom från.
  • Webbservertyp

    Vidare görs ett försök att fastställa webbservertypen. Beslutet baseras på huvudinformationen som returneras av OPTIONS-anropet. Närmare bestämt söks huvudvärden som anger kommunikation med ett SharePoint-dokumentbibliotek eller en Exchange WebStore-mapp. Om kommunikation identifieras sker ytterligare kommunikation från Office till servern för aktivering av följande funktioner för webbsamarbete:
    • Webbdiskussion
    • Uppdateringar av uppgiftslista
    • Dokumentutcheckning
    • Dokumentincheckning
    Föregående webbsamarbetsfunktioner stöds av vissa webbservertyper. För identifiering av webbservertypen sker en sökning efter följande huvuden:
    • MicrosoftSharePointTeamServices
    • MicrosoftTahoeServer
    • MicrosoftOfficeWebServer
    • MS-WebStore
Om webbservern kräver autentisering för slutförande av OPTIONS-begäran kan du bli ombedd att ange identifieringsinformation för att slutföra anropet. När anropet har slutförts cachelagras den insamlade informationen i registreringsdatafilen, så att anropet inte ska behöva upprepas för denna mapp. Prokollupptäcktscachen för Office finns under följande registernyckel:

HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Common\Internet\Server Cache


Servercachen innehåller undernyckelposter för alla webbmappar som har öppnats och returnerat ett OPTIONS-anrop. Varje post innehåller följande värden med lämplig inställning för mappen:
  • Protokoll

    Detta är ett 32-bitars DWORD-värde med webbredigeringsprotokollet för dokumentet. Följande värden gäller för närvarande:
    • 0 för skrivskyddat HTTP
    • 1 för WEC till en webbmapp med FPSE-funktion
    • 2 för DAV till en DAV-utökad webbmapp
  • Typ

    Detta är ett DWORD-värde som anger vilken typ av webbserver för dokumentsamarbete som hanterar mappen. Följande värden gäller för närvarande:
    • 0 för inget samarbete
    • 1 för SharePoint Team Server
    • 2 för Exchange 2000 Server
    • 3 för SharePoint Portal 2001 Server
    • 4 för utökad SharePoint 2001-mapp
    • 5 för Windows SharePoint Server och SharePoint Portal 2003 Server
  • Förfallodatum

    Detta är ett 64-bitars QWORD-värde med en förfallotid. Värdet är en Win32-FILETIME-struktur med förfallotiden i UTC-format (Universal Time Coordinate). Efter förfallotiden skickas en ny begäran till webbservern med ett nytt OPTIONS-anrop som kontroll av att serverkonfigurationen inte har ändrats sedan värdena cachelagrades senast. Förfallotidens längd varierar beroende på en slumpmässig dirigering. Längden är normalt två veckor eller mer.

    Viktigt! Registernyckeln tillhandahålls bara för information. Redigera inte registernyckeln eller värden direkt. Cacheminnet rensas med jämna mellanrum i Office och sparad information är därför bara tillfällig.
Det maximala antalet cacheposter kan anges med hjälp av registervärdet MaxCount under samma Server Cache-nyckel. Gamla poster tas bort i Office om det maximala antalet uppnås. Om inget utrymme kan rensas cachelagras inte resultaten av OPTIONS-anropet.

Identifiera kända nackdelar som orsakas av protokollupptäckt i Office

Protokollupptäckt i Office undanröjer den viktigaste nackdelen, som är att fastställa om dokumentet måste öppnas som skrivskyddat eller som läs-/skrivdokument på servern. Protokollupptäckt i Office kan emellertid ge vissa nya nackdelar. Följande problem är kända bieffekter av den aktuella utformningen:
  • Vid protokollupptäckt i Office används standard-HTTP 1.1-kommandot OPTIONS. Webbservrar som inte hanterar detta kommando kan inte stödja full läs-/skrivåtkomst i Office 2003. Detta är förväntat och avsiktligt.
  • Du kan bli ombedd att autentisera dig när du öppnar Office-filer. Detta händer om webbservern kräver autentisering för behandling av ett OPTIONS-anrop till mappens URI. Ändringar av serverkonfigurationen kan normalt göras för att undvika det här problemet genom att anonyma användare får rätt att bläddra i mappen. Bläddringsbehörigheter kallas även listbehörigheter. Uppmaningen till autentisering är förväntad om servern kräver autentisering.
  • Du kan uppmanas att välja ett klientcertifikat eller ett trust-a-server-certifikat vid öppnandet. Det här problemet kan uppstå även om certifikatinformationen tidigare har skickats till Internet Explorer för samma navigering. Eftersom det görs en ny begäran för processutrymmet i Office till servern, skapas en ny session varje gång. Den nya sessionen kan ge upphov till ytterligare säkerhetsvarningar eller ytterligare uppmaningar att slutföra OPTIONS-anropet.
  • Cookie-information för att samla in dokumentet används inte i OPTIONS-begäran. Om servern inte tillåter direkta anrop till mapp-URL utan denna cookie-information lyckas kanske inte OPTIONS-anropet. Om det här problemet uppstår kan användaren upprepade gånger uppmanas till autentisering, men kan kanske inte göra detta. Detta beror inte på att autentiseringsinformation saknas, utan på att det saknas tillfälliga cookies för webbservern. Problemet är specifikt för vissa webbserverkonstruktioner som är beroende av cookie-information i stället för autentiseringsinformation, eller som är beroende av cookie-information plus autentiseringsinformation.
  • Detta är ett känt problem i nätverkskonfigurationer där en CSS-belastningsutjämnare (Cisco Content Server Switch) med nivå-5-filtrering används i intranätmiljön. HTTP 1.1-kommandot OPTIONS hanteras inte korrekt av CSS-programmet. CSS-programmet vidarebefordrar inte anropet till webbservern. CSS-programmet returnerar inte heller ett svar till klienten som anger ett fel och sedan stänger TCP-anslutningen.

    Eftersom TCP-paketet aldrig bekräftas av servern tror klienten att servern inte har tagit emot meddelandet. Därför skickar klienten meddelandet igen. Meddelandet skickas upprepade gånger från Office, och ett svar inväntas tills TCP-anslutningen slutligen bryts på grund av timeout. Detta kan medföra att en klient slutar svara medan en Office-fil öppnas. Office-programmet inväntar svaret från servern, men detta tas aldrig emot eftersom CSS-belastningsutjämnaren tappar TCP-paketet.

    Cisco känner till problemet och arbetar på en uppdatering för att lösa det. Om du vill undvika problemet utan att installera uppdateringen kan du sänka CSS-filtreringen till regler på nivå 3 eller 4. Du kan även kringgå belastningsutjämnaren genom att ändra URL-adressen som öppnas, så att den pekar direkt på webbservern med innehållet.
Fördelarna med Office-protokollupptäckt uppväger nackdelarna som är kända för tillfället. Vi tror att problemen kommer att minska med tiden. Vi kommer att följa upp de sista två problemen för att säkerställa att det finns lösningar om den befintliga nätverksuppbyggnaden inte kan ändras. Vi anser att möjligheten att använda Office-protokollupptäckt är den rätta långsiktiga strategin för webbsamarbete.

Förstå HTTP-konvertering för UNC-omdirigerarfiler

På klienter med Windows XP Professional går det att skapa nätverksplatser för DAV-webbmappar med hjälp av webbklienttjänsten, som även kallas WebDAV-miniomdirigeraren. Genom den här webbklienttjänsten kan mappar med DAV-funktion visas som UNC-resurser.

Ett program kan öppna filen, redigera den och spara till den, eftersom programmet normalt sparar till en UNC-sökväg. Dokumentsamarbete kräver emellertid fler funktioner än de som tillhandahålls av webbklienttjänsten. Därför har kod lagts till i Office 2003 som används för att fastställa om en fil öppnas av webbklienttjänsten. Om en fil öppnas av webbklienttjänsten mappar Office 2003 sökvägen tillbaka till en fullständig URL-adress, och sedan öppnas filen separat med hjälp av protokollet för servertypen. På så vis kan fullständiga samarbetsfunktioner för dokumentet användas i ett Office 2003-program, på samma sätt som om filen öppnas direkt från URL-adressen i Office. Informationen ovan, inklusive Office-protokollupptäckt, gäller dokument som öppnas från en UNC-resurs med webbklientfunktion.

Förstå hyperlänkzonsäkerhet och säkerhetsmeddelanden

I Office 2003 används åtgärder för utökad säkerhet för Internet-hyperlänkar från länkar i Office-dokumentet. Här ingår överföring av säkerhetsidentifieringsinformation under en mer restriktiv säkerhetszonprincip, så att överföring av identifieringsinformation till servern kan tillåtas eller stoppas. Om överföringen tillåts eller stoppas beror på användarens zoninställningar.

I Office 2003 kontrolleras också att WININET har en korrekt fönsterreferens när navigeringen är under användarens kontroll. Detta innebär att användaren kan få säkerhetsmeddelanden via WININET om detta krävs för att utföra en åtgärd. Detta ökar webbsäkerheten i Office. Hårdare restriktioner för säkerhetszoner i Internet Explorer kan emellertid medföra varningar som inte visades i tidigare Office-versioner. Varningarna visas under hyperlänknavigering.

Dessutom visas en varning i Office 2003 under följande förhållanden:
  • En användare klickar på en hyperlänk i ett Office-dokument.
  • Ett dokument innehåller text som baseras på en URL-resurs som kan navigera.
Den extra varningen säkerställer att användaren vill förflyttas till webbplatsen och att webbplatsen är tillförlitlig. Varningsfunktionen kan styras med en registerinställning.

Om du vill veta mer klickar du på artikelnumret nedan och läser artikeln i Microsoft Knowledge Base:
829072 Inaktivera en hyperlänkvarning i Office 2003

Referenser

Mer information om OPTIONS-kommandot och HTTP 1.1 finns i RFC-specifikation (Request for Comments) 2616 för HTTP Working Group på följande Internet Engineering Task Force-webbplats:
http://www.ietf.org/rfc/rfc2616.txt
Om du vill veta mer om hyperlänkproblem i tidigare Office-versioner klickar du på följande artikelnummer och läser artiklarna i Microsoft Knowledge Base:
297891 Dåliga prestanda och problem med för lite minne vid hyperlänkning mellan program
810360 PROGRAMFEL: Cookie-information finns inte kvar i Word 2000 och Excel 2000 vid förflyttning till en hyperlänk i samma session
225234 Lösenord efterfrågas när Office-dokument öppnas i en webbläsare
314400 Lösenord efterfrågas i onödan när du klickar på en hyperlänk i ett Office-dokument
218153 Felmeddelande: "Internet- eller proxyserver kunde inte hittas" visas när du klickar på hyperlänk
280680Det går inte att följa en hyperlänk till ett Office-dokument

Egenskaper

Artikel-id: 838028 - Senaste granskning: den 20 juni 2005 - Revision: 1.0
Informationen i denna artikel gäller:
  • Microsoft Office Excel 2003
  • Microsoft Office PowerPoint 2003
  • Microsoft Office Word 2003
Nyckelord: 
kbinfo kbofficeauto KB838028

Ge feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com