7 min czytaniaInżynieria

Maksymalna długość URL: rzeczywisty limit znaków

W specyfikacji nie ma maksymalnej długości URL. Prawdziwym pułapem jest najniższy limit w łańcuchu, przez który przechodzi twój link: przeglądarka, serwer, skrzynka pocztowa albo kod QR.

Marius Voß
DevRel · edge infra
Maksymalna długość URL pokazana jako cztery systemy, przez które przechodzi link, każdy z własnym pułapem, przy czym pasek przeglądarki jest najmniej restrykcyjny z czterech

Nie ma maksymalnej długości URL. RFC 3986, standard definiujący składnię URI, nigdy jej nie ustala - opisuje, jakie znaki są dozwolone i jak składa się URL, i na tym kończy. To, na co faktycznie trafiasz, to łańcuch osobnych, niepowiązanych ze sobą limitów: pasek adresu w przeglądarce, serwer po drugiej stronie, proxy siedzące pomiędzy nimi, klient poczty, w którym ktoś otwiera twój link, albo kod QR, który zaraz wydrukujesz. Każdy z nich egzekwuje własny pułap, a prawdziwa maksymalna długość URL-a to ten pułap, który jest najniższy. Wyślij URL o długości 3000 znaków, a może wyrenderować się bez problemu w Chrome, zostać odrzucony przez serwer na domyślnych ustawieniach i dotrzeć do Outlooka zawinięty na cztery linie. Żadne z tego nie jest błędem. To praktyczna konsekwencja specyfikacji, która celowo milczała w tej sprawie.

Wynikają z tego cztery rzeczy: co standard mówi, a czego nie mówi, skąd wzięła się słynna liczba 2083 znaków i czemu wciąż pojawia się na listach kontrolnych lata po tym, jak przestała mieć znaczenie, jakie limity naprawdę dają się we znaki, kiedy link opuszcza przeglądarkę, i co zrobić z URL-em, który urósł za bardzo. Co ze wszystkim tym robi skracacz po drodze, opisują jak działają skracacze URL.

Co RFC 3986 faktycznie mówi o długości URL

RFC 3986 definiuje ogólną składnię URI - schemat, autorytet, ścieżkę, query, fragment - i milczy na temat tego, jak długi może być którykolwiek z tych elementów. Nie milczy przez przeoczenie; milczy celowo. Gramatyka w sekcji 3 buduje URI z niewielkiego zbioru reguł produkcji, i nic w tych regułach nie ogranicza, ile razy dana reguła może się powtórzyć. Segment ścieżki może mieć jeden znak albo sto tysięcy, jeśli chodzi o samą składnię. Długie URL-e to całkowicie legalne URL-e.

Jedyny limit, jaki RFC faktycznie narzuca, jest pośredni: komponent autorytetu URL-a zawiera nazwę hosta, a DNS ogranicza w pełni kwalifikowaną nazwę hosta znacznie poniżej tego, na co pozwala gramatyka URI - dokumentacja inżynierska Chromium ustawia ten pułap na 253 znaki łącznie, 63 na etykietę. Ścieżka, query string i fragment nie mają nigdzie w standardzie takiego ograniczenia.

To cała historia ze strony specyfikacji. Limit znaków URL-a, na który faktycznie trafiasz w praktyce, pochodzi z oprogramowania czytającego URL, nigdy z samego formatu URL-a.

Skąd wzięło się 2083 i co robią dziś przeglądarki

Jeśli gdziekolwiek widziałeś wytyczną dotyczącą długości URL, cytowała 2083 znaki. Ta liczba jest prawdziwa, ale należy do jednej przeglądarki, jednej epoki i jednej ścieżki kodu. Biblioteka sieciowa WinINET Internet Explorera definiowała INTERNET_MAX_URL_LENGTH jako 2083 znaki, a własne opracowanie inżynierskie Microsoftu na temat tego limitu zaznacza, że sam pasek adresu miał limit o jeden znak niższy, 2047. Ten pułap rządził ogromną częścią ruchu w sieci przez ponad dekadę, więc stał się liczbą, do której wszyscy projektowali, a przyzwyczajenie przeżyło przeglądarkę, którą opisuje.

Nowoczesne przeglądarki tak nie działają. Dokumentacja Chrome podaje wewnętrzny limit 2 megabajtów, narzucony po to, żeby uniknąć problemów z komunikacją międzyprocesową, a nie żeby chronić pole interfejsu, przy czym znacznie mniejsza stała, około 32 kilobajtów na desktopie, ogranicza to, co faktycznie wyświetli omnibox. Firefox i Safari są podobnie wielkoduszne - żadna z nich nie krztusi się URL-em zbliżonym długością do tego, jaki prawdopodobnie skonstruujesz ręcznie. Nigdy nie debugowałem realnego problemu produkcyjnego spowodowanego przez nowoczesną przeglądarkę odrzucającą długi URL. Każdy błąd związany z długim URL-em, jaki kiedykolwiek prześledziłem, zaczynał się dalej niż przeglądarka.

Rzeczywiste limity, które naprawdę dają się we znaki

Cztery miejsca, przez które przechodzi URL - pasek adresu przeglądarki, linia żądania serwera, klient poczty i kod QR - z praktycznym pułapem znaków i objawem, kiedy każdy z nich zostanie przekroczony

Ułóż w kolejności, przez co faktycznie przechodzi URL, a wzorzec pojawia się szybko: najciaśniejszy limit rzadko jest tym w przeglądarce.

  • Linia żądania serwera czyta URL jako część pierwszej linii żądania HTTP, a ta linia ma własny bufor. Przekrocz go, a serwer nigdy nie sparsuje twojej trasy - odrzuca połączenie, zanim kod twojej aplikacji w ogóle się uruchomi.
  • Klienci poczty obsługują przepełnienie inaczej. Outlook zawija długi zwykły tekstowy URL na kilka linii zamiast go ucinać, co jest brzydkie, ale wciąż klikalne; niektóre webmaile i bramki przekazujące są mniej wyrozumiałe i po prostu tną link.
  • Link wewnątrz wiadomości tekstowej konkuruje z treścią wiadomości o ten sam budżet znaków, a linki do marketingu SMS żyją wewnątrz segmentu 160 znaków - sam długi URL potrafi przesunąć jednosegmentowy tekst na dwa, co operatorzy rozliczają i filtrują inaczej.
  • Kod QR nie ucina długiego URL-a; po prostu robi się gęstszy. Jak duży musi być kod QR zależy bezpośrednio od tego, ile każesz mu zakodować, a URL obładowany parametrami śledzącymi potrafi przesunąć kod o wersję albo dwie wyżej, zmniejszając odległość, z jakiej wciąż da się go zeskanować.
  • Funkcje hiperłączy w arkuszach kalkulacyjnych narzucają własny twardy limit znaków dla argumentu linku, wyraźnie poniżej typowego otagowanego URL-a, a link, który go przekracza, zawodzi po cichu - komórka wyświetla się dobrze, sam link nie działa.
  • Platformy reklamowe ograniczają pole docelowego URL-a do stałej długości, którą same sobie ustaliły - to reguła platformy, a nie techniczna - a menedżer kampanii dowiaduje się o tym dopiero, kiedy przycisk zapisu odrzuca to, co przeglądarka otworzyłaby bez zająknięcia.

Żaden z tych limitów nie rozmawia z pozostałymi. URL może przejść przez linię żądania twojego serwera i wciąż umrzeć w arkuszu kalkulacyjnym trzy działy dalej.

Limity linii żądania serwera i proxy

Przypadek serwera zasługuje na osobne spojrzenie, bo to on generuje prawdziwy kod błędu zamiast kosmetycznej usterki. 414 Request-URI Too Long to odpowiedź, którą serwer wysyła, kiedy odmawia przetworzenia żądania, bo URI jest dłuższy, niż jest skłonny zinterpretować - limit rozmiaru URL-a egzekwowany po jednym skoku naraz, przez to oprogramowanie, które akurat w danej sekundzie czyta linię żądania.

Każdy serwer i proxy w łańcuchu egzekwuje własną wersję tego limitu. Dyrektywa Apache'a LimitRequestLine domyślnie wynosi 8190 bajtów dla całej linii żądania, co obejmuje metodę i wersję protokołu, nie tylko sam URL. nginx czyta nagłówki żądania do stałego bufora kontrolowanego przez large_client_header_buffers, domyślnie 8 kilobajtów, a linia żądania, która się w nim nie mieści, dostaje 414, zanim twoja trasa w ogóle zostanie dopasowana. Load balancery i CDN-y stojące przed jednym albo drugim często stosują trzeci, osobny limit, więc URL może przejść przez ustawienie twojego serwera źródłowego i wciąż zostać odrzucony jeden skok wcześniej.

Jeśli nie kontrolujesz każdego skoku, a po przekroczeniu pewnej wielkości firmy nikt tego nie robi, bezpiecznym ruchem jest projektowanie pod najciaśniejszy wspólny domyślny limit, a nie ten najbardziej wielkoduszny, jaki znalazłeś w pliku konfiguracyjnym.

Zbudowanie warstwy przekierowań samodzielnie, zamiast ręcznego parsowania żądań, jest tu nudną, ale skuteczną naprawą. API Elido przyjmuje miejsce docelowe o dowolnej rozsądnej długości i zwraca krótki link, który nigdy nie zmienia rozmiaru, więc pułap linii żądania serwera staje się czymś, co konfigurujesz raz na brzegu sieci, zamiast czymś, co każda integracja musi obsłużyć na własną rękę.

Jak zmierzyć prawdziwą długość URL-a, zanim go wyślesz

Liczba znaków to cały pomiar, i warto go sprawdzić, zanim URL trafi do kampanii, a nie po tym, jak nadejdzie raport o odbiciach.

printf '%s' "https://example.com/path?utm_source=newsletter&utm_campaign=spring-sale-2026" | wc -c

To daje ci długość w bajtach URL-a dokładnie takiego, jak został zapisany. Dwie rzeczy to komplikują. Po pierwsze, zakodowane procentowo znaki kosztują więcej, niż wyglądają: litera z akcentem albo emoji wewnątrz wartości query może rozszerzyć się do sześciu znaków lub więcej po zakodowaniu, więc mierz URL po zakodowaniu, nie przed. Po drugie, parametry UTM są zwykle najszybciej rosnącą częścią URL-a - garść tagów kampanii, źródła, medium i treści potrafi dodać kilkaset znaków do czegoś, co zaczynało jako krótka ścieżka, i to tam warto spojrzeć najpierw, kiedy URL po cichu urósł za bardzo.

Jeśli link, który wcześniej działał, nagle przestaje, przeprowadź ten sam trop, jaki zastosowałbyś dla każdego martwego linku: krótki link nie działa przeprowadza przez sprawdzanie miejsca docelowego bezpośrednio, co jest dokładnie tym sposobem, w jaki złapiesz URL, który urósł ponad limit serwera jeden parametr śledzący na raz.

Co zrobić, kiedy URL jest za długi

Długi otagowany URL, jego parametry przechowywane po stronie serwera przez skracacz, i krótki link, który podróżuje w jego miejsce

Naprawdę działają dwie naprawy, i to te same dwie bez względu na to, który limit uruchomiłeś.

Pierwsza to skrócenie URL-a. Krótki link to wskaźnik o stałej długości - slug ma tę samą długość bez względu na to, jak bardzo rośnie miejsce docelowe albo jego parametry śledzące, bo to wszystko żyje po stronie serwera i jest wyszukiwane przy każdym kliknięciu, zamiast być niesione wewnątrz samego linku. To rozwiązuje problem gęstości kodu QR, problem segmentu SMS i problem arkusza kalkulacyjnego jednym ruchem, bo wszystkie trzy dbają o liczbę znaków linku, nie o długość tego, dokąd ostatecznie prowadzi.

Druga to przeniesienie stanu poza query string całkowicie. Jeśli to, co czyni twój URL długim, to dane sesji, blob z zawartością koszyka albo długa lista filtrów, a nie prawdziwe parametry śledzące, te dane zwykle należą po stronie serwera za nieprzejrzystym identyfikatorem, a nie wypisane w pasku adresu. URL, który brzmi /checkout?session=a1b2c3d4, starzeje się lepiej niż taki, który brzmi /checkout?items=... z każdym SKU i ilością wypisanymi w całości, i omija wszystkie limity z tego artykułu naraz, bo nie zostaje już nic długiego do zmierzenia.

Obie naprawy wskazują ten sam kierunek: traktuj długość URL-a jako decyzję projektową, a nie przypadek tego, ile parametrów akurat się na nim nazbierało.

Przeczytaj serię filarową

Ten artykuł należy do klastra inżynieryjnego. Po stronę tego, co dzieje się na drugim końcu krótkiego linku, jak działają skracacze URL opisuje samo wyszukiwanie, a typy przekierowań opisuje kody statusu, które wchodzą w grę, kiedy miejsce docelowe zostanie już znalezione.

Powiązane na blogu

Najczęściej zadawane pytania

Jaka jest maksymalna długość URL?

Nie istnieje jedna, zdefiniowana przez sam standard sieci. RFC 3986 ustala składnię URL, ale nigdy nie ogranicza jego długości, więc prawdziwym pułapem jest ten system w łańcuchu, który egzekwuje najciaśniejszy limit: przeglądarka, serwer, klient poczty albo kod QR. Utrzymanie URL-a poniżej mniej więcej 2000 znaków przechodzi przez niemal każdy z tych systemów naraz, dlatego ta liczba wciąż pojawia się jako bezpieczny cel, mimo że żadna pojedyncza specyfikacja tego nie wymaga.

Czemu mówi się, że URL może mieć maksymalnie 2083 znaki?

Ta liczba pochodzi z biblioteki sieciowej WinINET Internet Explorera, która definiowała INTERNET_MAX_URL_LENGTH jako 2083 znaki, przy czym pasek adresu samej przeglądarki miał limit o jeden znak niższy, 2047. Ten limit rządził dużą częścią ruchu w sieci przez lata, więc stał się domyślnym bezpiecznym założeniem, a przyzwyczajenie do jego cytowania przeżyło przeglądarkę, którą opisywał.

Jaka jest maksymalna długość URL w Chrome i innych nowoczesnych przeglądarkach?

Dokumentacja Chrome podaje wewnętrzny limit 2 megabajtów, ustalony po to, żeby uniknąć problemów z komunikacją międzyprocesową, a nie żeby chronić pasek adresu, a osobna stała ogranicza to, co pasek adresu faktycznie wyświetli, około 32 kilobajtów na platformach desktopowych. Firefox i Safari są podobnie wyrozumiałe. W praktyce żadna aktualna przeglądarka nie jest limitem, na który trafisz jako pierwszy.

Co się dzieje, kiedy URL jest za długi?

Rodzaj awarii zależy całkowicie od tego, który system go odrzucił. Serwer albo proxy zwykle zwraca odpowiedź 414 Request-URI Too Long i nigdy nie uruchamia kodu twojej aplikacji; klient poczty zawija albo ucina link na kilka linii; kod QR po prostu robi się gęstszy i trudniejszy do zeskanowania z odległości; komórka arkusza kalkulacyjnego może wyglądać dobrze, podczas gdy leżący pod nią link po cichu przestaje działać.

Jak długi powinien być URL pod kątem SEO?

Sama długość nie jest czynnikiem rankingowym, ale URL obładowany zbędnymi parametrami jest często objawem czegoś, na czym wyszukiwarkom faktycznie zależy, jak duplikacja treści albo niejasna struktura witryny. W praktyce utrzymanie URL-i wyraźnie poniżej 2000 znaków omija powyższe problemy z kompatybilnością, a trzymanie ścieżki krótkiej i opisowej to bardziej decyzja dotycząca użyteczności niż SEO.

Jak sprawdzić, jak długi jest URL?

Policz znaki po zakodowaniu, a nie przed, bo wszystko spoza czystego ASCII rozrasta się po zakodowaniu procentowym. Jedna linijka w terminalu, printf '%s' "your-url" | wc -c, daje dokładną długość w bajtach, którą zaraz wyślesz - to ta sama liczba, którą zobaczy twój serwer, klient poczty albo generator kodów QR.

Wypróbuj Elido

Wklej URL, otrzymaj krótki link

Bez rejestracji. Link działa 30 dni. Zarejestruj się, aby zachować go na zawsze.

Za darmo, bez rejestracji · 2 dziennie

Wypróbuj Elido

Skracarka URL hostowana w UE: własne domeny, głęboka analityka i otwarte API. Darmowy plan - bez karty kredytowej.

Tagi
maximum url length
max url length
url character limit
url size limit
long urls
how long can a url be

Czytaj dalej