Znaki Unicode w adresach URL


135

Czy w 2010 r. Udostępniłbyś adresy URL zawierające znaki UTF-8 w dużym portalu internetowym?

Znaki Unicode są zabronione zgodnie z RFC w adresach URL (patrz tutaj ). Aby były zgodne ze standardami, musiałyby być zakodowane w procentach.

Moim głównym celem jest jednak serwowanie niezakodowanych znaków wyłącznie w celu posiadania ładnie wyglądających adresów URL, więc kodowanie procentowe nie działa.

Wydaje się, że wszystkie główne przeglądarki analizują te adresy URL w porządku, bez względu na to, co mówi RFC. Moje ogólne wrażenie jest jednak takie, że wychodząc z domeny przeglądarek internetowych robi się bardzo chwiejny:

  • Adresy URL są kopiowane + wklejane do plików tekstowych, wiadomości e-mail, a nawet witryn internetowych z innym kodowaniem
  • Biblioteki klienta HTTP
  • Egzotyczne przeglądarki, czytniki RSS

Czy mam słuszne wrażenie, że należy się tutaj spodziewać kłopotów, a zatem nie jest to (jeszcze) praktyczne rozwiązanie, jeśli obsługujesz odbiorców nietechnicznych i ważne jest, aby wszystkie Twoje linki działały poprawnie, nawet jeśli są cytowane i przekazywane dalej?

Czy istnieje jakiś magiczny sposób na wyświetlanie ładnie wyglądających adresów URL w HTML?

http://www.example.com/düsseldorf?neighbourhood=Lörick

który można skopiować + wkleić z nienaruszonymi znakami specjalnymi, ale działa poprawnie, gdy zostanie ponownie użyty w starszych klientach?


16
Ze swojej strony Firefox wyświetla znaki Unicode na pasku adresu URL, ale wysyła je do zakodowanego procentu serwera. Co więcej, gdy użytkownik kopiuje adres URL z paska adresu URL, Firefox zapewnia, że ​​zakodowany procent adresu URL jest kopiowany do schowka.
Siddhartha Reddy

Odpowiedzi:


126

Użyj kodowania procentowego. Nowoczesne przeglądarki zajmą się problemami z wyświetlaniem i wklejaniem oraz sprawią, że będzie czytelny dla człowieka. E. g. http://ko.wikipedia.org/wiki/ 위키 백과: 대문

Edycja: kiedy skopiujesz taki adres URL w Firefoksie, schowek będzie przechowywał zakodowaną w procentach formę (co zwykle jest dobrą rzeczą), ale jeśli skopiujesz tylko część, pozostanie niezakodowana.


Wow, właściwie masz rację! Jeśli wytniesz i wkleisz% zakodowany adres URL, Firefox zmieni go we właściwy adres do wyświetlenia.
Dean Harding

Wow, nie byłem tego świadomy. Są szanse, że to najlepsze rozwiązanie!
Pekka

33
@Dean to całkiem nowa zmiana - w 2005 roku wszystkie międzynarodowe wikipedie wyglądały jak prawdziwe% 6D% 65% 73% 73.
Roman Starkov,

2
Możesz już używać niezakodowanych adresów URL UTF-8, czyli IRI , w dokumentach HTML5 . Jeśli to zrobisz, wszystkie główne przeglądarki zrozumieją to i wyświetlą poprawnie na pasku adresu.
Oliver,

Jakie bajty współczesne przeglądarki wysyłają do serwerów w wierszu żądania GET /images/logo.png HTTP/1.1? Czy zawsze kodują URL w procentach?
Flimm

87

Co powiedział Tgr. Tło:

http://www.example.com/düsseldorf?neighbourhood=Lörick

To nie jest identyfikator URI. Ale to jest IRI .

Nie możesz dołączyć IRI do dokumentu HTML4; rodzaj atrybutów, takich jakhref jest zdefiniowany jako URI, a nie IRI. Niektóre przeglądarki i tak poradzą sobie tutaj z IRI, ale to nie jest dobry pomysł.

Aby zakodować IRI w URI, weź ścieżkę i części zapytania, zakoduj je w UTF-8, a następnie zakoduj procentowo bajty spoza ASCII:

http://www.example.com/d%C3%BCsseldorf?neighbourhood=L%C3%B6rick

Jeśli w części IRI zawierającej nazwę hosta znajdują się znaki spoza zestawu ASCII, np. http://例え.テスト/, zostały zakodowane przy użyciu Punycode .

Teraz masz identyfikator URI. To brzydki identyfikator URI. Ale większość przeglądarek ukryje to za Ciebie: skopiuj i wklej go w pasku adresu lub podążaj za nim w linku, a zobaczysz go wyświetlonego z oryginalnymi znakami Unicode. Wikipedia korzysta z tego od lat, np .:

http://en.wikipedia.org/wiki/ɸ

Jedyną przeglądarką, której zachowanie jest nieprzewidywalne i nie zawsze wyświetla ładną wersję IRI, jest ...

...cóż wiesz.


31
Wiem. Pewnego dnia ktoś musi wziąć duży klub i uderzyć tych programistów Lynx po głowie. Dzięki za doskonałe informacje ogólne.
Pekka

2
@bobince A jedyny bot (do 2013 r.), który również nie obsługuje identyfikatorów URI innych niż IRI, to ... ... no cóż, wiesz: bingbot! Domyśl.
Tom Harrison

1
HTML5 w końcu obsługuje IRI. Więcej informacji na ten temat można znaleźć w odpowiedzi na pokrewne pytanie .
Oliver

5
Odp: IE nie zawsze wyświetla ładne IRI - chronią użytkowników przed atakami phishingowymi opartymi na homografach. Zajrzyj na stronę w3.org/International/articles/idn-and-iri (w szczególności sekcję „Nazwy domen i wyłudzanie informacji”) i blogs.msdn.com/b/ie/archive/2006/07/31/684337.aspx
codingoutloud

2
Nazwy domen nie mają z tym nic wspólnego. Wszystkie przeglądarki blokują szeroki zakres znaków, aby zapobiec wyłudzaniu informacji. Wyświetlanie znaków spoza zestawu ASCII w ścieżce lub w części ciągu zapytania nie powoduje podobnego zagrożenia. IE po prostu nie zadał sobie trudu, aby go zaimplementować. (A Firefox jest jedynym, który zaimplementował go również dla części fragmentu.)
Tgr

16

W zależności od schematu adresu URL możesz sprawić, że część zakodowana w UTF-8 będzie „nieważna”. Na przykład, jeśli spojrzysz na adresy URL przepełnienia stosu, mają one następującą postać:

http://stackoverflow.com/questions/2742852/unicode-characters-in-urls

Jednak serwer tak naprawdę nie dba o to, czy część po identyfikatorze jest błędna, więc to również działa:

http://stackoverflow.com/questions/2742852/ こ れ は 、 こ れ を 日本語 の テ キ ス ト で す

Więc gdybyś miał taki układ, to mógłbyś potencjalnie użyć UTF-8 w części po identyfikatorze i nie miałoby znaczenia, gdyby został zniekształcony. Oczywiście to prawdopodobnie działa tylko w nieco szczególnych okolicznościach ...


Hmmm, bardzo sprytne myślenie! To może jeszcze być, że niektórzy klienci zadławić znaków bez względu na to gdzie się znajdują w ciągu, ale to by wyeliminować wszelkie problemy z zwyczajnego garblingu podczas kopiowania + wklejanie adresu URL, który moim zdaniem jest najważniejszą częścią. Jeszcze nie spojrzał na adres URL SO w ten sposób. Dzięki!
Pekka

cóż, to wciąż pozostawia nieprzetłumaczone słowo „pytania”, a ponadto jest coś po krzyżyku #, które następuje po całym adresie URL, ale bardzo fajna sztuczka !!
Evgeny

4
自動 翻 訳 機 を 使 っ て そ の 日本語 の URL を 作 っ た ね。
Glutexo

6

Nie jestem pewien, czy to dobry pomysł, ale jak wspomniano w innych komentarzach i jak to interpretuję, wiele znaków Unicode jest poprawnych w adresach URL HTML5 .

Np. hrefDokumenty mówią http://www.w3.org/TR/html5/links.html#attr-hyperlink-href :

Atrybut href w elementach a i area musi mieć wartość będącą prawidłowym adresem URL, potencjalnie otoczonym spacjami.

Następnie definicja „prawidłowego adresu URL” wskazuje na adres http://url.spec.whatwg.org/ , który definiuje punkty kodowe adresu URL jako:

Alfanumeryczne ASCII, "!", "$", "&", "'", "(", ")", "*", "+", ",", "-", ".", "/" , ":", ";", "=", "?", "@", "_", "~" i punkty kodowe w zakresach U + 00A0 do U + D7FF, U + E000 do U + FDCF , U + FDF0 do U + FFFD, U + 10000 do U + 1FFFD, U + 20000 do U + 2FFFD, U + 30000 do U + 3FFFD, U + 40000 do U + 4FFFD, U + 50000 do U + 5FFFD, U +60000 do U + 6FFFD, U + 70000 do U + 7FFFD, U + 80000 do U + 8FFFD, U + 90000 do U + 9FFFD, U + A0000 do U + AFFFD, U + B0000 do U + BFFFD, U + C0000 do U + CFFFD, U + D0000 do U + DFFFD, U + E1000 do U + EFFFD, U + F0000 do U + FFFFD, U + 100000 do U + 10FFFD.

Termin „punkty kodowe adresu URL” jest następnie używany w kilku częściach algorytmu analizowania, np. Dla stanu ścieżki względnej :

Jeśli c nie jest punktem kodowym adresu URL, a nie „%”, błąd analizy.

Również walidator http://validator.w3.org/ przekazuje adresy URL, takie jak "你好"i nie obsługuje adresów URL zawierających znaki takie jak spacje"a b"

Powiązane: jakie znaki powodują, że adres URL jest nieprawidłowy?


Ale oba adresy URL ( "你好"i "a b") muszą być zakodowane w procentach podczas wykonywania żądania HTTP, prawda?
Utku

@Utku dla "a b"jestem prawie pewien, że tak, ponieważ spacji nie ma na liście dozwolonych powyżej. Dla "你好", to zdecydowanie lepszy pomysł, aby procent kodowania, ale nie wiem, czy jest to tylko kwestia „implementacje nie są wystarczająco dobre” lub „standard mówi tak”. Wydaje się, że standard HTML zezwala na te znaki. Ale myślę, że jest to określone przez standard HTTP, a nie HTML. Zobacz też: stackoverflow.com/questions/912811/…
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功

Tak, myślałem o standardzie HTTP, a nie o HTML.
Utku

5

Ponieważ wszystkie te komentarze są prawdziwe, należy zauważyć, że jeśli zatwierdzone przez ICANN znaki arabskie (perskie) i chińskie mają być zarejestrowane jako nazwa domeny, wszystkie firmy tworzące przeglądarki (Microsoft, Mozilla, Apple itp.) Muszą obsługują Unicode w adresach URL bez żadnego kodowania, a te powinny być przeszukiwane przez Google itp.

Więc ten problem zostanie rozwiązany jak najszybciej.


2
@Nasser: True - mamy teraz również znaki specjalne w domenach niemieckich - ale są one zakodowane w postaci znaków ASCII przy użyciu Punycode . Chociaż z pewnością będą działać w głównych przeglądarkach, minie dużo czasu, zanim każda biblioteka klienta HTTP i egzotyczna aplikacja będzie w stanie poradzić sobie z niezakodowanymi znakami Unicode.
Pekka

@Pekka, nie jestem pewien, ale jak słyszałem, wszystkie przeglądarki muszą obsługiwać URL Unicode w 4. kwartale 2010 r. (Nie jestem pewien)
Nasser Hadjloo

Sprawę komplikuje fakt, że nie każdy klient użytkownika jest przeglądarką internetową. Największym przykładem jest samo Google: nie używa popularnych przeglądarek internetowych do indeksowania. Podobnie wiele bibliotek do interakcji API itp. Itp. - adresy URL są prawie dosłownie wszędzie, nie tylko w sieci WWW. Prawdopodobnie nawet teraz w twoim systemie plików.
Cornelius

1

Użyj formularza zakodowanego w procentach . Na przykład niektóre (głównie stare) komputery z systemem Windows XP nie obsługują Unicode, ale raczej kodowanie ISO. To jest powód, dla którego wymyślono adresy URL zakodowane w procentach. Ponadto, jeśli podasz użytkownikowi wydrukowany na papierze adres URL zawierający znaki, których nie można łatwo wpisać, może on mieć trudności z wpisaniem go (lub po prostu go zignorować). Forma zakodowana w procentach może być nawet używana na wielu najstarszych maszynach, jakie kiedykolwiek istniały (chociaż oczywiście nie obsługują one internetu).

Jest jednak minus, ponieważ znaki zakodowane procentowo są dłuższe niż oryginalne, co może skutkować naprawdę długimi adresami URL. Ale po prostu spróbuj to zignorować lub użyj skracacza adresów URL (polecam w tym przypadku goo.gl , który tworzy 13-znakowy adres URL). Ponadto, jeśli nie chcesz rejestrować się na konto Google, wypróbuj bit.ly (bit.ly tworzy nieco dłuższe adresy URL, których długość wynosi 14 znaków).


Dlaczego miałbym obsługiwać przestarzałe komputery, które nadal korzystają z systemu Windows XP?
Mateus Felipe

0

Dla mnie to jest właściwy sposób, to właśnie zadziałało:

    $linker = rawurldecode("$link");
    <a href="<?php echo $link;?>"   target="_blank"><?php echo $linker ;?></a>

To zadziałało, a teraz linki są wyświetlane poprawnie:

http://newspaper.annahar.com/article/121638 -معرض - جوزف-حرب-في-غاليري-جانين-ربيز-لوحاته-الجدية-تبحث-وتكتشف-وفرض-الل

Link znaleziony na:

http://www.galeriejaninerubeiz.com/newsite/news


2
„linki są wyświetlane poprawnie” - poza tym, że parser markdown StackOverflow nie interpretuje adresów URL zgodnie z przeznaczeniem!
MrWhite
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.