Diskussion:Uniform Resource Locator

genus

beginn der diskussion (2003)

Genus: weshalb heißt es hier "der URL", sollte es nicht "die URL" (lt. Duden) heißen?

Was ist ein Orter?? Mir ist dieses Wort bis jetzt nicht untergekommen ... --zeno 01:17, 11. Mai 2003 (CEST)

Nehmen wir doch "Ortsangabe"--3247 21:57, 7. Dez 2003 (CET)

Ist in diesem Fall ein Link zu Locator wirklich sinnvoll? Wenn, dann doch eher zur engl. Wikipedia, aber dort führt die Suche nach Locator auch zu URL. Euripides 15:54, 16. Jun 2003 (CEST)

@Hinweis:Locator> Ich denke eher an lokalisieren > ("Die") Lokalisation/(Gedanklich auch Position!!! (Die menschlichen Denkwege nicht vergessen...)) ("Gib mir mal die Einzigartige Gegenstands Position") Julian

Der oder die? (2005-2007)

Wenn unser aller Duden „die“ schreibt, sollte man da wirklich von „Fehler“ reden? Eine Herleitung über Wortbestandteile oder auch synonyme deutsche Wörter ist nicht sinnvoll, vor allem nicht, wenn dieser Wortbestandteil das urdeutsche Wort „Locator“ ist. Heißt es „die Pub“, weil Kneipe im Deutschen weiblich ist? Oder natürlich „das Whisky“, wegen des sächlichen Wassers?

Der Duden dokumentiert ja nur die deutsche Sprache wie sie verwendet wird. Sprich wenn alle "Sinn macht" benutzen wird diese Verwendung irgendwann auch im Duden auftauchen, egal ob das Deutschlehrern passt oder nicht. Bei vielen gängigen Lehn- und Fremdwörtern hat sich ein gewisser Artikel einfach durchgesetzt. Bei neuen Wörtern ist es aber durchaus üblich den Artikel an der Übersetzung festzumachen. Oft gibt es aber mehrere gute Übersetzungsmöglichkeiten und wenn man diese nennt wird das Gegenüber das in der Regel auch akzeptieren. --Cyclonus 23:54, 13. Jun 2005 (CEST)

Zusätzlich eine kleine Statistik über die Verbreitung im Internet: Eine Suche auf A9 ergibt mit die URL etwa 190.000 Treffer, mit der URL dagegen lediglich 57.200, obwohl in der Abfrage nur einige wichtige Akkusative ausgeklammert wurden, also noch genügend weitere weibliche Verwendungen mit enthalten sind. -- Mike, 16.02.2005

Dann such mal nach "das selbe" (mit Anführungsstrichen) und "dasselbe". Was beweist das? Die Mehrheit der Nutzer im Internet hat keine Ahnung von Rechtschreibung. Blödsinn, es beweist natürlich gar nichts. Ich gehe davon aus, dass sich "die" eingebürgert hat, weil es sprachlich gut passt völlig unabhängig von der Übersetzung. URL klingt schließlich ähnlich wie "Uhr" oder "Urne". Lokator gibt es im Deutschen zwar, im Duden steht aber auch (im Mittelalter...Land verteilender Ritter). Es ist wohl kaum ein gebräuchliches Wort und Locator mit Lokator zu übersetzen wäre wenig sinnvoll. --Cyclonus 23:54, 13. Jun 2005 (CEST)

Ich finde eine Frage nach dem Artikel hat in WikiPEDIA ohnehin nichts zu suchen, sondern gehört nach Wiktionary. --84.145.84.102 03:01, 6. Nov 2005 (CET) / Verzeihung,.. war nicht angemeldet --Calestyo 03:02, 6. Nov 2005 (CET)

Klar, da gehört ein entsprechender Vermerk hinter das Lemma. wikt:URL Hier sollte aber auch eine einheitliche und möglichst mehrheitsfähige Praxis gefunden werden:

A: URL – Was soll'n das sein?

B: Das ist die Adresse, die du da oben eingeben kannst!

A: Ach so, die URL – sach's doch gleich...

Die Langform von URL habe ich von Anfang an gekannt; „Lokator“ sagt aber im deutschen Sprachgebrauch kein halbwegs gesunder Mensch, wenn er auch Adresse sagen könnte. Deswegen ist diese Abkürzung feminin, punktum. Ich schreite jetzt zur Tat. --Tobias 06:35, 11. Apr. 2007 (CEST)

Der-Die-Streiterei (2005)

Der bizarre Streit um den Genus von URL erinnert mich an die entsprechende Zwiebelfisch-Kolumne „Krieg der Geschlechter“. Ich habe mich (nun zum zweiten Male) bemüht, den Artikel wertungsneutral zu verfassen, um den Verfechtern des der, die sich zwar in der Minderheit befinden, dafür aber um so fleißiger sind, nicht auf die Füße zu treten. Leider wurde diese Rücksichtnahme nicht belohnt.

Ich möchte doch darum bitten, an Polemik grenzende Bemerkungen wie „wohl um [...] zu rechtfertigen“ nur auf den Diskussionsseiten zu verwenden. Wie meine Bemerkungen oben und auch weitere Beispiele zeigen, ist das Geschlecht von Lehnwörtern nicht einfach durch Analogien zu bestimmen. -- Mike, 9. Mai 2005

zusammenfassung/stand der dinge (2007)

beide genera werden fuer "url" verwendet. im duden werden mittlerweile ebenfalls beide aufgefuehrt, wobei dem maskulinum das attribut "selten" verpasst bekommt, was auch der realitaet entspricht. allerdings ist einer enzklopaedie herzlich egal, wie oft etwas verwendet wird, weswegen ja beispielsweise auch die lemmata automobil (statt "auto") und omnibus (statt "bus") die jeweiligen fahrzeuge beschreiben.
dass "url" haeufiger als femininum eingestuft wird, liegt imho sehr wahrscheinlich daran, dass den wenigsten die lange form "uniform resource locator" bekannt ist. viele denken zudem, dass das "l" fuer "location" stuende. ein aehnliches problem duerfte "ide" fuer integrated development environment sein. "ide" hat ebenfalls zwei genera, femininum und neutrum. denn "ide" ist auch die abkuerzung fuer die deutsche uebersetzung "integrierte entwicklungsumgebung", was eindeutig femininum ist. "environment" steht allerdings sogar im duden als neutrum. somit gibt es auch hier in der sprachlichen verwendung kein richtig oder falsch.
der artikel ist jetzt mit dem maskulinum konsistent. deshalb habe ich eine kuerzliche umstellung m.->f. mit dem hinweis "kein mehrwert, da beides richtig ist" revertiert. -- seth 14:20, 4. Nov. 2007 (CET)

Der bei weitem gebräuchlichere Genus ist feminin, was auch aus dem Artikel hervorgeht; „der URL“ ist eben so selten, daß der Duden von dieser Variante zunächst nichts mitbekommen hat (und man kann eben nicht schließen, daß dieser Gebrauch zunehmen würde!). Daß das von einer Unkenntnis der Langform herrühren würde, ist eine durch nichts belegte Mutmaßung. Ebenso plausibel ist nämlich, daß man sich „URL“ üblicherweise als „Adresse“ übersetzt. Ich habe wieder auf „konsistent feminin“ geändert und betrachte jede weitere Reversion ohne eine tatsächliche Änderung im allgemeinen Sprachgebrauch als Vandalismus. Es gibt keinen Grund, in der Wikipedia vom allgemeinen Sprachgebrauch abzuweichen. --Tobias 15:10, 22. Jan. 2008 (CET)

zur herkunft des femininum: selbstverstaendlich ist es reine mutmassung (beachte die begriffe "imho" und "wahrscheinlich"). das uebernehmen des genus des schwachen synonyms "adresse" will ich gar nicht abstreiten. ebensowenig behaupte ich, dass der maskuline gebrauch zunaehme. das ist jedoch nicht der punkt. jener naemlich dreht sich um die fachsprachlich "richtigere" verwendung von "url", wie z.b. [1].

verwechsle nicht die meta- mit der objektsprache. beispiel: im allgemeinen sprachgebrauch verwendet kaum jemand den konjunktiv. und dennoch verwenden wir ihn in der wikipedia. allerdings schreiben wir im artikel konjunktiv, dass er selten verwendet wird. beispiel schlecht? ok, anderes beispiel: homepage, website, webseite. beachte auch die elend langen diskussionen, in denen sogar einige leute es als falsch darstellen wollten, dass "homepage" ugs. synonym zu "website" sei. bei "url" sind beide genera richtig, auch wenn maskulinum seltener verwendet wird. jedoch kaeme wohl kein vernfuenftiger mensch (ja, wieder mutmassung) auf die idee, ueber die uniform resource locator zu reden/schreiben. ich revertiere deswegen deine aenderungen. -- seth 00:02, 23. Jan. 2008 (CET)

Deine Beispiele sind sämtlich irrelevant. Und Deine Shift-Taste ist defekt.

Du erkennst an, daß „beide Genera richtig“ seien, und daß „die URL“ häufiger ist (und zwar weit häufiger). Eine einzelne, zehn Jahre alte Seite der Uni Bielefeld (zuletzt geändert am Dienstag, 12. August 1997, 11:27:38 Uhr) ist ja wohl kaum Beleg genug dafür, daß „der“ richtig und „die“ falsch sei. Inzwischen hat sich der Gebrauch „die URL“ durchgesetzt und ist damit richtig, punktum. Deine Auffassung, daß das „fachsprachlich falsch“ sei, fällt m. E. unter Theoriefindung.

Natürlich sagt niemand „die Uniform Resource Locator“ – die Langform einer englischen Abkürzung würde einfach im Deutschen niemand verwenden. Es ist aber eine bekannte Tatsache, daß sich für Abkürzungen oft ein eigener Genus einbürgert. Die Endung „-ator“ ist in der Abkürzung verdeckt und spielt für das grammatikalische Geschlecht keine Rolle mehr; es sagt ja auch niemand „der Modem“, obwohl durchaus viele wissen, daß es sich um ein Kurzwort für Modulator/Demodulator handelt. Es ist nicht die Aufgabe der Wikipedia, hier eine absolute Minderheitenposition zu vertreten und damit die Sprachgemeinschaft zu verunsichern. (Außerdem gab es schon bei den Römern Fälle, wo Genus und Endung nicht zusammenpaßten, wie z. B. beim „agricola“, dem Bauern. Das war also nie eine unumstößliche Regel)

Bevor Du also wieder revertest, bringe bitte hier auf der Diskussionsseite stichhaltigere Argumente bei, z. B. einen Link zu einer Wikipedia-Richtlinie, die dazu ermuntert, in solchen Fällen gegen den allgemeinen Usus auf einer absoluten Außenseiterposition zu bestehen. Ich respektiere in Artikeln ja auch, daß in der deutschen Wikipedia „reformiert“ geschrieben wird. Also solltest Du in der Lage sein, Deine formalgrammatikalischen Prinzipien dem Usus unterzuordnen; natürliche Sprachen funktionieren so einfach nicht. --Tobias 03:35, 25. Jan. 2008 (CET)

hey, unterstelle mir nichts, was ich nicht gesagt/geschrieben habe! "fachsprachlich falsch" habe ich nirgends geschrieben! weitere antwort folgt spaeter. -- seth 11:27, 25. Jan. 2008 (CET)

deine gegenargumente waeren ja an sich vielleicht gar nicht so schlecht, allerdings muessten sie sich dann gegen argumente deines diskussionspartners richten. das tun sie aber nicht, da ich an keiner stelle sage, dass das femininum bei "url" falsch sei. unterstelle mir also nichts, was ich nicht geschrieben habe! die bielefeld-seite war uebrigens lediglich ein willkuerliches beispiel, das mir google spontan ausspuckte. ich koennte noch viele weitere nennen.

dass "niemand" die langform verwendet, wird schon allein durch den wikipedia-artikel falsifiziert. aber egal; ich habe sogar ein paar ganz wenige leute gefunden, die bei der ausgeschriebenben form femininum verwenden, - siehe [2] - einige bilden aber bloss einen (vielleicht an "computer" angelehnten) seltsamen plural und machen damit keine aussage ueber das genus.

zum modem: selbstverstaendlich sagen leute auch "der modem". und diese ist auch die zuerst angefuehrte version im duden. abgesehen davon ist "modem" eher als kunst-/kurzwort denn als abkuerzung wie "pkw", "lsd" oder eben "url" zu sehen. die roemer sind uebrigens heute bei der diskussion um "url" herzlich egal, auch wenn selbstverstaendlich die etymologischen wurzeln dort anzusiedeln sind.

kurz: deine argumentation ist imho noch weniger stichhaltig als du mir es bei meiner unterstellst. dennoch habe ich keine weitere lust mich mit diesem thema zu befassen; zumal es letzlich wirklich sehr haarspalterisch ist, die eine ueber die andere version stellen zu wollen; letztlich laeuft es immer darauf hinaus: [3].

ps. meine shift-taste ist uebrigens nicht defekt, sondern funktioniert ganz hervorragend. zu stehenden autos sagst du doch auch nicht, dass sie kaputt seien. ;-p -- seth 11:10, 28. Jan. 2008 (CET)

Weitere Anmerkung zur Genusfrage (2008)

Ist die Mehrheitsmeinung eigentlich im Allgemeinen richtig? D.h. kann man diese Schlussfolgerung als immer geltend betrachten: "Wenn die Mehrheit eine Aussage für wahr hält, dann ist sie auch wahr."? Die Geschichte zeigt, dass dies nicht immer stimmt: Im Mittelalter glaubte die Mehrheit der Leute, dass es niemals einem Menschen möglich sein kann, sich schneller als das gesprochene Wort (der Schall) fortzubewegen. Jedoch war und ist dies nicht wahr. Natürlich heißt das nicht, dass das, das die Mehrheit sagt, immer falsch ist - es bedeutet nur, dass eine Aussage ganz unabhängig von der Mehrheitsmeinung wahr oder falsch sein kann.

Ich will mit diesem Beitrag nicht sagen, dass das eine Genus wahr, das andere falsch ist, sondern nur, dass man in einer Argumentation für das feminine Genus die Mehrheit nicht als "Wahrheitsfinder" verwenden darf.

Stichwort "Wahrheitsfindung": Diese ist natürlich nicht das Ziel der Wikipedia - deshalb gehört nicht eine Aussage wie "Dieses ist richtig, jenes ist falsch.", sondern eher ein Vermerk in den Artikel auf inhalticher Ebene hinein. Doch welche sprachliche Form man auf gramatikalischer Ebene in der Wikipedia verwendet, ist eine andere Frage. Anders formuliert: Die Lemmata sollen so erklärt werden, dass sie der allgemeinen Meinung entsprechen. Es heißt aber nicht, dass die Sprache, mit Hilfe derer die Lemmata erklärt werden, diejenige sein soll, die sich die Mehrheit unter dem Namen der Sprache vorstellt. D.h. wenn die Mehrheit meint, dass das feminine Genus bei dieser Abkürzung in dieser Sprache richtig ist, dann heißt das nicht, dass der Artikel selbst in dieser Sprache geschrieben sein muss, sondern vielmehr, dass im Artikel auch drin stehen muss, dass die Mehrheit das so betrachtet. Die Sprache, in der der Artikel geschrieben ist, kann durchaus eine andere sein. 2008-08-11 (nicht signierter Beitrag von 91.19.242.81 (Diskussion) 22:23, 11. Aug 2008 (CEST))

selbstverstaendlich hat nicht immer die mehrheit recht. allerdings laeuft es bei sprache tatsaechlich sehr haeufig noch in vielen teilen ziemlich urdemokratisch ab. "wahr" und "falsch" sind dort haeufig nicht definiert. stichworte sprachwandel, etymologie, volksetymologie.

fuer die verschiedenen genera von "url" gibt es jeweils unterschiedliche grammatische gruende, siehe auch einzelnachweis.

im uebrigen stimme ich dir zu. letztlich laeuft es in diesem fall darauf hinaus, dass es egal ist, welches genus wir verwenden. :-) -- seth 00:37, 12. Aug. 2008 (CEST)

Einheitlichkeit des Genus (2009)

Ganz gleich, welcher Genus verwendet wird: Man sollte ihn einheitlich verwenden. Drum habe ich den einzigen verbliebenen maskulinen kurzerhand in einen feminien geändert, also von "Der URL zu dem Wikipedia-Artikel „Webseite“ ist beispielsweise..." nach "Die URL zu dem Wikipedia-Artikel „Webseite“ ist beispielsweise...". (nicht signierter Beitrag von 94.219.98.124 (Diskussion | Beiträge) 13:38, 17. Feb. 2009 (CET))

slashes

Auf der Suche, nach einer einheitlichen Methodik, URIs und URLs in einer informationsverarbeitenden Webplattform zu verwenden, habe ich mich immer am '//' gestossen. Bei Windows-Netzwerkpfaden verwendet man zB ein vorangestelltes '\\', um sie zu identifizieren. URIs sind wieder nach dem Prinzip 'Protokollschema:Protokollspezifika' getrennt. Bei URLs gehört das '//' daher zu den Protokollspezifika, hat jedoch anscheinend auch nur eine Markerfunktion. Ich würde die Zusammenhänge von URI und URL deutlicher hervorheben. Also Doppelpunkt und Doppelschrägstrich in der Erklärung logisch trennen. Das heisst bis inklusive ':' entspricht eine URL einer URI. Ab inklusive '//' beginnt die URL mit einem spzifischen Marker. timetraveller 2007-06-08

Diese unter Windows übliche Notation für Netzwerkressourcen mit Backslashes heißt UNC; sie ist m.E. nie für weltweit eindeutige Adressierungen gedacht gewesen (NetBIOS ist ja auch in seiner Reinform nicht routingfähig), sondern nur zur Anwendung in einem einzelnen (Unternehmens-) Netz. Als entsprechende Notation zu \\Servername\Share\Pfad\zur\Datei wird manchmal file://Servername/Share/Pfad/zur/Datei verwendet (und dabei der Servername für Ressourcen auf dem aktuellen Rechner fortgelassen, was in drei aufeinanderfolgenden Schrägern resultiert; solche URLs mit dem Pseudoprotokoll „file:“ werden von Webbrowsern verwendet, wenn man eine Datei aus dem lokalen Dateisystem öffnet). --Tobias 17:38, 28. Jun. 2010 (CEST)

Zitierung

Man bräuchte unbedingt mal eine Zitierregel für URLs (manche sprechen schon von "www Punkt Q Minus 21 Punkt de") - das tut weh... Matt1971 01:02, 30. Mär 2005 (CEST)

Und was wäre Deiner Meinung nach die richtige Aussprache? Meinst Du nicht, dass das Problem eher Domänen mit ungünstig gewählten Namen ist? --Cyclonus 00:07, 14. Jun 2005 (CEST)

a) (Binde-)Strich?! - b) Ungünstig hin oder her, es geht ja um das Zitieren... Matt1971 ♫ Disku. 17:28, 25. Jun 2005 (CEST)

Gehen wir einfach mal davon aus, dass wir Webseiten meinen, da können wir uns die Protokollbezeichnung ([hatetepe-doppelpunkt-doppelsläsch]) getrost schenken, auch die "Standard"-Subdomain ([wehwehweh]) kann man außer acht lassen. Bleiben also noch Domain und TLD, wobei man den Punkt nicht extra erwähnen sollte, da es mittlerweile klar sein sollte, dass vor der TLD ein Punkt kommt. Für dein Beispiel (q-21.de) ergibt sich somit: [kuh-minus-einundzwanzig-de]. Wobei man den Punkt natürlich auch mitsprechen kann, wenn der URL arg kurz ist :) Subdomain und Protokoll sollten nur genannt werden, wenn sie vom "Erwarteten" (http und www) abweichen. --^icewind^ 12:00, 24. Okt. 2006 (CEST)

Bitte nicht „minus“ – selbst wenn es (glücklicherweise abnehmend) immer noch verwendet wird. Ein Bindestrich ist kein Minus (es wird hier in der Wikipedia ja sogar zwischen Minuszeichen und Gedankenstrich unterschieden).

Beim Weglassen von „www“ muß man sich natürlich darauf verlassen können, daß der Administrator den Webserver entsprechend konfiguriert hat, daß z. B. automatisch zur kanonischen Domainbezeichnung (mit „www.“) umgeleitet wird. Es sollte aber normalerweise ok sein, es fortzulassen, wenn schon klar ist, daß von einer Web-Adresse die Rede sein wird. --Tobias 15:17, 22. Jan. 2008 (CET)

sprachrealitaet ist, dass der bindestrich in webadressen fast immer mit "minus" wiedergegeben wird (so wie die meisten leute "url" mit femininum versehen, *zwinker*). -- seth 00:28, 23. Jan. 2008 (CET)

Es ist aber schlicht falsch. Semantisch ist es ein Bindestrich - wird doch wohl niemand behaupten, dass der zweite Teil vom ersten abgezogen wird. Das Zeichen ist auch ein anderes (Bindestrich = "-" = U+002D, minus = "−" = U+02D7 oder U+2212). "Q minus 21 de" wäre in Punycode "xn--q21-hc2a.de".--87.162.50.144 12:54, 5. Apr. 2009 (CEST)

freepay scam

Als Beispiel für eine URL wurde eine "laptops.freepay" referrer seite angegeben. Ich würde vorschlagen, die Wikipedia Seiten mal danach durchzuforsten, dieses Freepay Zeug scheint sich zu einer Plage zu entwickeln.

Uniform Resource "Location"

Ich denke nicht, dass wir die Verwendung falscher Bezeichnungen unterstützen sollten. Ich habe deshalb "Uniform Resource Location" aus dem Artikel gelöscht. Es gibt zwar ca. 21.800 Google-Hits mit "Uniform Resource Location", aber 2.170.000 für "Uniform Resource Locator". Und per Definition (RFC) heißt es nunmal "Uniform Resource Locator" und nichts anderes.--ChristianHujer 23:56, 18. Mär 2006 (CET)

Sinnvolle Übersetzung

Im Artikel steht engl. „einheitlicher Ortsangeber für Ressourcen“. Ich finde es nicht so wirklich gut, eine Übersetzung mit einem Gallizismus zu beschreiben. Meiner Meinung nach wäre es wesentlich sinnvoller, eine "richtige" Übersetzung anzuwenden. So benutze ich für die Übersetzung von "URL" bereits seit langem "einheitlicher Quellenanzeiger". Wenn es keine Einwände gibt, würde ich das gerne entsprechend anpassen wollen. --^icewind^ 12:04, 11. Okt. 2006 (CEST)

URL vs. URI

Der Artikel sollte überarbeitet werden. Die Definition von URL und URI ist falsch.

"Ein Uniform Resource Locator (Abk. URL; englisch für einheitlicher Ressourcenzeiger) identifiziert und lokalisiert eine Ressource"

Diese Aussage trifft auf einen Uniform Resource Identifier (kurz URI) zu. Ein URI benennt bzw. identifiziert eine Ressource ODER adressiert bzw. lokalisiert sie ODER macht beides zugleich. Ein URL hingegen adressiert bzw. lokalisiert eine Ressource nur.

"URLs sind eine Unterart der generellen Identifikationsbezeichnung mittels Uniform Resource Identifiern (URIs)."

URL ist keine Unterart "der generellen Identifikationsbezeichnung". URL identifiziert und bezeichnet nichts. URL ist eine Teilmenge von URI jedoch von dem "Teil" der adressiert.

"Da URLs die erste und häufigste Art von URIs darstellen, werden die Begriffe häufig synonym verwendet."

Die Aussage ist auch falsch. Zwei Begriffe synonym verwenden bedeutet, dass Begriff A anstelle von Begriff B und Begriff B anstelle von Begriff A verwendet wird. Das ist in diesem Fall nicht korrekt und wird auch nicht "häufig" so praktiziert. Anstelle des Begriffs URI wird nie der Begriff URL verwendet, da dies falsch wäre. Es wird häufig anstelle des Begriffs URL der Begriff URI verwendet. Aber nicht als Synonym, sondern weil dies per Definition korrekt ist. Zur Wiederholung: Ein URI benennt bzw. identifiziert eine Ressource ODER adressiert bzw. lokalisiert sie ODER macht beides zugleich.

Dies ist übrigens auch alles in der offiziellen URI Spezifikation bzw. dem Internet Standard rfc3986 Absatz 1.1.3 (Seite 7) nachzulesen.

---

Ich kann nicht sagen, daß ich den Unterschied nach Lektüre des ersten Absatzes kapiert hätte.

„Der Name des URI-Schemas ist daher in der Regel vom hierfür verwendeten Netzwerkdienst abgeleitet. Beispiele hierfür sind HTTP oder FTP.“

Da wäre nun wirklich ein Beispiel schick, wie es für die URL ja auch gegeben ist. --Tobias 06:07, 11. Apr. 2007 (CEST)

Da steht "URLs sind eine Unterart der generellen Identifikationsbezeichnung" aber was genau eine URL im Vergleich zu einer URI ist, was das spezifische an der URL ist, steht da nicht. --Manorainjan (Diskussion) 20:48, 29. Jul. 2016 (CEST)

URI identifizieren eine Ressource irgendwie, URL machen das speziell dadurch, dass sie sie lokalisieren, URN dadurch, dass sie sie benennen (=einen nicht ortsabhängigen Namen verwenden). --nenntmichruhigip (Diskussion) 01:26, 30. Jul. 2016 (CEST)

Nicht dass ich es jetzt begriffen hätte, ohne konkrete Beispiele, aber kann man sagen, dass die Vereinigungsmenge URL und URN die Menge URI bilden? --Manorainjan (Diskussion) 02:27, 30. Jul. 2016 (CEST)

@Manorainjan:

Schau bitte auf Uniform Resource Identifier #Konzeption.

• Es gibt noch mehr außer URL und URN, also weder-noch (und damit ist es keine Vereinigungsmenge), hingegen in der realen Welt praktisch keine sowohl-als-auch.

Eine Unterteilung der URI ist pragmatisch-historisch-gebräuchlich, aber nicht wissenschaftlich trennscharf.

VG --PerfektesChaos 10:50, 30. Jul. 2016 (CEST)

GIF-Breite

Wenn man schon ein GIF nimmt (wegen der Farben?), nachdem der Aufbau vorher durch - auch korrekt dargestellt war, dann sollte dieses aber schmaler werden. Auf kleinen Bildschirmen/Fenstern geht sonst Information verloren. Also, bitte ein deutlich schmaleres GIF oder wieder zurück. --Bernd vdB 20:46, 13. Mai 2007 (CEST)

Third-Level-Domain www

Mir ist noch unklar wieso die Third-Level-Domain meistens www heißt. Die IP läßt sich doch per DNS auch mit der Second-Level-Domain ermitteln. Und das Protokoll wird durch das http festgelegt. Wieso wird dann so häufig noch die Third-Level-Domain www benutzt? (nicht signierter Beitrag von 62.206.87.77 (Diskussion) 08:56 10. Aug 2007 (CEST))

WWW nennt sich das System, welches man für gewöhnlich als "Webseiten" kennt – sprich per Webbrowser abrufbare Internetseiten unter Verwendung des HTTP-Protokolls. Siehe auch World Wide Web. ×ASM× 22:34, 10. Aug. 2007 (CEST)

Meiner Erfahrung nach ist das www aber so gut wie immer überflüssig, so funktioniert z.B. google.com genauso wie www.google.com. Das www ist wahrscheinlich für unerfahrene, dass die eine URL auch erkennen. --Oms 22:21, 9. Sep. 2007 (CEST)

Dem letzten Eintrag möchte ich hier widersprechen, ich habe heute zufällig ein Gegenbeispiel gefunden und bitte um Hilfestellung dabei. Kurz das Beispiel und einige Erläuterungen von mir.

- "www.jrk.de" leitet um auf "www.jugendrotkreuz.de", die Seite des JRK-Bundesverbandes

- "jrk.de" leitet um auf "sh.jrk.de", die JRK-Seite aus Schleswig-Holstein

Bislang habe ich auch immer gedacht, dass das "www." überflüssig ist, weil ja "www.beispielseite.de" das gleiche Ergebnis bringt wie "beispielseite.de". Wieso kann es z. B. in diesem Fall anders sein? Ok, was das für die Öffentlichkeitsarbeit beider Inhalts-Anbieter bedeutet, muss man mit denen klären. Aber worin liegt der technische Unterschied begründet, dass es bei den meisten Seiten ohne das "www." klappt und in diesem Fall das Hinzufügen oder eben Weglassen des "www." entscheidend ist dafür, wo man landet? (Beide Beispiele bzw. Endresultate nach erfolgter Umleitung nutzen HTTP.)

Danke für eure Hilfe und Unterstützung. Weil das obige "Phänomen" ist mir auch nach über 20 Jahren PC-Erfahrung und einem informatik-basierten BWL-Studium ein Rätsel ... --Biller24 16:22, 4. Mär. 2009 (CET)

In den Anfangszeiten des Internets war es so, dass das www immer geschrieben werden musste, was daher kommt dass das Domain Name System eben nicht nur für das Internet, sondern auch für lokale Netzwerke verwendet wird, wobei die Third-Level-Domain den Rechnernamen darstellt (in diesem FAll eben "www"). Mittlerweile funktioniert es in den meisten Fällen auch ohne das www. Aber im Prinzip sind das mit und ohne www 2 verschiedene Adressen sodass es natürlich auch möglich ist beide auf verschiedene Seiten zu leiten. --Wickie³⁷ 16:51, 4. Mär. 2009 (CET)

Anscheinend muss auch heute eigentlich noch jeder Rechnername eine Third-Level-Domain besitzen, aber es können Aliasnamen eingerichtet werden, siehe auch CNAME_Resource_Record --Wickie³⁷ 16:59, 4. Mär. 2009 (CET)

Spät aber doch: "In den Anfangszeiten des Internets war es so, dass das www immer geschrieben werden musste" - nein, auch in den Anfangszeiten "musste" man www nicht schreiben. Ein Client verbindet je nach Protokoll zu einem spezifischen Port- http verwendet z.B. 80, 8080 oder 88 - ob da www davor steht oder nicht ist egal. Ebenso ist es vom DNS abhängig, ob www.example.com (im vergleich zu example.com) überhaupt irgendwohin auflöst - wie du schon sagst sind es zwei völlig unterschiedliche Adressen. Und es muss keineswegs jeder rechner eine 3rd-Level-Domain besitzen - webserver funktionieren auch, wenn sie überhaupt keinen öffentlichen Hostnamen besitzen auch mit einer IP-Adresse lässt sich ein gülter URL produzieren. Wenn jeder Rechner eine 3rd-Level-Domain bestizen würde, wären Top-Level-Domains oder Root-Level-Domains technisch unmöglich :) --suit 22:18, 21. Okt. 2009 (CEST)

Kurz und knapp: es handelt sich um eine Konvention, mehr nicht. Wenn das Protokoll bzw. der Port nicht angegeben ist, kann (und wird) ein Webbrowser erraten, daß eine Adresse www... vermutlich von einem HTTP-Server unter dem Standardport 80 bedient wird, und entsprechend http:// ergänzen, um die URL zu komplettieren. Bei der Konfiguration des Servers kann der Administrator dafür sorgen, daß beide Varianten (mit und ohne führendes www.) funktionieren und eine davon als „kanonisch“ behandelt wird o.ä.; selbst wenn eine Domain beispiel.deexample.com auf dem Nameserver als sog. Wildcard-Domain eingerichtet ist (und damit auch alle Subdomains incl. www.beispiel.dewww.example.com nach der selben IP-Adresse auflöst), ist noch lange nicht gesichert, daß der HTTP-Server auch auf beides reagiert (da HTTP 1.1 virtuelle Hosts erlaubt; siehe z.B. die Konfigurationsoptionen des Apache-Webservers). --Tobias 18:33, 28. Jun. 2010 (CEST)

Ich hab' mir erlaubt, deinen Beitrag RFC-2606-Konform zu machen ;) --suit 10:07, 29. Jun. 2010 (CEST)

www.domain.tld.

es wäre vielleicht auch noch interessant, zu erfahren, dass in der ursprünglichen, ganz 100% korrekten schreibweise eine url etwa so aussehen müsste:

"http://subdomain.domain.tld./"

Ursprünglich wurde NACH der TLD ebenfalls noch ein Punkt gemacht. (nicht signierter Beitrag von 170.56.58.156 (Diskussion) )

Das ist nicht richtig - der Punkt repräsentiert im DNS das Rootlevel - er ist aber optional.

http://localhost ist auch ein völlig gültiger URL - es muss also nichtmal zwingend eine öffentlicher Hostname sein --suit 13:27, 20. Nov. 2009 (CET)

URL-Grafik

Hier ein Vorschlag, wie man die "Grafik" (meiner Meinung) etwas übersichtlicher gestalten könnte:

http://hans:geheim@www.example.org:80/demo/example.cgi?land=de&stadt=aa#abschnitt1
|      |    |      |               | |                 |                |
|      |    |      Host            | Pfad              Query            Anker
|      |    Passwort               Port
|      Benutzer
Protokoll

Evtl. noch mit Farben zusätzlich. --AK-Palme 18:19, 14. Nov. 2007 (CET)

Gute Idee: auf diese Weise kommt die Struktur auch dann noch klar rüber, wenn keine Farben angezeigt werden können (z. B. bei Ausdruck mit einem Schwarzweiß-Laserdrucker). Und vielleicht noch die URL in nowiki-Tags einfassen. --Tobias 15:23, 22. Jan. 2008 (CET)

hab's eingebaut. ich finde es s/w zwar auch besser, aber jetzt sieht man nicht mehr, dass das "?" nicht zum pfad gehoert. ich will mir jedoch nicht einfach so erlauben, es zur query dazugehoeren zu lassen, denn eigentlich leitet es diese ja nur ein. hmm, kann man sich drueber streiten. ich halt mich raus. -- seth 00:10, 23. Jan. 2008 (CET)

fragment?

gudn tach!
aeh, fragment? heisst das nicht ueberall anker? -- seth 19:40, 22. Dez. 2008 (CET)

Natürlich heißt das Anker, von Fragment hab ich in dem Zusammenhang noch nie was gehört -- Wickie37 10:51, 23. Dez. 2008 (CET)

Nein, ein Anker ist das entsprechende DOM-Element, also früher das <a>, inzwischen jedes Element mit einer ID. Das Fragment ist der durch einen Anker eingeschlossene Teil des Dokuments oder, falls der Anker leer ist, der Ort im Dokument, an dem der Anker steht. Bei Webapplikationen kann der fragment identifier auch in eine Steueranweisung übersetzt werden, z.B. in [4] .--87.162.50.144 13:06, 5. Apr. 2009 (CEST)

Trailing Slashes

Immer wieder diskutiert wird die Notwendigkeit des endenden Schrägstrichs (Trailing Slash). Nach RFC 3986 ist ganz klar, dass er aufgeführt werden darf, aber nicht muss. Andererseits wird immer wieder empfohlen (z. B. http://www.standardzilla.com/2007/07/09/dont-forget-your-trailing-slash/ oder http://url-rewriting.de/anderes/trailing-slashes.html), ihn zu setzen, damit man klar erkennt, wenn ein Verzeichnis und nicht eine Datei gemeint ist. Sollte man da nicht ergänzen, dass man ihn weglassen kann, aber sinnvollerweise doch setzt?

Also besser http://example.org/ statt http://example.org und besser http://example.org/xyz/ statt http://example.org/xyz, bei Dateien aber http://example.org/abc.xhtml. -- XRay 21:27, 21. Okt. 2009 (CEST)

Trailing Slashes hinzufügen oder entfernen ist eine dämliche Idee - für einen HTTP-Server ist example.com/foo und example.com/foo/ etwas völlig anders. Auch gibt es keien "Dateien" im HTTP-Kontext. Das größte Do-Not ist das Entfernen oder Hinzufügen von Trailing Slashes in bestehenden URLs - z.B. weil man sie so schöner findet - das gehört sich einerseits nicht und andererseits kann es zu einem 404-Fehler führen (das behandelt der zweite von dir verlinkte Artikel - ist aber bei modernen Suchmaschinen nicht mehr der Fall).

Der erste Artikel ist jedenfalls Unsinn - "This URL (without the trailing slash) is not telling the server exactly what kind of file to look for" - na geh? Wie bereits erwähnt gibt es im HTTP-Kontext keine "Files" oder Verzeichnisse. Es kann höchstes etwas geben, was zufällig so aussieht.

Ein Webserver wird z.B. beim Aufruf von example.com/foo/bar.de.html die datei bar.html im ordern foo/ ausliefern. Bei einem aufruf von example.com/foo wird er versuchen die Datei foo.html oder foo.xml auszuliefern (je nachdem was die Inhaltsvereinbahrung besagt) - bei einem Aufruf von example.vom/foo wird er vielleicht index.html oder index.php ausliefern.

Ressourcen haben nur wenig mit den dahinterstehenden Dateien zu tun Genausogut kann bei einem Aufruf von example.com/Verzeichnis1/ aufgrund irgendwelcher Logik Verzeichnis96 ausgeliefert werden oder aber beim Aufruf von example.com/example.gif wird ein Directory-Listing (im XML-Format) des Ordners foobar/baz/qux/ ausgeliefert.

Also: egal was die Artikel sagen: Trailing-Slash oder nicht ist vollig egal, es bietet weder vor noch nachteile welche zu verwenden. Bei der Entscheidugn sollten zwar entsprechende Faktoren (wie z.B. Multiviewtauglichkeit) beachtet werden, aber das einzige was gilt ist "Cool URIs don't change - und wie diese URIs ausehen, ist geschmackssache des Seitenautors --suit 22:33, 21. Okt. 2009 (CEST)

Danke für die ausführliche Info. Ich hatte den anderen Weg, der zugegeben etwas vereinfacht ist, gewählt, um einen Unterschied zu verdeutlichen. Es scheint aber bei den Wikipedia-Artikel einen Zwist zu geben, der dazu führt, dass nur die Trailing Slashes immer wieder entfernt oder gesetzt werden. Ich fürchte, dieser Zwist wird bleiben. -- XRay 07:11, 22. Okt. 2009 (CEST)

Um ein Beispiel anzugeben:

http://www.dradio.de/dlf/sendungen/interview_dlf/1408859/ mit / bringt den gewünschten Artikel

http://www.dradio.de/dlf/sendungen/interview_dlf/1408859 bringt nur eine Übersichtsseite

--Itu 16:22, 17. Mär. 2011 (CET)

Pfad / Verzeichnis / url-path

Aus meiner Diskussionsseite entnommen --suit 10:05, 18. Nov. 2009 (CET)

Erstens: Unter der Überschrift "Pfad" / "url-path" änderst du: "das Verzeichnis" ==> "den Pfad". Für mich ist "das Verzeichnis" ein klarer Begriff; superkorrekt aber nicht besser wäre "Pfad und Name des Verzeichnisses". "Der Pfad" ist wörtlich eine Verzeichnisangabe vor dem eigentlichen Dateinamen, wird aber als Wischiwaschi-Begriff für alles verwendet. Können wir bitte die kleine Ungenauigkeit "Der Student ist in der Liste eingetragen" vs. "Der Name des Studenten ist in der Liste eingetragen" in Kauf nehmen, und dafür den genauen Begriff "Verzeichnis" lassen? Ich möchte nicht, dass jemand beim Lesen aus versehen an " die Datei '/' " denkt.

Zweitens: ", ohne dass dies für die den anfragenden Client ersichtlich wäre." bitte anders formulieren oder streichen. Das Thema ist komplexer, und wird jetzt ziemlich HTML-spezifisch, was der Überschrift des Artikels nicht gerecht wird: In der Antwort des Servers kann (und sollte) er nämlich verraten, was er tatsächlich liefert. Wenn er es tut, zeigt es der Browser auch an... Und so war es schließlich mal gedacht: Seite holen, ändern, und mit POST wieder auf den Server zurückspeichern.

-- A. Södler 10:10, 13. Nov. 2009 (CET)

Erstens: ausdrücklich nein - denn der Pfad ist eindeutig ein Pfad und kein Verzeichnis - das ist auch so in RFC 2396 bzw. 3986, dort steht "Path" nicht "Directory". Beispiel hier in der Wikipedia "/wiki/" ist ein Verzeichnis der Media-Wiki-Software - da trifft es noch zu, "Benutzer:Suit" ist aber keine Pfad - paradoxerweise existiert nichtmal eine Datei mit diesem Namen. Es ist eine Ressource bzw. ein Pfad. HTTP bzw. URLs kennen keine Verzeichisse oder Dateien. So ist z.B. in http://rebell.at/artikel/operation-flashpoint-2-groser-name-groses-spiel "/artikel/" kein Verzeichnis, ebenso ist "operation-flashpoint-2-groser-name-groses-spiel" Keine Datei - die einzig relevante Datei die Wirklich existiert ist index.php - mod_rewrite sorgt aber dafür, dass es aussieht als wäre es ein Verzeichnis mit einer Datei darin.

Ergo: Verzeichnis wäre auf jeden Fall falsch, da der Pfad ja nur eine "Datei" referenzieren könnte z.B. example.com/foo.txt - Datei wäre ebenfalls unpassend, da es ja ein Verzeichnis sein kan - z.B. example.com/foo/ - beides Zusammen (Verzeichnis(se) + Datei) ist hingegen ein Pfad. Darum sprachlich und fachlich korrekt.

Zweitens: Nein, es ist nicht HTML-spezifisch sondern HTTP-spezfisch (bzw. auch andere Protokolle, die URLs nutzen sind davon betroffen) - wie kommst du darauf, dass in einem HTTP-Response mitgeteilt wird, was tatsächlich geliefert wird? Der Client bekommt davon nichts mit (ob POST oder GET ist dabei völlig egal - es kann auch sein, dass er überhaupt keine Antwort erhält), das ist ein technisches Faktum. wenn ich example.com/foo/bar/baz.txt anfordere und der Server das ausliefert, werde ich niemals erfahren, ob es tatsächlich eine Datei gegeben hat oder ob der Server nur so tut, als ob es eine gäbe und nur z.B. PATH_INFO analysiert (so wie es z.B. die MediaWiki-Software tut) - siehe z.B. [5] --suit 10:29, 13. Nov. 2009 (CET)

Erstens: Im Dateisystem gilt: etc - Name einer Verzeichnisdatei; /etc/ - Pfad zu den Dateien in etc; /etc/hosts - (Pfad)Name der regulären Datei mit /etc/ als Pfad und hosts als Name. Es scheint immerhin Einigkeit zu herrschen, dass abweichend davon "Pfad" als "mal Datei, mal Verzeichnis" verstanden wird.

Jedoch: Unabhängig davon, dass in der URL beides zugelassen ist, und von dir eine Datei (falsch, korrekt: ein Datenstrom) zurück erwartet wird, referenziert das konkrete Beispiel "/" keine Datei, sondern den Pfad des Wurzelverzeichnisses, was in der Regel das Wurzelverzeichnis meint. Das Beispiel war auch wirklich so gemeint: fordere Äpfel an, und du bekommst Birnen.

Zweitens: Korrekt, es ist HTTP-spezfisch, nicht HTML-spezifisch — mein Fehler. Dennoch: unter http://en.wikipedia.org/wiki/HTTP_location findest du, dass der HTTP-Server durchaus verraten kann, welche Datei er liefert. (Achtung: bei Status 301, 302, 303, 307 ist der Datenstrom üblicherweise bereits enthalten, muss es aber nicht.) Der geänderte Dateipfad ist für das ursprüngliche Konzept (Zurückschreiben der geänderten Datei mit POST) notwendig. Dass es oft nicht geschieht, steht auf einem anderen Blatt. Deshalb ist der Hinweis, es sei für den Client nicht ersichtlich, nicht generell richtig.

-- A. Södler 09:11, 18. Nov. 2009 (CET)

add 1)

Eine Datei muss nicht immer physisch vorhanden sein - auch eine temporäre, nur im Bytecode des PHP-Interpreters existierende Darstellung von 10 physischen Dateien, mit 42 Includes stellt eine "Datei" dar.

Der von HTTP ausgelieferte Datenstrom stellt auch eine Datei dar (der HTTP-Header zählt auch dazu); im unixoiden Umfeld ist ohnehin alles eine Datei - auch Verzeichnisse oder Geräte sind strenggenommen Files - aber das sind alles Wortklauberein und Spitzfindigkeiten - darüber zu diskutieren ist müßig und nicht zielführend, da sich die Spezifikation eindeutig auf "path" beschränkt.

add 2)

RFC 2616 nennt für die Location lediglich, dass ein URI erlaubt ist ('Location = "Location" ":" absoluteURI') - technisch gesehen sind relative (Filesystem-)Pfade garnicht erlaubt - viele Webserver unterstützen sie (fälschlicherweise) trotzdem. Location: http://example.com/foo/bar.php ist eine schöne Ressource - muss aber keineswegs in irgend einer Weise dem Dateisystem entsprechend (was uns zu Punkt 1 zurückbringt - foo/bar.php kann z.B. auch dafür sorgen dass die physische Datei /var/www/example.com/qux.txt php HTTP ausgeliefert wird). --suit 09:28, 18. Nov. 2009 (CET)

Du bist ganz schön vom Thema abgewichen. Was ist nun mit dem eigenlichen Thema? Dein konkreter Vorschlag? Wie können wir den Ihnalt wieder in verständliche Form bringen?

Reite bitte nicht darauf herum, dass es in der URL-Spezifikation "path" heisst. Wenn jemand den Namen seiner Großmutter hineinschreibt, dann ist und bleibt "Isolde" ein Personnename — natürlich als Pfad in der URL...

-- A. Södler 09:54, 18. Nov. 2009 (CET)

Spezifikationen zu beachten und korrekte Terminiologie zu verwenden ist essentiell wenn man verständlich bleiben will (siehe z.B. diesen Artikel.

Wenn jemand den Artikel aufgrund der verwendeten Begriffe nicht versteht, hat er sich kundig zu machen - es ist immerhin ein Wiki - es gibt sogar einen Artikel über Pfade auf den man für diesen Fall verlinken könnte

Einen korrekten Begriff gegen einen falschen auszutauschen halte ich jedenfalls nicht für sonderlich sinnvoll. Sonst könnte man gleich einen Bot drüberlaufen lassen der Standard durch Standart ersetzt, einzige durch einzigste und ggf. zusätzlich überall ein paar Deppenleerzeichen einbaut :) --suit 10:04, 18. Nov. 2009 (CET)

Was soll der ganze Quatsch hier? Natürlich hat suit in diesem Fall Recht und seine Änderung hier ist vollkommen korrekt. --net 10:22, 23. Nov. 2009 (CET)

Man muss sich nur mal als Beispiel REST anschauen - dabei geht es ganz sicherlich nicht um Verzeichnisse. Oder auch bei Servlets: Wenn man www.xyz.com/service/unterpfad1/unterpfad2 aufruft ist überhaupt nichts darüber ausgesagt, welches Servlet damit angesprochen wird. Das wird serverseitig entschieden. Grüße--Flash1984 10:39, 23. Nov. 2009 (CET)

Hallo net, Klar ist es ein "path", da hat suit recht. Allerdings steht darin die Angabe a) einer Datei b) eines Skripts c) eines Verzeichnisses d) der Name meiner Großmutter. Im ursprünglichen Text sollte dargestellt werden, dass wenn man den Namen der Großmutter eingibt, eben nicht die Großmutter herauskommen muss, sondern z.B. eine Skript-Ausgabe. Um dies zu sagen, muss man die verwechselbaren Dinge (Großmutter, Skript-Ausgabe) im Beispiel nennen, da hilft es nicht zu sagen "obwohl ein path angefordert wurde, kommt eine Skript-Ausgabe heraus.

Das übliche und einfachste Beispiel ist nun einmal "/" ==> "/index.html", und ersteres sieht aus wie ein Verzeichnis(-Name), letzteres wie eine Datei (ein Datei-Name). So einfach ist das.

Ich bedaure, dass das ganze hier und im Artikel unnötig aufgebläht wird. Vielleicht sollte man die Diskussion doch wieder rüber zu suit schieben? ;-) -- A. Södler 10:15, 26. Nov. 2009 (CET)

Aufbau

Nach der sehr gelungenen Übersicht "mögliche Elemente einer URL" steht: "Zwingend erforderliche Mindestbestandteile einer URL sind dabei lediglich das Protokoll, der Host und der Pfad. Letzterer besteht zumindest aus einem Schrägstrich (/), (..)". Das steht für mich im Widerspruch zu "1.5 url-path (..) Der Pfad kann auch leer sein."

Sollte man deshalb in diesem einleitenden Absatz nicht knapper schreiben: "Zwingend erforderliche Mindestbestandteile einer URL sind dabei lediglich das Protokoll und der Host."

(Die Syntax des Bestandteils Pfad kann ja weiterhin 1.5 entnommen werden.) --132.231.8.180 15:10, 18. Nov. 2009 (CET)

Stimmt, korrigiere ich gleich - im Abschitt url-path steht das bereits richtig drin --suit 15:22, 18. Nov. 2009 (CET)

Danke fürs schnelle Antworten! Wenn Pfad weiterhin drin bleiben soll: Vielleicht wäre es dann ein klein wenig besser, in Anlehnung an

http://tools.ietf.org/html/rfc3986#section-3

zu schreiben

"Zwingend erforderliche Mindestbestandteile einer URL sind dabei lediglich das Protokoll, der Host und der Pfad. Der Pfad kann auch leer sein."

Ich persönlich verstehe nicht ganz, warum der Pfad ein zwingend erforderlicher Mindestbestandteil ist, wenn er auch leer sein kann. Oder habe ich da etwas übersehen? Es wunderte mich allerdings auch, weshalb in der Quelle steht "The scheme and path components are required, though the path may be empty (no characters)." Obwohl die in der Quelle angegebene Grammatik die Bezeichnung "hier-part" (ich denke das steht für hierarchical part) verwendet und so Host und Pfad zusammenfasst, das fand ich in diesem Zusammenhang klarer.

--132.231.8.180 17:11, 18. Nov. 2009 (CET)

Ohne Pfad ist es keine URL sondern nur ein Hostname mit Protokoll davor :)

Und als Informatiker sollte man wissen, dass ein Leerstring auch "etwas" ist - ganz im Unterschied zu NULL --suit 17:13, 18. Nov. 2009 (CET)

Sprachliches

Hallo Autoren,
ich würde diese Überschrift gern durch "Sprachgebrauch" ersetzen und die Untergliederung weglassen oder wenigstens nicht mit "Artikel" sondern "Genus" betiteln. Neben eurer Meinung interessiert mich, ob es ein Werkzeug gibt, das Verweise mit Ankern findet.
Grüße --Uncopy 11:10, 9. Dez. 2009 (CET)

gudn tach!

deine anmerkung ueber den duden habe ich wieder aus dem artikel entfernt, weil bereits im ersten satz des abschnittes etwa das gleiche (sogar etwas praeziser) stand.

deine idee zur ueberschrift habe ich umgesetzt.

deine frage bzgl. der anchors habe ich nicht verstanden, aber evtl. hilft dir template:anker weiter. falls nicht, stellst du deine frage am besten auf WP:FZW, zum einen passt sie dort besser als hier und zum anderen wirst du dort schneller antwort bekommen. -- seth 22:24, 10. Dez. 2009 (CET)

Die Änderung der Überschrift freut mich. Wenn man die Überschrift eines Absatzes ändert, kann es sein, dass Weiterleitungen nicht mehr präzise erfolgen, sondern nur noch schrotschussartig auf den Artikelanfang, was teilweise sehr verwirrend für den arglosen Leser ist. Es gibt ja tatsächlich eine Reihe von Weiterleitungen, die auf Absätze zielen, und dafür werden Anker verwendet, die die Wikisoftware automatisch aus den Überschriften erzeugt. Das Template könnte helfen, aber ich würde es vorziehen, bestehende Weiterleitungen direkt in den Absatz zu aktualisieren, dazu wäre nun eine Liste gut. Links auf diese Seite ist dabei sehr mühselig. (Ich hatte mich schon des öfteren gefragt ob es so was gibt und sollte die Frage wohl tatsächlich mal einem größeren Kreis vorlegen) Grüße --Uncopy 10:00, 11. Dez. 2009 (CET)

Übersetzung

Hallo, meine Änderung im Art. wurde eben rückgängig gemacht. Nur weil es einen Begriff auch in englisch gibt, wird der hier noch lange nicht verwendet. Das ist die Wikipedia für den deutschsprachigen Raum. Statt user sagen wir halt Benutzername, statt password Passwort, statt host Host. WP sollte allgemein-verständlich sein. Das ist sie, wenn sie allgemein-verständliche Begriffe benutzt und das sind i.d.R. die deutschen Entsprechungen. Ich sehe keinen sinnvollen Grund, weshalb hier englische Begriffe verwendet werden sollen. -88.130.127.176 23:36, 29. Mär. 2010 (CEST)

Nachdem es jetzt eine Woche lang keine Gegenstimmen gegeben hat, habe ich meine Änderung wieder hergestellt.

Die Sache ist damit erledigt. -88.130.87.110 00:22, 6. Apr. 2010 (CEST)

Es tut mir leid, dass ich nicht täglich in der Wikipedia herumgraben kann.

Es handelt sich um Fachbegriffe die in RFC 1738 exakt so stehen, darum werden sie nicht übersetzt. Die Übersetzung findet sich ohnehin im jeweiligen Absatz dazu.

Zudem mit diesem Edit wurden nicht nur die Übersetzungen sondern auch noch ein paar Fehler reinrevertiert - das ist nicht ok.

RFCs sind wie sie sind, die Übersetzt man nicht - RFC 2606 wäre sonst auch so ein Kandidat, da bekommt man die Krise wenn jemand beginnt <foo.example> in <foo.beispiel> umzubenennen --suit 10:14, 6. Apr. 2010 (CEST)

Hallo Suit, ich würde Dir dahingehend Recht geben, dass ein verbindlicher RFC-Text zumindest in der gültigen Originalversion dargestellt werden sollte - was aber eindeutig nicht heißt, dass er danach nicht als für hier Wissenssuchende in der hiesigen Sprache dargestellt werden sollte. Und ganz bestimmt nicht werden eindeutig übersetzbare Begriffe ('port'/'Port') in einer de:WP-fremden Sprache dargestellt...

Von daher definiere bitte konkret, was in deiner Wahrnehmung im IP-Edit unübersetzbar ist bzw. welche Fehler Du darin findest, damit diese Dinge korrigiert werden können - in der Gänze ist er aber IMHO näher an den de:WP-Konventionen als deine Version... --nb(NB) > ?! > +/- 17:29, 6. Apr. 2010 (CEST)

Es ist jetzt mehr als ein Vierteljahr vergangen. In all der Zeit wurde nicht dargelegt, weshalb eine Übersetzung der Begriffe des RFC verboten sein soll. (Selbst wenn sich eine derartige Meinung finden sollte, müsste sie mit einer belastbaren Quelle belegbar sein, die explizit eine Übersetzung verbietet.) Daher habe ich die Übersetzung wiederhergestellt. -88.130.122.77 01:26, 7. Jul. 2010 (CEST)

Ich hab' deine Änderungen wieder revertiert.

Begründung ist schlichtweg: die Begriffe sind technischer Natur und können nur sinngemäß übersetzt werden.

Mit der Begründung "wenn es eindeutig übersetzbare Begriffe sind" könnte man dann gleich anfangen "Domain" nach "Domäne" zu verschieben oder Fully Qualified Domain Name nach "Vollqualifizierter Domänennamen". Im URI-Artikel ist auch noch niemand auf die dämliche Idee gekommen, authority mit "Autorität" zu übersetzen.

Sogar in gängigen Übersetzungen der RFCs werden diese genannten Begriffe explizit nicht übersetzt - ganz einfach, weil es unsinnig ist sie zu übersetzen, da es sich um Fachbegriffe handelt nach denen man sucht und sie genauso vorfindet.

Es handelt sich in diesem Fall also eindeutig um einen Anglizismus (bzw. mehrere Anglizismen) die nicht sinnvoll übersetzt werden, aber erklärt werden können. --suit 09:51, 7. Jul. 2010 (CEST)

Natürlich kann man „protocol“ oder „password“ sinnvoll übersetzen und das sind natürlich auch keine Anglizismen. Auch schreibt man Anglizismen (wenn es Substantive sind) normalerweise trotzdem groß (in Überschriften schreibt man es sogar im Englischen groß).

Ich kann deine Begründung da leider beim besten Willen nicht nachvollziehen und dieser Edit ist in meinen Augen ein guter Kompromiss zwischen passenden Übersetzungen und englischen Ausdrücken, wo es keine sinnvolle Übersetzung gibt. --net 10:53, 7. Jul. 2010 (CEST)

Besonder der Aufbau (der vorformatierte Abschnit) ist 1:1 aus dem RFC übernommen, diesen zu übersetzen wäre erstrecht unsinnig.

Eione Kompromisslösung halte ich für weniger schlau - sie verwirrt mehr als es durch eine einheitliche, zum RFC konformen, nicht-deutschsprachige Schreibweise. Unter den entsprechenden Überschriften werden die Begriffe ohnehin unmittelbar erklärt. searchpath mit Suchpfad zu übersetzen ist z.B. extrem verwirrend, das Ding heisst nur so. Irgendwas gesucht wird da aber mitnichten, mit einer Suche oder einen Pfad hat das auch nicht wirklich etwas zu tun. Genausowenig lässt sich Hardware oder Software sinnvoll übersetzen. --suit 11:51, 7. Jul. 2010 (CEST)

Nachtrag: die von mit genannte deutsche Übersetzung von RFC 1738 hat sich dazu entschieden "Host" mit "Gastgeber" zu übersetzen. --suit 12:08, 7. Jul. 2010 (CEST)

Vorschlag: Wie wäre es mit sinnvollen Übersetzungen aus reputablen Quellen? Mir ist alledings keine bekannt, werder das W3C noch z.B. SELFHTML bieten hier entsprechede deutsche Beschreibungen an. Selbst etwas zu erfinden wäre somit Theoriefindung. Wenn, müsste das aber zumindest URI-Artikel nachgezogen werden. --suit 09:40, 8. Jul. 2010 (CEST)

Für Übersetzungen wie „Passwort“, „Benutzer“ oder „Protokoll“ braucht man keine Quellen, die sind sonnenklar. Aber egal, wegen mir kann es auch englisch stehen bleiben. Können wir uns wenigstens darauf einigen, dass Überschriften großgeschrieben werden? Das wird überall (auch in RFCs) so gehandhabt. --net 10:30, 15. Jul. 2010 (CEST)

Mir geht es nicht um die Übersetzungen für die ohnehin "Sonnenklaren" begriffen sondern um den Rest. Übersetzen sollte man die Begriffe entweder ganz oder garnicht. Überschriften groß schreiben ist aber sicher kein Fehler. --suit 11:54, 15. Jul. 2010 (CEST)

-or ist maskulin ?

Im Artikel steht, dass Wörter auf „-or“ (hier „Locator“) im Deutschen stets maskulin sind. Was ist mit dem Gegenbeispiel Ellinor (weiblicher Vorname) ? -- Juergen 91.52.182.54 15:34, 30. Mai 2010 (CEST)

gudn tach!

eigennamen koennen vermutlich fast immer als ausnahme herhalten. vieleicht sollten man jene hier explizit ausklammern. -- seth 00:02, 31. Mai 2010 (CEST)

Nun ja, das steht hier ja nur als Erklärung dafür, daß eine Minderheit die URL als grammatisch männlich betrachtet, weil aus dem Lateinischen stammende Fremdwörter auf „-or“ in aller Regel männlich sind (das Tor hingegen nicht; es ist ja auch kein Fremdwort... ;-). Man kann sich allerdings auf den Standpunkt stellen, daß es dieses grammatische Geschlecht im Englischen eh nicht mehr gibt und wir keinen antiken Römer mehr nach seiner Meinung fragen können...

Die Frage, aus der sich das grammatische Geschlecht herleitet, ist ohnehin nicht „Wie lautet die Langform der Abkürzung, und wie kann ich die wörtlich übersetzen?“, sondern „Was ist das?“, und die allgemeinverständliche Antwort lautet: eine Adresse. --Tobias 16:51, 28. Jun. 2010 (CEST)

Nein, ein URL ist keineswegs eine Adresse, es ist ein Ressourcenbezeichner.

Eine Adresse (etwa wie eine Domain) wäre Max Mustermann, Musterstraße 1, 1234 Musterhausen; ein Ressourcenbezeichner hingegen ist z.B. sowas: Max Mustermann, Musterstraße 1, 1234 Musterhausen; 1. Stockwerk, Zimmer Nummer 144, 3. Aktenschrank, 7. Ordner unter dem Reiter J, Dokument: "Beispiel", Seite 12 --suit 17:16, 28. Jun. 2010 (CEST)

gudn tach!

unabhaengig von deiner meinung wird internetadresse allgemein synonym zu url verwendet (siehe z.b. duden). -- seth 22:31, 29. Jun. 2010 (CEST)

Das bestreite ich nicht (steht auch so im Artikel, dass umgangssprachlich zwischen URL und Domain nicht unterschieden wird) - dennoch ist ein URL technisch ein Ressourcenbezeichner und keine Adresse. Ein URL ist ein URI aber nicht umgekehrt - dennoch werden beide begriffe häufig (nud falsch) Synonym verwandt. Im SGML-Kontext existieren Elemente, Attribute und Tags - dennoch werden sämliche Begriffe von vielen pauschal durch "Tag" ersetzt. Genauso wie der Pfad ein Pfad ist und keine Ordnerstruktur und die Sonne nicht untergeht sondern durch die Rotation der Erde um die eigene Achse aus dem Blickfeld verschwindet. Durch entsprechende korrekte Bezeichung der Dinge wie sie sind erkennt man den Fachmann (oder zumindest denjenigen der Ahnung hat). Nachdem für URL sowohl der alsauch die zulässig ist, werde ich auch weiterhin die logisch und technisch korrekte Variante der bevorzugen.

Nur weil etwas weniger oft verwandt wird, bedeutet das nicht, dass es nicht richtig ist. --suit 10:51, 30. Jun. 2010 (CEST)

Unterschied URL <> Internetadresse

Aus dem Artikel kann man leider den Unteschied zwischen URL und Internetadresse nicht ableiten, obwohl extra im Text daauf hingewiesen wird, dass diese Begriffe oft synonym verwendet werden, was, für mich als Laien, darauf schließen lässt, dass es Unterschiede gibt. (nicht signierter Beitrag von 80.123.60.210 (Diskussion) 22:04, 10. Dez. 2010 (CET))

gudn tach!

die begriffe werden so sehr synonym verwendet, dass der duden "url" u.a. mit "internetadresse" erklaert. hilfreich waere wohl ein beispiel eines urls, der keine internetadresse ist oder umgekehrt. vermutlich wuerde man so was wie "de.wikipedia.org" als internetadresse bezeichnen, aber korrekterweise nicht als url, weil das protokoll fehlt. aber das ist afaics schon ein grenzfall, weil man sich nun darueber streiten kann, ob "de.wikipedia.org" wirklich eine internetadresse ist. -- seth 23:54, 10. Dez. 2010 (CET)

"Umgangssprachlich" sollte da schon stehen, um die Sache klar zu machen (im Duden wird die Umgangssprache behandelt; mir fällt nichts ein, wie man sonst eine Abgrenzung zu "fachsprachlich" deutlich machen soll). Davon abgesehen ist de.wikipedia.org ein Domainname und keine Internetaddresse (wenn man das im Browser aufruft, ergänzt der das nur zu einer URL). Da "fehlt" auch kein Protokoll, weil der Domainname auch in anderen Kontexten verwendet wird: Mailadressen wie nobody@de.wikipedia org, die auch in URLs vorkommen können: mailto:nobody@wikipedia.org, Host-Datei-Einträgen wie "127.0.0.1 de.wikipedia.org", Telnet-Aufrufen wie "telnet nobody@de.wikipedia.org", was auch als URL notiert werden kann: telnet:nobody@de.wikipedia.org, etc.... Auf der anderen Seite muss eine URL gar keinen Host-Domainnamen enthalten, es können z.B. auch Dateien auf der lokalen Festplatte über URLs angesprochen werden: file:///Users/rk/Desktop/test.txt – das hat dann auch mit "Internetaddresse" nix mehr zu tun. Wenn man sich das so ansieht, wird klar, dass mit dem umgangssprachlichen "Internetaddresse" nur bestimmte URLs gemeint sind, nämlich Webaddressen wie http://de.wikipedia.org. Aus der Luft gegriffen ist das auch nicht, weil das Web schließlich der Anlass für die "Erfindung" der URL war ;-). --Raphael Kirchner 09:24, 11. Dez. 2010 (CET)

Ups, hab mir nochmal RFC1738 durchgesehen. Dort wird definiert, dass URLs für "location and access of resources via the Internet" gedacht sind und immer ein Host drin ist, zumindest implizit: Das bei file:... erlaubte Weglassen ist nur ein Sonderfall, der Host ist dann schon "da", nur eben "leer", was als "localhost" interpretiert wird. Und weil "URL" nur eine Definition ist, ist das so, weil es so definiert ist ;-). Man könnte natürlich kritisch anmerken, dass RFC1738 in sich nicht stimmig ist, weil "mailto:..." nur mit Bauchweh resp. Pragmatismus unter "location and access of resources via the Internet" zu fassen ist, im Dokument aber explizit erwähnt wird. Auch bei file:... wird (zähneknirschend?) eingeräumt, dass man das nur für lokale Dokumente und nicht übers Netzwerk einsetzen kann (der "Sonderfall" also nicht nur der Standardfall, sondern der einzig mögliche Fall ist). Aber einer der Erfolgsfaktoren für das WWW war ja eben der Pragmatismus... --Raphael Kirchner 10:54, 11. Dez. 2010 (CET)

(bk) gudn tach!

der duden stellt das attribut "ugs." fuer umgangssprachliche woerter bereit. bei der bedeutung "internetadresse" von "url" steht allerdings dieses attribut nicht. ebensowenig im wahrig. selbst lexika beschreien es teilweise so.[6] insofern halte ich "umgangssprachlich" fuer nicht 100%-ig treffend. man sollte aber, da stimme ich klar zu, angeben, dass das fachsprachlich (per rfc) differenzierter betrachtet wird.

eine domain kann man denke ich schon als internetadresse bezeichnen, da der begriff "internetadresse" nicht eindeutig definiert ist. dass der browser automatisch das http ergaenzt, ist ja nicht viel anders als das weglassen des ports, oder? es wird halt ein defaultwert angenommen (und der ist nicht "ftp" oder "gopher").

abgesehen davon ist dein beispiel mit "file" aber sehr gut. allerdings muesste der artikel noch entsprechend abgeaendert werden. denn dort wird derzeit nur von netzwerkprotokollen gesprochen, was "file" jedoch gar nicht ist. magst du den artikel entsprechend ueberarbeiten? -- seth 11:23, 11. Dez. 2010 (CET)

[7] halte ich deshalb fuer uebertrieben und btw. stimmt jetzt der duden als beleg ueberhaupt nicht mehr fuer die neue aussage. -- seth 11:27, 11. Dez. 2010 (CET)

...jo, bin grad beim Überarbeiten. Der Artikel ist in diesem Punkt falsch, d.h. gibt auch den als Quelle angegebenen RFC falsch wieder. Zu "ugs.": Was hälst Du von "im allgemeinen Sprachgebrauch"? Ah ja: Meinst Du mit "neue Aussage" die Erwähnung der irrtümlichen Gleichsetzung von Internet und WWW? Das steht z.B. in World Wide Web auch "unbelegt" drin, ich würde das auch fast als "allgemeinkundige Tatsache" sehen :D – aber vielleicht findet sich ja ein Beleg. --Raphael Kirchner 16:46, 11. Dez. 2010 (CET)

gudn tach!

ja, "allgemeiner sprachgebrauch" passt imho. (bei der unterscheidung zw. web und internet ist es btw. aehnlich.)

nach deiner aenderung sah es so aus, als solle der duden was anderes belegen. hab's selbst umgebaut.[8] -- seth 17:11, 11. Dez. 2010 (CET)

Sorry, da war ich etwas schlampig... so isses klarer! Es fand sich btw sogar eine Quelle für den "häufigen Irrtum" ;-) --Raphael Kirchner 17:15, 11. Dez. 2010 (CET)

Ich wiederhole meinen Kommentar vom Juni dieses Jahres nochmal:

[...] ein URL ist keineswegs eine Adresse, es ist ein Ressourcenbezeichner. Eine Adresse (etwa wie eine Domain) wäre "Max Mustermann, Musterstraße 1, 1234 Musterhausen;" ein Ressourcenbezeichner hingegen ist z.B. sowas: "Max Mustermann, Musterstraße 1, 1234 Musterhausen; 1. Stockwerk, Zimmer Nummer 144, 3. Aktenschrank, 7. Ordner unter dem Reiter J, Dokument: 'Beispiel', Seite" 12

Nachdem das Wort "Internetadresse" analog zur "Postadresse" verwandt wird, ist es also falsch. Natürlich könnte man sagen, dass eine Adresse auch auch sehr spezifisch sein kann - z.B. bei der Adressierung von Speicherbereichen. Aber das ist in diesem Kontext wohlkaum gemeint. --suit 20:07, 11. Dez. 2010 (CET)

Jo, "Adresse" ist eigentlich doppelt falsch, weil eine URL ja auch noch die Zugriffsmethode beinhaltet (was der durchschnittliche "Internetadresse"-Sager wohl kaum weiß – für den ist "http://" halt irgend so ein Vorgeplänkel), d.h. wenn schon wäre nur der zweite Teil der URL eine "Adresse". Aber es wird halt mal so verwendet und steht so im Duden, also gehört das in den Artikel. Dabei fällt mir gerade auf: So, wie es "falsch" verwendet wird (wenn z.B. im TV "unsere Internetadresse" eingeblendet wird), passt ja der Vergleich mit der Postadresse, da typischerweise nur auf die "Homepage" ohne Pfad verweisen wird. Die von Dir angeregte Klarstellung sollte also noch irgendwie sinnvoll bequellt in den Artikel rein. --Raphael Kirchner 21:13, 11. Dez. 2010 (CET)

@seth: Wasnjetzlos? Dass Internet und WWW gleichzusetzen ein Irrtum ist, ist nicht Ansichts- sondern Tatsache. Geht aus den Artikeln klar hervor und steht sogar in der unmittelbaren Quelle ;-). --Raphael Kirchner 00:02, 12. Dez. 2010 (CET)

gudn tach!

"Die Begriffe Internet und World Wide Web werden im Sprachgebrauch häufig gleichgesetzt." wird auch im verlinkten artikel gesagt. klar, es folgt direkt der satz "Technisch besteht allerdings ein erheblicher Unterschied." und dann die lange erklaerung dessen. aber der witz ist doch, dass die mehrzahl der sprecher diesen unterschied auf semantischer ebene gar nicht macht. es gibt also die alltagssprachen bedeutungen von "web" und von "internet" und eben auch die terminologischen, die wesentlich differenzierter sind; aehnlich wie die mehrzahl der sprecher dem url ein weibliches genus verpasst, obwohl wohl keiner "die uniform resource locator" sagen wuerde.

sprache bzw. die bedeutung der woerter wird durch die (mehrzahl der) sprecher gebildet. im artikel sollte selbstverstaendlich die fachlich uebliche bedeutung in den vordergrund gerueckt und beschrieben werden. wir duerfen in einer enzyklopaedie aber nicht wortbenutzung der mehrheit als "falsch" oder "irrtuemlich" bezeichnen, wenn jene leute ganz andere definitionen der woerter zugrunde legen, als es die fachwelt tut, sondern duerfen lediglich darauf hinweisen, dass es diesen unterschied gibt, ohne diesen zu werten.

es geht hier ja nicht darum, dass ein naturgesetz infrage gestellt wird, sondern wirklich nur um den sprachgebrauch; und bei jenem gibt es haeufig mehr als eine wahrheit. -- seth 00:30, 12. Dez. 2010 (CET)

Ahh - jetzt kapiere ich, was Du meinst! Stimmt, der Gedankengang ist schlüssig. Ich merke, dass ich da offensichtlich (berufsbedingt) etwas betriebsblind rangehe... Zum Genus: Lustig ist übrigens, dass "back in da days" (~1994), als unter österreichischen EDVern der Begriff URL gelernt wurde, in meinem Umfeld zumindest alle "die URL" sagten, weil man das als "Web-Adresse" verstand. Das ging im Kopf analog zu den bekannten Begriffen "Telnet-Adresse" und "Gopher-Adresse" (das waren die Vorläufer: man hat ja teilweise eine bestimmte Ressource erst über ein Telnet-Service bekommen, später gab's das via Gopher, und noch später im Web). --Raphael Kirchner 10:51, 12. Dez. 2010 (CET)

Einleitung

Könnte mal jemand den Einleitungssatz dahingehend ändern Uniform Resource Locator (URL, dt. „einheitlicher Quellenanzeiger“) ist ein Begriff aus .... (der Computertechnik oder der Programmiersprache oder was weiß ich)? Danke --Kürschner 10:12, 15. Sep. 2011 (CEST)

mailto: query

Bei mailto: ist es auch möglich, hinten eine „query“ anzuhängen, z. B.:

mailto:example@example.com?subject=btr&body=msg

Könnte man evtl. mit in den Artikel aufnehmen. DongKingKong0 (Diskussion) 22:17, 8. Feb. 2018 (CET)

@DongKingKong0: WP:Sei mutig! --Geri, ✉  15:35, 8. Sep. 2022 (CEST)