2010-06-10 2 views
0

J'utilise la balise imageen utilisant des caractères i18n dans l'URL de la balise d'image ne pas afficher l'image

<image src="/data/image/image.txt" /> 

le chemin /data/image/image.txt n'existe.

et il affiche également l'image.

mais quand je présente quelques caractères i18n dans le chemin permet de dire

<image src="/data/image组织/image.txt" /> 

il dit 404 image d'erreur non trouvée, mais le chemin/données/image 组织 /image.txt n'existe,

s'il vous plaît aidez-moi à trouver la solution pour cela?

J'ai utilisé le firebug aussi pour voir si les caractères sont décodés correctement ou non, dans firebug je suis capable de voir les caractères corrects ils ne sont pas changés, toujours il n'est pas capable de choisir l'image.

merci beaucoup à l'avance.

Note: J'utilise la balise <image> car elle ne me permettait pas d'écrire l'onglet img dans la publication, et j'ai changé le jif ext en txt.

considérez s'il vous plaît cela.

Répondre

0

Les caractères Unicode SONT légaux dans la partie de l'URL que vous les mettez, donc vous avez un problème ailleurs - probablement sur votre serveur web. Vérifiez les journaux de votre serveur Web pour vous assurer que le code 404 émis correspond à l'URL que vous pensez demander du côté du navigateur Web. Vous pouvez constater une incompatibilité dans l'encodage utilisé par le navigateur et la façon dont le serveur l'analyse (si votre serveur est capable de servir un URI internationalisé en premier lieu). Gardez à l'esprit que votre système de fichiers doit également prendre en charge Unicode et que votre serveur Web doit respecter l'encodage de votre système de fichiers. De plus, puisque vous n'avez pas précisé que vous utilisiez unicode (ce qui serait le moyen "facile"), les caractères non-unicode sont également légaux, mais la situation est beaucoup plus délicate. Une fois que vous commencez à introduire des jeux de caractères non-Unicode comme Shift-JIS, vous augmentez massivement le nombre d'outils qui doivent être compris et ne pas bousiller votre encodage de caractères.

+0

Les caractères non-ASCII dans les URI ne sont pas légaux (voir RFC 3986), mais le contenu de img/@ src dans HTML n'est pas un URI, cela peut fonctionner, en supposant que la page web et le serveur web quel encodage est utilisé (la requête passe par HTTP, ce qui * est * ASCII simple dans la ligne de requête). –

+0

Bah, je voulais dire l'URL. La seule partie de la ligne GET dans un en-tête qui doit être en latin-1 (et encore moins, en fait, certains caractères sont réservés) est le composant hôte. Le chemin après la résolution de l'hôte peut être dans n'importe quel codage sur lequel le client et le serveur peuvent s'entendre. –

+0

Salut à tous, pour la même demande que j'ai "Accept-Charset \t ISO-8859-1, utf-8; q = 0,7, *; q = 0,7" dans ma tête de requête wheras « Contenu -Type \t text/html; charset = utf-8 " dans mon en-tête de réponse. où je suis PASING le "src = portail/modules/fw/ma 组织 /homepage_title.gif" et la demande générée est "https: // /np/portal/modules/fw/my% E7% BB% 84% E7% BB% 87/homepage_title.gif " et la réponse dit "La ressource demandée (/ np/portal/modules/fw/my% E7% BB% 84% E7% BB% 87 /homepage_title.gif) ne sont pas disponibles." s'il vous plaît laissez-moi savoir si je manque quelque chose. – user363171

Questions connexes