itthon / Skype / Cirill URL-ek. Orosz nyelv az URL-ben. Mi az a cirill tartomány?

Cirill URL-ek. Orosz nyelv az URL-ben. Mi az a cirill tartomány?

Szóval, ma szerettem volna írni egy kicsit a cirill CNC-ben való használatáról. Szerintem az orosz nyelvű linkek nagyon jók lennének, ha nem... A pletykák szerint nem érhetők el a böngészők, keresők és egyéb rendszerek számára, és a böngésző címsorában valami teljesen szörnyűség jelenik meg. Ennyi az összes előnye, hátránya, pletykája és megvalósítása az oldalakon, szeretném elmondani.

Tehát egy példa arra, hogyan használhatja az orosz nyelvet az URL-ben, közvetlenül a böngésző címsorában látható. A következőket kell odaírni:

Http://site/news/2009/09/08/orosz_nyelv_in_URL.html

Nézzük meg, mit mond erről a hivatalos HTML 4.01 specifikáció:

B.2.1 Nem ASCII karakterek az URI attribútumértékekben Bár az URI-k nem tartalmaznak nem ASCII-értékeket, a szerzők néha megadják őket attribútumértékekben, amelyek URI-kat várnak el (azaz a %URI; ban,-ben DTD). Például a következőket hreférték az illegális: href="http://foo.org/Håkon">... Javasoljuk, hogy a felhasználói ügynökök a következő konvenciót alkalmazzák a nem ASCII karakterek kezelésére ilyen esetekben: - Minden egyes karaktert az UTF-8-ban (lásd ) egy vagy több bájtként ábrázoljon. - E bájtok kihagyása az URI kikerülési mechanizmussal (azaz úgy, hogy minden bájtot %HH-ra konvertál, ahol HH a bájtérték hexadecimális jelölése). Ez az eljárás egy szintaktikailag legális URI-t eredményez (a 2.2-es vagy a 2-es szakaszban meghatározottak szerint), amely független attól a karakterkódolástól, amelyre az URI-t hordozó HTML-dokumentumot átkódolták.

Ami nagyjából a következőket jelenti:

Bár egy URL-nek (van különbség az URL és az URI között, de ez itt nem fontos) csak latin (ASCII) karaktereket kell tartalmaznia, előfordul, hogy a szerzők ezeket beszúrják a link értékébe. Például a következő példában a href attribútum értéke érvénytelen: href="http://vasya.ru/Vasya_Pupkin">... Javasoljuk, hogy a böngészők a következőket tegyék: - Cserélje ki az egyes karaktereket urf-8 kódolással - Kódolja ezeket a karaktereket bájtonként url-kihagyással, azaz. hexadecimális értékek (minden bájt %HH lesz). Ennek eredményeként az URL szintaktikailag helyes lesz.

Külön megjegyezzük, hogy megkaptuk a linket (megszökött) UTF-8 kódolás, hossza ennek megfelelően nőtt. Azok a webmesterek, akiknek webhelye a win-1251-et használja fő kódolásként (mint például ez a webhely), másként kell kezelniük a hivatkozások nevét, például lefordíthatják a kívánt kódolásra.

IE8-ban sajnos csak akkor lesz elérhető tiszta orosz, ha ott kézzel beírjuk a címet. De hát ilyen az IE =).

A Yandexben az url-ben szereplő orosz nyelvet tökéletesen értik, sőt keresésre is használják.


A Google a linkekben nem ad jelentést a szavaknak, ráadásul az aláhúzással összekapcsolt szavakat egynek tekinti, az elválasztóként érdemes mínuszt (kötőjelet) használni. Ezt a tényt hevesen vitatták az xpoint.ru oldalon. Ugyanakkor a helyesen kialakított orosz nyelvű hivatkozásokat is megjeleníti.

Itt az ideje egy rövid interjúnak, kollégáimmal interjút készítettem ebben a témában:

ha például a link utf-8-ban van?
Jelu (programozó): hát krakozyabra felülről) Általában azt gondolom, hogy ez rossz Már régóta szerettem volna kérdezni valamit az optimalizálásról. Hogyan befolyásolja az url-ben szereplő orosz nyelv az optimalizálást?@ (optimalizáló): nem is tudom mit válaszoljak, szerintem ez attól függ, hogy mit szeretnél ennek eredményeként, pl. mire való ez a link. de szerintem nem fog sok bizalmat adni, és a jelentést a horgony adja át, szerintem az orosz nyelvnek semmi köze hozzá. @: Nem tudom, hogy konkrétan a kereső hogyan kezeli az orosz nyelvű linkeket. Nos, általánosságban beszélve arról, hogy ez hogyan befolyásolja, hajlamos vagyok azt gondolni, hogy semmi. A relevanciát az oldalon lévő szöveg befolyásolja, de nem az arra mutató URL. Szia. mi a véleményed az orosz nyelv használatáról az url-ben? ov3r (programozó): helló. negatív, már csak a különböző kódolások miatt is mi a véleményed az orosz nyelv használatáról az url-ben? Jaehee (Programozó): Most fedeztem fel, hogy a rohadt sap 255 karakternél hosszabb URL-eket csonkol, ami elszomorít. mert van egy urlenkódom az orosz nyelvből > 255 karakterhez. szukák. Egyébként a hosszú orosz URL-ek szépek, kellemesek, kényelmesek, mindenki számára érthetőek és növelik a relevanciát. mi a véleményed az orosz nyelv használatáról az url-ben? Sötét Nagyúr (programozó): shnyaga!

Kommenteld a cikket, legalább pár szót!

Hozzászólások:

    Tehát, Jaroszlav, egy orosz nyelvű URL létrehozásához feltételezzük, hogy már rendelkezik az url angol nyelvű implementációjával, ha saját webhelyet írt.
    Az adatbázisban az url utf-8[u] kódolásban van tárolva, függetlenül attól, hogy maga a webhely milyen kódolásban van. Ha a webhely 1251-es kódolású, akkor mentéskor konvertálja a kódolást Utf-8-ra.
    Amikor egy blogoldalon linket mutatunk, akkor az orosz nyelvet tartalmazó részt is fel kell dolgozni az urlencode php funkcióval.
    Ennek megfelelően a hír megtalálásához elemzi az url-t, és megkeresi az orosz nyelvet tartalmazó részt. sql lekérdezés valahogy így néz ki:
    SELECT ... ahol ... CONVERT(`caption_latin` USING utf8) = CONVERT("".$pname."" USING utf8) ... ahol a caption_latin az Ön URL-jét tartalmazó oszlop neve utf8 kódolásban.

    Még csak kezdő webmester vagyok, ezért nem értek néhány dolgot. Hogy őszinte legyek, nekem megfelelne a "bábuknak" szóló utasítás ebben a kérdésben))
    hogyan lehet elmenteni a kódolást Utf-8-ban?
    hogy kell kezelni az orosz nyelvet php függvénysel?
    mi az url elemzés?
    Elnézést kérek, ha néhány kérdés nevetségesnek tűnik, de még csak tanulok)
    Jó lenne példát mutatni a kód előtt és után (vagyis milyen változtatásokat kell végrehajtani a kódon, hogy orosz betűk kerüljenek az URL-be), szerintem a hozzám hasonló kezdőknek könnyebb lesz rájönni. .
    Előre is köszönöm.

    2 év telt el a cikk megjelenése óta. Az emberek teljes mértékben kihasználják a cirill betűs hivatkozások beállításának lehetőségét; Yasha örül ennek; a sapperek is boldogok; nem is olyan régen az anyakönyvvezetők terjeszthették az IDN-eket; be is vezettek egy zónát cirill betűvel (bár, ahogy jól értem, Unicode-ban minden domainhez álneveket adnak ki) ...
    Mindez nem tud mást, mint örülni.
    De nem mindenki (?) tanulta meg a helyes átirányítást (mármint a 301-et). Mert a fejlécek nem fogadják el a cirill betűs hivatkozásokat. Mit csinálnak a csalók a húrokkal, mielőtt beillesztik header("Helyszín: ".HERE);

    A szerzőnek (vagyis nekem) biztosan vannak megfontolásai. A hivatkozás előkészítése 301-es átirányításhoz nem különbözik a html-hez való hivatkozás előkészítésétől. Már írtam arról, hogy a blogom hogyan támogatja a linkek automatikus javítását.
    Itt az érdeklődés kedvéért törölheti a címsorból az évet, hónapot, vagy akár a teljes dátumot. Vagy egyszerűen megnyomhatja a gombot. Újra át lesz irányítva ehhez a cikkhez.
    Ha motorja adatokat tárol a win-1251-ben, akkor 2 lépést kell végrehajtania:

    • Alakítsa át a CNC-hivatkozásokért felelős mezőt UTF8 kódolásra
    • Jelenítse meg ezt a mezőt egy hivatkozásban az urlencode() használatával PHP-ben. (nem a teljes linket, hanem csak ez a rész url).
    Ha a motorod mindent utf-ben tárol, akkor érted, ugye? =)
  • Régóta vacakolok ezen...

    És korábban mindent úgy csináltam, ahogy a cikkben elhangzott: lefordítottam utf-8-ra, majd leárnyékoltam. Különféle...
    De kiderült, hogy a probléma az volt, hogy az urlencode() egyszerűen kikerült a perjelből.

    Köszönöm, a cikk miatt ismét elvállaltam a funkció kezelését. Értve) Itt van a függvény a php-ben:

    function redirectto($redirect_link)
    {
    $redirect_link=iconv("windows-1251", "utf-8", $átirányítási_link);
    $átirányítási_link=urlencode($átirányítási_link);
    $redirect_link=str_replace("%2F", "/", $átirányítási_link);
    header("Hely: ".$redirect_link.");
    }

    Jó napot. Lenne egy kérdésem... Először is. Szeretném elérni, hogy az urnának legyen lehetősége oroszul (igen, így fogalmaztam)).
    Tulajdonképpen mit kell tenni?)
    A felhasználó megpróbál hozzáférni a címhez host.domen/2011/article-1/
    Hogyan tudom ezt elkapni? Elkapja a 404-re küldött összes kérést? De akkor 200 helyett 404-es kód kerül visszaadásra. Vagy "soft 404 error" 200-as visszatérési kóddal? (Egyébként nem értem, hogyan kell ezt csinálni).
    Vagy állítsd be a .htaccess fájlt 301-es átirányításhoz? De akkor egy átirányítás történik (paradoxon, ugye?)) ... És amiatt, hogy a gazdagépen található összes fájl és mappa neve csak latin url-ben változik host.domain/2011/statja-1/(ez a helyes oldal címe). De ezt nem akarom) Azt akarom, hogy ez így jelenjen meg a címsorban host.domen/2011/article-1/ Az ErrorDocument 404 használatával a címsávban szereplő cím csak az marad. Mi teszi lehetővé, hogy kicsit megtévessze a természetet, és orosz nyelvet használjon olyan szerveren, ahol ezt nem lehet megtenni) Általában van valami ötlete?

    A mod_rewrite közben ásni fogok

    Egy ilyen erős mod_rewrite eszköz. De egy kicsit kényelmetlen vele dolgozni. Könnyebbé lehetett volna tenni. Bár ezt nyilvánvalóan a belső összetettsége okozza. Vagy csak "old school" hatások. Végül is mikor fejlesztették ki? Nos, nem a lényeg, mindent megtettem, ami a legfontosabb) De a mod_rewrite segítségével az opció nem volt olyan rugalmas. Jobb, ha az ilyen feldolgozást a php-ra hagyja, aki hibás kéréseket gyűjt össze a 404-ben.

    Motorunk a következő mod_rewrite szabályt használja:

    RewriteCond %(REQUEST_FILENAME) !-f
    RewriteRule ^(.*)$ index.php?rewrite_url_query_toget=$1

    Egyszerűen használható a RewriteRule ^(.*)$ index.php , de ebben az esetben az oldal címét a $_SERVER["REQUEST_URI"] változóból kell venni, ami nem lesz teljesen igaz, ha a motort egy mappában, és nem a gyökérben.

    Az oldalak gyűjtése a 404-es kérések feldolgozásával nem teljesen helyes. Először is előfordulhat, hogy alapértelmezés szerint 404-es állapot kerül visszaadásra. Másodszor, az Apache megpróbálhatja az oldalt HTTP 1.0 helyett HTTP 1.0-n keresztül visszaadni, mert a 404-es oldalt HTTP 1.0-n keresztül kell visszaküldeni, azaz nem a chunked módszert használja a kiadáshoz, ami szintén hibához vezet. Stb.
    A mod_rewrite pedig éppen a sokoldalúsága miatt igazán nehéz. Megfelelő tanulással sokat tehetsz vele.

    Nos, az első két probléma megoldódik a HTTP/1.1 200 Ok fejléc elküldésével. De határozottan egyetértek azzal, hogy ez nem teljesen helyes) Ez még mindig egy megoldás. Nem nyúlnék hozzá, ha mod-rewrite-el simán "összeragasztana" minden. Összeragadtam, de valahogy ferdén. Nos, egy óra alatt ezt a mechanizmust nem lehet pontosan elsajátítani. Megpróbálok kísérletezni a mod_rewrite parancsaival.

    Sziasztok! Láttam egy kérést, hogy legalább pár szóra szóljak hozzá, és most már vannak webhelyeim a WordPress-en, ahol ez a vállalkozás minden bejegyzésben és oldalon automatizált, oroszul használom a nevet, minden nagyobb böngészőben normálisan megjelenik. És valóban kényelmes a felhasználó számára.

    Szép hibaoldal

    Nem jelentkezett be, és nem jelölte be a négyzetet. Megjegyzését nem mentettük. Ha nem vagy bot, itt van, másold ki, illeszd be, és próbáld újra:

    Szia!
    Az ie-ben a hivatkozás kódolva jelenik meg. Ha jól értem, mert pl. oroszul nem lehet linkeket létrehozni? Ha böngészők szerint szűri a felhasználókat, és orosz nyelvű hivatkozásokat generál, kivéve az ie-t és átírásban az ie-t, akkor a keresőmotorok ezt az oldalt kettőnek fogják fel. Kiderült, hogy mindent átírással kell csinálni, vagy mégis vannak megoldások?

    A címsorba írja be például: mysite /? hello
    php kód
    $chpu = $_SZERVER["REQUEST_URI"];
    echo $chpu;
    php kód
    ilyesmit nyomtat: %D0%BF%D1%80%D0%B8%D0%B2%D0%B5%D1%82
    illessze be ezt a kódot az adatbázisba és élvezze :)

    Vlad, az ie -ben az oldal csak a 9. verzióig jelenik meg kódolva. Ez az összes böngésző kevesebb mint 5%-a.

    Hello, nagyon érdekes cikk, nem tudtam sokat.
    Nem egészen értettem azonban, hogyan lehet megoldani az orosz karakterek URL-ben való megjelenítésének problémáját.
    Megnéztem a "nyers forrást" (Operában ez Crl+U), és láttam, hogy van linkje, sőt - UTF-8 kilépés után (kiszabadult). De amikor a böngésző állapotsorában lebeg, a krakozyabry látható, és az átmenet után megkapja az orosz szöveget, ahogy kell. Amint nem próbáltam ki - meneküléssel és anélkül, és minden kódolással (UTF-8-ra konvertálás nélkül és vele együtt). Mindenesetre a linkre kattintás után szökött karaktereket kapok =(

    UPD: rájöttem. Kiderült, hogy egy ilyen trükk paraméterrel nem működik. Csak az elérési út egy részével, nem a lekérdezési_karakterlánccal. Úgy tűnik számomra, hogy érdemes ezt az árnyalatot hozzáadni - különben soha nem lehet tudni. Csak az elérési útra volt szükségem, de a teszthez ostobán a paramétert választottam. Érdekes egyébként, hogy mi okozta ezt a funkciót, és ki alakítja még mindig a fel nem lépett karaktereket felszabadult formává - böngésző vagy webszerver. Azt is érdekes lenne megérteni, hogy mi megy a szerverre, ha orosz betűk láthatók a címsorban. Ez egy feltörés a böngésző részéről, vagy tényleg elmúlnak anélkül, hogy megszöknének?

    És igen, a paraméterek sem olyan egyszerűek - egyszer telepítettem az nginx-et Apache nélkül, így úgy tűnik, hogy a paraméterek oroszul maradtak csere nélkül ... És úgy tűnik, még a PHP kódot is meg kellett változtatnom, hogy működjön (bár az adatbázis ugyanabban a kódolásban volt, mint a fejlesztői szerveren). az átírás működött, és "rossz" jöttek az adatok, valami ilyesmi.

    Az ún. hely.hash – azaz. mindennek, ami a rács után létezik, megvan a maga specifikációja. Ezért igen, a böngésző sajnos védi.


Független

1. Vásároljon cirill betűt Domain név.
2. Tárhely rendelése.
3. Kapcsolja össze ezt a domain nevet ehhez a tárhelyhez.
4. Hozzon létre egy "kapcsolati" oldalt tartalmazó webhelyet. A legegyszerűbb, ha létrehozunk egy "contacts" könyvtárat és benne az "index.html" fájlt.
5. Töltsd fel a létrehozott oldalt a tárhelyre.

Ne feledje, hogy a webhely tárhelyének tárolása során nem lesz „site. rf" és „xn--80aswg.xn--p1ai" (és a cím ebben a formában kerül továbbításra a hálózaton): a böngészőkkel való kompatibilitás biztosítása érdekében a domain nevek a https://ru.wikipedia-ban vannak kódolva. org/wiki/Punycode . Játssz a kódolással: https://www.punycoder.com

Tehát az alábbi Sphere hibás: a domain bárhol elérhető lesz a világon, és a keresők tökéletesen indexelik. András 2

Összesen 3.

SEO szempontból a bejövő link URL cseréje?

Andrey Sh. 4

Ha a tartalom megváltozik és/vagy nincs 301-es átirányítás, a hatás lehet pozitív vagy negatív is, sok tényezőtől függően, melynek első sorában a tartalom új oldal, az adományozó oldal bejövő belső linkjei és az adományozó oldal bejövő külső hivatkozásai.

Jevgenyij Y. 3

Ha megváltoztatta a bejövő link URL-jét, és ugyanazt a horgonyt hagyta meg, mint korábban, akkor nagy valószínűséggel a korábban átvitt hivatkozási tőke nem lesz ugyanaz, mint az új URL-t tartalmazó oldalról. Azok. egy új bejövő link átviszi a minimális súlyt az elfogadó oldalra, és idővel csak "súlyt" kap. Tényezők miatt, pl.: az oldal kora, az arra irányuló forgalom nagysága, az arra hivatkozók száma belső oldalak webhely, belső hivatkozási horgonyok, szám Külső linkekés az oldal horgonytípusai stb. Anton Velichko -1

Csak 2.

Mit jelent a cirill „.rf” tartomány, ha vannak „.ru” és „.su” tartományok?

Férfi. Regger. 7

Úgy gondolom, hogy ez volt az első lépés abban, hogy a Sportloto és a Komsomol tagjaival együtt létrehozzuk egyedi, rendkívül spirituális Internetünket. Most már hátra van, hogy felismerjük a latin ábécét az orosz érzelmeit sértőnek, el kell választani az internetet a Nyugattól, Kínával együtt az Aliexpress-szel, és csak egy oldalt hagyni „kapcsolatban”, nos, talán az osztálytársakkal és a Rush Today az első csatornával.

Szergej Raszszkazov 7

Csak 4.

Hogyan lehet kullancsot szerezni?

Vendég 1

Hogy a beérkező levelemet ne tömjék el a pipával kapcsolatos kérdések, azonnal leírom, hogyan szerezhetem meg.
Nem lehet:
1.Mata
2. Játékok/versenyek (%, tények, lt)
3. Kölcsönös feliratkozás/kérdés/lájk kérése (a válaszokban).
Ha ez rendben van, akkor lépj tovább.
1. Több mint 800 válasznak kell lennie.
2. Több mint 1000 előfizető, minél több, annál jobb.
3. A profil nem a tiéd, mivel nincsenek rólad fotók és/vagy ez a profil más célból készült (filmidézetek, élettippek, vicces mémek, stb.) A fotódat is mellékelni kell (2 ha szeretnéd )
4. Aktív profil, azaz minden nap arra jársz, hogy az elmúlt hetekben 5 vagy több kérdést tegyen fel és válaszoljon meg.
Ha megvan minden.
5. Kövesse a http://support.ask.fm/ics/support/ticketnewwizard.asp?style=classic linket
6. Írjon be néhány sort magáról: Teljes név - teljes név és vezetéknév, E-mail - cím Email; Érdeklődés típusa – Fiókellenőrzés; még néhány sor megnyílik a Profil URL-címe – egy link a fiókjára; Követőinek száma - az előfizetők száma; Tárgy - "Számlaellenőrzés" írjuk (idézőjelek nélkül); * Részletesen fejtse ki (maximum 64 000 karakter)
- Azt írjuk: „Helló! Szeretnék bejelölni egy pipát, és készen állok az ellenőrzési eljárás végrehajtására. (Azt is elmondhatod magadról, hogy hol lettél híres, amit csinálsz, csatolj linkeket a fiókokhoz, de ez nem kötelező).
7. Nyomja meg a Befejezés >>> gombot
További:
8. Várjuk az Ask levelét, kész / elutasítás Ha a kérésed belefér a jelölőnégyzetbe, akkor megkérünk, hogy készítsünk egy szelfit egy papírral, ahol a felhasználóneved és a mai dátum be van írva kézzel és a kezeddel jól látható teljes egészében, hogy egy darab papírt tartasz a kezében, és a teljes arcod (ami a legfontosabb), hogy te vagy az.
Mit írjunk egy papírra? Vegyen elő bármilyen lapot. Ügyeljen arra, hogy @ írja be a felhasználónevét és a levél megérkezésének dátumát. Küldje el válaszlevélben. „Itt a bizonyíték” szöveggel (idézőjelek nélkül)
9.Még egy napot várunk egy levélre.Ahol gratulálunk a pipa vételéhez.És örülünk.
A kérelmet március 14-én este 0:41-kor küldtem el; és ezen a napon 16:00-kor kértek szelfit; Másnap pedig 14:01-kor kapott egy pipát
Remélem részletesen kifejtettem és kipipálhatjátok, itt elmondtam a legapróbb részleteket is.
Képernyő https://pp.userapi.com/c836439/v836439430/2b55c/AnlMBXPbPWs.jpg
Ha bármilyen problémája van, írjon nekem, és segítek https://vk.com/maksimovde.Oleg 300

Összesen 1

Ma úgy döntöttem, hogy érintem a cirill betűs domainek népszerűsítésének témáját. Nagyon elfogult vagyok velük szemben, ezért a cikk szubjektív lesz, és nem állítja az igazat. Véleményemen, tapasztalatomon és néhány, a Google által tisztázott ponton kívül megkértem egy barátomat (egy cirill domain tulajdonosát), hogy írja le a cirill domainekkel való munka főbb árnyalatait, előnyeit és hátrányait. Ennek eredményeként sok információ derült ki, amelyeket most megpróbálok strukturálni.

Mi az a cirill tartomány?

Szóval mi van Cirill tartomány. Anélkül, hogy belemélyednénk a technikai oldalba, azt mondhatjuk, hogy egy ilyen tartományt cirill karakterekkel jelölnek, és célja az olvashatóság és az emlékezet javítása. A domain névrendszer (a DNS-t 1984-ben fejlesztették ki) csaknem 30 éves fennállása óta mindenki hozzászokott a latin ábécé szerinti domainekhez, a cirill betűs domain nevek megjelenése 2010-ben példátlan felhajtást keltett az internetes társadalomban. Sok informatikus szkeptikus volt egy ilyen újítással kapcsolatban, hiszen már akkor is látták a cirill használatának hátrányait a tartományokban. A hétköznapi webfelhasználók örültek, 183 000 cirill domaint regisztráltak az „.rf” zóna fennállásának első 6 órájában.

A cirill tartományok használata

Az első cirill tartományok a president.rf és a Government.rf voltak. Valamivel később (2009 vége - 2010 eleje) a cirill betűs domain nevek regisztrációja elérhetővé vált a védjegytulajdonosok, majd később Oroszország összes lakosa számára. Jelenleg már több tucat cirill betűs tartomány létezik, beleértve a ".ukr", ".bel" és más regionális és tematikus tartományokat.

A cirill betűs domain nevek hatóköre nagyon kiterjedt, kormányzati és magánszervezetek, online áruházak, bármilyen szintű cégek, bloggerek használják őket. Sok webmester a cirill betűs domaineket további tükörként használja webhelyeihez. A cégek gyakran csak azért vásárolnak ilyen neveket, hogy megvédjék magukat a cybersquatttól.

Előnyök és hátrányok

A cirill betűs tartományok használatának megvannak az előnyei és hátrányai. Nekem személy szerint sokkal több a hátránya (beleértve az objektív és szubjektív tényezőket is), azonban őszintén próbáltam legalább valamit találni a cirill tartományok javára. Próbáljuk mindkettőt felsorolni.

A cirill betűs domainek előnyei

  1. A cirill betűs tartomány könnyen olvasható és megjegyezhető. Információink szerint az ilyen domaineket csak olyan emberek számára hozták létre, akik nem nagyon értenek az átíráshoz és az angol nyelvhez.
  2. Hozzáadás képessége kulcsszavakat a domainhez, átírás nélkül. IMHO, ez a pont nem túl egyértelmű, nem figyeltem meg az SDL pozíciók kifejezett függőségét a tartomány kulcsától. Jobb, ha több időt fordítunk az illetékes névadásra.
  3. Ingyenes domain nevek nagy választéka cirill betűs területeken. Míg a latin ábécében három évtizedre jó néhány „ízletes” domain maradt, a cirill ábécé bevezetése lehetőséget adott arra, hogy cége számára találjon ilyen tartományt. Ez az előny azonban néhány éven belül valószínűleg már nem lesz meg.

Talán erről, meg mindenről.

A cirill tartományok hátrányai

  1. Néhány A böngészők másként másolják a webhely URL-címét. Például be Google Chrome a tartomány csak Punycode-ban van pufferelve, míg Mozilla Firefox lehetővé teszi a domain másolását címsor cirill betűkkel.
  2. Az alkotási képesség hiánya vállalati posta a domain számára. Sajnos a cirill betűs tartományok még nem használhatók megfelelően a létrehozáshoz postázási cím. A címet csak Punycode-ban használhatja. Például a " [e-mail védett] domain.rf", a cím így fog kinézni: " [e-mail védett]". Egyetértek, nem túl kényelmes. Igaz, a Google nem is olyan régen bejelentette a cirill betűk támogatásának kezdetét az e-mail címekben, de amíg a levelezők nem kezdik helyesen észlelni, és más keresőmotorok nem kezdik támogatni (a Runetben természetesen a domain fő levele a Yandextől származik) - több mint egy év telik el.
  3. Lehetséges problémák a referenciacserékkel végzett munka során, konkrétan GGL (GoGetLinks). A helyzet az, hogy a webhely címének egy része (domainnév) Punycode-ba alakul át, és maga az oldal/mappa/erőforrás címe (URL) Unicode hexadecimális rendszerben (általában UTF-8) kerül továbbításra. Emiatt a címek nagyon-nagyon hosszúak lehetnek, és a csererendszerek korlátai miatt problémák adódhatnak.
  4. A CMS telepítése és adminisztrálása során nehézségek adódhatnak. A Ebben a pillanatban, a népszerű CMS-ekkel nem lehet gond, de a saját maga által írt vagy nem túl jól kidolgozott rendszereknél előfordulhatnak nehézségek.
  5. Vannak olyan információk, hogy egyesek Előfordulhat, hogy az online víruskeresők nem működnek megfelelően cirill betűs címekkel oldalakat.
  6. Az internet külföldi felhasználóinak a kódolási problémák miatt nehézséget okoz a cirill tartományban található webhely elérése. A mai napig a legtöbb böngésző megtanulta helyesen „megérteni” és megjeleníteni a cirill betűs címeket, de nincs 100%-os garancia.
  7. Egy optimalizáló/webmester számára kényelmetlen a cirill betűs címekkel való munka. Szakmánk sajátosságai olyanok, hogy gyakran kell oldalcímeket másolnunk, vagy különféle programok beszámolóit elemezni. Az UTF-re konvertált URL-ek teljesen olvashatatlannak tűnnek, és csak a címből lehet megérteni, hogy milyen oldalról van szó (természetesen a link követése nélkül).
  8. És végül, ha az orosz billentyűzetkiosztás nincs telepítve a számítógépre, problémák lesznek a cím megadásával. Használható virtuális billentyűzet, persze, de ez nem mindig lehetséges, és enyhén szólva nem túl kényelmes.

Következtetés

Ahogy az elején említettem, a cirill betűs tartományoknak értelmezésem szerint több hátránya van, mint fordítva. De őszintén igyekeztem a csatornáimon talált és kapott összes információt feldolgozni, rendszerezni, hogy mindenki, aki szeretne ilyen domaint vásárolni, önállóan tudjon dönteni. Biztos vagyok benne, hogy még egy-két év múlva - és az általam leírt mínuszok egy nagyságrenddel kisebbek lesznek. Ám az internetes régiek többsége számára, akik hosszú ideje dolgoznak a WEB-területen, a cirill betűs tartományok továbbra is kissé furcsa és kétértelműek maradnak. Talán csak sok konzervatív van közöttünk 🙂

Mi a véleménye a cirill betűs tartományok előnyeiről és hátrányairól?

28.03.2018 Olvasási idő: 1 perc

2017. december 21. óta a Google SEO kivonatokat (SEO Snippets) – rövid oktatóvideókat – tesz közzé. Az alábbiakban egy másik SEO-részlet fordítása látható.

Ma a kérdést John Muller teszi fel Svájcból, azaz. i A kérdés a következő: Használhatók-e nem angol szavak egy URL-ben? Az angol nyelvű régiókon kívüli felhasználókat célzó webhelyek esetében néha nem világos, hogy a helyi nyelvű és a nem angol karakterek használhatók-e az URL-ekben.

A Google keresőmotorja elsősorban az URL-eket használja egy adott tartalom eléréséhez – ezen keresztül a Google bot feltérképezi az oldal tartalmát, és hozzáadja a keresési eredményekhez. Amíg az URL-ek érvényesek és egyediek, nem lesz probléma. A tartománynevek és a legfelső szintű domainek esetében a nem latin karakterek kódolása a Punycode konverterrel történik. Kicsit furcsán hangzik, ezért mondok egy példát: vegyük a Müller vezetéknevemet. A második betű felett pontok vannak, így a kódolás után másképp fog kinézni domain névként - "müller" -> "xn-mller--kva". Mindkét változat egyenértékű keresőmotor Google. Az URL többi része Unicode rendszerrel kódolható, UTF-8 nem latin karakterekhez. Nyelvtől függetlenül tegye lehetővé, hogy a felhasználók könnyen elkerüljék a szóközöket, vesszőket és egyéb karaktereket. Használjon kötőjelet a szavak elválasztásához a címben. Vannak, akik szívesebben használják az aláhúzás karaktert – ez is lehetséges, de a kötőjel könnyebben felismerhető. Ha webhelye több nyelven is elérhető, használja a megfelelő nyelvet az URL-ben az adott nyelvű tartalmi oldalakhoz. Összegezve tehát azt mondom: lehet nem angol szavakat használni az URL-ekben, ezt a nem angol nyelvű oldalakon kell megtenni.