L'ouverture d'un fichier CHM produit: "La navigation vers la page Web a été annulée"

J'essaye d'ouvrir un fichier .chm.

J'ai téléchargé la source, je l'ai extraite, puis j'ai double-cliqué Waffle.chmet cliqué sur "Ouvrir" mais quel que soit l'élément du fichier chm sur lequel je clique, je reçois le message:

Navigation to the webpage was canceled.  
What you can try: 
Retype the address.  

Que se passe t-il ici?

Sommaire

Les mises à jour de sécurité Microsoft 896358 et 840315 bloquent l'affichage du contenu des fichiers CHM lorsqu'ils sont ouverts à partir d'un lecteur réseau (ou d'un chemin UNC ). Il s'agit de la tentative de Windows d'empêcher les vecteurs d'attaque pour virus / malware d'infecter votre ordinateur et a bloqué le fichier .chm qui extrait des données via le protocole "InfoTech", utilisé par ce fichier chm.

Résumé du problème par Microsoft: http://support.microsoft.com/kb/896054

Solutions

1. Si vous utilisez Windows Server 2008, Windows 7, Windows a créé une solution rapide. Cliquez avec le bouton droit sur le fichier chm, et vous obtiendrez la boîte de dialogue "Propriétés de votre fichier.chm", en bas, un bouton appelé "Débloquer" apparaît. Cliquez sur Débloquer et appuyez sur OK, et essayez à nouveau d'ouvrir le fichier chm, cela fonctionne correctement. Cette option n'est pas disponible pour les versions antérieures de Windows avant WindowsXP (SP3).

   

2. Résolvez le problème en déplaçant votre fichier chm hors du lecteur réseau. Vous ne savez peut-être pas que vous utilisez un lecteur réseau, revérifiez maintenant: Faites un clic droit sur votre fichier .chm, cliquez sur Propriétés et regardez le champ "emplacement". S'il commence par deux contre-obliques comme ceci:, \\epicserver\blah\alors vous utilisez un lecteur en réseau. Donc, pour résoudre ce problème, copiez le fichier chm et collez-le dans un lecteur local, comme C: \ ou E :. Ensuite, essayez de rouvrir le fichier chm, Windows ne panique pas.

3. Dernier recours, si vous ne pouvez pas copier / déplacer le fichier hors du lecteur réseau. Si vous devez l'ouvrir là où il se trouve et que vous utilisez une version inférieure de Windows comme XP, Vista, ME ou autre, vous devrez manuellement dire à Windows de ne pas paniquer avec ce fichier .chm. L'utilitaire HHReg (HTML Help Registration Utility) automatise cette tâche. En gros, vous téléchargez l'utilitaire HHReg, chargez votre fichier .chm, appuyez sur OK et il créera les clés de registre nécessaires pour dire à Windows de ne pas le bloquer. Pour plus d'informations: http://www.winhelponline.com/blog/fix-cannot-view-chm-files-network-xp-2003-vista/

Windows 8 ou 10? -> Mettre à niveau vers Windows XP.

"débloquer" le fichier résout le problème. Capture d'écran:

Gagnez 8 x64:

déplacez-le simplement dans un autre dossier ou renommez votre dossier (dans mon cas: mon dossier était "c #"). évitez d'utiliser le symbole sur le nom du dossier. nommez-le avec une lettre.

terminé.

En plus de la réponse d'Eric Leschinski, et parce qu'il s'agit de stackoverflow, une solution programmatique:

Windows utilise des fourchettes de fichiers cachées pour marquer le contenu comme "téléchargé". Tronquer ces débloque le fichier. Le nom du flux utilisé pour les CHM est "Zone.Identifier". On peut accéder aux flux en ajoutant: streamname lors de l'ouverture du fichier. (gardez les sauvegardes la première fois, au cas où votre RTL gâcherait ça!)

Dans Delphi, cela ressemblerait à ceci:

var f : file;
begin
 writeln('unblocking ',s);
 assignfile(f,'some.chm:Zone.Identifier');
 rewrite(f,1);
 truncate(f);
 closefile(f);
end;

On me dit que sur les systèmes de fichiers non fourchus (comme FAT32), il y a des fichiers cachés, mais je ne suis pas encore allé au fond de cela.

DeleteFile () de Ps Delphi devrait également reconnaître les fourches.

La solution définitive est de permettre au protocole InfoTech de fonctionner dans la zone intranet.

Ajoutez la valeur suivante au registre et le problème devrait être résolu:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000001

Plus d'informations ici: http://support.microsoft.com/kb/896054

Aller au début

Type regsvr32 hhctrl.ocx

Vous devriez recevoir un message de réussite comme:

"DllRegisterServer dans hhctrl.ocx a réussi"

Maintenant, essayez à nouveau d'ouvrir votre fichier CHM.

L'autre façon consiste à utiliser différents logiciels tiers. Ce lien montre plus de logiciels tiers pour afficher les fichiers chm ...

J'ai essayé avec SumatraPDF et cela fonctionne très bien.

J'ai corrigé cela par programme dans mon logiciel, en utilisant C ++ Builder.

Avant d'attribuer le fichier d'aide CHM Application->HelpFile = HelpFileName, je vérifie s'il contient le flux "Zone.Identifier", et quand c'est le cas, je le supprime simplement.

String ZIStream(HelpFileName + ":Zone.Identifier") ;

if (FileExists(ZIStream))
    { DeleteFile(ZIStream) ; }

Il existe apparemment différents niveaux d'authentification. La plupart des articles que j'ai lus vous disent de définir MaxAllowedZone sur «1», ce qui signifie que la zone de la machine locale et la zone intranet sont autorisées mais que «4» permet l'accès à «toutes» les zones.

Pour plus d'informations, lisez cet article: https://support.microsoft.com/en-us/kb/892675

Voici à quoi ressemble mon registre (je n'étais pas sûr que cela fonctionnerait avec les caractères génériques mais cela semble fonctionner pour moi):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000004

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"UrlAllowList"="\\\\<network_path_root>;\\\\<network_path_root>\*;\\ies-inc.local;http://www.*;http://*;https://www.*;https://*;"

Comme note supplémentaire, bizarrement, la clé "UrlAllowList" était nécessaire pour que cela fonctionne sur un autre PC mais pas mon test. Ce n'est probablement pas du tout nécessaire, mais quand je l'ai ajouté, cela a résolu le problème. L'utilisateur n'a peut-être pas fermé le fichier d'origine ou quelque chose du genre. Donc juste une considération. Je suggère d'essayer le moins et de le tester, puis d'ajouter si nécessaire. Une fois que vous confirmez, vous pouvez déployer si nécessaire. Bonne chance!

Edit: PS Une autre méthode qui a fonctionné consistait à mapper le chemin d'accès au réseau localement en utilisant mklink / d (liaison symbolique dans Windows 7 ou plus récent), mais le mappage d'une lettre de lecteur réseau (Z: pour les tests) ne fonctionnait pas. Juste matière à réflexion et je n'ai pas eu à «débloquer» de fichiers. De plus, la «solution» acceptée n'a pas résolu le problème pour moi.