Можно ли использовать в домене нижнее подчеркивание

Содержание статьи

Может ли (доменное имя) поддомены иметь подчеркивание «» в нем?

могут ли поддомены (доменные имена) иметь подчеркивание _ в них?

7 ответов

большинство ответов здесь false. Совершенно законно иметь подчеркивание в доменном имени. Позвольте мне процитировать стандарт, RFC 2181, раздел 11, «синтаксис имен»:

сам DNS помещает только одно ограничение на определенные метки это можно использовать для идентификации записей ресурсов. Вот этот ограничение касается длины этикетки и полной имя. […] Реализации протоколов DNS не должны размещать ограничения на метки, которые можно использовать. В частности, DNS серверы не должны отказываться обслуживать зону, поскольку она содержит метки это может быть неприемлемо для некоторых клиентских программ DNS.

см. также исходную спецификацию DNS,RFC 1034, раздел 3.5 «Предпочтительный синтаксис имени», но прочитайте его внимательно.

Домены с подчеркиванием очень распространены в дикой природе. Проверка _jabber._tcp.gmail.com или _sip._udp.apnic.net.

другие RFC, упомянутые здесь, имеют дело с разные вещи. Оригинал вопрос был за доменные имена. Если вопрос для хоста имена (или для URL-адресов, которые включают имя хоста), то это разные, соответствующий стандарт RFC 1123 раздел 2.1 «хозяина Имена и цифры», который ограничивает хостов в буквы-цифры-дефис.

замечание по терминологии, в развитие ответа Бортцмейера

следует четко понимать определения. Как используется здесь:

доменное имя — это идентификатор ресурса в базе данных DNS
метка is часть доменного имени между точками
хоста это специальный тип доменного имени, идентифицирующего интернет хозяева

на хоста подлежит ограничениям RFC 952 и небольшая релаксация RFC 1123

RFC 2181 дает понять, что существует разница между доменным именем и именем хоста:

…[тот факт, что] любая двоичная метка может иметь запись MX, не означает, что любое двоичное имя может использоваться в качестве хост-части электронной почты адрес…

так подчеркивает в хоста нет-нет, подчеркивает в доменные имена are a-ok.

на практике, можно посмотреть хоста С подчеркивания. Как Принцип Робастности говорит:»Будьте консервативны в том, что вы посылаете, либеральны в том, что вы принимаете».

заметка о кодировке

в 21 веке оказывается, что хоста а также доменные имена может быть интернациональными! Это означает обращение к кодировкам в случае метки которые содержат символы, находящиеся за пределами разрешенного набора.

в частности, он позволяет кодировать _ на хоста (обновление 2017-07: это сомнительно, см. комментарии. The _ по-прежнему не может использоваться в именах хостов. Действительно, его нельзя даже использовать в интернационализированных этикетках.)

первый RFC для интернационализации был RFC 3490 от марта 2003 года, » интернационализация доменных имен в приложениях (IDNA)». Сегодня, мы имеем:

RFC 5890 «IDNA: определения и рамки документов»
RFC 5891 «IDNA: протокол»
RFC 5892 «кодовые точки Юникода и IDNA»
RFC 5893 «справа налево скрипты для IDNA»
RFC 5894 » IDNA: Предыстория, объяснение и обоснование»
RFC 5895 «отображение символов для IDNA 2008»

вы также можете проверить Википедии

RFC 5890 вводит термин LDH (буква-цифра-Гипен) этикетка на метки в хоста и говорит:

это классическая форма этикетки, хотя и с некоторыми дополнительными ограничения, в именах хостов (RFC 952). Его синтаксис идентичен тому, который описан как» синтаксис предпочтительного имени » в разделе 3.5 RFC 1034, измененного RFC 1123. Короче говоря, это строка, состоящая из букв ASCII, цифр и дефиса с дальнейшим ограничением, что дефис не может отображаться в начале или конце строки. Как и все DNS-метки, его общая длина не должна превышать 63 октетов.

возвращаясь к более простым временам,этот интернет-проект это раннее предложение для хоста интернационализации. Имена хостов с международными символами могут быть закодированы, например,’ RACE ‘ кодировка.

автор предложения «расовая кодировка» отмечает:

согласно RFC 1035, хост-части должны быть нечувствительны к регистру, начинаться и заканчиваться буквой или цифрой и содержать только буквы, цифры и символ дефиса («-«). Это, конечно, исключает любые интернационализированные персонажи, а также многие другие персонажи в репертуаре персонажей ASCII. Кроме того, части доменных имен должны быть 63 октета или короче в длина…. Все части имени после преобразования, содержащие интернационализированные символы, начинаются со строки » BQ—«. (…) Строку «БК» был выбран потому, что это крайне маловероятно существовать в частях хозяина прежде чем эта спецификация была произведена.

есть еще одна вещь, которую вам может понадобиться знать: если хост или часть поддомена url содержат подчеркивание, IE9 (не тестировали другие версии) не может писать куки.

Так что будьте осторожны. 🙂

уточнение bortzmeyer и Дэвид Tonhofer, доменное имя и метки имен поддоменов могут содержать ведущие подчеркивания, но больше нигде.

As Дэвид Tonhofer написал, метки являются частями между периодами и должны следовать правилу LDH за исключением при указании меток служб и портов, чтобы отличить их от обычных меток. Затем они должны произойти в начале метки, которая должна быть » короткой Имена » из имя службы и номер порта в реестре, номер порта без ведущих 0s или протокол (т. е. tcp, udp). Эти метки служб дополнительно ограничены 15 символами.

RFC2782 задает префикс поддомены служебных записей с подчеркиванием.
RFC6698 задает префикс номера портов с подчеркиваниями в записях сертификатов TLSA.

вопреки Давид Tonhofer’s ответ, IDN не позволяет кодировать подчеркивание (‘_’U+005F LOW LINE) или любой другой недопустимый символ ASCII.

С RFC5890

[..] два новых подмножества меток LDH создаются введение IDNA. Они называются зарезервированными метками LDH (R-LDH ярлыки) и Non-Reserved ярлыки LDH (ярлыки NR-LDH). Защищены ЛДГ метки, известные как» помеченные доменные имена » в некоторых других контекстах, имеют свойство, которое они содержать «—» в третьем и четвертом персонажи но которые в противном случае соответствуют правилам ярлыка LDH.

Punycode кодирует все кодовые точки ASCII как ASCII напрямую, включая подчеркивание. Полученный R-LDH не будет соответствовать правилам метки LDH. Например, Σ_.com будет закодировано как xn--_-zmb.com что нарушает правила. Может быть гомографическая кодовая точка, которая выглядит как подчеркивание, которое может быть закодировано юридически (возможно, ‘ ＿ ‘ U+ff3f fullwidth low line), но эти виды кодовых точек будут классифицированы как запрещенные RFC5892 под 2.3 IgnorableProperties как Noncharacter_Code_Point.

RACE (другая предлагаемая схема кодирования IDN) не была принята в качестве стандарта IETF и не должна использоваться.

я проследовал по ссылке на RFC1034 и прочитал большую часть и был удивлен, увидев это:

метки должны следовать правилам для имен узлов ARPANET. Они должны начинаться с буквы, заканчиваться буквой или цифрой и в качестве межкомнатных символов только буквы, цифры и дефис. Есть также некоторые ограничения по длине. Этикетки должны быть не более 63 символов.

для уточнения, доменные имена состоят из меток, разделенных точками «.». Эта спецификация должна быть устаревшей, поскольку в ней не упоминается использование подчеркиваний. Я могу понять путаницу, если кто-то спотыкается об эту спецификацию, не зная, что она устарела. Она устарела, не так ли?

Я пошел по ссылке на RFC2181 и прочитал некоторые из них. Особенно, когда это касается вопроса о том, что является авторитетным или каноническим именем и вопросом о том, что делает допустимую метку DNS.

Как было опубликовано ранее, в нем говорится, что есть только ограничение длины подводя итог, он гласит:

(об именах и допустимых метках)

Они уже достаточно указаны, однако спецификации, похоже, иногда игнорируются. Мы стремимся укрепить существующие спецификации.

вид оставляет мне интересно, является ли» ограничение длины только «»адекватным». Мы собираемся начать видеть доменные имена типа @#$%!! скоро? Разве интернет недостаточно облажался?

вот мои 2 цента из Java world:

из консоли Spark Scala с Java 8:

scala> new java.net.URI(«spark://spark_master»).getHost res10: String = null scala> new java.net.URI(«spark://spark-master»).getHost res11: String = spark-master scala> new java.net.URI(«spark://spark_master.google.fr»).getHost res12: String = null scala> new java.net.URI(«spark://spark.master.google.fr»).getHost res13: String = spark.master.google.fr scala> new java.net.URI(«spark://spark-master.google.fr:3434»).getHost res14: String = spark-master.google.fr scala> new java.net.URI(«spark://spark-master.goo_gle.fr:3434»).getHost res15: String = null

Это определенно плохая идея ^^

автор: resourceful-idiot

Источник

Домен с нижним подчеркиванием в зоне ru — это вообще как?

МА

На сайте с 02.11.2018

Offline

Господа домейнеры, проясните эту картинку:

Как такое возможно в зоне ru? Я бы понял, если какая-нибудь экзотическая зона, и то черт знает, прокатит ли такое. Или это дела минувших дней, и раньше такое можно было провернуть? И регистратор, к примеру, осознав, что домен уже зареган, но так низя, потом просто принудительно подчеркивание дефисом заменил с сохранением домена владельцем? Или это какая-нибудь кодировка хитрая использовалась? Или это просто бэки на домен неправильно изначально ставили, а потом разнесли по всяким другим страницам вот это всё?

Вопросы, вопросы.

Nokia x71 (https://x71.ru/) — хороший смартфон, и отзывы интересные

На сайте с 08.03.2009

Offline

227

А если на другом заборе напишут домен с верхним подчеркиванием, тоже будете терзаться вопросами?)) Просто перейдите, или чекните его, и все станет ясно….

МА

На сайте с 02.11.2018

Offline

fhuuz #:

Так не чекается.

На сайте с 03.11.2008

Offline

1463

На сайте с 27.02.2016

Offline

3.1. Требования к доменным именам

3.1.1. Доменное имя в домене .RU должно состоять из собственного обозначения, уникального в пределах домена верхнего уровня, и символов «.ru».

Собственное обозначение должно отвечать следующим техническим требованиям:

1)содержать не менее двух символов;

2)содержать не более 63 символов;

3)начинаться и заканчиваться буквой или цифрой;

4)не содержать символов, отличных от букв, цифр и дефиса (допустимыми буквами являются буквы латинского алфавита; прописные и строчные буквы не различаются);

5)не содержать одновременно дефисы в 3-й и 4-й позициях.

https://cctld.ru/files/pdf/docs/rules_ru-rf.pdf

На сайте с 03.11.2008

Offline

1463

Ravel #:

Вотоночёоказывается. Спс, бум знать.

На сайте с 22.07.2006

Offline

235

При проверке домена в регру редиректит на whois домена EDUALL.RU. А на скрине просто по ошибке неправильный урл с подчеркиванием проставили.

МА

На сайте с 02.11.2018

Offline

S_E_O #:

Ну там просто достаточно много страниц с разных доменов с такими как бы ошибками в урле. Потому и озадачило.

На сайте с 13.04.2006

Offline

310

Махмуд Аббас #:

Ну там просто достаточно много страниц с разных доменов с такими как бы ошибками в урле. Потому и озадачило.

Какой-то глюк конкретной системы. Таких доменов не бывает.

Возможно, по ошибке при выводе заменяют им, например, дефис.

Хотя посмотрел пример из топика — нет, просто разделитель слов, выходит. Хз кто, зачем и почему так сделал 🙂

Продвигай свои сайты на Main (https://mai.ru) Регистрация и продление доменов в российских и международных зонах по честным ценам без звездочек. (https://RegHome.ru) (R01, WebNames, UK2). Принимаем WMR, WMP, ЯД, Visa, MasterCard, Мир

На сайте с 20.03.2013

Offline

Скорей всего какой-нибудь скрипт валидатор заменяет небезопасный символ.

На сайте с 08.03.2009

Offline

227

19 ноября 2020, 19:21

#10

И после того, как вы поняли, что он не чекается, ясность, вернее, даже просветление, должно было снизойти- такого домена попросту нет и не могло быть, ибо регистрация с таким символом не могла пройти!

Источник

Можно ли использовать нижнее подчеркивание в имени домена

Может ли (доменное имя) поддомены иметь подчеркивание «» в нем?

могут ли поддомены (доменные имена) иметь подчеркивание _ в них?

7 ответов

сам DNS помещает только одно ограничение на определенные метки это можно использовать для идентификации записей ресурсов. Вот этот ограничение касается длины этикетки и полной имя. [. ] Реализации протоколов DNS не должны размещать ограничения на метки, которые можно использовать. В частности, DNS серверы не должны отказываться обслуживать зону, поскольку она содержит метки это может быть неприемлемо для некоторых клиентских программ DNS.

замечание по терминологии, в развитие ответа Бортцмейера

следует четко понимать определения. Как используется здесь:

RFC 2181 дает понять, что существует разница между доменным именем и именем хоста:

. [тот факт, что] любая двоичная метка может иметь запись MX, не означает, что любое двоичное имя может использоваться в качестве хост-части электронной почты адрес.

так подчеркивает в хоста нет-нет, подчеркивает в доменные имена are a-ok.

заметка о кодировке

вы также можете проверить Википедии

это классическая форма этикетки, хотя и с некоторыми дополнительными ограничения, в именах хостов (RFC 952). Его синтаксис идентичен тому, который описан как» синтаксис предпочтительного имени » в разделе 3.5 RFC 1034, измененного RFC 1123. Короче говоря, это строка, состоящая из букв ASCII, цифр и дефиса с дальнейшим ограничением, что дефис не может отображаться в начале или конце строки. Как и все DNS-метки, его общая длина не должна превышать 63 октетов.

автор предложения «расовая кодировка» отмечает:

согласно RFC 1035, хост-части должны быть нечувствительны к регистру, начинаться и заканчиваться буквой или цифрой и содержать только буквы, цифры и символ дефиса («-«). Это, конечно, исключает любые интернационализированные персонажи, а также многие другие персонажи в репертуаре персонажей ASCII. Кроме того, части доменных имен должны быть 63 октета или короче в длина. Все части имени после преобразования, содержащие интернационализированные символы, начинаются со строки » BQ-«. (. ) Строку «БК» был выбран потому, что это крайне маловероятно существовать в частях хозяина прежде чем эта спецификация была произведена.

Источник

Можно ли использовать нижнее подчеркивание в имени домена

Дискуссия бушует, что лучше для SEO, подчеркивания или дефис. Обновлено в 2012 году с последним словом от Google! Должны ли вы использовать тире или символы подчеркивания в ваших URL адресах для SEO? В отличие от многих вопросов SEO, дефис и дебаты с подчеркиванием имеют определенный правильный ответ и мы получили этот ответ непосредственно от Google.

Среди многих небольших хитростей, которые мы делаем для наших сайтов, чтобы максимизировать наши SEO в Google, это наши URL адреса SEO. Основная концепция заключается в том, чтобы сделать поисковую систему поиска дружественной, и мы считаем, что мы оптимизированы для лучшего ранжирования.

У Google нет проблем с чтением этих pesky / productid? = 5165681 URL адресов, тем не менее при прочих равных условиях URL, который читает / red-nike-кроссовки, станет лучше в Google.

Разделять слова адреса SEO с помощью дефиса или подчеркивания

Повторяющийся вопрос в адресах SEO заключается в том, следует ли использовать дефис или тире, подчеркивание (these_are_underscores) для разделения ваших слов. Что поисковая система Google распознает их как разделители слов.

Короткий ответ заключается в том, что вы должны использовать дефис для своих URL адресов SEO. Google относится к дефису как разделителю слов, но не относится к подобному подчеркиванию. Google обрабатывает и подчеркивает роль словаря, поэтому red_sneakers такие же, как redsneakers для Google. Это подтверждено непосредственно самими Google, в том числе тот факт, что использование тире над подчеркиванием будет иметь незначительное преимущество.

Опять же, адреса SEO должны использовать дефисы для разделения слов. Не используйте символы подчеркивания, не пытайтесь использовать пробелы и не разбивайте все слова вместе на одноходовое слово. По состоянию на 2012 год тире по-прежнему являются лучшим способом оптимизации ваших адресов в SEO.

История дефиса против подчеркивания SEO URL дискуссия

Одной из причин, почему этот вопрос так обсуждается, является из-за плохо сформулированного комментария, сделанного Matt’s Cut от Google в 2007 году, что для многих людей казалось, подразумевалось, что подчеркивания воспринимались как разделители слов.

Мэтт быстро исправил это восприятие в своем блоге, но вера сохранялась. Позже в 2009 году Мэтт подтвердил, что в действительности вы все равно должны использовать дефисы для своих URL адресов SEO, Google не рассматривает подчеркивания как разделители слов, и снова в 2010 году он рекомендовал использовать дефисы.

Стоит отметить, что если вы на сайте в настоящее время используете символы подчеркивания вместо тире. Что вероятно, не стоит хаоса их изменять, ведь 301 переадресация не передает 100% сока ссылок. Мэтт Каттс отметил, что рейтинг разница между использованием дефиса или подчеркивания незначительна, но это означает, что есть это рейтинговая разница.

Зачем использовать дефис?

На первый взгляд легко понять, что дефисы и подчеркивания обрабатываются поисковыми системами одинаково. Однако, это не так, короче говоря, Google рассматривает дефис как пространство или разделитель слов. Таким образом, хотя вы возможно не сможете добавить традиционное пространство, оно все равно появляется в глазах Google. С другой стороны, подчеркивание считается «столяром слов». Придерживаясь приведенного выше примера, miami_real_ee_agent аналогичен miamirealeeagent для Google.

Зачем использовать подчёркивание

Подчеркивание является символом, который первоначально появился на пишущей машинке и в основном использовался для подчеркивания слов. Первая система кодирования символов IBM была введена в 1964 году и использовала небольшой набор символов, среди которых подчеркивание было одним символом. В то время он назывался «символом разрыва», потому что он разбивал простые строки текста и кода, как в «rate_of_pay». К 1967 году символ подчеркивания также использовался в ASCII, раннем языке программирования.

В компьютерном программировании принято использовать знак подчеркивания непосредственно перед именем файла, предназначенного для внутреннего использования в компьютерной библиотеке или для файла заголовка. Ruby, Perl и Windows PowerShell также используют символы подчеркивания после определенных символов для создания специальной переменной.

Как избежать проблем со структурой URL вашего сайта

Лучшее, что вы можете сделать, это убедиться, что каждый URL использует дефисы и не подчеркивает. Наряду с этим, здесь приведены три дополнительных совета:

1. Используйте файл s.txt, чтобы заблокировать доступ Google к любым проблемным URL адресам.

2. Сократите URL адреса, когда это возможно, избавившись от чрезмерных параметров.

3. Регулярно проверяйте свой сайт на неработающие ссылки.

Вероятность заключается в том, что это очень мало влияет на то, действительно ли вы используете дефисы для разделения слов и подчеркивания для одной фразы.

Лучшая практика хороша при создании новых страниц, но я бы посоветовал не возвращаться к старым страницам и не менять дефисы и подчеркивания. Изменение адреса означает реализацию перенаправление, которое потеряет больше ценности, чем это изменение.

Источник

Можно ли использовать нижнее подчеркивание в имени домена

Яндекс увеличил размер баннера на Главной странице

FAQ по Core Web Vitals и Page Experience от Google

Стоит ли при регистрации доменного имени использовать дефисы или нижнее подчеркивание?

Слышал, что это не рекомендуется. А ваше мнение по этому поводу? И как, кстати, поисковики воспринимают такие сайты?

Ооо? с нижним подчёркиванием регистрируйте.

regnet, вроде субдомены такие можно делать. Может и в каких «зонах второго уровня» возможно такое?

Да, с нижним не получилось. Автоматически поменялось на дефисы.

Просто я зарегил уже, а теперь думаю, не поторопился ли?

А в чем проблема, собственно? O_o

Читал, что не рекомендуется использовать дефисы. Проблемы никакой нет! Хотел узнать мнение опытных оптимизаторов на этот счет. Вот и все!

Главное чтобы руки золотые были, если они растут не из того места и при этом плохо пахнут, даже прямой домен без дефисов не поможет.

Дык не просто читать надо, а думать. Почему не рекомендуется?:)

Это давно у «домейнеров» была такая фишка. но кто ж их слушает-то ????

Ну, не знаю я этих фишек, совсем «зеленый» еще в этом деле ????

С дефисами нормально. Главное чтоб смысл был от дефиса у названия домена, у меня с дефисами штук несколько доменов.

Отлично живут и не парятся. sear4er правильно сказал. Остальное мелочи.

С подчеркиванием домены не индексируются. ????

Источник