ਇੱਕ ਹੋਰ ਬਾਈਕ: ਅਸੀਂ ਯੂਨੀਕੋਡ ਸਟ੍ਰਿੰਗਾਂ ਨੂੰ UTF-30 ਨਾਲੋਂ 60-8% ਵਧੇਰੇ ਸੰਖੇਪ ਸਟੋਰ ਕਰਦੇ ਹਾਂ

ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਡਿਵੈਲਪਰ ਹੋ ਅਤੇ ਤੁਹਾਨੂੰ ਇੱਕ ਏਨਕੋਡਿੰਗ ਦੀ ਚੋਣ ਕਰਨ ਦੇ ਕੰਮ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈ ਰਿਹਾ ਹੈ, ਤਾਂ ਯੂਨੀਕੋਡ ਲਗਭਗ ਹਮੇਸ਼ਾ ਸਹੀ ਹੱਲ ਹੋਵੇਗਾ। ਖਾਸ ਨੁਮਾਇੰਦਗੀ ਵਿਧੀ ਸੰਦਰਭ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਪਰ ਅਕਸਰ ਇੱਥੇ ਵੀ ਇੱਕ ਵਿਆਪਕ ਜਵਾਬ ਹੁੰਦਾ ਹੈ - UTF-8। ਇਸ ਬਾਰੇ ਚੰਗੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹ ਤੁਹਾਨੂੰ ਬਿਨਾਂ ਖਰਚ ਕੀਤੇ ਸਾਰੇ ਯੂਨੀਕੋਡ ਅੱਖਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਬਾਈਟਸ। ਇਹ ਸੱਚ ਹੈ, ਉਹਨਾਂ ਭਾਸ਼ਾਵਾਂ ਲਈ ਜੋ ਸਿਰਫ਼ ਲਾਤੀਨੀ ਵਰਣਮਾਲਾ ਤੋਂ ਵੱਧ ਵਰਤਦੀਆਂ ਹਨ, “ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਹੀਂ” ਘੱਟੋ-ਘੱਟ ਦੋ ਬਾਈਟ ਪ੍ਰਤੀ ਅੱਖਰ. ਕੀ ਅਸੀਂ ਪੂਰਵ-ਇਤਿਹਾਸਕ ਏਨਕੋਡਿੰਗਾਂ 'ਤੇ ਵਾਪਸ ਪਰਤੇ ਬਿਨਾਂ ਬਿਹਤਰ ਕਰ ਸਕਦੇ ਹਾਂ ਜੋ ਸਾਨੂੰ ਸਿਰਫ਼ 256 ਉਪਲਬਧ ਅੱਖਰਾਂ ਤੱਕ ਸੀਮਤ ਕਰਦੇ ਹਨ?

ਹੇਠਾਂ ਮੈਂ ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਅਤੇ ਇੱਕ ਮੁਕਾਬਲਤਨ ਸਧਾਰਨ ਐਲਗੋਰਿਦਮ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਮੇਰੀ ਕੋਸ਼ਿਸ਼ ਨਾਲ ਆਪਣੇ ਆਪ ਨੂੰ ਜਾਣੂ ਕਰਵਾਉਣ ਦਾ ਪ੍ਰਸਤਾਵ ਦਿੰਦਾ ਹਾਂ ਜੋ ਤੁਹਾਨੂੰ UTF-8 ਵਿੱਚ ਰਿਡੰਡੈਂਸੀ ਨੂੰ ਸ਼ਾਮਲ ਕੀਤੇ ਬਿਨਾਂ ਦੁਨੀਆ ਦੀਆਂ ਜ਼ਿਆਦਾਤਰ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਲਾਈਨਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਬੇਦਾਅਵਾ। ਮੈਂ ਤੁਰੰਤ ਕੁਝ ਮਹੱਤਵਪੂਰਨ ਰਿਜ਼ਰਵੇਸ਼ਨ ਕਰਾਂਗਾ: ਵਰਣਿਤ ਹੱਲ UTF-8 ਲਈ ਇੱਕ ਵਿਆਪਕ ਬਦਲ ਵਜੋਂ ਪੇਸ਼ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਇਹ ਸਿਰਫ ਕੇਸਾਂ ਦੀ ਇੱਕ ਤੰਗ ਸੂਚੀ ਵਿੱਚ ਢੁਕਵਾਂ ਹੈ (ਹੇਠਾਂ ਉਹਨਾਂ 'ਤੇ ਹੋਰ), ਅਤੇ ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ ਇਸਦੀ ਵਰਤੋਂ ਤੀਜੀ-ਧਿਰ APIs (ਜੋ ਇਸ ਬਾਰੇ ਵੀ ਨਹੀਂ ਜਾਣਦੇ) ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਨ ਲਈ ਨਹੀਂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ। ਬਹੁਤੇ ਅਕਸਰ, ਆਮ-ਉਦੇਸ਼ ਕੰਪਰੈਸ਼ਨ ਐਲਗੋਰਿਦਮ (ਉਦਾਹਰਨ ਲਈ, ਡੀਫਲੇਟ) ਟੈਕਸਟ ਡੇਟਾ ਦੀ ਵੱਡੀ ਮਾਤਰਾ ਦੇ ਸੰਖੇਪ ਸਟੋਰੇਜ ਲਈ ਢੁਕਵੇਂ ਹੁੰਦੇ ਹਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਪਹਿਲਾਂ ਹੀ ਮੇਰੇ ਹੱਲ ਨੂੰ ਬਣਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ, ਮੈਨੂੰ ਯੂਨੀਕੋਡ ਵਿੱਚ ਇੱਕ ਮੌਜੂਦਾ ਮਿਆਰ ਮਿਲਿਆ ਹੈ, ਜੋ ਉਸੇ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ - ਇਹ ਕੁਝ ਹੋਰ ਗੁੰਝਲਦਾਰ (ਅਤੇ ਅਕਸਰ ਬਦਤਰ) ਹੁੰਦਾ ਹੈ, ਪਰ ਫਿਰ ਵੀ ਇਹ ਇੱਕ ਪ੍ਰਵਾਨਿਤ ਮਿਆਰ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਪਾ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਗੋਡੇ 'ਤੇ ਇਕੱਠੇ. ਮੈਂ ਤੁਹਾਨੂੰ ਉਸ ਬਾਰੇ ਵੀ ਦੱਸਾਂਗਾ।

ਯੂਨੀਕੋਡ ਅਤੇ UTF-8 ਬਾਰੇ

ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਇਹ ਕੀ ਹੈ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ ਯੂਨੀਕੋਡ и UTF- 8.

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ, 8-ਬਿੱਟ ਏਨਕੋਡਿੰਗ ਪ੍ਰਸਿੱਧ ਹੁੰਦੇ ਸਨ। ਉਹਨਾਂ ਦੇ ਨਾਲ, ਸਭ ਕੁਝ ਸਧਾਰਨ ਸੀ: 256 ਅੱਖਰਾਂ ਨੂੰ 0 ਤੋਂ 255 ਤੱਕ ਦੇ ਅੰਕਾਂ ਨਾਲ ਗਿਣਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ 0 ਤੋਂ 255 ਤੱਕ ਦੀਆਂ ਸੰਖਿਆਵਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਇੱਕ ਬਾਈਟ ਵਜੋਂ ਦਰਸਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਅਸੀਂ ਸ਼ੁਰੂ ਵਿੱਚ ਵਾਪਸ ਜਾਂਦੇ ਹਾਂ, ਤਾਂ ASCII ਏਨਕੋਡਿੰਗ ਪੂਰੀ ਤਰ੍ਹਾਂ 7 ਬਿੱਟਾਂ ਤੱਕ ਸੀਮਿਤ ਹੈ, ਇਸਲਈ ਇਸਦੀ ਬਾਈਟ ਪ੍ਰਤੀਨਿਧਤਾ ਵਿੱਚ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਬਿੱਟ ਜ਼ੀਰੋ ਹੈ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ 8-ਬਿੱਟ ਏਨਕੋਡਿੰਗ ਇਸਦੇ ਅਨੁਕੂਲ ਹਨ (ਉਹ ਸਿਰਫ "ਉੱਪਰ" ਵਿੱਚ ਵੱਖਰੇ ਹਨ। ਹਿੱਸਾ, ਜਿੱਥੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਬਿੱਟ ਇੱਕ ਹੈ)।

ਯੂਨੀਕੋਡ ਉਹਨਾਂ ਏਨਕੋਡਿੰਗਾਂ ਤੋਂ ਕਿਵੇਂ ਵੱਖਰਾ ਹੈ ਅਤੇ ਇਸ ਨਾਲ ਬਹੁਤ ਸਾਰੀਆਂ ਖਾਸ ਪੇਸ਼ਕਾਰੀਆਂ ਕਿਉਂ ਜੁੜੀਆਂ ਹਨ - UTF-8, UTF-16 (BE ਅਤੇ LE), UTF-32? ਆਓ ਇਸਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਕ੍ਰਮਬੱਧ ਕਰੀਏ.

ਮੂਲ ਯੂਨੀਕੋਡ ਸਟੈਂਡਰਡ ਕੇਵਲ ਅੱਖਰਾਂ (ਅਤੇ ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਅੱਖਰਾਂ ਦੇ ਵਿਅਕਤੀਗਤ ਭਾਗਾਂ) ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਸੰਖਿਆਵਾਂ ਵਿਚਕਾਰ ਪੱਤਰ ਵਿਹਾਰ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਅਤੇ ਇਸ ਸਟੈਂਡਰਡ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਸੰਭਾਵਿਤ ਸੰਖਿਆਵਾਂ ਹਨ - ਤੋਂ 0x00 ਨੂੰ 0x10FFFF (1 ਟੁਕੜੇ)। ਜੇਕਰ ਅਸੀਂ ਅਜਿਹੀ ਰੇਂਜ ਵਿੱਚ ਇੱਕ ਸੰਖਿਆ ਨੂੰ ਇੱਕ ਵੇਰੀਏਬਲ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਤਾਂ ਸਾਡੇ ਲਈ ਨਾ ਤਾਂ 114 ਅਤੇ ਨਾ ਹੀ 112 ਬਾਈਟ ਕਾਫ਼ੀ ਹੋਣਗੇ। ਅਤੇ ਕਿਉਂਕਿ ਸਾਡੇ ਪ੍ਰੋਸੈਸਰ ਤਿੰਨ-ਬਾਈਟ ਨੰਬਰਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਕੀਤੇ ਗਏ ਹਨ, ਸਾਨੂੰ ਪ੍ਰਤੀ ਅੱਖਰ 1 ਬਾਈਟ ਵਰਤਣ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਜਾਵੇਗਾ! ਇਹ UTF-2 ਹੈ, ਪਰ ਇਹ ਬਿਲਕੁਲ ਇਸ "ਬਰਬਾਦੀ" ਦੇ ਕਾਰਨ ਹੈ ਕਿ ਇਹ ਫਾਰਮੈਟ ਪ੍ਰਸਿੱਧ ਨਹੀਂ ਹੈ।

ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਯੂਨੀਕੋਡ ਦੇ ਅੰਦਰ ਅੱਖਰਾਂ ਦਾ ਕ੍ਰਮ ਬੇਤਰਤੀਬ ਨਹੀਂ ਹੈ। ਉਨ੍ਹਾਂ ਦੇ ਪੂਰੇ ਸੈੱਟ ਨੂੰ 17 ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ"ਜਹਾਜ਼", ਜਿਸ ਵਿੱਚ ਹਰੇਕ ਵਿੱਚ 65536 (0x10000) "ਕੋਡ ਪੁਆਇੰਟ" ਇੱਥੇ ਇੱਕ "ਕੋਡ ਪੁਆਇੰਟ" ਦੀ ਧਾਰਨਾ ਸਧਾਰਨ ਹੈ ਅੱਖਰ ਨੰਬਰ, ਯੂਨੀਕੋਡ ਦੁਆਰਾ ਇਸ ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਪਰ, ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਯੂਨੀਕੋਡ ਵਿੱਚ ਨਾ ਸਿਰਫ਼ ਵਿਅਕਤੀਗਤ ਅੱਖਰਾਂ ਦੀ ਗਿਣਤੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਸਗੋਂ ਉਹਨਾਂ ਦੇ ਭਾਗ ਅਤੇ ਸੇਵਾ ਚਿੰਨ੍ਹ ਵੀ ਹੁੰਦੇ ਹਨ (ਅਤੇ ਕਈ ਵਾਰ ਕੁਝ ਵੀ ਸੰਖਿਆ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ - ਸ਼ਾਇਦ ਕੁਝ ਸਮੇਂ ਲਈ, ਪਰ ਸਾਡੇ ਲਈ ਇਹ ਇੰਨਾ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ), ਇਸ ਲਈ ਇਹ ਵਧੇਰੇ ਸਹੀ ਹੈ ਹਮੇਸ਼ਾ ਖਾਸ ਤੌਰ 'ਤੇ ਸੰਖਿਆਵਾਂ ਦੀ ਗਿਣਤੀ ਬਾਰੇ ਗੱਲ ਕਰੋ, ਨਾ ਕਿ ਪ੍ਰਤੀਕਾਂ ਬਾਰੇ। ਹਾਲਾਂਕਿ, ਨਿਮਨਲਿਖਤ ਵਿੱਚ, ਸੰਖੇਪਤਾ ਦੀ ਖ਼ਾਤਰ, ਮੈਂ ਅਕਸਰ "ਕੋਡ ਪੁਆਇੰਟ" ਸ਼ਬਦ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹੋਏ, "ਪ੍ਰਤੀਕ" ਸ਼ਬਦ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗਾ।

ਯੂਨੀਕੋਡ ਜਹਾਜ਼। ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ, ਇਸਦਾ ਜ਼ਿਆਦਾਤਰ (ਜਹਾਜ਼ 4 ਤੋਂ 13) ਅਜੇ ਵੀ ਅਣਵਰਤਿਆ ਹੈ।

ਸਭ ਤੋਂ ਕਮਾਲ ਦੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਸਾਰੇ ਮੁੱਖ "ਮੱਝ" ਜ਼ੀਰੋ ਪਲੇਨ ਵਿੱਚ ਪਏ ਹਨ, ਇਸਨੂੰ "ਕਹਿੰਦੇ ਹਨ।ਮੂਲ ਬਹੁਭਾਸ਼ਾਈ ਪਲੇਨ". ਜੇਕਰ ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਆਧੁਨਿਕ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ (ਚੀਨੀ ਸਮੇਤ) ਵਿੱਚ ਟੈਕਸਟ ਸ਼ਾਮਲ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸ ਪਲੇਨ ਤੋਂ ਅੱਗੇ ਨਹੀਂ ਜਾਵੋਗੇ। ਪਰ ਤੁਸੀਂ ਬਾਕੀ ਯੂਨੀਕੋਡ ਨੂੰ ਵੀ ਨਹੀਂ ਕੱਟ ਸਕਦੇ ਹੋ - ਉਦਾਹਰਨ ਲਈ, ਇਮੋਜੀ ਮੁੱਖ ਤੌਰ 'ਤੇ ਅੰਤ ਵਿੱਚ ਸਥਿਤ ਹੁੰਦੇ ਹਨ। ਅਗਲਾ ਜਹਾਜ਼"ਪੂਰਕ ਬਹੁਭਾਸ਼ਾਈ ਪਲੇਨ"(ਇਹ ਤੱਕ ਫੈਲਦਾ ਹੈ 0x10000 ਨੂੰ 0x1FFFF). ਇਸ ਲਈ UTF-16 ਅਜਿਹਾ ਕਰਦਾ ਹੈ: ਸਾਰੇ ਅੱਖਰ ਅੰਦਰ ਆਉਂਦੇ ਹਨ ਮੂਲ ਬਹੁਭਾਸ਼ਾਈ ਪਲੇਨ, ਇੱਕ ਅਨੁਸਾਰੀ ਦੋ-ਬਾਈਟ ਨੰਬਰ ਦੇ ਨਾਲ "ਜਿਵੇਂ ਹੈ" ਏਨਕੋਡ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਹਾਲਾਂਕਿ, ਇਸ ਰੇਂਜ ਵਿੱਚ ਕੁਝ ਸੰਖਿਆਵਾਂ ਖਾਸ ਅੱਖਰਾਂ ਨੂੰ ਬਿਲਕੁਲ ਨਹੀਂ ਦਰਸਾਉਂਦੀਆਂ ਹਨ, ਪਰ ਇਹ ਸੰਕੇਤ ਦਿੰਦੀਆਂ ਹਨ ਕਿ ਬਾਈਟਾਂ ਦੇ ਇਸ ਜੋੜੇ ਤੋਂ ਬਾਅਦ ਸਾਨੂੰ ਇੱਕ ਹੋਰ 'ਤੇ ਵਿਚਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ - ਇਹਨਾਂ ਚਾਰ ਬਾਈਟਾਂ ਦੇ ਮੁੱਲਾਂ ਨੂੰ ਇਕੱਠੇ ਜੋੜ ਕੇ, ਅਸੀਂ ਇੱਕ ਸੰਖਿਆ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ ਜੋ ਕਵਰ ਕਰਦਾ ਹੈ ਪੂਰੀ ਵੈਧ ਯੂਨੀਕੋਡ ਰੇਂਜ। ਇਸ ਵਿਚਾਰ ਨੂੰ "ਸਰੋਗੇਟ ਜੋੜੇ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ - ਤੁਸੀਂ ਸ਼ਾਇਦ ਉਹਨਾਂ ਬਾਰੇ ਸੁਣਿਆ ਹੋਵੇਗਾ।

ਇਸ ਲਈ UTF-16 ਲਈ ਦੋ ਜਾਂ (ਬਹੁਤ ਘੱਟ ਮਾਮਲਿਆਂ ਵਿੱਚ) ਚਾਰ ਬਾਈਟ ਪ੍ਰਤੀ "ਕੋਡ ਪੁਆਇੰਟ" ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹ ਹਰ ਸਮੇਂ ਚਾਰ ਬਾਈਟ ਵਰਤਣ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ, ਪਰ ਲਾਤੀਨੀ (ਅਤੇ ਹੋਰ ASCII ਅੱਖਰ) ਜਦੋਂ ਇਸ ਤਰੀਕੇ ਨਾਲ ਏਨਕੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਜ਼ੀਰੋ 'ਤੇ ਅੱਧੀ ਥਾਂ ਬਰਬਾਦ ਹੋ ਜਾਂਦੀ ਹੈ। UTF-8 ਨੂੰ ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ: ਇਸ ਵਿੱਚ ASCII, ਪਹਿਲਾਂ ਵਾਂਗ, ਸਿਰਫ਼ ਇੱਕ ਬਾਈਟ ਰੱਖਦਾ ਹੈ; ਤੋਂ ਕੋਡ 0x80 ਨੂੰ 0x7FF - ਦੋ ਬਾਈਟ; ਤੋਂ 0x800 ਨੂੰ 0xFFFF - ਤਿੰਨ, ਅਤੇ ਤੋਂ 0x10000 ਨੂੰ 0x10FFFF - ਚਾਰ. ਇੱਕ ਪਾਸੇ, ਲਾਤੀਨੀ ਵਰਣਮਾਲਾ ਵਧੀਆ ਬਣ ਗਈ ਹੈ: ASCII ਨਾਲ ਅਨੁਕੂਲਤਾ ਵਾਪਸ ਆ ਗਈ ਹੈ, ਅਤੇ ਵੰਡ 1 ਤੋਂ 4 ਬਾਈਟਾਂ ਤੱਕ ਵਧੇਰੇ ਬਰਾਬਰ "ਫੁੱਲ" ਹੈ। ਪਰ ਲਾਤੀਨੀ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਵਰਣਮਾਲਾਵਾਂ, UTF-16 ਦੇ ਮੁਕਾਬਲੇ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਲਾਭ ਨਹੀਂ ਕਰਦੀਆਂ, ਅਤੇ ਕਈਆਂ ਨੂੰ ਹੁਣ ਦੋ ਦੀ ਬਜਾਏ ਤਿੰਨ ਬਾਈਟਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ - ਇੱਕ ਦੋ-ਬਾਈਟ ਰਿਕਾਰਡ ਦੁਆਰਾ ਕਵਰ ਕੀਤੀ ਗਈ ਸੀਮਾ 32 ਗੁਣਾ ਘੱਟ ਗਈ ਹੈ, ਜਿਸ ਨਾਲ 0xFFFF ਨੂੰ 0x7FF, ਅਤੇ ਨਾ ਤਾਂ ਚੀਨੀ ਅਤੇ ਨਾ ਹੀ, ਉਦਾਹਰਨ ਲਈ, ਜਾਰਜੀਅਨ ਇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ। ਸਿਰਿਲਿਕ ਅਤੇ ਪੰਜ ਹੋਰ ਅੱਖਰ - hurray - ਖੁਸ਼ਕਿਸਮਤ, 2 ਬਾਈਟ ਪ੍ਰਤੀ ਅੱਖਰ।

ਅਜਿਹਾ ਕਿਉਂ ਹੁੰਦਾ ਹੈ? ਆਓ ਦੇਖੀਏ ਕਿ UTF-8 ਅੱਖਰ ਕੋਡਾਂ ਨੂੰ ਕਿਵੇਂ ਦਰਸਾਉਂਦਾ ਹੈ:

ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸੰਖਿਆਵਾਂ ਨੂੰ ਦਰਸਾਉਣ ਲਈ, ਇੱਥੇ ਚਿੰਨ੍ਹ ਨਾਲ ਚਿੰਨ੍ਹਿਤ ਬਿੱਟ ਵਰਤੇ ਗਏ ਹਨ x. ਇਹ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਇੱਕ ਦੋ-ਬਾਈਟ ਰਿਕਾਰਡ ਵਿੱਚ ਸਿਰਫ 11 ਅਜਿਹੇ ਬਿੱਟ ਹਨ (16 ਵਿੱਚੋਂ)। ਇੱਥੇ ਮੋਹਰੀ ਬਿੱਟਾਂ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਸਹਾਇਕ ਫੰਕਸ਼ਨ ਹੈ। ਇੱਕ ਚਾਰ-ਬਾਈਟ ਰਿਕਾਰਡ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਕੋਡ ਪੁਆਇੰਟ ਨੰਬਰ ਲਈ 21 ਵਿੱਚੋਂ 32 ਬਿੱਟ ਨਿਰਧਾਰਤ ਕੀਤੇ ਗਏ ਹਨ - ਇਹ ਲਗਦਾ ਹੈ ਕਿ ਤਿੰਨ ਬਾਈਟ (ਜੋ ਕੁੱਲ 24 ਬਿੱਟ ਦਿੰਦੇ ਹਨ) ਕਾਫ਼ੀ ਹੋਣਗੇ, ਪਰ ਸੇਵਾ ਮਾਰਕਰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਖਾ ਜਾਂਦੇ ਹਨ।

ਕੀ ਇਹ ਬੁਰਾ ਹੈ? ਸਚ ਵਿੱਚ ਨਹੀ. ਇੱਕ ਪਾਸੇ, ਜੇਕਰ ਅਸੀਂ ਸਪੇਸ ਦੀ ਬਹੁਤ ਪਰਵਾਹ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਸਾਡੇ ਕੋਲ ਕੰਪਰੈਸ਼ਨ ਐਲਗੋਰਿਦਮ ਹਨ ਜੋ ਆਸਾਨੀ ਨਾਲ ਸਾਰੀਆਂ ਵਾਧੂ ਐਂਟਰੌਪੀ ਅਤੇ ਰਿਡੰਡੈਂਸੀ ਨੂੰ ਖਤਮ ਕਰ ਸਕਦੇ ਹਨ। ਦੂਜੇ ਪਾਸੇ, ਯੂਨੀਕੋਡ ਦਾ ਟੀਚਾ ਸਭ ਤੋਂ ਵੱਧ ਯੂਨੀਵਰਸਲ ਕੋਡਿੰਗ ਪ੍ਰਦਾਨ ਕਰਨਾ ਸੀ। ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ UTF-8 ਵਿੱਚ ਏਨਕੋਡ ਕੀਤੀ ਇੱਕ ਲਾਈਨ ਨੂੰ ਕੋਡ ਲਈ ਸੌਂਪ ਸਕਦੇ ਹਾਂ ਜੋ ਪਹਿਲਾਂ ਸਿਰਫ਼ ASCII ਨਾਲ ਕੰਮ ਕਰਦਾ ਸੀ, ਅਤੇ ਡਰੋ ਨਹੀਂ ਕਿ ਇਹ ASCII ਰੇਂਜ ਤੋਂ ਇੱਕ ਅੱਖਰ ਵੇਖੇਗਾ ਜੋ ਅਸਲ ਵਿੱਚ ਉੱਥੇ ਨਹੀਂ ਹੈ (ਆਖ਼ਰਕਾਰ, UTF-8 ਵਿੱਚ ਸਾਰੇ ਜ਼ੀਰੋ ਬਿੱਟ ਤੋਂ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੇ ਬਾਈਟਸ - ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜੋ ASCII ਹੈ)। ਅਤੇ ਜੇਕਰ ਅਸੀਂ ਅਚਾਨਕ ਇੱਕ ਵੱਡੀ ਸਤਰ ਤੋਂ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਪੂਛ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਡੀਕੋਡ ਕੀਤੇ ਬਿਨਾਂ ਕੱਟਣਾ ਚਾਹੁੰਦੇ ਹਾਂ (ਜਾਂ ਨੁਕਸਾਨੇ ਗਏ ਭਾਗ ਤੋਂ ਬਾਅਦ ਜਾਣਕਾਰੀ ਦੇ ਹਿੱਸੇ ਨੂੰ ਬਹਾਲ ਕਰਨਾ), ਤਾਂ ਸਾਡੇ ਲਈ ਔਫਸੈੱਟ ਨੂੰ ਲੱਭਣਾ ਆਸਾਨ ਹੈ ਜਿੱਥੇ ਇੱਕ ਅੱਖਰ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ (ਇਹ ਕਾਫ਼ੀ ਹੈ ਬਾਈਟਾਂ ਨੂੰ ਛੱਡਣ ਲਈ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਥੋੜ੍ਹਾ ਅਗੇਤਰ ਹੈ 10).

ਫਿਰ ਕੁਝ ਨਵਾਂ ਕਿਉਂ ਕੱਢਿਆ?

ਇਸ ਦੇ ਨਾਲ ਹੀ, ਕਦੇ-ਕਦਾਈਂ ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਡੀਫਲੇਟ ਵਰਗੇ ਕੰਪਰੈਸ਼ਨ ਐਲਗੋਰਿਦਮ ਮਾੜੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ, ਪਰ ਤੁਸੀਂ ਸਟ੍ਰਿੰਗਜ਼ ਦੀ ਸੰਖੇਪ ਸਟੋਰੇਜ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਨਿੱਜੀ ਤੌਰ 'ਤੇ, ਮੈਨੂੰ ਇਮਾਰਤ ਬਾਰੇ ਸੋਚਣ ਵੇਲੇ ਇਸ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ ਕੰਪਰੈੱਸਡ ਪ੍ਰੀਫਿਕਸ ਟ੍ਰੀ ਮਨਮਾਨੇ ਭਾਸ਼ਾਵਾਂ ਦੇ ਸ਼ਬਦਾਂ ਸਮੇਤ ਇੱਕ ਵੱਡੇ ਸ਼ਬਦਕੋਸ਼ ਲਈ। ਇੱਕ ਪਾਸੇ, ਹਰ ਇੱਕ ਸ਼ਬਦ ਬਹੁਤ ਛੋਟਾ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਸੰਕੁਚਿਤ ਕਰਨਾ ਬੇਅਸਰ ਹੋਵੇਗਾ। ਦੂਜੇ ਪਾਸੇ, ਟ੍ਰੀ ਸਥਾਪਨ ਜਿਸ ਬਾਰੇ ਮੈਂ ਵਿਚਾਰ ਕੀਤਾ ਹੈ, ਇਸ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਸੀ ਤਾਂ ਕਿ ਸਟੋਰ ਕੀਤੀ ਸਤਰ ਦੇ ਹਰੇਕ ਬਾਈਟ ਨੇ ਇੱਕ ਵੱਖਰਾ ਟ੍ਰੀ ਵਰਟੈਕਸ ਤਿਆਰ ਕੀਤਾ, ਇਸਲਈ ਉਹਨਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਘਟਾਉਣਾ ਬਹੁਤ ਉਪਯੋਗੀ ਸੀ। ਮੇਰੀ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ Az.js (ਇਸ ਤਰਾਂ pymorphy2, ਜਿਸ 'ਤੇ ਇਹ ਅਧਾਰਤ ਹੈ) ਇੱਕ ਸਮਾਨ ਸਮੱਸਿਆ ਨੂੰ ਅਸਾਨੀ ਨਾਲ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ - ਵਿੱਚ ਪੈਕ ਕੀਤੀਆਂ ਸਤਰ DAWG- ਸ਼ਬਦਕੋਸ਼, ਇੱਥੇ ਸਟੋਰ ਕੀਤਾ ਗਿਆ ਹੈ ਚੰਗਾ ਪੁਰਾਣਾ CP1251. ਪਰ, ਜਿਵੇਂ ਕਿ ਸਮਝਣਾ ਆਸਾਨ ਹੈ, ਇਹ ਸਿਰਫ ਇੱਕ ਸੀਮਤ ਵਰਣਮਾਲਾ ਲਈ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ - ਚੀਨੀ ਵਿੱਚ ਇੱਕ ਲਾਈਨ ਅਜਿਹੇ ਸ਼ਬਦਕੋਸ਼ ਵਿੱਚ ਨਹੀਂ ਜੋੜੀ ਜਾ ਸਕਦੀ ਹੈ।

ਵੱਖਰੇ ਤੌਰ 'ਤੇ, ਮੈਂ ਅਜਿਹੇ ਡੇਟਾ ਢਾਂਚੇ ਵਿੱਚ UTF-8 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਪੈਦਾ ਹੋਣ ਵਾਲੀ ਇੱਕ ਹੋਰ ਕੋਝਾ ਸੂਖਮਤਾ ਨੂੰ ਨੋਟ ਕਰਨਾ ਚਾਹਾਂਗਾ। ਉਪਰੋਕਤ ਤਸਵੀਰ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਜਦੋਂ ਇੱਕ ਅੱਖਰ ਨੂੰ ਦੋ ਬਾਈਟਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਉਸਦੇ ਨੰਬਰ ਨਾਲ ਸਬੰਧਤ ਬਿੱਟ ਇੱਕ ਕਤਾਰ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦੇ, ਸਗੋਂ ਬਿੱਟਾਂ ਦੇ ਇੱਕ ਜੋੜੇ ਦੁਆਰਾ ਵੱਖ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। 10 ਮੱਧ ਵਿੱਚ: 110xxxxx 10xxxxxx. ਇਸਦੇ ਕਾਰਨ, ਜਦੋਂ ਅੱਖਰ ਕੋਡ ਵਿੱਚ ਦੂਜੇ ਬਾਈਟ ਦੇ ਹੇਠਲੇ 6 ਬਿੱਟ ਓਵਰਫਲੋ ਹੁੰਦੇ ਹਨ (ਅਰਥਾਤ, ਇੱਕ ਤਬਦੀਲੀ ਹੁੰਦੀ ਹੈ 10111111 → 10000000), ਫਿਰ ਪਹਿਲਾ ਬਾਈਟ ਵੀ ਬਦਲ ਜਾਂਦਾ ਹੈ। ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਅੱਖਰ "ਪੀ" ਨੂੰ ਬਾਈਟਸ ਦੁਆਰਾ ਦਰਸਾਇਆ ਗਿਆ ਹੈ 0xD0 0xBF, ਅਤੇ ਅਗਲਾ "r" ਪਹਿਲਾਂ ਹੀ ਹੈ 0xD1 0x80. ਇੱਕ ਪ੍ਰੀਫਿਕਸ ਟ੍ਰੀ ਵਿੱਚ, ਇਹ ਪੇਰੈਂਟ ਨੋਡ ਨੂੰ ਦੋ ਵਿੱਚ ਵੰਡਦਾ ਹੈ - ਇੱਕ ਅਗੇਤਰ ਲਈ 0xD0, ਅਤੇ ਲਈ ਇੱਕ ਹੋਰ 0xD1 (ਹਾਲਾਂਕਿ ਸਮੁੱਚੀ ਸਿਰਿਲਿਕ ਵਰਣਮਾਲਾ ਸਿਰਫ ਦੂਜੇ ਬਾਈਟ ਦੁਆਰਾ ਏਨਕੋਡ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ)।

ਮੈਨੂੰ ਕੀ ਮਿਲਿਆ

ਇਸ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਦੇ ਹੋਏ, ਮੈਂ ਬਿੱਟਾਂ ਨਾਲ ਖੇਡਾਂ ਖੇਡਣ ਦਾ ਅਭਿਆਸ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਅਤੇ ਉਸੇ ਸਮੇਂ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਯੂਨੀਕੋਡ ਦੀ ਬਣਤਰ ਨਾਲ ਥੋੜਾ ਬਿਹਤਰ ਜਾਣੂ ਹੋ ਗਿਆ। ਨਤੀਜਾ UTF-C ਇੰਕੋਡਿੰਗ ਫਾਰਮੈਟ ਸੀ ("C" ਲਈ ਸੰਖੇਪ), ਜੋ ਪ੍ਰਤੀ ਕੋਡ ਪੁਆਇੰਟ 3 ਬਾਈਟਾਂ ਤੋਂ ਵੱਧ ਖਰਚ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਅਕਸਰ ਤੁਹਾਨੂੰ ਸਿਰਫ ਖਰਚ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਪੂਰੀ ਏਨਕੋਡਡ ਲਾਈਨ ਲਈ ਇੱਕ ਵਾਧੂ ਬਾਈਟ. ਇਹ ਇਸ ਤੱਥ ਵੱਲ ਖੜਦਾ ਹੈ ਕਿ ਬਹੁਤ ਸਾਰੇ ਗੈਰ-ASCII ਅੱਖਰਾਂ 'ਤੇ ਅਜਿਹੀ ਏਨਕੋਡਿੰਗ ਹੁੰਦੀ ਹੈ UTF-30 ਨਾਲੋਂ 60-8% ਵਧੇਰੇ ਸੰਖੇਪ.

ਮੈਂ ਫਾਰਮ ਵਿੱਚ ਏਨਕੋਡਿੰਗ ਅਤੇ ਡੀਕੋਡਿੰਗ ਐਲਗੋਰਿਦਮ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀਆਂ ਉਦਾਹਰਣਾਂ ਪੇਸ਼ ਕੀਤੀਆਂ ਹਨ JavaScript ਅਤੇ Go ਲਾਇਬ੍ਰੇਰੀਆਂ, ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਆਪਣੇ ਕੋਡ ਵਿੱਚ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਵਰਤ ਸਕਦੇ ਹੋ। ਪਰ ਮੈਂ ਅਜੇ ਵੀ ਇਸ ਗੱਲ 'ਤੇ ਜ਼ੋਰ ਦੇਵਾਂਗਾ ਕਿ ਇੱਕ ਅਰਥ ਵਿੱਚ ਇਹ ਫਾਰਮੈਟ ਇੱਕ "ਸਾਈਕਲ" ਬਣਿਆ ਹੋਇਆ ਹੈ, ਅਤੇ ਮੈਂ ਇਸਨੂੰ ਵਰਤਣ ਦੀ ਸਿਫਾਰਸ਼ ਨਹੀਂ ਕਰਦਾ ਹਾਂ ਇਹ ਸਮਝੇ ਬਿਨਾਂ ਕਿ ਤੁਹਾਨੂੰ ਇਸਦੀ ਕਿਉਂ ਲੋੜ ਹੈ. ਇਹ ਅਜੇ ਵੀ ਇੱਕ ਗੰਭੀਰ "UTF-8 ਦੇ ਸੁਧਾਰ" ਨਾਲੋਂ ਇੱਕ ਪ੍ਰਯੋਗ ਹੈ। ਫਿਰ ਵੀ, ਉੱਥੇ ਕੋਡ ਬਹੁਤ ਸਾਰੀਆਂ ਟਿੱਪਣੀਆਂ ਅਤੇ ਟੈਸਟ ਕਵਰੇਜ ਦੇ ਨਾਲ ਸਾਫ਼-ਸਾਫ਼, ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ।

ਟੈਸਟ ਦੇ ਨਤੀਜੇ ਅਤੇ UTF-8 ਨਾਲ ਤੁਲਨਾ

ਮੈਂ ਵੀ ਕੀਤਾ ਡੈਮੋ ਪੰਨਾ, ਜਿੱਥੇ ਤੁਸੀਂ ਐਲਗੋਰਿਦਮ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦਾ ਮੁਲਾਂਕਣ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਮੈਂ ਤੁਹਾਨੂੰ ਇਸਦੇ ਸਿਧਾਂਤਾਂ ਅਤੇ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਬਾਰੇ ਹੋਰ ਦੱਸਾਂਗਾ।

ਬੇਲੋੜੀਆਂ ਬਿੱਟਾਂ ਨੂੰ ਖਤਮ ਕਰਨਾ

ਬੇਸ਼ਕ, ਮੈਂ UTF-8 ਨੂੰ ਅਧਾਰ ਵਜੋਂ ਲਿਆ। ਪਹਿਲੀ ਅਤੇ ਸਭ ਤੋਂ ਸਪੱਸ਼ਟ ਚੀਜ਼ ਜੋ ਇਸ ਵਿੱਚ ਬਦਲੀ ਜਾ ਸਕਦੀ ਹੈ ਉਹ ਹੈ ਹਰੇਕ ਬਾਈਟ ਵਿੱਚ ਸੇਵਾ ਬਿੱਟਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਘਟਾਉਣਾ। ਉਦਾਹਰਨ ਲਈ, UTF-8 ਵਿੱਚ ਪਹਿਲਾ ਬਾਈਟ ਹਮੇਸ਼ਾ ਕਿਸੇ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ 0, ਜਾਂ ਨਾਲ 11 - ਇੱਕ ਅਗੇਤਰ 10 ਸਿਰਫ਼ ਹੇਠਾਂ ਦਿੱਤੇ ਬਾਈਟਾਂ ਵਿੱਚ ਇਹ ਹੈ। ਆਓ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਬਦਲੀਏ 11 'ਤੇ 1, ਅਤੇ ਅਗਲੀਆਂ ਬਾਈਟਾਂ ਲਈ ਅਸੀਂ ਅਗੇਤਰਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਟਾ ਦੇਵਾਂਗੇ। ਕੀ ਹੋਵੇਗਾ?

0xxxxxxx - 1 ਬਾਈਟ
10xxxxxx xxxxxxxx - 2 ਬਾਈਟ
110xxxxx xxxxxxxx xxxxxxxx - 3 ਬਾਈਟ

ਉਡੀਕ ਕਰੋ, ਚਾਰ-ਬਾਈਟ ਰਿਕਾਰਡ ਕਿੱਥੇ ਹੈ? ਪਰ ਹੁਣ ਇਸਦੀ ਲੋੜ ਨਹੀਂ ਹੈ - ਜਦੋਂ ਤਿੰਨ ਬਾਈਟਾਂ ਵਿੱਚ ਲਿਖਦੇ ਹੋ, ਸਾਡੇ ਕੋਲ ਹੁਣ 21 ਬਿੱਟ ਉਪਲਬਧ ਹਨ ਅਤੇ ਇਹ ਸਾਰੇ ਨੰਬਰਾਂ ਲਈ ਕਾਫੀ ਹੈ 0x10FFFF.

ਅਸੀਂ ਇੱਥੇ ਕੀ ਕੁਰਬਾਨੀ ਕੀਤੀ ਹੈ? ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਬਫਰ ਵਿੱਚ ਇੱਕ ਮਨਮਾਨੇ ਸਥਾਨ ਤੋਂ ਅੱਖਰ ਸੀਮਾਵਾਂ ਦਾ ਪਤਾ ਲਗਾਉਣਾ. ਅਸੀਂ ਇੱਕ ਆਰਬਿਟਰਰੀ ਬਾਈਟ ਵੱਲ ਇਸ਼ਾਰਾ ਨਹੀਂ ਕਰ ਸਕਦੇ ਅਤੇ ਇਸ ਤੋਂ ਅਗਲੇ ਅੱਖਰ ਦੀ ਸ਼ੁਰੂਆਤ ਨਹੀਂ ਲੱਭ ਸਕਦੇ। ਇਹ ਸਾਡੇ ਫਾਰਮੈਟ ਦੀ ਇੱਕ ਸੀਮਾ ਹੈ, ਪਰ ਅਭਿਆਸ ਵਿੱਚ ਇਹ ਘੱਟ ਹੀ ਜ਼ਰੂਰੀ ਹੈ। ਅਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਬਫਰ ਵਿੱਚੋਂ ਲੰਘਣ ਦੇ ਯੋਗ ਹੁੰਦੇ ਹਾਂ (ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਇਹ ਛੋਟੀਆਂ ਲਾਈਨਾਂ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ)।

2 ਬਾਈਟਾਂ ਨਾਲ ਢੱਕਣ ਵਾਲੀਆਂ ਭਾਸ਼ਾਵਾਂ ਦੀ ਸਥਿਤੀ ਵੀ ਬਿਹਤਰ ਹੋ ਗਈ ਹੈ: ਹੁਣ ਦੋ-ਬਾਈਟ ਫਾਰਮੈਟ 14 ਬਿੱਟਾਂ ਦੀ ਰੇਂਜ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਕੋਡ ਹਨ 0x3FFF. ਚੀਨੀ ਬਦਕਿਸਮਤ ਹਨ (ਉਨ੍ਹਾਂ ਦੇ ਅੱਖਰ ਜ਼ਿਆਦਾਤਰ ਇਸ ਤੋਂ ਹੁੰਦੇ ਹਨ 0x4E00 ਨੂੰ 0x9FFF), ਪਰ ਜਾਰਜੀਅਨ ਅਤੇ ਹੋਰ ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਵਧੇਰੇ ਮਜ਼ੇਦਾਰ ਹਨ - ਉਹਨਾਂ ਦੀਆਂ ਭਾਸ਼ਾਵਾਂ ਵੀ ਪ੍ਰਤੀ ਅੱਖਰ 2 ਬਾਈਟਾਂ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦੀਆਂ ਹਨ।

ਏਨਕੋਡਰ ਸਥਿਤੀ ਦਰਜ ਕਰੋ

ਆਉ ਹੁਣ ਲਾਈਨਾਂ ਦੇ ਗੁਣਾਂ ਬਾਰੇ ਆਪਣੇ ਆਪ ਸੋਚੀਏ। ਡਿਕਸ਼ਨਰੀ ਵਿੱਚ ਅਕਸਰ ਇੱਕੋ ਵਰਣਮਾਲਾ ਦੇ ਅੱਖਰਾਂ ਵਿੱਚ ਲਿਖੇ ਸ਼ਬਦ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਹ ਕਈ ਹੋਰ ਲਿਖਤਾਂ ਲਈ ਵੀ ਸੱਚ ਹੈ। ਇਹ ਇੱਕ ਵਾਰ ਇਸ ਅੱਖਰ ਨੂੰ ਦਰਸਾਉਣਾ ਚੰਗਾ ਹੋਵੇਗਾ, ਅਤੇ ਫਿਰ ਇਸਦੇ ਅੰਦਰਲੇ ਅੱਖਰ ਦੀ ਸੰਖਿਆ ਨੂੰ ਦਰਸਾਓ। ਆਓ ਦੇਖੀਏ ਕਿ ਕੀ ਯੂਨੀਕੋਡ ਸਾਰਣੀ ਵਿੱਚ ਅੱਖਰਾਂ ਦੀ ਵਿਵਸਥਾ ਸਾਡੀ ਮਦਦ ਕਰੇਗੀ।

ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਯੂਨੀਕੋਡ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ ਜਹਾਜ਼ 65536 ਕੋਡ ਹਰੇਕ। ਪਰ ਇਹ ਇੱਕ ਬਹੁਤ ਲਾਭਦਾਇਕ ਵੰਡ ਨਹੀਂ ਹੈ (ਜਿਵੇਂ ਕਿ ਪਹਿਲਾਂ ਹੀ ਕਿਹਾ ਗਿਆ ਹੈ, ਅਕਸਰ ਅਸੀਂ ਜ਼ੀਰੋ ਪਲੇਨ ਵਿੱਚ ਹੁੰਦੇ ਹਾਂ). ਦੁਆਰਾ ਵੰਡ ਵਧੇਰੇ ਦਿਲਚਸਪ ਹੈ ਬਲਾਕ. ਇਹਨਾਂ ਰੇਂਜਾਂ ਦੀ ਹੁਣ ਕੋਈ ਨਿਸ਼ਚਿਤ ਲੰਬਾਈ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਹ ਵਧੇਰੇ ਅਰਥਪੂਰਨ ਹਨ - ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ 'ਤੇ, ਹਰ ਇੱਕ ਇੱਕੋ ਵਰਣਮਾਲਾ ਦੇ ਅੱਖਰਾਂ ਨੂੰ ਜੋੜਦਾ ਹੈ।

ਬੰਗਾਲੀ ਵਰਣਮਾਲਾ ਦੇ ਅੱਖਰਾਂ ਵਾਲਾ ਇੱਕ ਬਲਾਕ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਇਤਿਹਾਸਕ ਕਾਰਨਾਂ ਕਰਕੇ, ਇਹ ਬਹੁਤ ਸੰਘਣੀ ਪੈਕੇਜਿੰਗ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਹੈ - 96 ਅੱਖਰ 128 ਬਲਾਕ ਕੋਡ ਪੁਆਇੰਟਾਂ ਵਿੱਚ ਅਰਾਜਕਤਾ ਨਾਲ ਖਿੰਡੇ ਹੋਏ ਹਨ।

ਬਲਾਕਾਂ ਦੀ ਸ਼ੁਰੂਆਤ ਅਤੇ ਉਹਨਾਂ ਦੇ ਆਕਾਰ ਹਮੇਸ਼ਾ 16 ਦੇ ਗੁਣਜ ਹੁੰਦੇ ਹਨ - ਇਹ ਸਿਰਫ਼ ਸਹੂਲਤ ਲਈ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਬਹੁਤ ਸਾਰੇ ਬਲਾਕ 128 ਜਾਂ ਇੱਥੋਂ ਤੱਕ ਕਿ 256 ਦੇ ਗੁਣਜ ਵਾਲੇ ਮੁੱਲਾਂ 'ਤੇ ਸ਼ੁਰੂ ਅਤੇ ਖ਼ਤਮ ਹੁੰਦੇ ਹਨ - ਉਦਾਹਰਨ ਲਈ, ਮੂਲ ਸਿਰਿਲਿਕ ਵਰਣਮਾਲਾ 256 ਬਾਈਟ ਲੈਂਦੀ ਹੈ 0x0400 ਨੂੰ 0x04FF. ਇਹ ਕਾਫ਼ੀ ਸੁਵਿਧਾਜਨਕ ਹੈ: ਜੇਕਰ ਅਸੀਂ ਇੱਕ ਵਾਰ ਅਗੇਤਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਦੇ ਹਾਂ 0x04, ਫਿਰ ਕੋਈ ਵੀ ਸਿਰਿਲਿਕ ਅੱਖਰ ਇੱਕ ਬਾਈਟ ਵਿੱਚ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਸੱਚ ਹੈ ਕਿ ਇਸ ਤਰ੍ਹਾਂ ਅਸੀਂ ASCII (ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਹੋਰ ਅੱਖਰ) 'ਤੇ ਵਾਪਸ ਜਾਣ ਦਾ ਮੌਕਾ ਗੁਆ ਦੇਵਾਂਗੇ। ਇਸ ਲਈ ਅਸੀਂ ਇਹ ਕਰਦੇ ਹਾਂ:

1. ਦੋ ਬਾਈਟ 10yyyyyy yxxxxxxx ਨਾ ਸਿਰਫ਼ ਇੱਕ ਨੰਬਰ ਦੇ ਨਾਲ ਇੱਕ ਚਿੰਨ੍ਹ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ yyyyyy yxxxxxxx, ਪਰ ਇਹ ਵੀ ਬਦਲੋ ਮੌਜੂਦਾ ਵਰਣਮਾਲਾ 'ਤੇ yyyyyy y0000000 (ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਸਭ ਤੋਂ ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਬਿੱਟਾਂ ਨੂੰ ਛੱਡ ਕੇ ਸਾਰੇ ਬਿੱਟਾਂ ਨੂੰ ਯਾਦ ਰੱਖਦੇ ਹਾਂ 7 ਬਿੱਟ);
2. ਇੱਕ ਬਾਈਟ 0xxxxxxx ਇਹ ਮੌਜੂਦਾ ਵਰਣਮਾਲਾ ਦਾ ਅੱਖਰ ਹੈ। ਇਸਨੂੰ ਸਿਰਫ਼ ਉਸ ਔਫਸੈੱਟ ਵਿੱਚ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ ਜੋ ਸਾਨੂੰ ਪਗ 1 ਵਿੱਚ ਯਾਦ ਹੈ। ਜਦੋਂ ਕਿ ਅਸੀਂ ਵਰਣਮਾਲਾ ਨੂੰ ਨਹੀਂ ਬਦਲਿਆ, ਆਫਸੈੱਟ ਜ਼ੀਰੋ ਹੈ, ਇਸਲਈ ਅਸੀਂ ASCII ਨਾਲ ਅਨੁਕੂਲਤਾ ਬਣਾਈ ਰੱਖੀ ਹੈ।

ਇਸੇ ਤਰ੍ਹਾਂ 3 ਬਾਈਟਾਂ ਦੀ ਲੋੜ ਵਾਲੇ ਕੋਡਾਂ ਲਈ:

1. ਤਿੰਨ ਬਾਈਟ 110yyyyy yxxxxxxx xxxxxxxx ਇੱਕ ਨੰਬਰ ਦੇ ਨਾਲ ਇੱਕ ਚਿੰਨ੍ਹ ਦਰਸਾਓ yyyyyy yxxxxxxx xxxxxxxx, ਬਦਲੋ ਮੌਜੂਦਾ ਵਰਣਮਾਲਾ 'ਤੇ yyyyyy y0000000 00000000 (ਛੋਟਿਆਂ ਨੂੰ ਛੱਡ ਕੇ ਸਭ ਕੁਝ ਯਾਦ ਹੈ 15 ਬਿੱਟ), ਅਤੇ ਉਸ ਬਾਕਸ ਨੂੰ ਚੁਣੋ ਜਿਸ ਵਿੱਚ ਅਸੀਂ ਹੁਣ ਹਾਂ ਲੰਬੇ ਮੋਡ (ਜਦੋਂ ਵਰਣਮਾਲਾ ਨੂੰ ਇੱਕ ਡਬਲ-ਬਾਈਟ ਵਿੱਚ ਬਦਲਦੇ ਹੋਏ, ਅਸੀਂ ਇਸ ਫਲੈਗ ਨੂੰ ਰੀਸੈਟ ਕਰਾਂਗੇ);
2. ਦੋ ਬਾਈਟ 0xxxxxxx xxxxxxxx ਲੰਬੇ ਮੋਡ ਵਿੱਚ ਇਹ ਮੌਜੂਦਾ ਵਰਣਮਾਲਾ ਦਾ ਅੱਖਰ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ, ਅਸੀਂ ਇਸਨੂੰ ਸਟੈਪ 1 ਤੋਂ ਆਫਸੈੱਟ ਦੇ ਨਾਲ ਜੋੜਦੇ ਹਾਂ। ਫਰਕ ਸਿਰਫ ਇਹ ਹੈ ਕਿ ਹੁਣ ਅਸੀਂ ਦੋ ਬਾਈਟਸ ਪੜ੍ਹਦੇ ਹਾਂ (ਕਿਉਂਕਿ ਅਸੀਂ ਇਸ ਮੋਡ ਵਿੱਚ ਬਦਲਿਆ ਹੈ)।

ਚੰਗਾ ਲੱਗਦਾ ਹੈ: ਹੁਣ ਜਦੋਂ ਕਿ ਸਾਨੂੰ ਉਸੇ 7-ਬਿੱਟ ਯੂਨੀਕੋਡ ਰੇਂਜ ਤੋਂ ਅੱਖਰਾਂ ਨੂੰ ਏਨਕੋਡ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਅਸੀਂ ਸ਼ੁਰੂ ਵਿੱਚ 1 ਵਾਧੂ ਬਾਈਟ ਅਤੇ ਪ੍ਰਤੀ ਅੱਖਰ ਕੁੱਲ ਇੱਕ ਬਾਈਟ ਖਰਚ ਕਰਦੇ ਹਾਂ।

ਪੁਰਾਣੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚੋਂ ਇੱਕ ਤੋਂ ਕੰਮ ਕਰਨਾ। ਇਹ ਪਹਿਲਾਂ ਹੀ ਅਕਸਰ UTF-8 ਨੂੰ ਹਰਾਉਂਦਾ ਹੈ, ਪਰ ਅਜੇ ਵੀ ਸੁਧਾਰ ਦੀ ਗੁੰਜਾਇਸ਼ ਹੈ।

ਕੀ ਬੁਰਾ ਹੈ? ਪਹਿਲਾਂ, ਸਾਡੀ ਇੱਕ ਸ਼ਰਤ ਹੈ, ਅਰਥਾਤ ਮੌਜੂਦਾ ਵਰਣਮਾਲਾ ਆਫਸੈੱਟ ਅਤੇ ਚੈੱਕਬਾਕਸ ਲੰਬੇ ਮੋਡ. ਇਹ ਸਾਨੂੰ ਹੋਰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ: ਹੁਣ ਇੱਕੋ ਅੱਖਰ ਨੂੰ ਵੱਖ-ਵੱਖ ਸੰਦਰਭਾਂ ਵਿੱਚ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਏਨਕੋਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਸਬਸਟਰਿੰਗਾਂ ਦੀ ਖੋਜ ਕਰਨਾ, ਉਦਾਹਰਨ ਲਈ, ਇਸ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਬਾਈਟਾਂ ਦੀ ਤੁਲਨਾ ਕਰਕੇ। ਦੂਜਾ, ਜਿਵੇਂ ਹੀ ਅਸੀਂ ਵਰਣਮਾਲਾ ਨੂੰ ਬਦਲਿਆ, ਇਹ ASCII ਅੱਖਰਾਂ ਦੀ ਏਨਕੋਡਿੰਗ ਨਾਲ ਖਰਾਬ ਹੋ ਗਿਆ (ਅਤੇ ਇਹ ਨਾ ਸਿਰਫ ਲਾਤੀਨੀ ਵਰਣਮਾਲਾ ਹੈ, ਸਗੋਂ ਬੁਨਿਆਦੀ ਵਿਰਾਮ ਚਿੰਨ੍ਹ ਵੀ ਹੈ, ਖਾਲੀ ਥਾਂਵਾਂ ਸਮੇਤ) - ਉਹਨਾਂ ਨੂੰ ਵਰਣਮਾਲਾ ਨੂੰ ਦੁਬਾਰਾ 0 ਵਿੱਚ ਬਦਲਣ ਦੀ ਲੋੜ ਹੈ, ਯਾਨੀ, ਦੁਬਾਰਾ ਇੱਕ ਵਾਧੂ ਬਾਈਟ (ਅਤੇ ਫਿਰ ਸਾਡੇ ਮੁੱਖ ਬਿੰਦੂ ਤੇ ਵਾਪਸ ਜਾਣ ਲਈ ਇੱਕ ਹੋਰ)।

ਇੱਕ ਵਰਣਮਾਲਾ ਵਧੀਆ ਹੈ, ਦੋ ਬਿਹਤਰ ਹਨ

ਆਉ ਉੱਪਰ ਦੱਸੇ ਗਏ ਤਿੰਨਾਂ ਨੂੰ ਇੱਕ ਹੋਰ ਵਿੱਚ ਨਿਚੋੜਦੇ ਹੋਏ, ਆਪਣੇ ਬਿੱਟ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਥੋੜਾ ਜਿਹਾ ਬਦਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ:

0xxxxxxx — 1 ਬਾਈਟ ਸਧਾਰਨ ਮੋਡ ਵਿੱਚ, 2 ਲੰਬੇ ਮੋਡ ਵਿੱਚ
11xxxxxx - 1 ਬਾਈਟ
100xxxxx xxxxxxxx - 2 ਬਾਈਟ
101xxxxx xxxxxxxx xxxxxxxx - 3 ਬਾਈਟ

ਹੁਣ ਇੱਕ ਦੋ-ਬਾਈਟ ਰਿਕਾਰਡ ਵਿੱਚ ਇੱਕ ਘੱਟ ਉਪਲਬਧ ਬਿੱਟ ਹੈ - ਕੋਡ ਪੁਆਇੰਟ ਤੱਕ 0x1FFFਅਤੇ ਨਹੀਂ 0x3FFF. ਹਾਲਾਂਕਿ, ਇਹ ਅਜੇ ਵੀ ਡਬਲ-ਬਾਈਟ UTF-8 ਕੋਡਾਂ ਨਾਲੋਂ ਕਾਫ਼ੀ ਵੱਡਾ ਹੈ, ਜ਼ਿਆਦਾਤਰ ਆਮ ਭਾਸ਼ਾਵਾਂ ਅਜੇ ਵੀ ਫਿੱਟ ਹਨ, ਸਭ ਤੋਂ ਵੱਧ ਧਿਆਨ ਦੇਣ ਯੋਗ ਨੁਕਸਾਨ ਡਿੱਗ ਗਿਆ ਹੈ ਹੀਰਾਗਾਨਾ и ਕਾਟਾਕਾਨਾ, ਜਾਪਾਨੀ ਉਦਾਸ ਹਨ।

ਇਹ ਨਵਾਂ ਕੋਡ ਕੀ ਹੈ? 11xxxxxx? ਇਹ ਆਕਾਰ ਵਿੱਚ 64 ਅੱਖਰਾਂ ਦੀ ਇੱਕ ਛੋਟੀ ਜਿਹੀ "ਸਟੈਸ਼" ਹੈ, ਇਹ ਸਾਡੇ ਮੁੱਖ ਵਰਣਮਾਲਾ ਦੇ ਪੂਰਕ ਹੈ, ਇਸਲਈ ਮੈਂ ਇਸਨੂੰ ਸਹਾਇਕ ਕਿਹਾ (ਸਹਾਇਕ) ਵਰਣਮਾਲਾ। ਜਦੋਂ ਅਸੀਂ ਮੌਜੂਦਾ ਵਰਣਮਾਲਾ ਨੂੰ ਬਦਲਦੇ ਹਾਂ, ਤਾਂ ਪੁਰਾਣੀ ਵਰਣਮਾਲਾ ਦਾ ਇੱਕ ਟੁਕੜਾ ਸਹਾਇਕ ਬਣ ਜਾਂਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ASCII ਤੋਂ ਸਿਰਿਲਿਕ ਵਿੱਚ ਬਦਲਿਆ - ਸਟੈਸ਼ ਵਿੱਚ ਹੁਣ 64 ਅੱਖਰ ਸ਼ਾਮਲ ਹਨ ਲਾਤੀਨੀ ਵਰਣਮਾਲਾ, ਨੰਬਰ, ਸਪੇਸ ਅਤੇ ਕੌਮਾ (ਗੈਰ-ASCII ਟੈਕਸਟ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਵਾਰ ਵਾਰ ਸੰਮਿਲਨ)। ASCII 'ਤੇ ਵਾਪਸ ਜਾਓ - ਅਤੇ ਸਿਰਿਲਿਕ ਵਰਣਮਾਲਾ ਦਾ ਮੁੱਖ ਹਿੱਸਾ ਸਹਾਇਕ ਵਰਣਮਾਲਾ ਬਣ ਜਾਵੇਗਾ।

ਦੋ ਵਰਣਮਾਲਾਵਾਂ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਲਈ ਧੰਨਵਾਦ, ਅਸੀਂ ਅੱਖਰਾਂ ਨੂੰ ਬਦਲਣ ਲਈ ਘੱਟੋ-ਘੱਟ ਲਾਗਤਾਂ ਨਾਲ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਟੈਕਸਟ ਨੂੰ ਸੰਭਾਲ ਸਕਦੇ ਹਾਂ (ਵਿਰਾਮ ਚਿੰਨ੍ਹ ਅਕਸਰ ASCII ਵਿੱਚ ਵਾਪਸੀ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ, ਪਰ ਉਸ ਤੋਂ ਬਾਅਦ ਸਾਨੂੰ ਵਾਧੂ ਵਰਣਮਾਲਾ ਤੋਂ ਬਹੁਤ ਸਾਰੇ ਗੈਰ-ASCII ਅੱਖਰ ਪ੍ਰਾਪਤ ਹੋਣਗੇ, ਬਿਨਾਂ ਦੁਬਾਰਾ ਬਦਲ ਰਿਹਾ ਹੈ).

ਬੋਨਸ: ਉਪ-ਵਰਣਮਾਲਾ ਦਾ ਪ੍ਰੀਫਿਕਸਿੰਗ 11xxxxxx ਅਤੇ ਇਸਦੇ ਸ਼ੁਰੂਆਤੀ ਆਫਸੈੱਟ ਨੂੰ ਹੋਣ ਲਈ ਚੁਣਨਾ 0xC0, ਸਾਨੂੰ CP1252 ਨਾਲ ਅੰਸ਼ਕ ਅਨੁਕੂਲਤਾ ਮਿਲਦੀ ਹੈ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, CP1252 ਵਿੱਚ ਏਨਕੋਡ ਕੀਤੇ ਬਹੁਤ ਸਾਰੇ (ਪਰ ਸਾਰੇ ਨਹੀਂ) ਪੱਛਮੀ ਯੂਰਪੀਅਨ ਟੈਕਸਟ UTF-C ਵਿੱਚ ਇੱਕੋ ਜਿਹੇ ਦਿਖਾਈ ਦੇਣਗੇ।

ਇੱਥੇ, ਹਾਲਾਂਕਿ, ਇੱਕ ਮੁਸ਼ਕਲ ਪੈਦਾ ਹੁੰਦੀ ਹੈ: ਮੁੱਖ ਵਰਣਮਾਲਾ ਤੋਂ ਇੱਕ ਸਹਾਇਕ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ? ਤੁਸੀਂ ਉਹੀ ਆਫਸੈੱਟ ਛੱਡ ਸਕਦੇ ਹੋ, ਪਰ - ਹਾਏ - ਇੱਥੇ ਯੂਨੀਕੋਡ ਢਾਂਚਾ ਪਹਿਲਾਂ ਹੀ ਸਾਡੇ ਵਿਰੁੱਧ ਖੇਡ ਰਿਹਾ ਹੈ। ਅਕਸਰ ਵਰਣਮਾਲਾ ਦਾ ਮੁੱਖ ਹਿੱਸਾ ਬਲਾਕ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦਾ (ਉਦਾਹਰਣ ਵਜੋਂ, ਰੂਸੀ ਰਾਜਧਾਨੀ "ਏ" ਵਿੱਚ ਕੋਡ ਹੁੰਦਾ ਹੈ 0x0410, ਹਾਲਾਂਕਿ ਸਿਰਿਲਿਕ ਬਲਾਕ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ 0x0400). ਇਸ ਤਰ੍ਹਾਂ, ਪਹਿਲੇ 64 ਅੱਖਰਾਂ ਨੂੰ ਸਟੈਸ਼ ਵਿੱਚ ਲੈ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਵਰਣਮਾਲਾ ਦੇ ਪੂਛ ਵਾਲੇ ਹਿੱਸੇ ਤੱਕ ਪਹੁੰਚ ਗੁਆ ਸਕਦੇ ਹਾਂ।

ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਮੈਂ ਹੱਥੀਂ ਵੱਖ-ਵੱਖ ਭਾਸ਼ਾਵਾਂ ਨਾਲ ਸੰਬੰਧਿਤ ਕੁਝ ਬਲਾਕਾਂ ਵਿੱਚੋਂ ਲੰਘਿਆ, ਅਤੇ ਉਹਨਾਂ ਲਈ ਮੁੱਖ ਇੱਕ ਦੇ ਅੰਦਰ ਸਹਾਇਕ ਵਰਣਮਾਲਾ ਦੇ ਆਫਸੈੱਟ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕੀਤਾ। ਲਾਤੀਨੀ ਵਰਣਮਾਲਾ, ਇੱਕ ਅਪਵਾਦ ਵਜੋਂ, ਆਮ ਤੌਰ 'ਤੇ ਬੇਸ 64 ਵਾਂਗ ਮੁੜ ਕ੍ਰਮਬੱਧ ਕੀਤਾ ਗਿਆ ਸੀ।

ਅੰਤਿਮ ਛੋਹਾਂ

ਆਉ ਅੰਤ ਵਿੱਚ ਸੋਚੀਏ ਕਿ ਅਸੀਂ ਹੋਰ ਕਿੱਥੇ ਕੁਝ ਸੁਧਾਰ ਸਕਦੇ ਹਾਂ.

ਨੋਟ ਕਰੋ ਕਿ ਫਾਰਮੈਟ 101xxxxx xxxxxxxx xxxxxxxx ਤੱਕ ਨੰਬਰਾਂ ਨੂੰ ਏਨਕੋਡ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ 0x1FFFFF, ਅਤੇ ਯੂਨੀਕੋਡ ਪਹਿਲਾਂ, 'ਤੇ ਖਤਮ ਹੁੰਦਾ ਹੈ 0x10FFFF. ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਆਖਰੀ ਕੋਡ ਪੁਆਇੰਟ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦਰਸਾਇਆ ਜਾਵੇਗਾ 10110000 11111111 11111111. ਇਸ ਲਈ, ਅਸੀਂ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਜੇਕਰ ਪਹਿਲਾ ਬਾਈਟ ਰੂਪ ਦਾ ਹੈ 1011xxxx (ਕਿੱਥੇ xxxx 0 ਤੋਂ ਵੱਧ), ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਕੁਝ ਹੋਰ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਉੱਥੇ ਹੋਰ 15 ਅੱਖਰ ਜੋੜ ਸਕਦੇ ਹੋ ਜੋ ਇੱਕ ਬਾਈਟ ਵਿੱਚ ਏਨਕੋਡਿੰਗ ਲਈ ਨਿਰੰਤਰ ਉਪਲਬਧ ਹਨ, ਪਰ ਮੈਂ ਇਸਨੂੰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ।

ਆਓ ਉਨ੍ਹਾਂ ਯੂਨੀਕੋਡ ਬਲਾਕਾਂ ਨੂੰ ਵੇਖੀਏ ਜਿਨ੍ਹਾਂ ਨੂੰ ਹੁਣ ਤਿੰਨ ਬਾਈਟਾਂ ਦੀ ਲੋੜ ਹੈ। ਅਸਲ ਵਿੱਚ, ਜਿਵੇਂ ਕਿ ਪਹਿਲਾਂ ਹੀ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਇਹ ਚੀਨੀ ਅੱਖਰ ਹਨ - ਪਰ ਉਹਨਾਂ ਨਾਲ ਕੁਝ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ, ਉਹਨਾਂ ਵਿੱਚੋਂ 21 ਹਜ਼ਾਰ ਹਨ. ਪਰ ਹੀਰਾਗਾਨਾ ਅਤੇ ਕਾਟਾਕਾਨਾ ਵੀ ਉੱਥੇ ਉੱਡ ਗਏ - ਅਤੇ ਹੁਣ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਨਹੀਂ ਹਨ, ਦੋ ਸੌ ਤੋਂ ਘੱਟ। ਅਤੇ, ਕਿਉਂਕਿ ਅਸੀਂ ਜਾਪਾਨੀ ਨੂੰ ਯਾਦ ਕੀਤਾ, ਇੱਥੇ ਇਮੋਜੀ ਵੀ ਹਨ (ਅਸਲ ਵਿੱਚ, ਉਹ ਯੂਨੀਕੋਡ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਥਾਵਾਂ 'ਤੇ ਖਿੰਡੇ ਹੋਏ ਹਨ, ਪਰ ਮੁੱਖ ਬਲਾਕ ਰੇਂਜ ਵਿੱਚ ਹਨ। 0x1F300 - 0x1FBFF). ਜੇ ਤੁਸੀਂ ਇਸ ਤੱਥ ਬਾਰੇ ਸੋਚਦੇ ਹੋ ਕਿ ਹੁਣ ਇੱਥੇ ਇਮੋਜੀ ਹਨ ਜੋ ਇੱਕ ਵਾਰ ਵਿੱਚ ਕਈ ਕੋਡ ਪੁਆਇੰਟਾਂ ਤੋਂ ਇਕੱਠੇ ਕੀਤੇ ਗਏ ਹਨ (ਉਦਾਹਰਨ ਲਈ, ਇਮੋਜੀ ‍‍‍‍ ਵੱਧ ਤੋਂ ਵੱਧ 7 ਕੋਡ ਹੁੰਦੇ ਹਨ!), ਫਿਰ ਹਰ ਇੱਕ 'ਤੇ ਤਿੰਨ ਬਾਈਟ ਖਰਚ ਕਰਨਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸ਼ਰਮ ਵਾਲੀ ਗੱਲ ਹੈ (7 × 3 = 21 ਬਾਈਟ ਇੱਕ ਆਈਕਨ ਦੀ ਖ਼ਾਤਰ, ਇੱਕ ਡਰਾਉਣਾ ਸੁਪਨਾ)।

ਇਸ ਲਈ, ਅਸੀਂ ਇਮੋਜੀ, ਹੀਰਾਗਾਨਾ ਅਤੇ ਕਾਟਾਕਾਨਾ ਨਾਲ ਸੰਬੰਧਿਤ ਕੁਝ ਚੁਣੀਆਂ ਹੋਈਆਂ ਰੇਂਜਾਂ ਨੂੰ ਚੁਣਦੇ ਹਾਂ, ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਲਗਾਤਾਰ ਸੂਚੀ ਵਿੱਚ ਦੁਬਾਰਾ ਨੰਬਰ ਦਿੰਦੇ ਹਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਤਿੰਨ ਦੀ ਬਜਾਏ ਦੋ ਬਾਈਟਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਏਨਕੋਡ ਕਰਦੇ ਹਾਂ:

1011xxxx xxxxxxxx

ਸ਼ਾਨਦਾਰ: ਉਪਰੋਕਤ ‍‍‍ ਇਮੋਜੀ, ਜਿਸ ਵਿੱਚ 7 ​​ਕੋਡ ਪੁਆਇੰਟ ਹੁੰਦੇ ਹਨ, UTF-8 ਵਿੱਚ 25 ਬਾਈਟ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਇਸ ਵਿੱਚ ਫਿੱਟ ਕਰਦੇ ਹਾਂ 14 (ਹਰੇਕ ਕੋਡ ਪੁਆਇੰਟ ਲਈ ਬਿਲਕੁਲ ਦੋ ਬਾਈਟ) ਤਰੀਕੇ ਨਾਲ, ਹੈਬਰ ਨੇ ਇਸਨੂੰ ਹਜ਼ਮ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦਿੱਤਾ (ਪੁਰਾਣੇ ਅਤੇ ਨਵੇਂ ਸੰਪਾਦਕ ਦੋਵਾਂ ਵਿੱਚ), ਇਸ ਲਈ ਮੈਨੂੰ ਇੱਕ ਤਸਵੀਰ ਦੇ ਨਾਲ ਇਸਨੂੰ ਪਾਉਣਾ ਪਿਆ.

ਆਓ ਇੱਕ ਹੋਰ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ। ਜਿਵੇਂ ਕਿ ਸਾਨੂੰ ਯਾਦ ਹੈ, ਮੂਲ ਵਰਣਮਾਲਾ ਜ਼ਰੂਰੀ ਹੈ ਉੱਚ 6 ਬਿੱਟ, ਜਿਸ ਨੂੰ ਅਸੀਂ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹਾਂ ਅਤੇ ਹਰੇਕ ਅਗਲੇ ਡੀਕੋਡ ਕੀਤੇ ਚਿੰਨ੍ਹ ਦੇ ਕੋਡ ਨਾਲ ਗੂੰਦ ਕਰਦੇ ਹਾਂ। ਚੀਨੀ ਅੱਖਰਾਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਜੋ ਬਲਾਕ ਵਿੱਚ ਹਨ 0x4E00 - 0x9FFF, ਇਹ ਜਾਂ ਤਾਂ ਬਿੱਟ 0 ਜਾਂ 1 ਹੈ। ਇਹ ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ ਨਹੀਂ ਹੈ: ਸਾਨੂੰ ਇਹਨਾਂ ਦੋ ਮੁੱਲਾਂ ਵਿਚਕਾਰ ਵਰਣਮਾਲਾ ਨੂੰ ਲਗਾਤਾਰ ਬਦਲਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ (ਜਿਵੇਂ ਕਿ ਤਿੰਨ ਬਾਈਟ ਖਰਚ ਕਰੋ)। ਪਰ ਨੋਟ ਕਰੋ ਕਿ ਲੰਬੇ ਮੋਡ ਵਿੱਚ, ਕੋਡ ਤੋਂ ਹੀ ਅਸੀਂ ਅੱਖਰਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਘਟਾ ਸਕਦੇ ਹਾਂ ਜੋ ਅਸੀਂ ਛੋਟੇ ਮੋਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਏਨਕੋਡ ਕਰਦੇ ਹਾਂ (ਉੱਪਰ ਦੱਸੀਆਂ ਸਾਰੀਆਂ ਚਾਲਾਂ ਤੋਂ ਬਾਅਦ, ਇਹ 10240 ਹੈ) - ਫਿਰ ਹਾਇਰੋਗਲਿਫਸ ਦੀ ਰੇਂਜ ਵਿੱਚ ਸ਼ਿਫਟ ਹੋ ਜਾਵੇਗਾ 0x2600 - 0x77FF, ਅਤੇ ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਇਸ ਸਾਰੀ ਰੇਂਜ ਵਿੱਚ, ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ 6 ਬਿੱਟ (21 ਵਿੱਚੋਂ) 0 ਦੇ ਬਰਾਬਰ ਹੋਣਗੇ। ਇਸ ਤਰ੍ਹਾਂ, ਹਾਇਰੋਗਲਿਫ ਦੇ ਕ੍ਰਮ ਦੋ ਬਾਈਟ ਪ੍ਰਤੀ ਹਾਇਰੋਗਲਿਫ (ਜੋ ਕਿ ਇੰਨੀ ਵੱਡੀ ਰੇਂਜ ਲਈ ਅਨੁਕੂਲ ਹੈ) ਦੀ ਵਰਤੋਂ ਕਰਨਗੇ, ਬਿਨਾਂ ਵਰਣਮਾਲਾ ਸਵਿੱਚਾਂ ਦਾ ਕਾਰਨ ਬਣ ਰਿਹਾ ਹੈ।

ਵਿਕਲਪਕ ਹੱਲ: SCSU, BOCU-1

ਯੂਨੀਕੋਡ ਮਾਹਰ, ਲੇਖ ਦਾ ਸਿਰਲੇਖ ਪੜ੍ਹ ਕੇ, ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਇਹ ਯਾਦ ਦਿਵਾਉਣ ਲਈ ਜਲਦਬਾਜ਼ੀ ਕਰਨਗੇ ਕਿ ਯੂਨੀਕੋਡ ਮਾਪਦੰਡਾਂ ਵਿੱਚ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਮੌਜੂਦ ਹੈ। ਯੂਨੀਕੋਡ ਲਈ ਸਟੈਂਡਰਡ ਕੰਪਰੈਸ਼ਨ ਸਕੀਮ (SCSU), ਜੋ ਲੇਖ ਵਿੱਚ ਵਰਣਿਤ ਇੱਕ ਐਨਕੋਡਿੰਗ ਵਿਧੀ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ।

ਮੈਂ ਇਮਾਨਦਾਰੀ ਨਾਲ ਸਵੀਕਾਰ ਕਰਦਾ ਹਾਂ: ਮੈਨੂੰ ਇਸਦੀ ਮੌਜੂਦਗੀ ਬਾਰੇ ਉਦੋਂ ਹੀ ਪਤਾ ਲੱਗਾ ਜਦੋਂ ਮੈਂ ਆਪਣੇ ਫੈਸਲੇ ਨੂੰ ਲਿਖਣ ਵਿੱਚ ਡੂੰਘਾਈ ਨਾਲ ਡੁੱਬਿਆ ਹੋਇਆ ਸੀ। ਜੇ ਮੈਨੂੰ ਇਸ ਬਾਰੇ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਪਤਾ ਹੁੰਦਾ, ਤਾਂ ਮੈਂ ਸ਼ਾਇਦ ਆਪਣੀ ਖੁਦ ਦੀ ਪਹੁੰਚ ਨਾਲ ਆਉਣ ਦੀ ਬਜਾਏ ਇੱਕ ਲਾਗੂਕਰਨ ਲਿਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਹੁੰਦੀ।

ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ SCSU ਉਹਨਾਂ ਵਿਚਾਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜੋ ਮੈਂ ਆਪਣੇ ਆਪ ਲੈ ਕੇ ਆਇਆ ਹਾਂ ("ਵਰਣਮਾਲਾ" ਦੀ ਧਾਰਨਾ ਦੀ ਬਜਾਏ ਉਹ "ਵਿੰਡੋਜ਼" ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਅਤੇ ਮੇਰੇ ਕੋਲ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹੋਰ ਵੀ ਉਪਲਬਧ ਹਨ)। ਉਸੇ ਸਮੇਂ, ਇਸ ਫਾਰਮੈਟ ਦੇ ਵੀ ਨੁਕਸਾਨ ਹਨ: ਇਹ ਏਨਕੋਡਿੰਗ ਨਾਲੋਂ ਕੰਪਰੈਸ਼ਨ ਐਲਗੋਰਿਦਮ ਦੇ ਥੋੜਾ ਨੇੜੇ ਹੈ. ਖਾਸ ਤੌਰ 'ਤੇ, ਸਟੈਂਡਰਡ ਬਹੁਤ ਸਾਰੀਆਂ ਨੁਮਾਇੰਦਗੀ ਵਿਧੀਆਂ ਦਿੰਦਾ ਹੈ, ਪਰ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਹੈ ਕਿ ਸਰਵੋਤਮ ਨੂੰ ਕਿਵੇਂ ਚੁਣਨਾ ਹੈ - ਇਸਦੇ ਲਈ, ਏਨਕੋਡਰ ਨੂੰ ਕੁਝ ਕਿਸਮ ਦੇ ਹੇਰਿਸਟਿਕਸ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਇੱਕ SCSU ਏਨਕੋਡਰ ਜੋ ਚੰਗੀ ਪੈਕੇਜਿੰਗ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਮੇਰੇ ਐਲਗੋਰਿਦਮ ਨਾਲੋਂ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਅਤੇ ਵਧੇਰੇ ਮੁਸ਼ਕਲ ਹੋਵੇਗਾ।

ਤੁਲਨਾ ਕਰਨ ਲਈ, ਮੈਂ SCSU ਦੇ ਇੱਕ ਮੁਕਾਬਲਤਨ ਸਧਾਰਨ ਲਾਗੂਕਰਨ ਨੂੰ JavaScript ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ - ਕੋਡ ਵਾਲੀਅਮ ਦੇ ਰੂਪ ਵਿੱਚ ਇਹ ਮੇਰੇ UTF-C ਨਾਲ ਤੁਲਨਾਯੋਗ ਨਿਕਲਿਆ, ਪਰ ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ ਨਤੀਜਾ ਦਸ ਪ੍ਰਤੀਸ਼ਤ ਮਾੜਾ ਸੀ (ਕਈ ਵਾਰ ਇਹ ਇਸ ਤੋਂ ਵੱਧ ਵੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਬਹੁਤਾ ਨਹੀਂ)। ਉਦਾਹਰਨ ਲਈ, ਹਿਬਰੂ ਅਤੇ ਯੂਨਾਨੀ ਵਿੱਚ ਲਿਖਤਾਂ ਨੂੰ UTF-C ਦੁਆਰਾ ਏਨਕੋਡ ਕੀਤਾ ਗਿਆ ਸੀ SCSU ਨਾਲੋਂ 60% ਵਧੀਆ (ਸ਼ਾਇਦ ਉਹਨਾਂ ਦੇ ਸੰਖੇਪ ਵਰਣਮਾਲਾ ਦੇ ਕਾਰਨ)

ਵੱਖਰੇ ਤੌਰ 'ਤੇ, ਮੈਂ ਇਹ ਜੋੜਾਂਗਾ ਕਿ SCSU ਤੋਂ ਇਲਾਵਾ ਯੂਨੀਕੋਡ ਨੂੰ ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ ਪੇਸ਼ ਕਰਨ ਦਾ ਇੱਕ ਹੋਰ ਤਰੀਕਾ ਵੀ ਹੈ - BOCU-1, ਪਰ ਇਸਦਾ ਉਦੇਸ਼ MIME ਅਨੁਕੂਲਤਾ ਲਈ ਹੈ (ਜਿਸਦੀ ਮੈਨੂੰ ਲੋੜ ਨਹੀਂ ਸੀ) ਅਤੇ ਏਨਕੋਡਿੰਗ ਲਈ ਥੋੜਾ ਵੱਖਰਾ ਤਰੀਕਾ ਲੈਂਦਾ ਹੈ। ਮੈਂ ਇਸਦੀ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਦਾ ਮੁਲਾਂਕਣ ਨਹੀਂ ਕੀਤਾ ਹੈ, ਪਰ ਇਹ ਮੈਨੂੰ ਜਾਪਦਾ ਹੈ ਕਿ ਇਹ SCSU ਤੋਂ ਵੱਧ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਨਹੀਂ ਹੈ.

ਸੰਭਵ ਸੁਧਾਰ

ਮੇਰੇ ਦੁਆਰਾ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਐਲਗੋਰਿਦਮ ਡਿਜ਼ਾਈਨ ਦੁਆਰਾ ਸਰਵ ਵਿਆਪਕ ਨਹੀਂ ਹੈ (ਸ਼ਾਇਦ ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਮੇਰੇ ਟੀਚੇ ਯੂਨੀਕੋਡ ਕੰਸੋਰਟੀਅਮ ਦੇ ਟੀਚਿਆਂ ਤੋਂ ਬਹੁਤ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ)। ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਜ਼ਿਕਰ ਕੀਤਾ ਹੈ ਕਿ ਇਹ ਮੁੱਖ ਤੌਰ 'ਤੇ ਇੱਕ ਕੰਮ ਲਈ ਵਿਕਸਤ ਕੀਤਾ ਗਿਆ ਸੀ (ਇੱਕ ਪ੍ਰੀਫਿਕਸ ਟ੍ਰੀ ਵਿੱਚ ਇੱਕ ਬਹੁ-ਭਾਸ਼ਾਈ ਸ਼ਬਦਕੋਸ਼ ਨੂੰ ਸਟੋਰ ਕਰਨਾ), ਅਤੇ ਇਸ ਦੀਆਂ ਕੁਝ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੂਜੇ ਕੰਮਾਂ ਲਈ ਚੰਗੀ ਤਰ੍ਹਾਂ ਅਨੁਕੂਲ ਨਹੀਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਪਰ ਇਹ ਤੱਥ ਕਿ ਇਹ ਇੱਕ ਮਿਆਰੀ ਨਹੀਂ ਹੈ ਇੱਕ ਪਲੱਸ ਹੋ ਸਕਦਾ ਹੈ - ਤੁਸੀਂ ਇਸਨੂੰ ਆਸਾਨੀ ਨਾਲ ਆਪਣੀਆਂ ਲੋੜਾਂ ਮੁਤਾਬਕ ਸੋਧ ਸਕਦੇ ਹੋ.

ਉਦਾਹਰਨ ਲਈ, ਸਪੱਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਤੁਸੀਂ ਰਾਜ ਦੀ ਮੌਜੂਦਗੀ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾ ਸਕਦੇ ਹੋ, ਸਟੇਟਲੈਸ ਕੋਡਿੰਗ ਬਣਾ ਸਕਦੇ ਹੋ - ਬਸ ਵੇਰੀਏਬਲਾਂ ਨੂੰ ਅਪਡੇਟ ਨਾ ਕਰੋ offs, auxOffs и is21Bit ਏਨਕੋਡਰ ਅਤੇ ਡੀਕੋਡਰ ਵਿੱਚ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਇੱਕੋ ਵਰਣਮਾਲਾ ਦੇ ਅੱਖਰਾਂ ਦੇ ਕ੍ਰਮ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਪੈਕ ਕਰਨਾ ਸੰਭਵ ਨਹੀਂ ਹੋਵੇਗਾ, ਪਰ ਇਸ ਗੱਲ ਦੀ ਗਾਰੰਟੀ ਹੋਵੇਗੀ ਕਿ ਉਹੀ ਅੱਖਰ ਹਮੇਸ਼ਾਂ ਇੱਕੋ ਬਾਈਟ ਨਾਲ ਏਨਕੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪ੍ਰਸੰਗ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਤੁਸੀਂ ਡਿਫੌਲਟ ਸਥਿਤੀ ਨੂੰ ਬਦਲ ਕੇ ਇੱਕ ਖਾਸ ਭਾਸ਼ਾ ਲਈ ਏਨਕੋਡਰ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰ ਸਕਦੇ ਹੋ - ਉਦਾਹਰਨ ਲਈ, ਰੂਸੀ ਟੈਕਸਟ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਕਰਦੇ ਹੋਏ, ਸ਼ੁਰੂ ਵਿੱਚ ਏਨਕੋਡਰ ਅਤੇ ਡੀਕੋਡਰ ਸੈੱਟ ਕਰੋ offs = 0x0400 и auxOffs = 0. ਇਹ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਸਟੇਟਲੈੱਸ ਮੋਡ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਅਰਥ ਰੱਖਦਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਇਹ ਪੁਰਾਣੇ ਅੱਠ-ਬਿੱਟ ਏਨਕੋਡਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਸਮਾਨ ਹੋਵੇਗਾ, ਪਰ ਲੋੜ ਅਨੁਸਾਰ ਸਾਰੇ ਯੂਨੀਕੋਡ ਤੋਂ ਅੱਖਰ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਯੋਗਤਾ ਨੂੰ ਹਟਾਏ ਬਿਨਾਂ।

ਪਹਿਲਾਂ ਜ਼ਿਕਰ ਕੀਤੀ ਗਈ ਇੱਕ ਹੋਰ ਕਮੀ ਇਹ ਹੈ ਕਿ UTF-C ਵਿੱਚ ਏਨਕੋਡ ਕੀਤੇ ਵੱਡੇ ਟੈਕਸਟ ਵਿੱਚ ਇੱਕ ਆਰਬਿਟਰੇਰੀ ਬਾਈਟ ਦੇ ਨੇੜੇ ਅੱਖਰ ਸੀਮਾ ਲੱਭਣ ਦਾ ਕੋਈ ਤੇਜ਼ ਤਰੀਕਾ ਨਹੀਂ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਆਖਰੀ ਨੂੰ ਕੱਟਦੇ ਹੋ, ਕਹੋ, ਏਨਕੋਡਡ ਬਫਰ ਤੋਂ 100 ਬਾਈਟ, ਤਾਂ ਤੁਹਾਨੂੰ ਕੂੜਾ ਹੋਣ ਦਾ ਖਤਰਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਕੁਝ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਏਨਕੋਡਿੰਗ ਮਲਟੀ-ਗੀਗਾਬਾਈਟ ਲਾਗਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਨਹੀਂ ਬਣਾਈ ਗਈ ਹੈ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਨੂੰ ਠੀਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਬਾਈਟ 0xBF ਕਦੇ ਵੀ ਪਹਿਲੀ ਬਾਈਟ ਦੇ ਰੂਪ ਵਿੱਚ ਦਿਖਾਈ ਨਹੀਂ ਦੇਣਾ ਚਾਹੀਦਾ (ਪਰ ਦੂਜੀ ਜਾਂ ਤੀਜੀ ਹੋ ਸਕਦੀ ਹੈ)। ਇਸਲਈ, ਏਨਕੋਡਿੰਗ ਕਰਦੇ ਸਮੇਂ, ਤੁਸੀਂ ਕ੍ਰਮ ਨੂੰ ਪਾ ਸਕਦੇ ਹੋ 0xBF 0xBF 0xBF ਹਰ, ਕਹੋ, 10 KB - ਫਿਰ, ਜੇਕਰ ਤੁਹਾਨੂੰ ਇੱਕ ਸੀਮਾ ਲੱਭਣ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇਹ ਚੁਣੇ ਹੋਏ ਟੁਕੜੇ ਨੂੰ ਸਕੈਨ ਕਰਨ ਲਈ ਕਾਫੀ ਹੋਵੇਗਾ ਜਦੋਂ ਤੱਕ ਇੱਕ ਸਮਾਨ ਮਾਰਕਰ ਨਹੀਂ ਮਿਲਦਾ। ਪਿਛਲੇ ਦੇ ਬਾਅਦ 0xBF ਇੱਕ ਅੱਖਰ ਦੀ ਸ਼ੁਰੂਆਤ ਹੋਣ ਦੀ ਗਰੰਟੀ ਹੈ। (ਡੀਕੋਡਿੰਗ ਕਰਦੇ ਸਮੇਂ, ਤਿੰਨ ਬਾਈਟਾਂ ਦੇ ਇਸ ਕ੍ਰਮ ਨੂੰ, ਬੇਸ਼ਕ, ਅਣਡਿੱਠ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।)

ਸੰਖੇਪ ਵਿੱਚ

ਜੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਪੜ੍ਹ ਲਿਆ ਹੈ, ਤਾਂ ਵਧਾਈਆਂ! ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਤੁਸੀਂ, ਮੇਰੇ ਵਾਂਗ, ਯੂਨੀਕੋਡ ਦੀ ਬਣਤਰ ਬਾਰੇ ਕੁਝ ਨਵਾਂ ਸਿੱਖਿਆ (ਜਾਂ ਤੁਹਾਡੀ ਯਾਦਦਾਸ਼ਤ ਨੂੰ ਤਾਜ਼ਾ ਕੀਤਾ)।

ਡੈਮੋ ਪੰਨਾ. ਹਿਬਰੂ ਦੀ ਉਦਾਹਰਨ UTF-8 ਅਤੇ SCSU ਦੋਵਾਂ ਦੇ ਫਾਇਦੇ ਦਿਖਾਉਂਦੀ ਹੈ।

ਉਪਰੋਕਤ ਵਰਣਿਤ ਖੋਜ ਨੂੰ ਮਿਆਰਾਂ 'ਤੇ ਇੱਕ ਘੁਸਪੈਠ ਨਹੀਂ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਮੈਂ ਆਪਣੇ ਕੰਮ ਦੇ ਨਤੀਜਿਆਂ ਤੋਂ ਆਮ ਤੌਰ 'ਤੇ ਸੰਤੁਸ਼ਟ ਹਾਂ, ਇਸ ਲਈ ਮੈਂ ਉਨ੍ਹਾਂ ਤੋਂ ਖੁਸ਼ ਹਾਂ ਸਾਂਝਾ ਕਰੋ: ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਛੋਟੀ JS ਲਾਇਬ੍ਰੇਰੀ ਦਾ ਵਜ਼ਨ ਸਿਰਫ਼ 1710 ਬਾਈਟ ਹੁੰਦਾ ਹੈ (ਅਤੇ ਕੋਈ ਨਿਰਭਰਤਾ ਨਹੀਂ ਹੁੰਦੀ ਹੈ)। ਜਿਵੇਂ ਕਿ ਮੈਂ ਉੱਪਰ ਦੱਸਿਆ ਹੈ, ਉਸਦਾ ਕੰਮ ਇੱਥੇ ਪਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਡੈਮੋ ਪੰਨਾ (ਇੱਥੇ ਟੈਕਸਟਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਵੀ ਹੈ ਜਿਸ 'ਤੇ ਇਸਦੀ ਤੁਲਨਾ UTF-8 ਅਤੇ SCSU ਨਾਲ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ)।

ਅੰਤ ਵਿੱਚ, ਮੈਂ ਇੱਕ ਵਾਰ ਫਿਰ ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਵੱਲ ਧਿਆਨ ਖਿੱਚਾਂਗਾ ਜਿਨ੍ਹਾਂ ਵਿੱਚ UTF-C ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਇਸ ਦੀ ਕੋਈ ਕੀਮਤ ਨਹੀਂ:

• ਜੇਕਰ ਤੁਹਾਡੀਆਂ ਲਾਈਨਾਂ ਕਾਫ਼ੀ ਲੰਬੀਆਂ ਹਨ (100-200 ਅੱਖਰਾਂ ਤੋਂ)। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਕੰਪਰੈਸ਼ਨ ਐਲਗੋਰਿਦਮ ਜਿਵੇਂ ਕਿ ਡੀਫਲੇਟ ਦੀ ਵਰਤੋਂ ਕਰਨ ਬਾਰੇ ਸੋਚਣਾ ਚਾਹੀਦਾ ਹੈ.
• ਜੇਕਰ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ ASCII ਪਾਰਦਰਸ਼ਤਾ, ਯਾਨੀ, ਇਹ ਤੁਹਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਏਨਕੋਡ ਕੀਤੇ ਕ੍ਰਮਾਂ ਵਿੱਚ ASCII ਕੋਡ ਸ਼ਾਮਲ ਨਹੀਂ ਹਨ ਜੋ ਅਸਲ ਸਤਰ ਵਿੱਚ ਨਹੀਂ ਸਨ। ਇਸਦੀ ਲੋੜ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜੇਕਰ, ਜਦੋਂ ਤੀਜੀ-ਧਿਰ APIs (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਡੇਟਾਬੇਸ ਨਾਲ ਕੰਮ ਕਰਨਾ) ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਏਨਕੋਡਿੰਗ ਨਤੀਜੇ ਨੂੰ ਬਾਈਟਾਂ ਦੇ ਐਬਸਟਰੈਕਟ ਸੈੱਟ ਵਜੋਂ ਪਾਸ ਕਰਦੇ ਹੋ, ਨਾ ਕਿ ਸਤਰ ਵਜੋਂ। ਨਹੀਂ ਤਾਂ, ਤੁਹਾਨੂੰ ਅਚਾਨਕ ਕਮਜ਼ੋਰੀਆਂ ਹੋਣ ਦਾ ਖਤਰਾ ਹੈ।
• ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਮਨਮਾਨੇ ਔਫਸੈੱਟ 'ਤੇ ਅੱਖਰ ਸੀਮਾਵਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਲੱਭਣ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੁੰਦੇ ਹੋ (ਉਦਾਹਰਣ ਲਈ, ਜਦੋਂ ਇੱਕ ਲਾਈਨ ਦਾ ਹਿੱਸਾ ਖਰਾਬ ਹੋ ਜਾਂਦਾ ਹੈ)। ਇਹ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਸਿਰਫ ਸ਼ੁਰੂ ਤੋਂ ਲਾਈਨ ਨੂੰ ਸਕੈਨ ਕਰਕੇ (ਜਾਂ ਪਿਛਲੇ ਭਾਗ ਵਿੱਚ ਵਰਣਨ ਕੀਤੀ ਸੋਧ ਨੂੰ ਲਾਗੂ ਕਰਕੇ)।
• ਜੇਕਰ ਤੁਹਾਨੂੰ ਸਟ੍ਰਿੰਗਜ਼ ਦੀ ਸਮੱਗਰੀ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਕਾਰਵਾਈ ਕਰਨ ਦੀ ਲੋੜ ਹੈ (ਉਨ੍ਹਾਂ ਨੂੰ ਛਾਂਟੋ, ਉਹਨਾਂ ਵਿੱਚ ਸਬਸਟਰਿੰਗਾਂ ਦੀ ਖੋਜ ਕਰੋ, ਜੋੜੋ)। ਇਸ ਲਈ ਸਟ੍ਰਿੰਗਾਂ ਨੂੰ ਪਹਿਲਾਂ ਡੀਕੋਡ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਇਸਲਈ ਇਹਨਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ UTF-C UTF-8 ਨਾਲੋਂ ਹੌਲੀ ਹੋਵੇਗਾ (ਪਰ ਕੰਪਰੈਸ਼ਨ ਐਲਗੋਰਿਦਮ ਨਾਲੋਂ ਤੇਜ਼)। ਕਿਉਂਕਿ ਇੱਕੋ ਸਤਰ ਨੂੰ ਹਮੇਸ਼ਾ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਏਨਕੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਡੀਕੋਡਿੰਗ ਦੀ ਸਹੀ ਤੁਲਨਾ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ ਅਤੇ ਬਾਈਟ-ਬਾਈ-ਬਾਈਟ ਆਧਾਰ 'ਤੇ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

ਅੱਪਡੇਟ: ਯੂਜ਼ਰ ਟਿਓਮੀਚ ਹੇਠ ਟਿੱਪਣੀ ਵਿੱਚ UTF-C ਦੀਆਂ ਲਾਗੂ ਹੋਣ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਉਜਾਗਰ ਕਰਨ ਵਾਲਾ ਗ੍ਰਾਫ ਪੋਸਟ ਕੀਤਾ ਹੈ। ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ UTF-C ਇੱਕ ਆਮ-ਉਦੇਸ਼ ਕੰਪਰੈਸ਼ਨ ਐਲਗੋਰਿਦਮ (LZW ਦੀ ਇੱਕ ਪਰਿਵਰਤਨ) ਨਾਲੋਂ ਵਧੇਰੇ ਕੁਸ਼ਲ ਹੈ ਜਦੋਂ ਤੱਕ ਪੈਕ ਕੀਤੀ ਸਤਰ ਛੋਟੀ ਹੈ ~140 ਅੱਖਰ (ਹਾਲਾਂਕਿ, ਮੈਂ ਨੋਟ ਕਰਦਾ ਹਾਂ ਕਿ ਤੁਲਨਾ ਇੱਕ ਟੈਕਸਟ 'ਤੇ ਕੀਤੀ ਗਈ ਸੀ; ਦੂਜੀਆਂ ਭਾਸ਼ਾਵਾਂ ਲਈ ਨਤੀਜਾ ਵੱਖਰਾ ਹੋ ਸਕਦਾ ਹੈ)।


ਸਰੋਤ: www.habr.com