ବ୍ୟାଚ୍ ଫାଇଲରେ ଏନକୋଡ୍ ହୋଇଥିବା ପ୍ରକ୍ସି ପ୍ରମାଣପତ୍ର ଅକ୍ଷୁର୍ଣ୍ଣ ରଖନ୍ତୁ

ପ୍ରକ୍ସି URL ସିଧାସଳଖ ବିନ୍ୟାସ କରିବା ସମୟରେ କାମ କରେ, କିନ୍ତୁ ସେହି ମୂଲ୍ୟ Windows ବ୍ୟାଚ୍ ଫାଇଲକୁ ଗଲା ପରେ ପ୍ରମାଣୀକରଣ ବିଫଳ ହୁଏ। HTTP କ୍ଲାଏଣ୍ଟ URL ପାଇବା ପୂର୍ବରୁ ବ୍ୟାଚ୍ ପାର୍ସର ଶତକଡ଼ା ଚିହ୍ନ ବଦଳାଇଛି କି ନାହିଁ ଯାଞ୍ଚ କରନ୍ତୁ।

ଦୁଇଟି ପୃଥକ ପ୍ରତିନିଧିତ୍ୱ ଅଛି। URL ଏନକୋଡିଂ ପ୍ରତିନିଧିତ୍ୱ କରିପାରେ ବ୍ୟାକସ୍ଲାସ୍କୁ %5C ଭାବରେ ଏବଂ ପ୍ରଶ୍ନଚିହ୍ନକୁ %3F ଭାବରେ। ବ୍ୟାଚ୍-ଫାଇଲ ନିର୍ଦ୍ଦେଶରେ ଆକ୍ଷରିକ ଶତକଡ଼ା ଚିହ୍ନକୁ %% ଭାବରେ ଏସ୍କେପ୍ କରିବାକୁ ପଡ଼େ।

ଉଦାହରଣ domain\user ଖାତା ପାଇଁ, ପ୍ଲେସହୋଲ୍ଡର ପାସୱାର୍ଡ pass? ସହିତ, ଏକ .bat ଫାଇଲରେ ଏହା ରହିପାରେ:

set "https_proxy=http://domain%%5Cuser:pass%%[email protected]:8080"

ପରେ ଆରମ୍ଭ ହେଉଥିବା ପ୍ରକ୍ରିୟାକୁ domain%5Cuser:pass%3F ଥିବା URL ମିଳିବା ଉଚିତ। ଦ୍ୱିଗୁଣିତ ଶତକଡ଼ା ଚିହ୍ନଗୁଡ଼ିକ ବ୍ୟାଚ୍ ଉତ୍ସର, କ୍ଲାଏଣ୍ଟ ସଞ୍ଚୟ କରୁଥିବା ପ୍ରକ୍ସି URLର ନୁହେଁ।

ସେହି ବ୍ୟାଚ୍ ବନାନକୁ .npmrc ଫାଇଲ କିମ୍ବା ପ୍ରୟୋଗର ପ୍ରକ୍ସି କ୍ଷେତ୍ରରେ ନକଲ କରନ୍ତୁ ନାହିଁ: ସେହି ଇନପୁଟଗୁଡ଼ିକ ସମାନ ବ୍ୟାଚ୍ ପାର୍ସିଂ ପର୍ଯ୍ୟାୟ ଦେଇ ଯାଆନ୍ତି ନାହିଁ। ସେହିପରି, ଏହି ଉଦାହରଣ PowerShell ସିଣ୍ଟାକ୍ସ ନୁହେଁ। ଅନ୍ୟ ଏକ ର୍ୟାପର, ଯେପରି CALL କିମ୍ବା ଦ୍ୱିତୀୟ ସେଲ ପାଇଁ ନିର୍ମିତ ନିର୍ଦ୍ଦେଶ, ଆଉ ଏକ ପାର୍ସିଂ ପାସ୍ ଆଣିପାରେ ଏବଂ ଏହାର ନିଜସ୍ୱ ସମୀକ୍ଷା ଆବଶ୍ୟକ।

SET ନ୍ୟସ୍ତକୁ ଦେଖାଯାଇଥିବା ପରି ଉଦ୍ଧୃତି ଚିହ୍ନରେ ରଖନ୍ତୁ ଯାହା ଫଳରେ ଆକସ୍ମିକ ଖାଲିସ୍ଥାନ କିମ୍ବା ସେଲ ମେଟାକ୍ୟାରେକ୍ଟର ଅନିଚ୍ଛିତ ନିର୍ଦ୍ଦେଶର ଅଂଶ ନ ହେବ। କେବଳ ଉଦ୍ଧୃତି ଚିହ୍ନ ଶତକଡ଼ା ବିସ୍ତାରକୁ ରୋକେ ନାହିଁ।

ଫଳାଫଳ ଯାଞ୍ଚ କରିବା ସମୟରେ, ପାସୱାର୍ଡ ଥିବା URLକୁ ସେୟାର ହୋଇଥିବା ଲଗରେ ଛାପିବା ପରିବର୍ତ୍ତେ ଆଶାକରାଯାଉଥିବା ଏନକୋଡିଂକୁ ସମ୍ପାଦିତ ପ୍ରତିନିଧିତ୍ୱ ସହିତ ତୁଳନା କରନ୍ତୁ। ସେଲ୍-ଏସ୍କେପିଂ ମରାମତି ପ୍ରମାଣପତ୍ର ସଂରକ୍ଷିତ ରଖେ; ଏହା ଏପରି ପ୍ରମାଣୀକରଣ ଯୋଜନା ଚୟନ କରେ ନାହିଁ ଯାହାକୁ କ୍ଲାଏଣ୍ଟ ପୂର୍ବରୁ ସମର୍ଥନ କରୁ ନ ଥିଲା।