Tech Help
Base64 ਫਾਈਲਾਂ ਵੱਡੀਆਂ ਕਿਉਂ ਕਰਦਾ ਹੈ?
Base64 ਆਮ ਤੌਰ ਤੇ ਬਾਈਨਰੀ ਡਾਟਾ ਨੂੰ ਲਗਭਗ ਇੱਕ ਤਿਹਾਈ ਵੱਡਾ ਕਰਦਾ ਹੈ। 3 ਬਾਈਟ ਤੋਂ 4 ਅੱਖਰ ਦੀ ਬਣਤਰ, ਪੈਡਿੰਗ, Data URL ਦਾ ਵਾਧੂ ਭਾਰ, ਅਤੇ ਉਹ ਆਕਾਰ ਕਦੋਂ ਫਾਇਦੇਮੰਦ ਹੈ ਵੇਖੋ।
Base64 ਆਮ ਤੌਰ ਤੇ ਬਾਈਨਰੀ ਡਾਟਾ ਨੂੰ ਲਗਭਗ ਇੱਕ ਤਿਹਾਈ ਵੱਡਾ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਹਰ 3 ਬਾਈਨਰੀ ਬਾਈਟ ਨੂੰ 4 ਛਪਣਯੋਗ Base64 ਅੱਖਰਾਂ ਨਾਲ ਦਰਸਾਉਂਦਾ ਹੈ।
ਜੇ ਇਨਪੁੱਟ ਲੰਬਾਈ 3 ਦੀ ਠੀਕ ਗੁਣਜ ਨਹੀਂ, ਤਾਂ ਮਿਆਰੀ ਪੈਡਡ Base64 = ਅੱਖਰ ਜੋੜ ਸਕਦਾ ਹੈ। ਏਨਕੋਡ ਲੰਬਾਈ 4 × ceil(n / 3) ਹੈ, ਜਿੱਥੇ n ਅਸਲ ਬਾਈਟ ਲੰਬਾਈ ਹੈ।
«ਲਗਭਗ 33%» ਵੱਡੇ ਇਨਪੁੱਟ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਬਹੁਤ ਛੋਟੇ ਇਨਪੁੱਟ ਤੇ ਪੈਡਿੰਗ ਤੋਂ ਫੀਸਦ ਬਹੁਤ ਵੱਡਾ ਦਿਖ ਸਕਦਾ ਹੈ। Base64 ਸੰਕੁਚਨ ਨਹੀਂ। ਏਨਕੋਡਿੰਗ ਬਨਾਮ ਏਨਕ੍ਰਿਪਸ਼ਨ ਲਈ [Base64 ਏਨ੍ਕ੍ਰਿਪ੍ਸ਼ਨ ਨਹੀਂ: ਇਹ ਅਸਲ ਕੀ ਕਰ੍ਦਾ ਹੈ](/pa/story/base64-is-not-encryption) ਵੇਖੋ।
ਇਹ ਲੇਖ ਦੱਸਦਾ ਹੈ ਕਿ Base64 ਆਉਟਪੁੱਟ ਅਸਲ ਬਾਈਟਾਂ ਤੋਂ ਵੱਡਾ ਕਿਉਂ ਹੈ। ਇਹ ਸੁਰੱਖਿਆ ਗਾਈਡ ਨਹੀਂ। ਜੇ ਏਨਕੋਡਿੰਗ ਬਨਾਮ ਏਨਕ੍ਰਿਪਸ਼ਨ ਚਾਹੀਦੀ ਹੋਵੇ ਤਾਂ Base64 ਏਨ੍ਕ੍ਰਿਪ੍ਸ਼ਨ ਨਹੀਂ: ਇਹ ਅਸਲ ਕੀ ਕਰ੍ਦਾ ਹੈ ਵਰਤੋ।
Base64 ਨੂੰ ਵਧੇਰੇ ਥਾਂ ਕਿਉਂ ਚਾਹੀਦੀ ਹੈ?
3 ਬਾਈਟ 24 ਬਿਟ ਹਨ। Base64 ਉਨ੍ਹਾਂ 24 ਬਿਟ ਨੂੰ 6 ਬਿਟ ਦੇ 4 ਗਰੁੱਪਾਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ। ਹਰ ਗਰੁੱਪ ਇੱਕ Base64 ਅੱਖਰ ਨਾਲ ਜੁੜਦਾ ਹੈ, ਇਸ ਲਈ 3 ਇਨਪੁੱਟ ਬਾਈਟ 4 ਆਉਟਪੁੱਟ ਅੱਖਰ ਬਣਦੇ ਹਨ। ASCII ਅੱਖਰ ਪ੍ਰਤੀ 1 ਬਾਈਟ ਵਜੋਂ ਸੰਭਾਲਿਆ ਤਾਂ ਉਹ 4 / 3 ≈ 1.333 ਹੈ — ਲਗਭਗ 33.3% ਵਾਧਾ।
- 3 ਬਾਈਟ (24 ਬਿਟ)
- 6 ਬਿਟ ਦੇ 4 ਗਰੁੱਪਾਂ ਵਿੱਚ ਵੰਡੋ
- ਹਰ ਗਰੁੱਪ → ਇੱਕ Base64 ਅੱਖਰ
- 4 ਅੱਖਰ (ਅਕਸਰ ਲਿਖਤ ਦੇ 4 ਬਾਈਟ)
ਇੱਕ ਸਾਦਾ, ਜਾਂਚਯੋਗ ਉਦਾਹਰਨ
ਇਹ ਏਨਕੋਡਿੰਗਾਂ ਮਿਆਰੀ ਪੈਡਡ Base64 ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ।
Man
Man
Base64
TWFu
Man ਤਿੰਨ UTF-8/ASCII ਬਾਈਟ ਹਨ। TWFu ਚਾਰ ਅੱਖਰ ਹਨ: 3 → 4।
Hello
Hello
Base64
SGVsbG8=
Hello ਪੰਜ ਬਾਈਟ ਹੈ। SGVsbG8= ਅੱਠ ਅੱਖਰ ਹੈ, ਇੱਕ = ਸਮੇਤ। ਛੋਟੇ ਡਾਟਾ ਤੇ ਪੈਡਿੰਗ ਫੀਸਦ ਨੂੰ 33% ਤੋਂ ਵੱਡਾ ਦਿਖਾਉਂਦੀ ਹੈ।
Base64 ਆਕਾਰ ਕਿਵੇਂ ਕੱਢੀਏ?
ਮਿਆਰੀ ਪੈਡਡ Base64 ਲਈ, encodedLength = 4 × ceil(originalBytes / 3).
| ਅਸਲ ਬਾਈਟ | Base64 ਅੱਖਰ |
|---|---|
| 1 | 4 |
| 2 | 4 |
| 3 | 4 |
| 4 | 8 |
| 5 | 8 |
| 6 | 8 |
1 ਜਾਂ 2 ਬਾਈਟ ਫਿਰ ਵੀ 4 ਅੱਖਰ ਦਿੰਦੇ ਹਨ। ਫਾਰਮੂਲਾ ਵਰਤੋ, ਤੈਅ 33% ਨਹੀਂ।
«=» ਪੈਡਿੰਗ ਦਾ ਕੀ ਅਰਥ ਹੈ?
= ਨਿਸ਼ਾਨ ਦੱਸਦਾ ਹੈ ਕਿ ਆਖਰੀ 3-ਬਾਈਟ ਖੰਡ ਭਰਿਆ ਨਹੀਂ ਸੀ। 1 ਇਨਪੁੱਟ ਬਾਈਟ ਦੋ = ਅੱਖਰ ਵਰਤਦਾ ਹੈ; 2 ਬਾਈਟ ਇੱਕ; 3 ਬਾਈਟ ਕੋਈ ਨਹੀਂ। ਪੈਡਿੰਗ ਏਨਕ੍ਰਿਪਸ਼ਨ ਜਾਂ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ।
ਕੀ Base64URL ਘੱਟ ਥਾਂ ਲੈਂਦਾ ਹੈ?
Base64URL + ਨੂੰ - ਅਤੇ / ਨੂੰ _ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ Base64 ਐਨਕੋਡ ਏਨਕੋਡ ਤੇ ਅੰਤਲੇ = ਛੱਡ ਦਿੰਦਾ ਹੈ। ਉਨ੍ਹਾਂ = ਅੱਖਰਾਂ ਜਿੰਨੀ ਸਟ੍ਰਿੰਗ ਛੋਟੀ ਹੋ ਸਕਦੀ ਹੈ। 3 ਬਾਈਟ → 4 ਅੱਖਰ ਦੀ ਬਣਤਰ ਉਹੀ ਰਹਿੰਦੀ ਹੈ, ਇਸ ਲਈ Base64URL ਵਧੇਰੇ ਥਾਂ-ਕੁਸ਼ਲ ਬਾਈਨਰੀ ਫਾਰਮੈਟ ਨਹੀਂ।
ਛੋਟਾ ਇਨਪੁੱਟ 33% ਤੋਂ ਵੱਧ ਕਿਉਂ ਵਧ ਸਕਦਾ ਹੈ?
1 ਬਾਈਟ → 4 ਅੱਖਰ ਲੰਬਾਈ ਵਿੱਚ 300% ਵਾਧਾ ਹੈ। 2 ਬਾਈਟ → 4 ਹੈ 100%। 3 ਬਾਈਟ → 4 ਲਗਭਗ 33.3% ਹੈ। ਜਿਵੇਂ n ਵਧੇ, ਪੈਡਿੰਗ ਘੱਟ ਮਾਅਨੇ ਰੱਖਦੀ ਹੈ ਅਤੇ ਵਾਧੂ ਭਾਰ ਲਗਭਗ 33% ਕੋਲ ਆਉਂਦਾ ਹੈ। Base64 ਹਰ ਵਾਰ ਠੀਕ 33% ਵੱਡਾ ਨਹੀਂ ਹੁੰਦਾ।
Base64 Data URL ਹੋਰ ਵੱਡੀ ਕਿਉਂ ਹੁੰਦੀ ਹੈ?
Data URL ਪੇਲੋਡ ਤੋਂ ਪਹਿਲਾਂ data:image/png;base64, ਵਰਗਾ ਅਗੇਤਰ ਜੋੜਦੀ ਹੈ। ਬਹੁਤ ਛੋਟੀ ਫਾਈਲ ਤੇ ਉਹ ਅਗੇਤਰ ਫੀਸਦ ਤੇ ਹਾਵੀ ਹੋ ਸਕਦਾ ਹੈ। Base64 ਐਨਕੋਡ ਕੱਚਾ Base64 ਜਾਂ Data URL ਦੇ ਸਕਦਾ ਹੈ; Data URL ਆਉਟਪੁੱਟ ਮਿਆਰੀ ਵਰਣਮਾਲਾ ਵਰਤਦਾ ਹੈ।
Base64 ਬਨਾਮ ਬਾਈਨਰੀ: ਕਿਹੜਾ ਛੋਟਾ ਹੈ?
ਕੱਚਾ ਬਾਈਨਰੀ ਢੋਆ-ਢੁਆਈ ਅਤੇ ਭੰਡਾਰਨ ਲਈ ਥਾਂ ਵਿੱਚ ਵਧੇਰੇ ਕੁਸ਼ਲ ਹੈ। Base64 ਵੱਡਾ ਹੈ, ਪਰ JSON, ਈਮੇਲ ਅਤੇ ਸਿਰਫ-ਲਿਖਤ ਰਾਹਾਂ ਵਿੱਚ ਲਿਖਤ-ਸੁਰੱਖਿਅਤ ਹੈ। ਇਹ ਬਾਈਨਰੀ-ਤੋਂ-ਲਿਖਤ ਏਨਕੋਡਿੰਗ ਹੈ, ਸੰਕੁਚਨ ਨਹੀਂ।
ਕੀ Base64 ਫਾਈਲਾਂ ਸੰਕੁਚਿਤ ਕਰਦਾ ਹੈ?
ਨਹੀਂ। Base64 ਸੰਕੁਚਨ ਫਾਰਮੈਟ ਨਹੀਂ। ਏਨਕੋਡ ਕੀਤੀ ਲਿਖਤ ਆਮ ਤੌਰ ਤੇ ਅਸਲ ਬਾਈਟਾਂ ਤੋਂ ਵੱਡੀ ਹੁੰਦੀ ਹੈ। ਜੇ ਬਾਅਦ ਵਿੱਚ ਉਸ ਲਿਖਤ ਤੇ gzip ਜਾਂ Brotli ਲਾਓ ਤਾਂ ਕੁਝ ਦੁਹਰਾਅ ਸੁੰਗੜ ਸਕਦਾ ਹੈ—ਨਤੀਜਾ ਡਾਟਾ ਅਤੇ ਸੰਕੁਚਕ ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। gzip Base64 ਦਾ ਵਾਧੂ ਭਾਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਹਟਾਉਂਦਾ।
ਜੇ Base64 ਤੇ gzip ਲੱਗੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?
HTTP ਸੰਕੁਚਨ Base64 ਲਿਖਤ ਵਿੱਚ ਕੁਝ ਦੁਹਰਾਏ ਪੈਟਰਨ ਘਟਾ ਸਕਦਾ ਹੈ। JPEG, PNG ਜਾਂ ZIP ਕੱਚੇ ਬਾਈਟ ਵਜੋਂ ਵੀ ਅਕਸਰ ਮਾੜੇ ਸੰਕੁਚਿਤ ਹੁੰਦੇ ਹਨ, ਅਤੇ Base64-ਫਿਰ-gzip ਹਾਲੇ ਮਾਮਲੇ ਤੇ ਨਿਰਭਰ ਹੈ। gzip ਤੋਂ ਬਾਅਦ ਕੋਈ ਵਿਆਪਕ ਵਾਧੂ ਫੀਸਦ ਨਹੀਂ।
ਕੀ ਫਾਈਲਾਂ Base64 ਵਜੋਂ ਰੱਖਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ?
Base64 ਬਾਈਨਰੀ ਨੂੰ JSON ਖੇਤਰ, ਛੋਟੀ ਇਨਲਾਈਨ ਸੰਪਤੀ, ਸਿਰਫ-ਲਿਖਤ API, ਕਾਪੀ/ਪੇਸਟ, ਜਾਂ Data URL ਵਿੱਚ ਬਿਠਾ ਸਕਦਾ ਹੈ। ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਤੇ ਭੰਡਾਰਨ, ਮੈਮੋਰੀ ਅਤੇ ਪੇਲੋਡ ਆਕਾਰ ਸਭ ਵਧਦੇ ਹਨ। ਇਸਦਾ ਮਤਲਬ «ਫਾਈਲਾਂ ਲਈ Base64 ਕਦੇ ਨਾ ਵਰਤੋ» ਨਹੀਂ।
JSON API ਵਿੱਚ Base64 ਆਮ ਕਿਉਂ ਹੈ?
JSON ਵਿੱਚ ਮੂਲ ਕੱਚਾ-ਬਾਈਨਰੀ ਕਿਸਮ ਨਹੀਂ, ਇਸ ਲਈ API ਅਕਸਰ ਬਾਈਟ Base64 ਸਟ੍ਰਿੰਗ ਵਿੱਚ ਰੱਖਦੇ ਹਨ। ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਲਈ multipart/form-data, ਆਬਜੈਕਟ ਭੰਡਾਰਨ, ਜਾਂ ਸਿੱਧਾ ਬਾਈਨਰੀ ਅਪਲੋਡ ਵਧੀਆ ਫਿੱਟ ਹੋ ਸਕਦਾ ਹੈ। ਕੋਈ ਵਿਕਲਪ ਹਮੇਸ਼ਾ ਸਭ ਤੋਂ ਵਧੀਆ ਨਹੀਂ।
ਈਮੇਲ ਵਿੱਚ Base64 ਕਿਉਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ?
MIME ਬਾਈਨਰੀ ਅਟੈਚਮੈਂਟ ਨੂੰ ਲਿਖਤ-ਸੁਰੱਖਿਅਤ ਅੱਖਰਾਂ ਵਜੋਂ ਯਾਤਰਾ ਕਰਵਾਉਣ ਲਈ Base64 ਵਰਤ ਸਕਦਾ ਹੈ। ਉਹੀ ਆਕਾਰ ਦਾ ਵਾਧੂ ਭਾਰ ਲਾਗੂ ਰਹਿੰਦਾ ਹੈ। ਇਹ ਆਵਾਜਾਈ ਪ੍ਰਤੀਨਿਧਤਾ ਹੈ, ਛੋਟੀ ਫਾਈਲ ਨਹੀਂ।
ਵਾਧੂ ਆਕਾਰ ਕਦੋਂ ਫਾਇਦੇਮੰਦ ਹੈ?
ਵਾਧੂ ਆਕਾਰ ਉਦੋਂ ਫਾਇਦੇਮੰਦ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਬਾਈਨਰੀ ਲਿਖਤ ਅੰਦਰ ਬੈਠਣੀ ਹੋਵੇ, ਪੇਲੋਡ ਛੋਟਾ ਹੋਵੇ, API Base64 ਮੰਗੇ, ਜਾਂ Data URL ਚਾਹੀਦੀ ਹੋਵੇ। ਵੱਡੇ ਮੀਡੀਆ ਲਈ ਜਦੋਂ ਸਿਸਟਮ ਇਜਾਜ਼ਤ ਦੇਵੇ ਤਾਂ ਕੱਚਾ ਬਾਈਨਰੀ ਚੁਣੋ।
Base64 ਕਦੋਂ ਛੱਡਣਾ ਚਾਹੀਦਾ ਹੈ?
ਵੱਡੀਆਂ ਫਾਈਲਾਂ, ਤੰਗ ਬੈਂਡਵਿਡਥ, ਵਾਰ-ਵਾਰ ਤਬਾਦਲਾ, ਜਾਂ ਜਦੋਂ ਬਾਈਨਰੀ ਰਾਹ ਪਹਿਲਾਂ ਹੀ ਹੋਵੇ ਤਾਂ ਛੱਡੋ—ਹਾਲਾਤ ਅਨੁਸਾਰ, «Base64 ਮਾੜੀ ਪ੍ਰਥਾ ਹੈ» ਨਹੀਂ।
ਪੈਡਡ Base64 ਲੰਬਾਈਆਂ ਜੋ ਤੁਸੀਂ ਜਾਂਚ ਸਕਦੇ ਹੋ
ਅਸਲ ਬਾਈਟ ਗਿਣਤੀਆਂ ਅਤੇ ਮਿਆਰੀ ਪੈਡਡ Base64 ਅੱਖਰ ਗਿਣਤੀਆਂ:
| ਅਸਲ ਬਾਈਟ | Base64 ਅੱਖਰ |
|---|---|
| 1 | 4 |
| 2 | 4 |
| 3 | 4 |
| 10 | 16 |
| 100 | 136 |
| 1,000 | 1,336 |
ਸਾਰੀਆਂ ਕਤਾਰਾਂ 4 × ceil(n / 3) ਦੀ ਪਾਲਣਾ ਕਰਦੀਆਂ ਹਨ। ਇਹ Base64 ਅੱਖਰ ਗਿਣਤੀਆਂ ਹਨ।
ਉਦਾਹਰਨ: 1,000 ਬਾਈਟ ਫਾਈਲ ਕਿੰਨੀ ਵੱਡੀ ਹੋਵੇਗੀ?
4 × ceil(1000 / 3). ceil(333.333…) = 334, ਅਤੇ 4 × 334 = 1336। ਤਾਂ 1,000 ਬਾਈਟ 1,336 Base64 ਅੱਖਰ ਬਣਦੇ ਹਨ। UTF-8/ASCII ਵਜੋਂ ਸੰਭਾਲਿਆ ਤਾਂ ਹਰ ਅੱਖਰ ਆਮ ਤੌਰ ਤੇ 1 ਬਾਈਟ ਹੈ—1,336 ਨੂੰ ਮੈਮੋਰੀ ਵਿੱਚ ਠੀਕ ਬਾਈਟ ਗਿਣਤੀ ਨਾ ਮੰਨੋ।
ਕੀ Base64 ਫਾਈਲ ਆਕਾਰ ਤੋਂ ਵੱਧ ਮੈਮੋਰੀ ਲੈ ਸਕਦਾ ਹੈ?
ਕੁਝ ਰਨਟਾਈਮ ਸਟ੍ਰਿੰਗ ਨੂੰ ਅੱਖਰ ਪ੍ਰਤੀ 1 ਬਾਈਟ ਤੋਂ ਵੱਧ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਏਨਕੋਡ/ਡਿਕੋਡ ਬਫਰ ਅਤੇ ਸਟ੍ਰਿੰਗ ਇਕੱਠੇ ਰੱਖ ਸਕਦੇ ਹਨ। ਮੈਮੋਰੀ ਵਰਤੋਂ ਠੀਕ ਅੱਖਰ ਲੰਬਾਈ ਨਹੀਂ।
ਆਕਾਰ ਦੀ ਸਾਦੀ ਫੈਸਲਾ ਗਾਈਡ
ਜੇ ਸਿਸਟਮ ਕੱਚਾ ਬਾਈਨਰੀ ਮੰਨਦਾ ਹੋਵੇ ਤਾਂ ਆਕਾਰ ਲਈ ਉਹ ਚੁਣੋ। ਜੇ ਸਿਰਫ ਲਿਖਤ ਇਜਾਜ਼ਤ ਹੋਵੇ ਤਾਂ Base64 ਫਿੱਟ ਹੋ ਸਕਦਾ ਹੈ। ਵੱਡੇ ਪੇਲੋਡ ਤੇ ਬਾਈਨਰੀ ਅਪਲੋਡ ਰਾਹ ਵੇਖੋ। URL-ਸੁਰੱਖਿਅਤ ਲਿਖਤ ਲਈ Base64URL ਸੋਚੋ—3 ਤੋਂ 4 ਫੈਲਾਅ ਰਹਿੰਦਾ ਹੈ।
- ਬਾਈਨਰੀ ਡਾਟਾ ਭੇਜਣਾ ਹੈ
- ਕੱਚਾ ਬਾਈਨਰੀ ਇਜਾਜ਼ਤ? ਆਕਾਰ ਲਈ ਬਾਈਨਰੀ ਚੁਣੋ
- ਸਿਰਫ-ਲਿਖਤ ਖੇਤਰ? Base64 ਉਚਿਤ ਹੋ ਸਕਦਾ ਹੈ
- ਵੱਡਾ ਪੇਲੋਡ? ਬਾਈਨਰੀ ਅਪਲੋਡ ਰਾਹ ਵੇਖੋ
- URL-ਸੁਰੱਖਿਅਤ ਲਿਖਤ ਚਾਹੀਦੀ? Base64URL ਸੋਚੋ
- ਵੱਡੇ ਇਨਪੁੱਟ ਤੇ ਲਗਭਗ 33% ਵਧੇਰੇ ਲਿਖਤ ਦੀ ਉਮੀਦ ਕਰੋ
Base64 ਡਾਟਾ ਛੋਟਾ ਕਰਨ ਲਈ ਨਹੀਂ ਬਣਿਆ। ਇਹ ਬਾਈਨਰੀ ਨੂੰ ਲਿਖਤ-ਆਧਾਰਿਤ ਸਿਸਟਮਾਂ ਵਿੱਚ ਦਿਖਾਉਣਾ ਸੌਖਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੀਮਤ ਵਾਧੂ ਆਕਾਰ ਹੈ।
ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ Base64 ਏਨਕੋਡ ਜਾਂ ਡਿਕੋਡ ਕਰੋ
NEXNARA Base64 ਐਨਕੋਡ ਲਿਖਤ ਏਨਕੋਡ ਅਤੇ ਡਿਕੋਡ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਾਈਲ ਨੂੰ Base64 ਜਾਂ Data URL ਬਣਾ ਸਕਦਾ ਹੈ ਤੇ Base64 ਨੂੰ ਫਾਈਲ ਵਿੱਚ ਮੋੜ ਸਕਦਾ ਹੈ।
ਲਿਖਤ UTF-8 ਬਾਈਟ ਫਿਰ Base64 ਵਰਤਦੀ ਹੈ—ਸਿਰਫ ASCII ਨਹੀਂ। Standard ਜਾਂ Base64URL ਚੁਣੋ। ਫਾਈਲ ਆਉਟਪੁੱਟ ਕੱਚਾ Base64 ਜਾਂ Data URL ਹੋ ਸਕਦੀ ਹੈ (ਮਿਆਰੀ ਵਰਣਮਾਲਾ)। ਗਲਤ ਇਨਪੁੱਟ ਰੱਦ ਹੁੰਦਾ ਹੈ। ਗੈਰ-UTF-8 ਬਾਈਟ ਨੂੰ ਫਾਈਲ ਚਾਹੀਦੀ ਹੈ, ਲਿਖਤ ਡਿਕੋਡ ਨਹੀਂ।
10 MB ਤੋਂ ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਟੈਬ ਹੌਲੀ ਕਰ ਸਕਦੀਆਂ ਹਨ (ਚੇਤਾਵਨੀ)। 32 MB ਤੋਂ ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਰੋਕੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
ਏਨਕੋਡਿੰਗ ਅਤੇ ਡਿਕੋਡਿੰਗ ਤੁਹਾਡੇ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਹੁੰਦੀ ਹੈ। ਇਸ ਸੰਦ ਲਈ ਫਾਈਲ NEXNARA ਸਰਵਰ ਤੇ ਨਹੀਂ ਭੇਜੀ ਜਾਂਦੀ। ਇਸ਼ਤਿਹਾਰ ਅਤੇ ਹੋਰ ਸਾਈਟ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਾਲੇ ਨੈੱਟਵਰਕ ਵਰਤਦੀਆਂ ਹਨ।
Base64 ਐਨਕੋਡ ਵਿੱਚ ਲਿਖਤ ਜਾਂ ਫਾਈਲ ਚਿਪਕਾਓ ਅਤੇ ਅਸਲ ਬਾਈਟਾਂ ਦੀ ਤੁਲਨਾ ਏਨਕੋਡ ਲੰਬਾਈ ਨਾਲ ਕਰੋ।
FAQ
Base64 ਫਾਈਲ ਆਕਾਰ ਕਿਉਂ ਵਧਾਉਂਦਾ ਹੈ?
ਇਹ 3 ਬਾਈਟ (24 ਬਿਟ) ਨੂੰ 4 ਅੱਖਰਾਂ (4 × 6 ਬਿਟ) ਤੇ ਮੈਪ ਕਰਦਾ ਹੈ। ਲਿਖਤ ਵਜੋਂ ਸੰਭਾਲਿਆ ਤਾਂ ਵੱਡੇ ਇਨਪੁੱਟ ਤੇ ਲਗਭਗ ਇੱਕ ਤਿਹਾਈ ਵਧੇਰੇ ਹੈ।
ਕੀ Base64 ਹਮੇਸ਼ਾ 33% ਵੱਡਾ ਹੁੰਦਾ ਹੈ?
ਨਹੀਂ। ਵੱਡੇ ਇਨਪੁੱਟ ਲਗਭਗ 33.3% ਕੋਲ ਆਉਂਦੇ ਹਨ। ਬਹੁਤ ਛੋਟੇ ਇਨਪੁੱਟ ਪੈਡਿੰਗ ਤੋਂ ਵੱਧ ਵਧ ਸਕਦੇ ਹਨ। 4 × ceil(n / 3) ਵਰਤੋ।
Base64 ਬਾਈਨਰੀ ਤੋਂ ਕਿੰਨਾ ਵੱਡਾ ਹੈ?
ਮਿਆਰੀ ਪੈਡਡ ਲੰਬਾਈ 4 × ceil(n / 3) ਅੱਖਰ ਹੈ। Data URL ਅਗੇਤਰ ਹੋਰ ਜੋੜਦਾ ਹੈ।
ਕੀ Base64 ਸੰਕੁਚਨ ਫਾਈਲ ਆਕਾਰ ਘਟਾਉਂਦਾ ਹੈ?
Base64 ਸੰਕੁਚਿਤ ਨਹੀਂ ਕਰਦਾ। ਏਨਕੋਡ ਕੀਤੀ ਲਿਖਤ ਤੇ gzip ਜਾਂ Brotli ਕੁਝ ਸੁੰਗੜ ਸਕਦੇ ਹਨ; ਹਰ ਮਾਮਲੇ ਵਿੱਚ ਵਾਧੂ ਭਾਰ ਨਹੀਂ ਮਿਟਾਉਂਦੇ।
ਕੀ Base64URL ਘੱਟ ਥਾਂ ਲੈਂਦਾ ਹੈ?
ਇਹ = ਪੈਡਿੰਗ ਛੱਡ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਸਟ੍ਰਿੰਗ 0–2 ਅੱਖਰ ਛੋਟੀ ਹੋ ਸਕਦੀ ਹੈ। 3 ਤੋਂ 4 ਏਨਕੋਡਿੰਗ ਬਣਤਰ ਉਹੀ ਹੈ।
ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਲਈ Base64 ਵਰਤਾਂ?
ਸਿਰਫ ਜੇ ਲਿਖਤ ਚਾਹੀਦੀ ਹੋਵੇ। ਵੱਡੇ ਜਾਂ ਵਾਰ-ਵਾਰ ਤਬਾਦਲੇ ਤੇ ਬਾਈਨਰੀ ਰਾਹ ਅਕਸਰ ਛੋਟਾ ਹੁੰਦਾ ਹੈ। API ਲਈ Base64 ਹਮੇਸ਼ਾ ਗਲਤ ਨਹੀਂ।