Pour moi (http://fr.wikipedia.org/wiki/Inode ) les inodes sont des structures de données propres au file-system (sous Unix notamment). Quel est le rapport avec le codage HTML ?
Si tu réfléchissais, en relisant l'intégralité des interventions, tu pourrais te douter de pourquoi j'ai proposer d'utiliser l'inode (même si je ne pensais qu'au numéro de nœud).
Pour moi (http://fr.wikipedia.org/wiki/Inode ) les inodes sont des
structures de données propres au file-system (sous Unix notamment). Quel
est le rapport avec le codage HTML ?
Si tu réfléchissais, en relisant l'intégralité des interventions, tu
pourrais te douter de pourquoi j'ai proposer d'utiliser l'inode (même si
je ne pensais qu'au numéro de nœud).
Pour moi (http://fr.wikipedia.org/wiki/Inode ) les inodes sont des structures de données propres au file-system (sous Unix notamment). Quel est le rapport avec le codage HTML ?
Si tu réfléchissais, en relisant l'intégralité des interventions, tu pourrais te douter de pourquoi j'ai proposer d'utiliser l'inode (même si je ne pensais qu'au numéro de nœud).
euh, il ne s'agit pas de codage html, mais le but de la manip est d'avoir un encodage d'un path quelconque (sous le DOCUMENT_ROOT du serveur) en ID au sens HTML/CSS du terme càd : commençant par une lettre A-Za-z et ne contenant que : A-Za-z0-9:.
Les caractères permis sont en fait : A-Za-z0-9:._-
26+26+10+4 = 66 caractères autorisés, soit un de plus que ce qui est nécessaire pour un encodage en Base64 : du coup, si tu veux pouvoir traiter tous les noms possibles d'une façon relativement compacte, c'est peut-être une idée à creuser.
function base64_pathname_encode($path) { return strtr(base64_encode($path), '+/=', '-:_'); } function base64_pathname_decode($id) { return base64_decode(strtr($id, '-:_', '+/=')); }
À partir du moment où le premier caractère du path est dans la partie ASCII 7 bits (par exemple s'il commence par un '/'), tu es en plus assuré que l'id commencera par l'une des lettres [A-Za-f], ce qui te permet de vérifier la condition HTML/CSS selon laquelle un id doit commencer par une lettre.
pour l'instant j'ai choisi (solution de facilité provisoire) d'utiliser "urlencode" côté php et encodeURIComponent côté JavaScript (ils ne sont pas rigoureusement équivalents), puis remplaçement des "%" par ":".
Ce n'est pas présent par défaut en JavaScript, mais on peut le trouver très facilement : <http://www.google.fr/search?qºse64+javascript>.
ça marche pas mal chez moi mais je n'utilise pas de catactères accentués dans les noms de fichiers, j'ai juste rencontré un problème avec un fichier nommé "User's guide.txt", amha c'est le "'" qui pose pb.
Avec cette méthode tu n'auras bien sûr pas de problème avec « ' ». En fait, le principal inconvénient que j'y vois (si c'en est un), c'est que le chemin n'est pas reconnaissable à l'½il quand on regarde le code source. Mais rien ne t'empêche de rajouter le chemin réel en commentaire si tu en as besoin.
Le 09/06/2008 08:27, Une Bévue a écrit :
euh, il ne s'agit pas de codage html, mais le but de la manip est
d'avoir un encodage d'un path quelconque (sous le DOCUMENT_ROOT du
serveur) en ID au sens HTML/CSS du terme càd :
commençant par une lettre A-Za-z
et ne contenant que :
A-Za-z0-9:.
Les caractères permis sont en fait :
A-Za-z0-9:._-
26+26+10+4 = 66 caractères autorisés, soit un de plus que ce qui est
nécessaire pour un encodage en Base64 : du coup, si tu veux pouvoir
traiter tous les noms possibles d'une façon relativement compacte,
c'est peut-être une idée à creuser.
function base64_pathname_encode($path) {
return strtr(base64_encode($path), '+/=', '-:_');
}
function base64_pathname_decode($id) {
return base64_decode(strtr($id, '-:_', '+/='));
}
À partir du moment où le premier caractère du path est dans la partie
ASCII 7 bits (par exemple s'il commence par un '/'), tu es en plus
assuré que l'id commencera par l'une des lettres [A-Za-f], ce qui te
permet de vérifier la condition HTML/CSS selon laquelle un id doit
commencer par une lettre.
pour l'instant j'ai choisi (solution de facilité provisoire) d'utiliser
"urlencode" côté php et encodeURIComponent côté JavaScript (ils ne sont
pas rigoureusement équivalents), puis remplaçement des "%" par ":".
Ce n'est pas présent par défaut en JavaScript, mais on peut le trouver
très facilement : <http://www.google.fr/search?qºse64+javascript>.
ça marche pas mal chez moi mais je n'utilise pas de catactères accentués
dans les noms de fichiers, j'ai juste rencontré un problème avec un
fichier nommé "User's guide.txt", amha c'est le "'" qui pose pb.
Avec cette méthode tu n'auras bien sûr pas de problème avec « ' ». En
fait, le principal inconvénient que j'y vois (si c'en est un), c'est
que le chemin n'est pas reconnaissable à l'½il quand on regarde le code
source. Mais rien ne t'empêche de rajouter le chemin réel en commentaire
si tu en as besoin.
euh, il ne s'agit pas de codage html, mais le but de la manip est d'avoir un encodage d'un path quelconque (sous le DOCUMENT_ROOT du serveur) en ID au sens HTML/CSS du terme càd : commençant par une lettre A-Za-z et ne contenant que : A-Za-z0-9:.
Les caractères permis sont en fait : A-Za-z0-9:._-
26+26+10+4 = 66 caractères autorisés, soit un de plus que ce qui est nécessaire pour un encodage en Base64 : du coup, si tu veux pouvoir traiter tous les noms possibles d'une façon relativement compacte, c'est peut-être une idée à creuser.
function base64_pathname_encode($path) { return strtr(base64_encode($path), '+/=', '-:_'); } function base64_pathname_decode($id) { return base64_decode(strtr($id, '-:_', '+/=')); }
À partir du moment où le premier caractère du path est dans la partie ASCII 7 bits (par exemple s'il commence par un '/'), tu es en plus assuré que l'id commencera par l'une des lettres [A-Za-f], ce qui te permet de vérifier la condition HTML/CSS selon laquelle un id doit commencer par une lettre.
pour l'instant j'ai choisi (solution de facilité provisoire) d'utiliser "urlencode" côté php et encodeURIComponent côté JavaScript (ils ne sont pas rigoureusement équivalents), puis remplaçement des "%" par ":".
Ce n'est pas présent par défaut en JavaScript, mais on peut le trouver très facilement : <http://www.google.fr/search?qºse64+javascript>.
ça marche pas mal chez moi mais je n'utilise pas de catactères accentués dans les noms de fichiers, j'ai juste rencontré un problème avec un fichier nommé "User's guide.txt", amha c'est le "'" qui pose pb.
Avec cette méthode tu n'auras bien sûr pas de problème avec « ' ». En fait, le principal inconvénient que j'y vois (si c'en est un), c'est que le chemin n'est pas reconnaissable à l'½il quand on regarde le code source. Mais rien ne t'empêche de rajouter le chemin réel en commentaire si tu en as besoin.
Olivier Miakinen
Le 09/06/2008 09:44, je répondais à Une Bévue :
[ Base64 modifié ]
À partir du moment où le premier caractère du path est dans la partie ASCII 7 bits (par exemple s'il commence par un '/'), tu es en plus assuré que l'id commencera par l'une des lettres [A-Za-f], ce qui te permet de vérifier la condition HTML/CSS selon laquelle un id doit commencer par une lettre.
Rien ne t'empêche d'ailleurs de rajouter toi-même une ou plusieurs lettres au début de l'ID, par exemple la chaîne « ID: ». Ainsi tu seras sûr que ton id généré ne sera jamais égal par hasard à un autre id que tu mettrais en dur dans le code HTML.
Le 09/06/2008 09:44, je répondais à Une Bévue :
[ Base64 modifié ]
À partir du moment où le premier caractère du path est dans la partie
ASCII 7 bits (par exemple s'il commence par un '/'), tu es en plus
assuré que l'id commencera par l'une des lettres [A-Za-f], ce qui te
permet de vérifier la condition HTML/CSS selon laquelle un id doit
commencer par une lettre.
Rien ne t'empêche d'ailleurs de rajouter toi-même une ou plusieurs
lettres au début de l'ID, par exemple la chaîne « ID: ». Ainsi tu
seras sûr que ton id généré ne sera jamais égal par hasard à un autre
id que tu mettrais en dur dans le code HTML.
À partir du moment où le premier caractère du path est dans la partie ASCII 7 bits (par exemple s'il commence par un '/'), tu es en plus assuré que l'id commencera par l'une des lettres [A-Za-f], ce qui te permet de vérifier la condition HTML/CSS selon laquelle un id doit commencer par une lettre.
Rien ne t'empêche d'ailleurs de rajouter toi-même une ou plusieurs lettres au début de l'ID, par exemple la chaîne « ID: ». Ainsi tu seras sûr que ton id généré ne sera jamais égal par hasard à un autre id que tu mettrais en dur dans le code HTML.
unbewusst.sein
Olivier Miakinen <om+ wrote:
Rien ne t'empêche d'ailleurs de rajouter toi-même une ou plusieurs lettres au début de l'ID, par exemple la chaîne « ID: ». Ainsi tu seras sûr que ton id généré ne sera jamais égal par hasard à un autre id que tu mettrais en dur dans le code HTML.
merci beaucoup pour tes précisions, notamment sur les caractères additionnels (_-), ça va modifier/simplifier mon code actuel en php. -- Une Bévue
Olivier Miakinen <om+news@miakinen.net> wrote:
Rien ne t'empêche d'ailleurs de rajouter toi-même une ou plusieurs
lettres au début de l'ID, par exemple la chaîne « ID: ». Ainsi tu
seras sûr que ton id généré ne sera jamais égal par hasard à un autre
id que tu mettrais en dur dans le code HTML.
merci beaucoup pour tes précisions, notamment sur les caractères
additionnels (_-), ça va modifier/simplifier mon code actuel en php.
--
Une Bévue
Rien ne t'empêche d'ailleurs de rajouter toi-même une ou plusieurs lettres au début de l'ID, par exemple la chaîne « ID: ». Ainsi tu seras sûr que ton id généré ne sera jamais égal par hasard à un autre id que tu mettrais en dur dans le code HTML.
merci beaucoup pour tes précisions, notamment sur les caractères additionnels (_-), ça va modifier/simplifier mon code actuel en php. -- Une Bévue
unbewusst.sein
Mickaël Wolff wrote:
Peut-être qu'il faudra que tu codes quelque chose d'équivalent à base64, mais adapté aux ID.
OUI !!! merci de m'avoir rappellé à base64. le seul pb est que base64 utilise 65 caractères dont trois (+, /, =) qui ne sont pas autorisés pour l'ID. une idée simple serait de transformer, après base64, le + en : et le / en ., reste à faire qqc pour le 65ième code (=).
comme = joue le rôle de complément, je peux sans doute m'arranger pour qu'il n'apparaisse pas càd faire en sorte que le nombre de bits soit tjs un multiple de 6, ou, plus facilement, le nombre d'octets multiple de 3.
par exemple en pré-inserrant des "/" (qui n'existent pas sur Unix) en fin de chaine.
-- Une Bévue
Mickaël Wolff <mickael.wolff@laposte.net> wrote:
Peut-être qu'il faudra que tu codes quelque chose d'équivalent à
base64, mais adapté aux ID.
OUI !!! merci de m'avoir rappellé à base64.
le seul pb est que base64 utilise 65 caractères dont trois (+, /, =) qui
ne sont pas autorisés pour l'ID. une idée simple serait de transformer,
après base64, le + en : et le / en ., reste à faire qqc pour le 65ième
code (=).
comme = joue le rôle de complément, je peux sans doute m'arranger pour
qu'il n'apparaisse pas càd faire en sorte que le nombre de bits soit tjs
un multiple de 6, ou, plus facilement, le nombre d'octets multiple de 3.
par exemple en pré-inserrant des "/" (qui n'existent pas sur Unix) en
fin de chaine.
Peut-être qu'il faudra que tu codes quelque chose d'équivalent à base64, mais adapté aux ID.
OUI !!! merci de m'avoir rappellé à base64. le seul pb est que base64 utilise 65 caractères dont trois (+, /, =) qui ne sont pas autorisés pour l'ID. une idée simple serait de transformer, après base64, le + en : et le / en ., reste à faire qqc pour le 65ième code (=).
comme = joue le rôle de complément, je peux sans doute m'arranger pour qu'il n'apparaisse pas càd faire en sorte que le nombre de bits soit tjs un multiple de 6, ou, plus facilement, le nombre d'octets multiple de 3.
par exemple en pré-inserrant des "/" (qui n'existent pas sur Unix) en fin de chaine.
-- Une Bévue
Olivier Miakinen
Le 09/06/2008 13:10, Une Bévue répondait à Mickaël Wolff :
Peut-être qu'il faudra que tu codes quelque chose d'équivalent à base64, mais adapté aux ID.
OUI !!! merci de m'avoir rappellé à base64.
Tiens, je n'avais pas vu que Mickaël l'avait déjà proposé. Et moi qui croyais avoir eu une idée originale ! ;-)
le seul pb est que base64 utilise 65 caractères dont trois (+, /, =) qui ne sont pas autorisés pour l'ID. une idée simple serait de transformer, après base64, le + en : et le / en ., reste à faire qqc pour le 65ième code (=).
Je ne vois toujours pas pourquoi tu t'interdis d'utiliser les caractères - et _ qui sont parfaitement valides.
Cela étant, il y aurait quand même plusieurs solutions possibles.
comme = joue le rôle de complément, je peux sans doute m'arranger pour qu'il n'apparaisse pas càd faire en sorte que le nombre de bits soit tjs un multiple de 6, ou, plus facilement, le nombre d'octets multiple de 3.
par exemple en pré-inserrant des "/" (qui n'existent pas sur Unix) en fin de chaine.
Plus simplement, tu supprimes les '=' après encodage, et tu les rajoutes avant le décodage, de façon à ce que la longueur de la chaîne encodée soit un multiple de 4. Les '=' et '==' ne servent que lorsque la chaîne encodée en Base64 est incluse dans un texte (par exemple un courriel) et qu'il est peu commode de calculer sa longueur.
Autre solution : tu codes le '+' par '::', le '/' par '..' et le '=' par ':.' ou '.:'.
Mais encore une fois les '-' et '_' sont autorisés dans un id.
Le 09/06/2008 13:10, Une Bévue répondait à Mickaël Wolff :
Peut-être qu'il faudra que tu codes quelque chose d'équivalent à
base64, mais adapté aux ID.
OUI !!! merci de m'avoir rappellé à base64.
Tiens, je n'avais pas vu que Mickaël l'avait déjà proposé. Et moi qui
croyais avoir eu une idée originale ! ;-)
le seul pb est que base64 utilise 65 caractères dont trois (+, /, =) qui
ne sont pas autorisés pour l'ID. une idée simple serait de transformer,
après base64, le + en : et le / en ., reste à faire qqc pour le 65ième
code (=).
Je ne vois toujours pas pourquoi tu t'interdis d'utiliser les caractères
- et _ qui sont parfaitement valides.
Cela étant, il y aurait quand même plusieurs solutions possibles.
comme = joue le rôle de complément, je peux sans doute m'arranger pour
qu'il n'apparaisse pas càd faire en sorte que le nombre de bits soit tjs
un multiple de 6, ou, plus facilement, le nombre d'octets multiple de 3.
par exemple en pré-inserrant des "/" (qui n'existent pas sur Unix) en
fin de chaine.
Plus simplement, tu supprimes les '=' après encodage, et tu les rajoutes
avant le décodage, de façon à ce que la longueur de la chaîne encodée
soit un multiple de 4. Les '=' et '==' ne servent que lorsque la chaîne
encodée en Base64 est incluse dans un texte (par exemple un courriel)
et qu'il est peu commode de calculer sa longueur.
Autre solution : tu codes le '+' par '::', le '/' par '..' et le '=' par
':.' ou '.:'.
Mais encore une fois les '-' et '_' sont autorisés dans un id.
Le 09/06/2008 13:10, Une Bévue répondait à Mickaël Wolff :
Peut-être qu'il faudra que tu codes quelque chose d'équivalent à base64, mais adapté aux ID.
OUI !!! merci de m'avoir rappellé à base64.
Tiens, je n'avais pas vu que Mickaël l'avait déjà proposé. Et moi qui croyais avoir eu une idée originale ! ;-)
le seul pb est que base64 utilise 65 caractères dont trois (+, /, =) qui ne sont pas autorisés pour l'ID. une idée simple serait de transformer, après base64, le + en : et le / en ., reste à faire qqc pour le 65ième code (=).
Je ne vois toujours pas pourquoi tu t'interdis d'utiliser les caractères - et _ qui sont parfaitement valides.
Cela étant, il y aurait quand même plusieurs solutions possibles.
comme = joue le rôle de complément, je peux sans doute m'arranger pour qu'il n'apparaisse pas càd faire en sorte que le nombre de bits soit tjs un multiple de 6, ou, plus facilement, le nombre d'octets multiple de 3.
par exemple en pré-inserrant des "/" (qui n'existent pas sur Unix) en fin de chaine.
Plus simplement, tu supprimes les '=' après encodage, et tu les rajoutes avant le décodage, de façon à ce que la longueur de la chaîne encodée soit un multiple de 4. Les '=' et '==' ne servent que lorsque la chaîne encodée en Base64 est incluse dans un texte (par exemple un courriel) et qu'il est peu commode de calculer sa longueur.
Autre solution : tu codes le '+' par '::', le '/' par '..' et le '=' par ':.' ou '.:'.
Mais encore une fois les '-' et '_' sont autorisés dans un id.
unbewusst.sein
Olivier Miakinen <om+ wrote:
Tiens, je n'avais pas vu que Mickaël l'avait déjà proposé. Et moi qui croyais avoir eu une idée originale ! ;-)
> le seul pb est que base64 utilise 65 caractères dont trois (+, /, =) qui > ne sont pas autorisés pour l'ID. une idée simple serait de transformer, > après base64, le + en : et le / en ., reste à faire qqc pour le 65ième > code (=).
Je ne vois toujours pas pourquoi tu t'interdis d'utiliser les caractères - et _ qui sont parfaitement valides.
Cela étant, il y aurait quand même plusieurs solutions possibles.
> comme = joue le rôle de complément, je peux sans doute m'arranger pour > qu'il n'apparaisse pas càd faire en sorte que le nombre de bits soit tjs > un multiple de 6, ou, plus facilement, le nombre d'octets multiple de 3. > > par exemple en pré-inserrant des "/" (qui n'existent pas sur Unix) en > fin de chaine.
Plus simplement, tu supprimes les '=' après encodage, et tu les rajoutes avant le décodage, de façon à ce que la longueur de la chaîne encodée soit un multiple de 4. Les '=' et '==' ne servent que lorsque la chaîne encodée en Base64 est incluse dans un texte (par exemple un courriel) et qu'il est peu commode de calculer sa longueur.
Autre solution : tu codes le '+' par '::', le '/' par '..' et le '=' par ':.' ou '.:'.
Mais encore une fois les '-' et '_' sont autorisés dans un id.
oui, oui, j'ai bien compris ton message, j'ai réalisé quelques tests et incorporé ça dans ma page "Ajax Tree File Browser", en adoptant tes conseils.
quand ça marchera sur free, je proposerai ça en téléchargement.
en fait, j'ai repris un design trouvable là : <http://gscripts.net/free-php-scripts/Listing_Script/AJAX_File_Browser/d etails.html>
que j'ai modifié en partie pour cet encodage.
faire un balayage de dossier par XHR est un très bonne idée, amha, le brouteur n'est pas surchargé car il n'avalle qu'un niveau de hiérarchie à la fois.
-- Une Bévue
Olivier Miakinen <om+news@miakinen.net> wrote:
Tiens, je n'avais pas vu que Mickaël l'avait déjà proposé. Et moi qui
croyais avoir eu une idée originale ! ;-)
> le seul pb est que base64 utilise 65 caractères dont trois (+, /, =) qui
> ne sont pas autorisés pour l'ID. une idée simple serait de transformer,
> après base64, le + en : et le / en ., reste à faire qqc pour le 65ième
> code (=).
Je ne vois toujours pas pourquoi tu t'interdis d'utiliser les caractères
- et _ qui sont parfaitement valides.
Cela étant, il y aurait quand même plusieurs solutions possibles.
> comme = joue le rôle de complément, je peux sans doute m'arranger pour
> qu'il n'apparaisse pas càd faire en sorte que le nombre de bits soit tjs
> un multiple de 6, ou, plus facilement, le nombre d'octets multiple de 3.
>
> par exemple en pré-inserrant des "/" (qui n'existent pas sur Unix) en
> fin de chaine.
Plus simplement, tu supprimes les '=' après encodage, et tu les rajoutes
avant le décodage, de façon à ce que la longueur de la chaîne encodée
soit un multiple de 4. Les '=' et '==' ne servent que lorsque la chaîne
encodée en Base64 est incluse dans un texte (par exemple un courriel)
et qu'il est peu commode de calculer sa longueur.
Autre solution : tu codes le '+' par '::', le '/' par '..' et le '=' par
':.' ou '.:'.
Mais encore une fois les '-' et '_' sont autorisés dans un id.
oui, oui, j'ai bien compris ton message, j'ai réalisé quelques tests et
incorporé ça dans ma page "Ajax Tree File Browser", en adoptant tes
conseils.
quand ça marchera sur free, je proposerai ça en téléchargement.
en fait, j'ai repris un design trouvable là :
<http://gscripts.net/free-php-scripts/Listing_Script/AJAX_File_Browser/d
etails.html>
que j'ai modifié en partie pour cet encodage.
faire un balayage de dossier par XHR est un très bonne idée, amha, le
brouteur n'est pas surchargé car il n'avalle qu'un niveau de hiérarchie
à la fois.
Tiens, je n'avais pas vu que Mickaël l'avait déjà proposé. Et moi qui croyais avoir eu une idée originale ! ;-)
> le seul pb est que base64 utilise 65 caractères dont trois (+, /, =) qui > ne sont pas autorisés pour l'ID. une idée simple serait de transformer, > après base64, le + en : et le / en ., reste à faire qqc pour le 65ième > code (=).
Je ne vois toujours pas pourquoi tu t'interdis d'utiliser les caractères - et _ qui sont parfaitement valides.
Cela étant, il y aurait quand même plusieurs solutions possibles.
> comme = joue le rôle de complément, je peux sans doute m'arranger pour > qu'il n'apparaisse pas càd faire en sorte que le nombre de bits soit tjs > un multiple de 6, ou, plus facilement, le nombre d'octets multiple de 3. > > par exemple en pré-inserrant des "/" (qui n'existent pas sur Unix) en > fin de chaine.
Plus simplement, tu supprimes les '=' après encodage, et tu les rajoutes avant le décodage, de façon à ce que la longueur de la chaîne encodée soit un multiple de 4. Les '=' et '==' ne servent que lorsque la chaîne encodée en Base64 est incluse dans un texte (par exemple un courriel) et qu'il est peu commode de calculer sa longueur.
Autre solution : tu codes le '+' par '::', le '/' par '..' et le '=' par ':.' ou '.:'.
Mais encore une fois les '-' et '_' sont autorisés dans un id.
oui, oui, j'ai bien compris ton message, j'ai réalisé quelques tests et incorporé ça dans ma page "Ajax Tree File Browser", en adoptant tes conseils.
quand ça marchera sur free, je proposerai ça en téléchargement.
en fait, j'ai repris un design trouvable là : <http://gscripts.net/free-php-scripts/Listing_Script/AJAX_File_Browser/d etails.html>
que j'ai modifié en partie pour cet encodage.
faire un balayage de dossier par XHR est un très bonne idée, amha, le brouteur n'est pas surchargé car il n'avalle qu'un niveau de hiérarchie à la fois.
-- Une Bévue
Vincent Lefevre
Dans l'article <1ii9dj8.6uv2tcs63f0cN%, Une Bévue écrit:
Mickaël Wolff wrote:
> En fait, l'inode est l'identifiant du fichier au sein du système de > fichier. Il y a deux problèmes qu'on peut entrevoir : > > - l'inode n'est unique que dans un même système de fichiers
pas grave, il doit-être particuliérement rare d'avoir un site qui fonctionne sur plusieurs systèmes de fichiers non ?
Mais l'édition d'un fichier peut modifier l'inode. Et les inodes changent en cas de récupération des données via un backup.
> Peut-être qu'il faudra que tu codes quelque chose d'équivalent à > base64, mais adapté aux ID.
ben il faut un codage unique rapide implémentable facilement en JS et en PHP, voire en ruby. comme, pour les noms de fichiers, la tendance est à l'utf-8, voire utf-16,
Ça n'a pas de sens. Un id est une suite de caractères, alors que de l'UTF-8 est une suite d'octets et l'UTF-16 est une suite de mots de 16 bits.
notes que l'auteur original de "AJAX_File_Browser" ne s'est pas cassé les pieds il a mis carément le path comme id sans-même encoder les "/"... et sur mac os x ça roule, mais il y a qq petits bugs dans ces scripts. <http://gscripts.net/free-php-scripts/Listing_Script/AJAX_File_Browser/d etails.html>
Pas standard. Et même sans parler d'id, certains caractères de contrôle (qui peuvent se trouver dans les noms de fichiers) sont incompatibles avec XML.
Dans l'article <1ii9dj8.6uv2tcs63f0cN%unbewusst.sein@weltanschauung.com.invalid>,
Une Bévue <unbewusst.sein@weltanschauung.com.invalid> écrit:
Mickaël Wolff <mickael.wolff@laposte.net> wrote:
> En fait, l'inode est l'identifiant du fichier au sein du système de
> fichier. Il y a deux problèmes qu'on peut entrevoir :
>
> - l'inode n'est unique que dans un même système de fichiers
pas grave, il doit-être particuliérement rare d'avoir un site qui
fonctionne sur plusieurs systèmes de fichiers non ?
Mais l'édition d'un fichier peut modifier l'inode. Et les inodes
changent en cas de récupération des données via un backup.
> Peut-être qu'il faudra que tu codes quelque chose d'équivalent à
> base64, mais adapté aux ID.
ben il faut un codage unique rapide implémentable facilement en JS et en
PHP, voire en ruby.
comme, pour les noms de fichiers, la tendance est à l'utf-8, voire
utf-16,
Ça n'a pas de sens. Un id est une suite de caractères, alors que de
l'UTF-8 est une suite d'octets et l'UTF-16 est une suite de mots de
16 bits.
notes que l'auteur original de "AJAX_File_Browser" ne s'est pas cassé
les pieds il a mis carément le path comme id sans-même encoder les
"/"...
et sur mac os x ça roule, mais il y a qq petits bugs dans ces scripts.
<http://gscripts.net/free-php-scripts/Listing_Script/AJAX_File_Browser/d
etails.html>
Pas standard. Et même sans parler d'id, certains caractères de contrôle
(qui peuvent se trouver dans les noms de fichiers) sont incompatibles
avec XML.
Dans l'article <1ii9dj8.6uv2tcs63f0cN%, Une Bévue écrit:
Mickaël Wolff wrote:
> En fait, l'inode est l'identifiant du fichier au sein du système de > fichier. Il y a deux problèmes qu'on peut entrevoir : > > - l'inode n'est unique que dans un même système de fichiers
pas grave, il doit-être particuliérement rare d'avoir un site qui fonctionne sur plusieurs systèmes de fichiers non ?
Mais l'édition d'un fichier peut modifier l'inode. Et les inodes changent en cas de récupération des données via un backup.
> Peut-être qu'il faudra que tu codes quelque chose d'équivalent à > base64, mais adapté aux ID.
ben il faut un codage unique rapide implémentable facilement en JS et en PHP, voire en ruby. comme, pour les noms de fichiers, la tendance est à l'utf-8, voire utf-16,
Ça n'a pas de sens. Un id est une suite de caractères, alors que de l'UTF-8 est une suite d'octets et l'UTF-16 est une suite de mots de 16 bits.
notes que l'auteur original de "AJAX_File_Browser" ne s'est pas cassé les pieds il a mis carément le path comme id sans-même encoder les "/"... et sur mac os x ça roule, mais il y a qq petits bugs dans ces scripts. <http://gscripts.net/free-php-scripts/Listing_Script/AJAX_File_Browser/d etails.html>
Pas standard. Et même sans parler d'id, certains caractères de contrôle (qui peuvent se trouver dans les noms de fichiers) sont incompatibles avec XML.
Dans l'article <484d1639$, Olivier Miakinen <om+ écrit:
Autre solution : tu codes le '+' par '::', le '/' par '..' et le '=' par ':.' ou '.:'.
Mieux vaut faire un codage adapté sans passer par base64. Et puis éviter d'utiliser ":" dans les id: c'est incompatible avec les namespaces, et en particulier avec XPath:
Dans l'article <484d1639$1@neottia.net>,
Olivier Miakinen <om+news@miakinen.net> écrit:
Autre solution : tu codes le '+' par '::', le '/' par '..' et le '=' par
':.' ou '.:'.
Mieux vaut faire un codage adapté sans passer par base64. Et puis éviter
d'utiliser ":" dans les id: c'est incompatible avec les namespaces, et
en particulier avec XPath:
Dans l'article <484d1639$, Olivier Miakinen <om+ écrit:
Autre solution : tu codes le '+' par '::', le '/' par '..' et le '=' par ':.' ou '.:'.
Mieux vaut faire un codage adapté sans passer par base64. Et puis éviter d'utiliser ":" dans les id: c'est incompatible avec les namespaces, et en particulier avec XPath:
Mieux vaut faire un codage adapté sans passer par base64.
Pourquoi cela ? Je trouve au contraire préférable d'utiliser un transcodage bien éprouvé, quitte à remplacer 3 caractères sur les 65. Bien sûr, on peut s'amuser à coder soi-même un équivalent qui le fasse directement (surtout en JS où ça n'existe pas en standard), mais pratiquement je n'y vois que des inconvénients.
Et puis éviter d'utiliser ":" dans les id: c'est incompatible avec les namespaces, et en particulier avec XPath:
http://bugzilla.gnome.org/show_bug.cgi?id7841
D'accord. Ça ne pose pas de problème, il suffit d'utiliser le « . » à la place du « : » pour remplacer le « / » de Base64.
Le 11/06/2008 01:05, Vincent Lefevre a écrit :
Mieux vaut faire un codage adapté sans passer par base64.
Pourquoi cela ? Je trouve au contraire préférable d'utiliser un
transcodage bien éprouvé, quitte à remplacer 3 caractères sur les
65. Bien sûr, on peut s'amuser à coder soi-même un équivalent qui
le fasse directement (surtout en JS où ça n'existe pas en standard),
mais pratiquement je n'y vois que des inconvénients.
Et puis éviter
d'utiliser ":" dans les id: c'est incompatible avec les namespaces, et
en particulier avec XPath:
http://bugzilla.gnome.org/show_bug.cgi?id7841
D'accord. Ça ne pose pas de problème, il suffit d'utiliser le « . » à la
place du « : » pour remplacer le « / » de Base64.
Mieux vaut faire un codage adapté sans passer par base64.
Pourquoi cela ? Je trouve au contraire préférable d'utiliser un transcodage bien éprouvé, quitte à remplacer 3 caractères sur les 65. Bien sûr, on peut s'amuser à coder soi-même un équivalent qui le fasse directement (surtout en JS où ça n'existe pas en standard), mais pratiquement je n'y vois que des inconvénients.
Et puis éviter d'utiliser ":" dans les id: c'est incompatible avec les namespaces, et en particulier avec XPath:
http://bugzilla.gnome.org/show_bug.cgi?id7841
D'accord. Ça ne pose pas de problème, il suffit d'utiliser le « . » à la place du « : » pour remplacer le « / » de Base64.
