Kial kelkaj URL-j finiĝas per suprenstreko?

Eble vi trovis URL-jn, kiuj finiĝas per suprenstreko (kiel https://freakspot.net/eo//, servila dosieruja radiko), kaj aliajn, kiuj ne finiĝas per suprenstreko (kiel ĉi tiu : https://www.gnu.org/gnu/gnu.html). Kio estas la diferenco? Ĉu gravas?

URL estas esence adreso al afero. La URL-j ne nur aludas retejojn, sed ankaŭ aliajn specojn de aferoj. Kelkaj ekzemploj de URL-skemoj estas http, https, ftp, telnet, data kaj mailto. En ĉi tiu artikolo mi parolas pri retejoj, kiuj uzas la http- aŭ la https-skemon.

URL-adresoj, kiuj finiĝas per suprenstreko, referencas dosierujon; tiuj, kiuj ne, referencas dosieron. Kiam vi klakas la ligilon https://freakspot.net/eo, la servilo rimarkas, ke la bezonata adreso ne estas dosiero, kaj iras al https://freakspot.net/eo/. Ĉi tie ĝi trovas ĉefan dosieron nomitan index.htmlindex kun alia finaĵo kaj montras ĝian enhavon.

Sekve la ŝarĝo de retejo estas pli rapida, kiam ni uzas ligilojn al ĉefaj retejoj, kiuj finiĝas per suprenstrekoj (ekzemple /) aŭ kiam ni ligas al la dosiernomo (ekzemple https://freakspot.net/eo/arba-strukturo-per-CSS-kaj-HTML/index.html).

Arba strukturo per CSS kaj HTML

Kelkfoje utilas prezenti datumojn per arba strukturo kiel tiu, kiun kreas la tree-programo. La tree-programo kreas eligon de arbo de dosierujoj kiel tiu ĉi:


✔ /var/www/html/Repos/Freak-Spot/freak-theme [master|✔] $ tree
.
├── static
│   ├── css
│   │   └── style.css
│   ├── genericons
│   │   ├── COPYING.txt
│   │   ├── genericons.css
│   │   ├── Genericons.eot
│   │   ├── Genericons.svg
│   │   ├── Genericons.ttf
│   │   ├── Genericons.woff
│   │   ├── LICENSE.txt
│   │   └── README.md
│   ├── images
│   │   ├── creativecommons_public-domain_80x15.png
│   │   ├── gnu-head-mini.png
│   │   └── questioncopyright-favicon.png
│   └── js
│       ├── functions.js
│       └── jquery-3.1.1.js
└── templates
    ├── archives.html
    ├── article.html
    ├── article_info.html
    ├── author.html
    ├── authors.html
    ├── base.html
    ├── category.html
    ├── index.html
    ├── page.html
    ├── pagination.html
    ├── period_archives.html
    ├── tag.html
    ├── taglist.html
    └── tags.html

6 directories, 28 files

Por prezenti la komandon tiel, kiel ĝi aperas en terminalo, mi uzis la HTML-etikedojn <samp> kaj <pre> (<pre><samp>eliro de tree</samp></pre>). Sed kio okazas, se mi volas inkludi ligilon aŭ uzi aliajn HTML-elementojn, aŭ CSS? Tiuokaze ni devas uzi CSS por montri la branĉan aspekton.

Legu plu el Arba strukturo per CSS kaj HTML

Trovi rompitajn ligilojn en retejo

«Paĝo ne trovita», «eraro 404», ktp.: tio ĝenas. Do, reta programisto, serĉu kaj reparu la rompitajn ligilojn de via retejo de tempo al tempo.

Trovi ilin

Ekzistas multaj retaj iloj; mia prefera estas W3C Link Checker. Eblas ankaŭ instali ĝin en via komputilo, ĉar ĝi estas libera programaro.

La instruoj pri ĝia uzado troviĝas en ĝia deponejo. Mi montras rapide al vi en la jena video, kiel instali kaj uzi ĝin en via komputilo:

Legu plu el Trovi rompitajn ligilojn en retejo

Efektive validigi HTML-n

La lingvo HTML konformas kun la WHATWG-normo. Ĉar ĝi estas markolingvo, eraro en HTML ne kaŭzas, ke la paĝaro ceŝu funkcii, sed la retumilo ĝin montras kiel eble plej bone.

Havi erarojn en HTML estas problema, ĉar ĝi povas aperigi neatenditajn kaj malfacile reprodukteblajn erarojn, ĉefe kiam ili nur aperas en konkreta retumilo. Do estas necesega skribi validan HTML-n.

Tamen estas facile fari erarojn kaj ĝin pretervidi. Sekve oni rekomendas validigi la HTML-kodon, tio estas, trovi la erarojn kaj korekti ilin. Por tio ekzistas validiloj, kiuj generale simple montras erarojn. La plej ĝisdatigita kaj rekomendinda estas The Nu Html Checker. La W3C subtenas nodon de ĉi tiu validilo, kiu permesas al ni validigi HTML-dokumentojn en la retumilo, enigante URL-n, alŝutante dosieron kaj skribante la kodon en formularo. Ĉar ĉi tiu validilo estas libera programaro, vi povas instali ĝin facile en via komputilo.

Reta validado de la retejo de GNU https://gnu.org/.

La reta validilo bone funkcias, se vi nur devas validigi kelkajn retejojn okaze, sed ĝi ne utilas por validigi tutan retejon. Por tio mi rekomendas uzi la version de The Nu Html Checker, kiun oni plenumas en terminalo. Ĝi troviĝas en la dosiero vnu.jar (Java estas bezona).

Mi persone uzas la html5validator-pakon, ĉar mi laboras kun Python kaj ĝi ne signifas kroma dependaĵo. Por instali ĉi tiun pakon en GNU/Linukso-distribuo bazita sur Debiano oni nur devas plenumi...

sudo apt install default-jre
sudo pip3 install html5validator

Post la instalo havas ni programon kun la nomo html5validator, kiun ni povas plenumi en la terminalo:

html5validator index.html

Utilega argumento estas --root, kiu permesas validigi ĉiujn dosierojn en dosierujo, kaj en la dosierujo ene de la dosierujo..., tiel ĝis ĉiun ĝi validigis. Mi uzas ĝin donante la kernan dosierujon de mia retejo, validante tiel la tutan retejon en kelkaj sekundoj.

html5validator --root retejo/

Estas inde uzi ian kontinuan integriĝon por eviti plenumi mane la antaŭan komandon ĉiam, kiam vi ŝanĝas ion en la retejo. Por tio mi uzas GitLab CI. Tiel mi prizorgas ĉi tiun retejon kaj multajn aliajn sen HTML-eraroj kaj kiam mi rompas ion, mi rimarkas baldaŭ.

Ĉi tiu testo de GitLab CI montras, ke la retejo estis kreita sukcese kaj sen HTML-eraroj.