બેચ ફાઇલમાં એન્કોડ થયેલ પ્રોક્સી ઓળખપત્રો અકબંધ રાખો

પ્રોક્સી 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 શેર કરેલા લોગમાં છાપવાને બદલે અપેક્ષિત એન્કોડિંગની સંપાદિત રજૂઆત સાથે સરખામણી કરો. શેલ-એસ્કેપિંગ સુધારો ઓળખપત્ર જાળવી રાખે છે; તે એવી પ્રમાણીકરણ યોજના પસંદ કરતું નથી જે ક્લાયન્ટ પહેલેથી સમર્થન આપતું ન હતું.