URL - Історія редагувань

Spam cleanup script: Cleaning up links to custom-paper-writing.com

2012-03-10T06:49:52Z

Cleaning up links to custom-paper-writing.com

Nixiedelacruz в 12:57, 24 жовтня 2011

2011-10-24T12:57:20Z

Galja в 13:03, 31 січня 2011

2011-01-31T13:03:10Z

Galja в 23:08, 30 січня 2011

2011-01-30T23:08:27Z

Показати зміни

Galja в 22:39, 30 січня 2011

2011-01-30T22:39:21Z

Galja в 22:01, 30 січня 2011

2011-01-30T22:01:53Z

Показати зміни

VicktoR в 08:48, 28 грудня 2010

2010-12-28T08:48:51Z

Galja в 13:20, 27 грудня 2010

2010-12-27T13:20:34Z

Galja в 13:16, 27 грудня 2010

2010-12-27T13:16:58Z

Galja в 13:14, 27 грудня 2010

2010-12-27T13:14:37Z

← Попередня версія		Версія за 06:49, 10 березня 2012
Рядок 192:		Рядок 192:
	# http://richvibe.blogspot.com/2010/10/url.html		# http://richvibe.blogspot.com/2010/10/url.html
	# http://denweb.ru/put-veb-mastera/osnovnye-ponyatiyaurl-cookies-kilobajty-i-kilobity-chast3.html		# http://denweb.ru/put-veb-mastera/osnovnye-ponyatiyaurl-cookies-kilobajty-i-kilobity-chast3.html
−
−	~~[http://custom-paper-writing.com/custom_research_paper research paper help]~~

← Попередня версія		Версія за 12:57, 24 жовтня 2011
Рядок 192:		Рядок 192:
	# http://richvibe.blogspot.com/2010/10/url.html		# http://richvibe.blogspot.com/2010/10/url.html
	# http://denweb.ru/put-veb-mastera/osnovnye-ponyatiyaurl-cookies-kilobajty-i-kilobity-chast3.html		# http://denweb.ru/put-veb-mastera/osnovnye-ponyatiyaurl-cookies-kilobajty-i-kilobity-chast3.html
		+
		+	[http://custom-paper-writing.com/custom_research_paper research paper help]

← Попередня версія		Версія за 13:03, 31 січня 2011
Рядок 188:		Рядок 188:
	=='''Ініціатива PURL'''==		=='''Ініціатива PURL'''==
	Ще один кардинальний недолік URL полягає у відсутності гнучкості. Ресурси у Всесвітній павутині та Інтернеті переміщуються, а посилання у вигляді URL залишаються, вказуючи на вже відсутні ресурси. Це особливо болісно для електронних бібліотек, каталогів та енциклопедій. Для вирішення цієї проблеми було запропоновано постійні локатори PURL (англ. Persistent Uniform Resource Locator). По суті це ті ж URL, але вони вказують не на конкретне місце розташування ресурсу, а на запис в базі даних PURL, де, у свою чергу, записаний вже конкретний URL-адресу ресурсу. При зверненні до PURL сервер знаходить потрібну запис в цій базі даних і перенаправляє запит вже на конкретне місце розташування ресурсу. Якщо адресу ресурсу змінюється, то немає потреби виправляти всі незліченні посилання на нього - досить лише змінити запис у БД. На даний момент ця ідея не стандартизована і не має широкого розповсюдження.		Ще один кардинальний недолік URL полягає у відсутності гнучкості. Ресурси у Всесвітній павутині та Інтернеті переміщуються, а посилання у вигляді URL залишаються, вказуючи на вже відсутні ресурси. Це особливо болісно для електронних бібліотек, каталогів та енциклопедій. Для вирішення цієї проблеми було запропоновано постійні локатори PURL (англ. Persistent Uniform Resource Locator). По суті це ті ж URL, але вони вказують не на конкретне місце розташування ресурсу, а на запис в базі даних PURL, де, у свою чергу, записаний вже конкретний URL-адресу ресурсу. При зверненні до PURL сервер знаходить потрібну запис в цій базі даних і перенаправляє запит вже на конкретне місце розташування ресурсу. Якщо адресу ресурсу змінюється, то немає потреби виправляти всі незліченні посилання на нього - досить лише змінити запис у БД. На даний момент ця ідея не стандартизована і не має широкого розповсюдження.
		+	=='''Список використаних джерел'''==
		+	# http://wiki.fizmat.tnpu.edu.ua/index.php/URL
		+	# http://richvibe.blogspot.com/2010/10/url.html
		+	# http://denweb.ru/put-veb-mastera/osnovnye-ponyatiyaurl-cookies-kilobajty-i-kilobity-chast3.html

@@ Рядок 8: / Рядок 8: @@
 У цьому записі:
-'''схема'''
+<br>'''схема'''
-схема звернення до ресурсу; в більшості випадків мається на увазі мережевий протокол
+<br>схема звернення до ресурсу; в більшості випадків мається на увазі мережевий протокол
-'''логін'''
+<br>'''логін'''
-ім'я користувача, використовуване для доступу до ресурсу
+<br>ім'я користувача, використовуване для доступу до ресурсу
-'''пароль'''
+<br>'''пароль'''
-пароль указаного користувача
+<br>пароль указаного користувача
-'''хост'''
+<br>'''хост'''
-повністю прописане доменне ім'я хоста в системі DNS або IP-адреса хоста у формі чотирьох десяткових чисел, розділених крапками; числа - натуральні в інтервалі від 0 до 255.
+<br>повністю прописане доменне ім'я хоста в системі DNS або IP-адреса хоста у формі чотирьох десяткових чисел, розділених крапками; числа - натуральні в інтервалі від 0 до 255.
-'''порт'''
+<br>'''порт'''
-порт хоста для підключення
+<br>порт хоста для підключення
-'''URL-шлях'''
+<br>'''URL-шлях'''
-уточнююча інформація про місце знаходження ресурсу; залежить від протоколу.
+<br>уточнююча інформація про місце знаходження ресурсу; залежить від протоколу.
-'''параметри'''
+<br>'''параметри'''
-рядок запиту з переданими на сервер (методом GET) параметрами. Роздільник параметрів - знак '''&'''. Приклад:? Параметр_1 = значення_1 & параметр_2 = значення_2 & параметр3 = значеніе_3
+<br>рядок запиту з переданими на сервер (методом GET) параметрами. Роздільник параметрів - знак <br>'''&'''. Приклад:? Параметр_1 = значення_1 & параметр_2 = значення_2 & параметр3 = значення_3
-якоря
+<br>'''якоря'''
-ідентифікатор «якоря», що посилається на деяку частину (розділ) відкривається документа.
+<br>ідентифікатор «якоря», що посилається на деяку частину (розділ) відкривається документа.
 На сьогоднішній день Тім Бернес-Лі визнає, що символ подвійної косої риси у структурі URL є надлишковим.
-Схеми (протоколи) URL
+=='''Схеми (протоколи) URL'''==
-Загальноприйняті схеми (протоколи) URL включають:
+<br>Загальноприйняті схеми (протоколи) URL включають:
-• ftp - Протокол передачі файлів FTP
+<br>• ftp - Протокол передачі файлів FTP
-• http - Протокол передачі гіпертексту HTTP
+<br>• http - Протокол передачі гіпертексту HTTP
-• https - Спеціальна реалізація протоколу HTTP, що використовує шифрування (як правило, SSL або TLS)
+<br>• https - Спеціальна реалізація протоколу HTTP, що використовує шифрування (як правило, SSL або TLS)
-• gopher - Протокол Gopher
+<br>• gopher - Протокол Gopher
-• mailto - Адреса електронної пошти
+<br>• mailto - Адреса електронної пошти
-• news - Новини Usenet
+<br>• news - Новини Usenet
-• nntp - Новини Usenet через протокол NNTP
+<br>• nntp - Новини Usenet через протокол NNTP
-• irc - Протокол IRC
+<br>• irc - Протокол IRC
-• prospero - Служба каталогів Prospero Directory Service
+<br>• prospero - Служба каталогів Prospero Directory Service
-• telnet - Посилання на інтерактивну сесію Telnet
+<br>• telnet - Посилання на інтерактивну сесію Telnet
-• wais - База даних системи WAIS
+<br>• wais - База даних системи WAIS
-• xmpp - Протокол XMPP (частина Jabber)
+<br>• xmpp - Протокол XMPP (частина Jabber)
-• file - Ім'я локального файлу
+<br>• file - Ім'я локального файлу
-• data - Безпосередні дані (Data: URL)
+<br>• data - Безпосередні дані (Data: URL)
-Екзотичні схеми URL:
+<br>Екзотичні схеми URL:
-• afs - Глобальне ім'я файлу у файловій системі Andrew File System
+<br>• afs - Глобальне ім'я файлу у файловій системі Andrew File System
-• cid - Ідентифікатор вмісту для частин MIME
+<br>• cid - Ідентифікатор вмісту для частин MIME
-• mid - Ідентифікатор повідомлень для електронної пошти
+<br>• mid - Ідентифікатор повідомлень для електронної пошти
-• mailserver - Доступ до даних з поштових серверів
+<br>• mailserver - Доступ до даних з поштових серверів
-• nfs - Ім'я файлу в мережевій файловій системі NFS
+<br>• nfs - Ім'я файлу в мережевій файловій системі NFS
-• tn3270 - Емуляція інтерактивної сесії Telnet 3270
+<br>• tn3270 - Емуляція інтерактивної сесії Telnet 3270
-• z39.50 - Доступ до служб ANSI Z39.50
+<br>• z39.50 - Доступ до служб ANSI Z39.50
-• skype - Протокол Skype
+<br>• skype - Протокол Skype
-• smsto - Відкриття редактора SMS в деяких мобільних телефонах
+<br>• smsto - Відкриття редактора SMS в деяких мобільних телефонах
-• ed2k - Файлообмінна мережа eDonkey, побудована за принципом P2P
+<br>• ed2k - Файлообмінна мережа eDonkey, побудована за принципом P2P

@@ Рядок 1: / Рядок 1: @@
-==
 Адреси хост-комп'ютерів в мережі Інтернет можуть мати подвійну кодування:
-    * Обов'язкове кодування, зручну для роботи системи телекомунікації в мережі: IP-адресу;
+* Обов'язкове кодування, зручну для роботи системи телекомунікації в мережі: IP-адресу;
-    * Необов'язкову кодування, зручну для абонента мережі: доменний DNS-адреса (DNS - Domain Name System).
+* Необов'язкову кодування, зручну для абонента мережі: доменний DNS-адреса (DNS - Domain Name System).
 Цифровий IP-адреса версії V.4 представляє собою 32-розрядне двійкове число. Для зручності він розділяється на чотири блоки по 8 біт, які можна записати в десятковому вигляді. Адреса містить повну інформацію, необхідну для ідентифікації комп'ютера. Зважаючи на величезну кількість підключених до мережі комп'ютерів і різних організацій відчувається обмеженість 32-розрядних IP-адрес, тому ведеться розробка модернізованого протоколу IP-адресації, що має на меті:
-    * Підвищення пропускної здатності мережі;
+* Підвищення пропускної здатності мережі;
-    * Створення краще масштабується і адаптируемой схеми адресації;
+* Створення краще масштабується і адаптируемой схеми адресації;
-    * Забезпечення гарантій якості транспортних послуг;
+* Забезпечення гарантій якості транспортних послуг;
-    * Забезпечення захисту інформації, переданої в мережі.
+* Забезпечення захисту інформації, переданої в мережі.
 Основою нового протоколу V.6 є 128-бітові адреси, забезпечують понад 1000 адрес на кожного жителя землі. Впровадження цієї адресації зніме проблему дефіциту цифрових адрес. Проте головною метою розробки нового протоколу є не стільки розширення розрядності адреси, скільки збільшення рівнів ієрархії в адресі, що відбиває тепер 5 ідентифікаторів: два старших для провайдерів мережі (ідентифікатори провайдера та його реєстру) і три для абонентів (абонента, його мережі і вузла мережі) .

@@ Рядок 53: / Рядок 53: @@
 URL представляє собою текстову рядок без пробілів. У цьому рядку спочатку вказується метод доступу до ресурсу, тобто протокол доступу, потім адресу ресурсу в Мережі (ім'я домену і хост-машини) і, нарешті, повний шлях до файлу на сервері.
-:[[Файл:галя2.jpg]]
+:[[Файл:формат url.jpg]]
 :[[Файл:url.jpg]]

← Попередня версія		Версія за 13:16, 27 грудня 2010
Рядок 48:		Рядок 48:

	: [[Файл:Uniform Resource Locator.jpg]]		: [[Файл:Uniform Resource Locator.jpg]]
		+
		+	:Перше поняття - URL. Що таке URL? URL (Uniform Resource Locator) - це унікальний адреса для доступу до інформаційних ресурсів в інтернеті (зокрема, до веб-сторінок). Якщо користувачеві відомий URL веб-сторінки, він може побачити її, задавши цей URL в адресному рядку браузера.
		+
		+	URL представляє собою текстову рядок без пробілів. У цьому рядку спочатку вказується метод доступу до ресурсу, тобто протокол доступу, потім адресу ресурсу в Мережі (ім'я домену і хост-машини) і, нарешті, повний шлях до файлу на сервері.

	:[[Файл:галя2.jpg]]		:[[Файл:галя2.jpg]]

← Попередня версія		Версія за 13:14, 27 грудня 2010
Рядок 52:		Рядок 52:

	:[[Файл:url.jpg]]		:[[Файл:url.jpg]]
		+
		+	:Що таке статичний URL
		+	Статичний URL - це той, який не змінюється і зазвичай не містить URL параметрів. Він виглядет приблизно так:
		+
		+	http://www.example.com/archive/january.htm
		+
		+	Статичні URL можна знайти в Google, використовуючи конструкцію filetype: htm. Для великих, часто оновлюваних сайтів: форумів, онлайн магазинів, блогів і систем управління контентом вебмайстра використовують динамічні URL.
		+	Що таке динамічний URL
		+	Якщо контент сайту збережений у базі даних і відображається на сторінках за запитом, тоді можуть використовуватися динамічні урли. У цьому випадку сайт складається тільки з шаблонів для контенту. Зазвичай динамічний URL виглядає приблизно так:
		+
		+	http://code.google.com/p/google-checkout-php-sample-code/issues/detail?id=31
		+
		+	Google уважає, що якщо в урле є знаки?, =, &, Тоді це динамічний URL. Один з недоліків динамічного URL в тому, що можливий випадок дублювання контенту. Тобто урл з різними параметрами може привести до одного і того ж контенту. Це одна з причин, по якій вебмайстра реврайтят урли в статичні.
		+	Google рекомендує не переписувати динамічні URL в статичні
		+	У своєму пості гуглі говорять і підкреслюють не потрібно переформовувати динамічні URL, щоб вони виглядали статичними, але в той же час визнають, що "статичні URL може мати невелику перевагу в клікабельності (CTR) ". І знову ж таки говорять про те, що "динамічні URL мають привілеї над статичними ". Коротко резюміруюя їх статтю, можна зробити висновок, що вони активно рекомендують використовувати динамічні URL і не переписувати їх у статичні, аргументуючи це тим, що:
		+
		+	* досить складно зробити правильним зміна динамічних URL в статичні
		+	* Googblebot може успішно індексувати динамічні URL й інтерпретувати різні параметри
		+	* при зміні URL ви можете позбавити бота цінних параметрів, що беруть участь в ранжируванні
		+
		+	Думки вебмайстрів про динамічних і статичних URL
		+	У коментарях до згаданої статті вебмайстра у великому числі висловлюють невдоволення, посилаючись на переваги статичних урлов. Однак працівники Google у відповідях заявляють, і правильно помічають, що блог для веб-майстрів, а не для SEOшніков і пост писався саме для цієї аудиторії. Дійсно, багато вебмастера далеко не є знавцями SEO і можуть наробити багато помилок при реврайте динамічних URL в статичні. Google намагається з одного боку допомогти вебмайстрам, а з іншого зробити свою пошукову видачу більш релевантною для користувача.
		+	Ренд Фішкін у своєму блозі висловлює думку про те, що Google дивиться на цю проблему з іншого ракурсу, як фахівець з маркетингу. Говорить про те, що Google не обманює або дізінформірует, а лише переймаються про найголовніше - ефективно і раціонально індексувати web і зберігати точні дані про контент сторінок.
		+	Переваги динамічних URL
		+
		+	* зазвичай вони коротші
		+	* гугл (перший з 4-х головних пошукачів) говорить, що може їх ефективно індексувати
		+
		+	Недоліки динамічних URL
		+
		+	* низький CTR в серп, в електронних листах, а також на форумах / блогах, де просто використовують копіпаст
		+	* велика веротяность обрізання кінцевої частини URL і в результаті отримання чотиреста четвертий помилки при копіпаст
		+	* низька релевантність ключового слова
		+	* майже неможливо написати вручну і поширювати на бізнес-картах або диктувати по телефону
		+	* дуже складно запам'ятовується або не запам'ятовується зовсім
		+	* користувач точно не знає, чого очікувати перед тим, як запросить сторінку
		+	* не оптимізовані для анкорного тексту (часто при копіпаст в блоги, форуми та ін)
		+
		+	Переваги статичних URL
		+
		+	* високий CTR у пошукових результатах, електронних листах (email), на сторінках і т.д.
		+	* велика релевантність ключових словах
		+	* просто для копіювання, вставки, і розповсюдження онлайн та офлайн
		+	* легко запам'ятати і таким чином можна використовувати в брендінгу та офлайн медіа
		+	* користувач зараннее може інтуїтивно знати, що йому очікувати при введенні урла в браузері
		+	* можна чекати гарного анкорного тексту при використанні посилань у вигляді урла
		+	* всі 4 з головних пошукачів і безліч інших псів зазвичай працюють зі статичними URL набагато простіше, ніж з динамічними, особливо при великій кількості параметрів
		+
		+	Недоліки статичних URL
		+
		+	* ви можете наплутати чого-небудь у процесі реврайта, що призведе до проблем отримання контенту користувачами і ботами