URL კოდირება და დეკოდირება, დეველოპერებისთვის ახსნილი
ჩაწერეთ URL-ში ჰარი, ან კირილიცური სიტყვა, ან ამპერსანდი, რომელიც თქვენს მონაცემებს ეკუთვნის და არა თავად მისამართს — და რაღაც უნდა დაუთმოს ადგილი. ვები მხოლოდ პატარა, პროგნოზირებადი ASCII სიმბოლოთა ნაკრებისთვის იძლევა უსაფრთხო გადატანის გარანტიას. ყველაფერი დანარჩენი უნდა გაეხვას ისეთ ფორმატში, რომელზეც მარშრუტიზატორები, სერვერები და ბრაუზერები ერთმანეთს ეთანხმებიან. ეს ფორმატია პროცენტული კოდირება, უფრო ხშირად წოდებული URL კოდირებად, და ეს გვერდი საშუალებას გაძლევთ, ტექსტი ორივე მიმართულებით გარდაქმნათ პირდაპირ თქვენს ბრაუზერში.
რა არის ნამდვილად პროცენტული კოდირება
წესი მექანიკური და მარტივად დასაფიქსირებელია. ნებისმიერი სიმბოლო, რომელიც პირდაპირ ვერ გამოჩნდება, იცვლება % ნიშნით, რომელსაც მოსდევს ორი თექვსმეტობითი ციფრი, რომელიც ამ სიმბოლოს ბაიტის მნიშვნელობას აღწერს. ჰარი %20-ად იქცევა. პლუსის ნიშანი — %2B-ად. ბადეს ნიშანი — %23-ად. როცა სიმბოლო რამდენიმე ბაიტს შეესაბამება, როგორც ხდება UTF-8-ში ასო-ბგერების უმეტესობასთან, უბრალოდ რამდენიმე სამეული გამოდის რიგში: ევროს ნიშანი %E2%82%AC-ად იქცევა. დეკოდირება პროცესს პირიქით ატარებს, ყოველ სამეულს საწყის ბაიტად კითხულობს.
ეს კონვენცია URI სპეციფიკაციაშია (RFC 3986) განსაზღვრული, და ის განზრახ მოსაწყენია. მოსაწყენობა სწორედ არსია. ყოველ კარგად აწყობილ HTTP კლიენტსა და სერვერს პლანეტაზე ერთი და იგივე წესები აქვს იმპლემენტირებული, ასე რომ, ერთ ადგილას სწორად კოდირებული ბმული ყველგან ხელუხლებელი ჩამოვა.
რატომ უნდა არსებობდეს ის
URL-ები ორი ტიპის სიმბოლოს ატარებს, სხვადასხვა როლით. დაცული სიმბოლოები, როგორიცაა /, ?, #, &, = და :, სტრუქტურულია. ისინი პარსერს ეუბნება, სად მთავრდება ბილიკი და იწყება მოთხოვნის სტრიქონი, ან სად წყდება ერთი პარამეტრი და იწყება მომდევნო. თუ თქვენს ფაქტობრივ მონაცემში ერთ-ერთი ეს სიმბოლოა, ის აუცილებლად უნდა დაიკოდოს, რომ პარსერმა იგი პუნქტუაციად არ ჩათვალოს. შეკვეთის რეფერენსი, როგორიცაა A&B/2024, თუ ნედლი შევა მოთხოვნის სტრიქონში, ორ პარამეტრად და ბილიკის სეგმენტად აღიქმება, არასწორად.
შემდეგ არის არაუსაფრთხო და non-ASCII სიმბოლოები: ჰარები, ბრჭყალები, კუთხოვანი ფრჩხილები, მახვილიანი ასოები, ემოჯი — ყველაფერი, რაც ჩვეულებრივი ASCII დიაპაზონის მიღმაა. მათ არაფერი აქვთ საერთო პირდაპირ URL-ში გამოჩენასთან — ან იმიტომ, რომ გადატანისას ზიანდება, ან იმიტომ, რომ მათი განსაზღვრული წარმოდგენა არ არსებობს. მათი კოდირება ბმულებს სუფთასა და პროგნოზირებადს ტოვებს, შემთხვევითობის ნაცვლად.
სად ხვდებით მას რეალურ სამუშაოში
მოთხოვნის სტრიქონები კლასიკური მაგალითია. ყოველი მნიშვნელობა, რომელსაც ?key=...-ს ურთავთ, უნდა იყოს კოდირებული, რომ მომხმარებლის შეყვანილმა ინფორმაციამ ვერ დაარღვიოს სტრუქტურა. იგივე ეხება HTML ფორმის გაგზავნას application/x-www-form-urlencoded ტიპით, სადაც ბრაუზერი ველების მნიშვნელობებს ავტომატურად კოდირებს (და, ისტორიული კონვენციით, ჰარებს +-ად აქცევს და არა %20-ად). ასევე შეხვდებით მას, როცა ქმნით ბმულებს, რომლებიც არალათინური სათაურების მქონე გვერდებზე მიმართავს, როცა API მოთხოვნებს ხელით აწყობთ, როცა გადამისამართების სამიზნეს პარამეტრად გადასცემთ, და როცა ცდილობთ გაარკვიოთ, რატომ ჩამოდის სერვერზე დაზიანებული ის მოთხოვნა, რომელიც მისამართის ველში ნორმალურად გამოიყურება.
encodeURI და encodeURIComponent
JavaScript ორ ენკოდერს გვთავაზობს, და არასწორის არჩევა ხშირი ხარვეზია. განსხვავება მოქმედების არეალშია. encodeURIComponent ერთი მონაცემისთვისაა, მაგალითად, მოთხოვნის ერთი მნიშვნელობისთვის. ის თითქმის ყველაფერს კოდირებს, დაცული სიმბოლოების /, ?, :, @, &, =, + და # ჩათვლით. სწორედ ეს გჭირდებათ მაშინ, როცა მონაცემს შეუძლია ეს სიმბოლოები ჩვეულებრივ ტექსტად შეიცავდეს.
encodeURI კი მთელი მისამართისთვისაა, რომელიც სამუშაოდ გინდათ შეინარჩუნოთ. ის სტრუქტურულ სიმბოლოებს ხელუხლებელს ტოვებს, ასე რომ, ხაზები, ორწერტილები და კითხვის ნიშნები, რომლებიც URL-ს ერთად ინახავს, გადარჩება. გამოიყენეთ ის, როცა სრული URL გაქვთ და მხოლოდ ჰარებისა და non-ASCII სიმბოლოების გასუფთავება გინდათ; მიმართეთ encodeURIComponent-ს ყოველთვის, როცა უფრო დიდ URL-ში ჩასმას აპირებთ. მარტივი წესი: მთელი ბმულის კოდირებისთვის — encodeURI, ჩასამატებელი ნაწილების კოდირებისთვის — encodeURIComponent.
ყველაფერი თქვენს მოწყობილობაზე რჩება
ეს ხელსაწყო მთლიანად თქვენს ბრაუზერში მუშაობს. ტექსტი, რომელსაც ჩასვამთ, ლოკალურად კოდირდება ან დეკოდირდება იმავე სტანდარტული პროცედურებით და არასდროს იმგზავრება სერვერზე, რაც მას უსაფრთხოს ხდის ტოკენებისთვის, ხელმოწერილი პარამეტრებისთვის ან ნებისმიერი სხვა მონაცემისთვის, რომლის ქსელში გაგზავნაც არ გსურთ. თუ სხვა ტექსტურ გარდაქმნებთანაც გაქვთ საქმე, Base64 გადამყვანი მის გვერდით არის, და ჩვენი დეველოპერული ხელსაწყოების სრულ ნაკრებსაც შეგიძლიათ გაეცნოთ, კიდევ უფრო ხშირად საჭირო დამხმარეებისთვის.
ხშირად დასმული კითხვები
რას ნიშნავს %20 URL-ში?
ეს დაკოდირებული ჰარია. ჰარის სიმბოლო URL-ში პირდაპირ დაუშვებელია, ამიტომ ის იცვლება პროცენტის ნიშნით და თექვსმეტობითი მნიშვნელობით 20, რომელიც ჰარის ბაიტის მნიშვნელობაა.
რატომ ვხედავ ხანდახან პლუსის ნიშანს %20-ის ნაცვლად?
HTML ფორმის მონაცემები, ტიპით application/x-www-form-urlencoded, ჰარებს ისტორიული კონვენციით პლუსის ნიშნად კოდირებს. ჩვეულებრივ ბილიკში ან მოთხოვნაში ჰარი %20-ად კოდირდება. ორივე თავის კონტექსტში ისევ ჰარად დეკოდირდება.
როდის უნდა გამოვიყენო encodeURIComponent encodeURI-ს ნაცვლად?
გამოიყენეთ encodeURIComponent ერთი მნიშვნელობისთვის, რომელსაც URL-ში ჩასვამთ, მაგალითად, მოთხოვნის პარამეტრისთვის, რადგან ის დაცულ სიმბოლოებსაც კოდირებს. გამოიყენეთ encodeURI სრული მისამართისთვის, როცა გინდათ შეინარჩუნოთ ხაზები, ორწერტილები და კითხვის ნიშნები, რომლებიც მას აერთიანებს.
ცვლის URL კოდირება ჩემი მონაცემის მნიშვნელობას?
არა. კოდირება სრულად შექცევადია. შედეგის დეკოდირება ზუსტად საწყის ტექსტს გიბრუნებთ, ბაიტ-ბაიტ, თუ ორივე მხარეს ერთი და იგივე სიმბოლოთა ნაკრებია გამოყენებული.
როგორ მუშავდება non-ASCII სიმბოლოები, როგორიცაა მახვილები ან ემოჯი?
ისინი ჯერ UTF-8 ბაიტებად იქცევა, შემდეგ თითოეული ბაიტი ცალკე პროცენტულ სამეულად გარდაიქმნება. ერთადერთი მახვილიანი ასო ან ემოჯი ამიტომ შეიძლება რამდენიმე სამეულად გაფართოვდეს დაკოდირებულ გამონატანში.
იგზავნება ჩემი ტექსტი სერვერზე ამ ხელსაწყოს გამოყენებისას?
არა. კოდირება და დეკოდირება მთლიანად თქვენს ბრაუზერში ხდება. არაფერი, რასაც ჩასვამთ, არ იტვირთება, ასე რომ, ის უსაფრთხოა კონფიდენციალური ან მგრძნობიარე სტრიქონებისთვისაც.