web-dev-qa-db-fra.com

Comment obtenir l'URL Hash (#) depuis le serveur

Je sais que côté client (javascript), vous pouvez utiliser windows.location.hash mais que vous ne trouvez pas accès au serveur.

asp.neturlfragment-identifier
130
Ricky Supit

Nous nous sommes trouvés dans une situation où nous devions conserver le hachage d'URL dans les publications ASP.Net. Comme le navigateur n'envoie pas le hachage au serveur par défaut, la seule façon de le faire est d'utiliser du Javascript:

  1. Lorsque le formulaire est soumis, prenez le hachage (window.location.hash) Et stockez-le dans un champ de saisie masqué côté serveur. Placez-le dans une DIV avec un identifiant de "urlhash" afin que nous puissions le trouver facilement. plus tard.

  2. Sur le serveur vous pouvez utiliser cette valeur si vous devez faire quelque chose avec elle. Vous pouvez même le changer si vous en avez besoin.

  3. Au chargement de la page sur le client, vérifiez la valeur de ce champ masqué. Vous voudrez le trouver par la DIV dans laquelle il est contenu, car l'ID généré automatiquement ne sera pas connu. Oui, vous pouvez faire quelques ruses avec .ClientID, mais nous avons trouvé plus simple d’utiliser simplement le wrapper DIV, car cela permet à tout ce Javascript de vivre dans un fichier externe et d’être utilisé de manière générique. .

  4. Si le champ de saisie masqué a une valeur valide, définissez-le comme un hachage d'URL (window.location.hash again) Et/ou effectuez d'autres actions.

Nous avons utilisé jQuery pour simplifier la sélection du champ, etc. En somme, il s’agit de quelques appels jQuery, un pour enregistrer la valeur et un autre pour le restaurer.

Avant de soumettre:

$("form").submit(function() {
  $("input", "#urlhash").val(window.location.hash);
});

Sur le chargement de la page:

var hashVal = $("input", "#urlhash").val();
if (IsHashValid(hashVal)) {
  window.location.hash = hashVal;
}

IsHashValid() peut vérifier "undefined" ou d'autres choses que vous ne voulez pas gérer.

Assurez-vous également que vous utilisez $(document).ready() correctement, bien sûr.

131
Chris

RFC 2396 section 4.1:

Lorsqu'une référence URI est utilisée pour effectuer une action d'extraction sur la ressource identifiée, l'identificateur de fragment facultatif, séparé de l'URI par un caractère hachuré ("#"), consiste en des informations de référence supplémentaires destinées à être interprété par l'agent d'utilisateur une fois l'opération de récupération terminée . En tant que tel, il ne fait pas partie d'un URI, mais est souvent utilisé conjointement avec un URI.

(emphase ajoutée)

79
Mauricio Scheffer

C'est parce que le navigateur ne transmet pas cette partie au serveur, désolé.

41
Julien Oster

Le seul choix est probablement de le lire côté client et de le transférer manuellement sur le serveur (GET/POST/AJAX). Cordialement Artur

Vous pouvez aussi voir comment jouer avec le bouton Précédent et l'historique du navigateur chez Malcan

7
Artur

Juste pour exclure la possibilité que vous n'essayiez pas réellement de voir le fragment sur un GET/POST et que vous vouliez savoir comment accéder à la partie d'un objet URI que vous avez dans votre code côté serveur, elle se trouve sous Uri.Fragment ( MSDN docs ).

3
patridge

Solution possible pour les requêtes GET:

Nouveau format de lien: http://example.com/yourDirectory?hash=video01

Appelez cette fonction vers le haut du contrôleur ou http://example.com/yourDirectory/index.php:

function redirect()
{
    if (!empty($_GET['hash'])) {
        /** Sanitize & Validate $_GET['hash']
               If valid return string
               If invalid: return empty or false
        ******************************************************/
        $validHash = sanitizeAndValidateHashFunction($_GET['hash']);
        if (!empty($validHash)) {
            $url = './#' . $validHash;
        } else {
            $url = '/your404page.php';
        }
        header("Location: $url");
    }
}
0
webaholik