பேஸ்64 குறியாக்கத்தைப் புரிந்துகொள்வது: டெவலப்பர்கள் மற்றும் அன்றாடப் பயனர்களுக்கான நடைமுறைக் குறிப்புகள்

பேஸ்64 குறியாக்கத்தைப் புரிந்துகொள்வது: டெவலப்பர்கள் மற்றும் அன்றாடப் பயனர்களுக்கான நடைமுறைக் குறிப்புகள்

டெவலப்பர் பணிகளில் பெரும்பாலானவை, பூகம்பத்தின் போது பிரிண்டரிலிருந்து உதிர்ந்து விழுந்தது போலத் தோற்றமளிக்கும் எழுத்துச் சரங்களை உற்றுப் பார்ப்பதை உள்ளடக்கியுள்ளன. நீண்ட எழுத்துத் துண்டுகள், எண்கள், கூட்டல் குறிகள், சாய்வுக் கோடுகள், இறுதியில் சமக்குறிகள். சில நேரங்களில் அது பாதிப்பில்லாத குறியாக்கம் செய்யப்பட்ட தரவாக இருக்கும். சில நேரங்களில் அது ஒரு டோக்கனாக இருக்கும். சில நேரங்களில் அது, பழுதின்றி இருப்பது போல் பாசாங்கு செய்யும் ஒரு செயலிழந்த தரவுச் சுமையாக இருக்கும்.

குறியாக்கம் செய்யப்பட்ட தரவு என்பது இயல்பானது. உரை வடிவத்தை எதிர்பார்க்கும் அமைப்புகளில் பைனரி தகவல்கள் தடையின்றிச் செல்வதை இது உறுதி செய்கிறது; கட்டமைக்கப்பட்ட மதிப்புகளை API-கள் பரிமாறிக் கொள்ள இது உதவுகிறது; மேலும், பதிவுகள் மற்றும் உள்ளமைப்புக் கோப்புகளை எளிதாகக் கொண்டு செல்லவும் இது வழிவகுக்கிறது. ஆனால், இது ஒரு சிறிய சிக்கலையும் உருவாக்குகிறது: அந்தத் தரவு படிக்க முடியாததாகத் தோன்றுவதால், மக்கள் பெரும்பாலும் அது பாதுகாக்கப்பட்டது போலவே கருதுகிறார்கள். ஆனால், பொதுவாக அது பாதுகாக்கப்பட்டிருப்பதில்லை.

அந்த வேறுபாடு முக்கியமானது. குறியாக்கம் என்பது பிரதிநிதித்துவத்தைப் பற்றியது. பாதுகாப்பு என்பது காப்பதைப் பற்றியது. அவை இரண்டும் ஒன்றல்ல, மேலும் அவற்றைக் குழப்பிக் கொள்வதால்தான் பல சிறிய பிழைகள், தரவுக் கசிவுகள் மற்றும் நள்ளிரவுப் பிழைதிருத்த அமர்வுகள் தொடங்குகின்றன.

ஒரு யதார்த்தமான சூழ்நிலை: வெப்ஹூக்கில் உள்ள மர்ம டோக்கன்

ஒரு சிறிய மென்பொருள் குழு, தங்களது செயலியுடன் ஒரு பில்லிங் சேவையை இணைப்பதாகக் கற்பனை செய்து பாருங்கள். ஒரு கட்டணம் வெற்றிகரமாகச் செலுத்தப்பட்ட பிறகு, அந்த பில்லிங் சேவை ஒரு வெப்ஹூக்கை அனுப்புகிறது. அந்த பேலோடில் வாடிக்கையாளர் ஐடி, நிகழ்வின் வகை, நேரமுத்திரை மற்றும் ஒரு கையொப்பமிடப்பட்ட மதிப்பு ஆகியவை அடங்கியுள்ளன. ஒரு டெவலப்பர், லாக்ஸிலிருந்து விசித்திரமாகத் தோற்றமளிக்கும் ஒரு சரத்தை நகலெடுத்து, அதை ஒரு அரட்டைத் தொடரில் இடுகிறார்: “இது என்னவென்று யாருக்காவது தெரியுமா?”

ஒருவர், “இது மறைகுறியாக்கம் செய்யப்பட்டது போல் தெரிகிறது” என்கிறார். மற்றொருவர், “இல்லை, அநேகமாக இது குறியாக்கம் செய்யப்பட்டிருக்கலாம்” என்கிறார். அவர்கள் அதன் ஒரு பகுதியை மறைகுறியாக்கம் நீக்க, திடீரென்று உள்ளே படிக்கக்கூடிய JSON கிடைக்கிறது. இது உதவிகரமானதுதான். ஆனால், ஒருங்கிணைப்பின் போது விரிவான பதிவுசெய்தல் இயக்கப்பட்டிருந்ததால், அதே பதிவு வரியில் ஒரு சோதனைக் கணக்கின் பியரர் டோக்கனும் உள்ளது. இது வெறும் சோதனை ஓட்டம்தான், அதனால் யாரும் பதறுவதில்லை. இருப்பினும், இது ஒரு உண்மையான பாடம். அந்தச் சரம் குப்பையாகத் தோன்றியது, ஆனால் உண்மையில் அது வெளிப்படையாகத் தெரிந்த, ஆனால் வேறு விதமாகக் காட்டப்பட்ட ஒரு முக்கியமான பயன்பாட்டுத் தரவுதான்.

இது போன்ற விஷயங்கள் அடிக்கடி நடக்கும். டெவலப்பர்கள் கவனக்குறைவாக இருப்பதால் அல்ல, மாறாக குறியாக்கம் செய்யப்பட்ட தரவு பாதி மறைக்கப்பட்டது போல் தோன்றுவதால்தான். அதை நகலெடுப்பது எளிது, டிக்கெட்டுகளில் ஒட்டுவது எளிது, டெர்மினல் ஹிஸ்டரியில் விட்டுவிடுவது எளிது. பின்னர் வாரங்கள் கழித்து, ஒரு பிழை கண்காணிப்பு அமைப்பில் ஒரு ரகசியம் ஏன் தோன்றுகிறது என்று நீங்கள் ஆச்சரியப்படுவீர்கள்.

குறியாக்கம் என்பது மறைகுறியாக்கம் அல்ல, அது ஒருபோதும் அவ்வாறு இருந்ததும் இல்லை.

முதல் விதி எளிமையானது: இரகசியத் திறவுகோல் இல்லாமல் ஒருவரால் அதைத் தலைகீழாக மாற்ற முடிந்தால், அது மறைகுறியாக்கம் ஆகாது. குறியாக்கம் என்பது தரவின் வடிவத்தை மாற்றி, மற்றொரு அமைப்பு அதை பாதுகாப்பாகக் கையாள வழிவகை செய்வதாகும். மறைகுறியாக்கம், திறவுகோல் இல்லாதவர்களிடமிருந்து தரவின் பொருளைப் பாதுகாக்கிறது.

எனவே, ஒரு அமர்வு மதிப்பு, API சான்று, வாடிக்கையாளர் மின்னஞ்சல், உள் ஐடி அல்லது ஆவண உள்ளடக்கம் ஆகியவை வெறுமனே குறியாக்கம் செய்யப்பட்டிருந்தால், அதைப் படிக்க முடியும் என்று கருதுங்கள். முதல் பார்வையில் உங்கள் இறுதிப் பயனரால் படிக்க முடியாமல் இருக்கலாம், ஆனால் அடிப்படைக் கருவிகளும் ஒரு நிமிட நேரமும் உள்ள எவராலும் படிக்க முடியும்.

இது குறிப்பாக டோக்கன்களுக்குப் பொருந்தும். சில டோக்கன்கள் தெளிவற்ற, சீரற்ற சரங்களாக இருக்கின்றன, சில படிக்கக்கூடிய பகுதிகளைக் கொண்டிருக்கின்றன, மேலும் சில கையொப்பமிடப்பட்டிருந்தாலும் மறைகுறியாக்கம் செய்யப்படவில்லை. ஒரு கையொப்பமிடப்பட்ட டோக்கன், அது மாற்றப்படவில்லை என்பதை நிரூபிக்க முடியும், ஆனால் அது அதன் உள்ளடக்கங்களை வெளிப்படுத்திவிடக்கூடும். அதுவாகவே அது ஒரு மோசமான வடிவமைப்பு அல்ல; டோக்கனின் வடிவம் தனிப்பட்ட தரவைப் பாதுகாக்கும் நோக்கம் கொண்டதாக இல்லாவிட்டால், நீங்கள் அதற்குள் தனிப்பட்ட தரவை வைக்கக்கூடாது என்பதே இதன் பொருள்.

குறியாக்கம் செய்யப்பட்ட தரவு பொதுவாக தோன்றும் இடத்தில்

நீங்கள் எதிர்பார்ப்பதை விட அதிகமான இடங்களில் குறியாக்கம் செய்யப்பட்ட சரங்களை எதிர்கொள்வீர்கள். அவற்றில் சில பொதுவானவை:

• API கோரிக்கைகள் மற்றும் பதில்கள் , குறிப்பாக JSON அல்லது XML வழியாக பைனரி உள்ளடக்கத்தை அனுப்பும்போது.
• மின்னஞ்சல் அமைப்புகளில் , இணைப்புகளுக்கும் குறிப்பிட்ட தலைப்புகளுக்கும் உரை-பாதுகாப்பான வடிவமைப்பு தேவைப்படுகிறது.
• உள்ளமைவு கோப்புகள் , பெரும்பாலும் சான்றிதழ்கள், சாவிகள் அல்லது சூழல் மாறிகளில் பொருந்த வேண்டிய தரவுத் தொகுப்புகளுக்கானவை.
• CSS அல்லது HTML-க்குள் ஒரு சிறிய படத்தை நேரடியாக உட்பொதிப்பது போன்ற தரவு URL-கள் .
• டோக்கன் வடிவங்கள் மற்றும் கையொப்பமிடப்பட்ட செய்திகள் உள்ளிட்ட அங்கீகார செயல்முறைகள் .
• பதிவுகள் மற்றும் பிழைதிருத்த வெளியீடு , இந்த இடங்களில்தான் விஷயங்கள் விரைவாகக் குழப்பமடையக்கூடும்.

இவற்றில் எதுவும் தானாகவே சந்தேகத்திற்குரியதாகிவிடாது. குறியாக்கம் பயனுள்ளது. பிரச்சனை நுட்பத்தில் இல்லை, அதைச் சுற்றியுள்ள கவனக்குறைவான கையாளுதலில்தான் உள்ளது.

தலைவலியைத் தவிர்க்க உதவும் நடைமுறைப் பழக்கங்கள்

குறியாக்கம் செய்யப்பட்ட முக்கியமான தரவை முக்கியமானதாகவே கருதுங்கள். அசல் மதிப்பு ஒரு கடவுச்சொல், டோக்கன், தனிப்பட்ட ஆவணம், தனிப்பட்ட அடையாளங்காட்டி அல்லது முக்கியப் பொருளாக இருந்தால், குறியாக்கம் செய்யப்பட்ட பதிப்பிற்கும் அதே கவனம் தேவை. அதை நீங்கள் திருத்தியமைக்காத வரை, பொது அரட்டை, சிக்கல் கண்காணிப்பாளர்கள், ஸ்கிரீன்ஷாட்கள் அல்லது ஆதரவு மின்னஞ்சல்களில் ஒட்ட வேண்டாம்.

முடிந்தவரை உங்கள் தரவுகளுக்குப் பெயரிடுங்கள். 'data' என்பதற்குப் பதிலாக 'encodedPayload ' என்ற மாறி சிறந்தது. "குறியாக்கப்பட்ட சான்றிதழைக் கொண்டுள்ளது, பதிவு செய்ய வேண்டாம்" என்று கூறும் ஒரு குறிப்பு அவ்வளவு சிறப்பாக இருக்காது, ஆனால் அது மாலை 6:40 மணிக்கு சோர்வாக இருக்கும் அடுத்த நபருக்கு உதவும்.

பதிவுகளை சலிப்பூட்டாதவையாக வைத்திருங்கள். பதிவுகள், உங்கள் பயன்பாட்டின் முழுமையான தனிப்பட்ட நிலையை மீண்டும் உருவாக்குவதற்குப் பதிலாக, அதன் செயல்பாட்டைப் பிழைதிருத்த உதவ வேண்டும். டோக்கன்களை மறைக்கவும். நீண்ட தரவுப் பகுதிகளைச் சுருக்கவும். தெரிந்த இரகசியங்களை மறைக்கவும். மேலும், தற்காலிகப் பிழைதிருத்தப் பதிவுகளில் கவனமாக இருங்கள், ஏனெனில் தற்காலிகக் குறியீட்டிற்கு நிரந்தர இடத்திற்குள் நுழையும் அபாரமான திறன் உண்டு.

குறியீட்டைப் பிரிப்பதற்கு அல்லது செயலாக்குவதற்கு முன் சரிபார்க்கவும். உங்கள் செயலி பயனர்களிடமிருந்தோ அல்லது வெளிப்புற அமைப்புகளிடமிருந்தோ குறியாக்கம் செய்யப்பட்ட உள்ளீட்டை ஏற்றுக்கொண்டால், அளவு வரம்புகளையும் எதிர்பார்க்கப்படும் வடிவத்தையும் சரிபார்க்கவும். மிகப்பெரிய குறியாக்கம் செய்யப்பட்ட தரவுகள் நினைவகத்தை வீணடிக்கக்கூடும். தவறான வடிவமைப்பு கொண்ட தரவுகள் விசித்திரமான விளிம்புநிலைச் சிக்கல்களைத் தூண்டக்கூடும். இது கவர்ச்சிகரமான வேலை அல்ல, ஆனால் தற்செயலான உற்பத்திப் பிழைகளைத் துரத்துவதை விட இது மேலானது.

எப்போது குறியாக்கம் செய்யக்கூடாது என்பதை அறிந்து கொள்ளுங்கள். தரவுத்தளம் அல்லது URL-க்கு "பாதுகாப்பானதாக" மாற்றுவதற்காக, உருவாக்குநர்கள் சில நேரங்களில் தரவைக் குறியாக்கம் செய்கிறார்கள். ஆனால், முறையான எஸ்கேப்பிங், அளவுருவாக்கப்பட்ட வினவல்கள் அல்லது தளத்தின் URL கருவிகளைப் பயன்படுத்துவதே சரியான தீர்வாகும். குறியாக்கம் என்பது ஒரு பரிமாற்றத் தீர்வின் பகுதியாக இருக்கலாம், ஆனால் அது சேருமிடத்தில் தரவைச் சரியாகக் கையாளுவதற்கு மாற்றாகாது.

மக்கள் செய்யும் பொதுவான தவறுகள்

குறியாக்கம் செய்யப்பட்டது பாதுகாப்பானது என்று கருதுவதுதான் இதில் உள்ள பெரிய தவறு. அது அப்படியல்ல. நீங்கள் ஒரே ஒரு விஷயத்தை மட்டும் நினைவில் கொள்ள வேண்டுமென்றால், இதை நினைவில் கொள்ளுங்கள்.

மற்றொரு பொதுவான தவறு இரட்டை குறியாக்கம் ஆகும். ஒரு சேவை ஒரு மதிப்பைக் குறியாக்கம் செய்கிறது, பின்னர் மற்றொரு அடுக்கு அதை மீண்டும் குறியாக்கம் செய்கிறது. இதனால், ஒரு பக்கம் ஒரு முறையும், மறுபக்கம் இரண்டு முறையும் குறியீட்டை நீக்குவதால், திடீரென்று ஒரு சூழலில் எல்லாம் சரியாக வேலை செய்து, மற்றொரு சூழலில் தோல்வியடைகிறது. அந்தப் பிழை அறிக்கை பொதுவாக, "ஒருங்கிணைப்பு சீரற்ற முறையில் தரவைச் சிதைக்கிறது" என்பது போன்ற கவித்துவமான ஒரு வாக்கியத்தைக் குறிப்பிடும். அது சீரற்றதல்ல. அடுக்குகள் ஒன்றுக்கொன்று ஒத்துப்போகாததே இதற்குக் காரணம்.

மக்கள் எழுத்துக் குறியாக்கத்தையும் மறந்துவிடுகிறார்கள். உரை என்பது வெறும் உரை மட்டுமல்ல. ஒரு அமைப்பு ஒரு சரத்தை UTF-8 ஆகக் கருதி, மற்றொன்று வேறு ஒன்றைக் கருதினால், உங்களுக்கு உடைந்த பெயர்கள், சிதைந்த குறியீடுகள் அல்லது செல்லாத கையொப்பங்கள் கிடைக்கலாம். கையொப்பங்கள் அல்லது ஹாஷ்கள் சம்பந்தப்பட்டிருக்கும்போது இது குறிப்பாக எரிச்சலூட்டுகிறது, ஏனெனில் பைட்டுகளில் ஒரு சிறிய வேறுபாடு கூட முடிவை மாற்றிவிடும்.

வரி முறிவுகள் மற்றொரு தந்திரமான விஷயமாகும். சில குறியாக்க வடிவங்கள் மடிக்கப்பட்ட வரிகளை அனுமதிக்கின்றன, சில அமைப்புகள் ஒற்றை வரியை எதிர்பார்க்கின்றன, மேலும் சூழல் மாறிகள் நீங்கள் நினைப்பது போல் வடிவமைப்பைப் பாதுகாக்காமல் போகலாம். வரிசைப்படுத்தல் அமைப்புகளில் நகலெடுக்கப்படும் சான்றிதழ்கள் இந்த வகையான சிக்கல்களுக்குப் பெயர் பெற்றவை.

மேலும், இடைநிரப்புதல் (padding) உள்ளது. சில குறியாக்கம் செய்யப்பட்ட சரங்களின் முடிவில் உள்ள அந்தச் சமக்குறிகள், அதன் வகை மற்றும் டிகோடரைப் பொறுத்து முக்கியத்துவம் வாய்ந்ததாக இருக்கலாம். அவை "விருப்பத்திற்குரியவை போல் தெரிகின்றன" என்பதால் அவற்றை நீக்குவது ஒரு வழக்கமான உத்தியாகும், மேலும் அது சில சமயங்களில் பலனளிக்கும், ஆனால் பின்னர் முற்றிலும் பலனளிக்காமல் போகும்.

குறியாக்கம் செய்யப்பட்ட தரவுப் பொதிகளைக் குழப்பமின்றிப் பிழைதிருத்தம் செய்தல்

ஏதேனும் செயலிழக்கும்போது, சற்று நிதானமாகச் செயல்படுங்கள். முதலில், நீங்கள் கையாளும் தரவு எந்த வகை மற்றும் அது எங்கிருந்து வந்தது என்பதைக் கண்டறியுங்கள். அது பயனரின் கட்டுப்பாட்டில் உள்ளதா? அது ஒரு டோக்கனா? அது ஒரு இணைப்பா? அதை உங்கள் கணினியிலேயே ஆய்வு செய்வது பாதுகாப்பானதா?

பிழைதிருத்தத்தின் போது, முக்கியத்துவம் இல்லாத ஒரு மாதிரியை நீங்கள் மறைகுறியீடு நீக்க வேண்டியிருந்தால், நம்பகமான உள்ளூர் கருவியையோ அல்லது உங்களுக்குப் புரியும் ஒரு எளிய பயன்பாட்டையோ பயன்படுத்துங்கள். விரைவான சோதனைகளுக்கு, Base64 Encoder/Decoder போன்ற உலாவி அடிப்படையிலான உதவியாளர் பயனுள்ளதாக இருக்கும்; ஆனால், உங்கள் கொள்கைகள் அனுமதித்தால் தவிர, இரகசியங்களையோ அல்லது வாடிக்கையாளரின் தனிப்பட்ட தரவுகளையோ எந்தக் கருவியிலும் ஒட்டுவதைத் தவிர்க்கவும்.

உண்மையான மாதிரியின் அதே கட்டமைப்பைக் கொண்ட ஒரு போலி மாதிரியை உருவாக்க முயற்சி செய்யுங்கள். டோக்கன்களுக்குப் பதிலாக போலி மதிப்புகளை இடுங்கள். வாடிக்கையாளர் விவரங்களுக்குப் பதிலாக புனைந்த உரையை இடுங்கள். வடிவத்தை அப்படியே வைத்துக்கொண்டு, ஆபத்தை நீக்குங்கள். இது கூடுதல் வேலை போல் தோன்றலாம், ஆனால் இது உரையாடல்களில் உள்ள பிழைகளைச் சரிபார்ப்பதை மிகவும் பாதுகாப்பானதாக ஆக்குகிறது.

ஒரு எளிய மன சரிபார்ப்புப் பட்டியல்

• அசல் தரவு என்ன? குறியாக்கத்திற்கு முன் அது முக்கியமானதாக இருந்தால், குறியாக்கத்திற்குப் பிறகும் அது முக்கியமானதாகவே இருக்கும்.
• யாரால் இதை மாற்றியமைக்க முடியும்? இரகசியத் திறவுகோல் தேவையில்லை என்றால், யாராலும் முடியும் என்று கருதுங்கள்.
• இது ஏன் குறியாக்கம் செய்யப்பட்டுள்ளது? பரிமாற்றம், சேமிப்பு, உட்பொதித்தல், இணக்கத்தன்மை அல்லது வேறு ஏதேனும் காரணத்திற்காகவா?
• அது எங்கே பதிவு செய்யப்படுகிறது? பயன்பாட்டுப் பதிவுகள், ப்ராக்ஸி பதிவுகள், உலாவி கன்சோல்கள், செயலிழப்பு அறிக்கைகள் மற்றும் CI வெளியீடு ஆகியவற்றைச் சரிபார்க்கவும்.
• அதன் அளவு என்னவாக இருக்கலாம்? அது நினைவகச் சிக்கலாக மாறுவதற்கு முன்பே, வெளிப்புற உள்ளீட்டிற்கு வரம்புகளை நிர்ணயித்துக் கொள்ளுங்கள்.
• இரு அமைப்புகளும் ஒரே வகை மற்றும் எழுத்துக் குறியாக்கத்தைப் பயன்படுத்துகின்றனவா? மிகச் சிறிய வேறுபாடுகள் கூட மிகவும் சலிப்பூட்டும், அதிக செலவை உண்டாக்கும் பிழைகளை உருவாக்குகின்றன.

குறியாக்கம் செய்யப்பட்ட தரவு என்பது, ஏதேனும் ஒன்றைச் சேதப்படுத்தும் வரை அல்லது சங்கடமான இடத்தில் கசியும் வரை முக்கியத்துவம் வாய்ந்ததாகத் தோன்றாத அன்றாட மென்பொருள் உருவாக்க விவரங்களில் ஒன்றாகும். அதை அச்சத்துடன் அல்லாமல், சிறிதளவு சந்தேகத்துடன் கையாளுங்கள். முக்கியமான தரவுகளை அவை இருக்கக்கூடாத இடங்களில் வைக்காதீர்கள்; எது, ஏன் குறியாக்கம் செய்யப்பட்டுள்ளது என்பதில் தெளிவாக இருங்கள்; மேலும், படிக்க முடியாததாகத் தோன்றும் சரங்கள் உங்களை ஏமாற்றி, உங்கள் கவனத்தைக் குறைத்துக்கொள்ள அனுமதிக்காதீர்கள்.

பெரும்பாலான நேரங்களில், அதுவே போதுமானது. கச்சிதமானதோ, மாயாஜாலமானதோ அல்ல. செவ்வாய்க்கிழமையை ஒரு விபத்து அறிக்கையாக மாறிவிடாமல் தடுக்கும் வகையிலான ஒரு கவனமான பொறியியல் வேலை.