ಮತ್ತೊಂದು ಬೈಕು: ನಾವು ಯುನಿಕೋಡ್ ತಂತಿಗಳನ್ನು UTF-30 ಗಿಂತ 60-8% ಹೆಚ್ಚು ಕಾಂಪ್ಯಾಕ್ಟ್ ಸಂಗ್ರಹಿಸುತ್ತೇವೆ

ನೀವು ಡೆವಲಪರ್ ಆಗಿದ್ದರೆ ಮತ್ತು ಎನ್‌ಕೋಡಿಂಗ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಕಾರ್ಯವನ್ನು ನೀವು ಎದುರಿಸುತ್ತಿದ್ದರೆ, ಯುನಿಕೋಡ್ ಯಾವಾಗಲೂ ಸರಿಯಾದ ಪರಿಹಾರವಾಗಿದೆ. ನಿರ್ದಿಷ್ಟ ಪ್ರಾತಿನಿಧ್ಯ ವಿಧಾನವು ಸಂದರ್ಭವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ, ಆದರೆ ಹೆಚ್ಚಾಗಿ ಇಲ್ಲಿ ಸಾರ್ವತ್ರಿಕ ಉತ್ತರವಿದೆ - UTF-8. ಅದರ ಬಗ್ಗೆ ಒಳ್ಳೆಯ ವಿಷಯವೆಂದರೆ ಅದು ಎಲ್ಲಾ ಯುನಿಕೋಡ್ ಅಕ್ಷರಗಳನ್ನು ಖರ್ಚು ಮಾಡದೆ ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ ತುಂಬಾ ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಬಹಳಷ್ಟು ಬೈಟ್‌ಗಳು. ನಿಜ, ಲ್ಯಾಟಿನ್ ವರ್ಣಮಾಲೆಗಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಬಳಸುವ ಭಾಷೆಗಳಿಗೆ, "ಹೆಚ್ಚು ಅಲ್ಲ" ಕನಿಷ್ಠ ಪ್ರತಿ ಅಕ್ಷರಕ್ಕೆ ಎರಡು ಬೈಟ್‌ಗಳು. ಕೇವಲ 256 ಲಭ್ಯವಿರುವ ಅಕ್ಷರಗಳಿಗೆ ನಮ್ಮನ್ನು ಸೀಮಿತಗೊಳಿಸುವ ಇತಿಹಾಸಪೂರ್ವ ಎನ್‌ಕೋಡಿಂಗ್‌ಗಳಿಗೆ ಹಿಂತಿರುಗದೆ ನಾವು ಉತ್ತಮವಾಗಿ ಮಾಡಬಹುದೇ?

ಈ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಲು ಮತ್ತು UTF-8 ನಲ್ಲಿನ ಪುನರುಕ್ತಿಯನ್ನು ಸೇರಿಸದೆಯೇ ಪ್ರಪಂಚದ ಹೆಚ್ಚಿನ ಭಾಷೆಗಳಲ್ಲಿ ಸಾಲುಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ತುಲನಾತ್ಮಕವಾಗಿ ಸರಳವಾದ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ನನ್ನ ಪ್ರಯತ್ನವನ್ನು ನಾನು ಕೆಳಗೆ ಪರಿಚಯಿಸುತ್ತೇನೆ.

ಹಕ್ಕು ನಿರಾಕರಣೆ. ನಾನು ತಕ್ಷಣ ಕೆಲವು ಪ್ರಮುಖ ಕಾಯ್ದಿರಿಸುವಿಕೆಗಳನ್ನು ಮಾಡುತ್ತೇನೆ: ವಿವರಿಸಿದ ಪರಿಹಾರವನ್ನು UTF-8 ಗೆ ಸಾರ್ವತ್ರಿಕ ಬದಲಿಯಾಗಿ ನೀಡಲಾಗಿಲ್ಲ, ಇದು ಪ್ರಕರಣಗಳ ಕಿರಿದಾದ ಪಟ್ಟಿಯಲ್ಲಿ ಮಾತ್ರ ಸೂಕ್ತವಾಗಿದೆ (ಅವುಗಳ ಮೇಲೆ ಕೆಳಗೆ ಹೆಚ್ಚು), ಮತ್ತು ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ ಮೂರನೇ ವ್ಯಕ್ತಿಯ API ಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಇದನ್ನು ಬಳಸಬಾರದು (ಅದರ ಬಗ್ಗೆ ತಿಳಿದಿಲ್ಲ). ಹೆಚ್ಚಾಗಿ, ಸಾಮಾನ್ಯ ಉದ್ದೇಶದ ಸಂಕೋಚನ ಕ್ರಮಾವಳಿಗಳು (ಉದಾಹರಣೆಗೆ, ಡಿಫ್ಲೇಟ್) ದೊಡ್ಡ ಪ್ರಮಾಣದ ಪಠ್ಯ ಡೇಟಾದ ಕಾಂಪ್ಯಾಕ್ಟ್ ಸಂಗ್ರಹಣೆಗೆ ಸೂಕ್ತವಾಗಿದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಈಗಾಗಲೇ ನನ್ನ ಪರಿಹಾರವನ್ನು ರಚಿಸುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ನಾನು ಯೂನಿಕೋಡ್‌ನಲ್ಲಿಯೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮಾನದಂಡವನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇನೆ, ಅದು ಅದೇ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ - ಇದು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ (ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಕೆಟ್ಟದಾಗಿದೆ), ಆದರೆ ಇನ್ನೂ ಇದು ಅಂಗೀಕೃತ ಮಾನದಂಡವಾಗಿದೆ ಮತ್ತು ಕೇವಲ ಹಾಕಲಾಗಿಲ್ಲ ಮೊಣಕಾಲಿನ ಮೇಲೆ ಒಟ್ಟಿಗೆ. ಅವನ ಬಗ್ಗೆಯೂ ಹೇಳುತ್ತೇನೆ.

ಯುನಿಕೋಡ್ ಮತ್ತು 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, ಮತ್ತು ಚೈನೀಸ್ ಅಥವಾ, ಉದಾಹರಣೆಗೆ, ಜಾರ್ಜಿಯನ್ ಅನ್ನು ಅದರಲ್ಲಿ ಸೇರಿಸಲಾಗಿಲ್ಲ. ಸಿರಿಲಿಕ್ ಮತ್ತು ಇತರ ಐದು ವರ್ಣಮಾಲೆಗಳು - ಹುರ್ರೇ - ಅದೃಷ್ಟ, ಪ್ರತಿ ಪಾತ್ರಕ್ಕೆ 2 ಬೈಟ್‌ಗಳು.

ಇದು ಏಕೆ ಸಂಭವಿಸುತ್ತದೆ? UTF-8 ಅಕ್ಷರ ಸಂಕೇತಗಳನ್ನು ಹೇಗೆ ಪ್ರತಿನಿಧಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ:

ನೇರವಾಗಿ ಸಂಖ್ಯೆಗಳನ್ನು ಪ್ರತಿನಿಧಿಸಲು, ಚಿಹ್ನೆಯೊಂದಿಗೆ ಗುರುತಿಸಲಾದ ಬಿಟ್‌ಗಳನ್ನು ಇಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ x. ಎರಡು-ಬೈಟ್ ದಾಖಲೆಯಲ್ಲಿ ಕೇವಲ 11 ಅಂತಹ ಬಿಟ್‌ಗಳು (16 ರಲ್ಲಿ) ಇವೆ ಎಂದು ನೋಡಬಹುದು. ಇಲ್ಲಿ ಪ್ರಮುಖ ಬಿಟ್‌ಗಳು ಸಹಾಯಕ ಕಾರ್ಯವನ್ನು ಮಾತ್ರ ಹೊಂದಿವೆ. ನಾಲ್ಕು-ಬೈಟ್ ದಾಖಲೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ಕೋಡ್ ಪಾಯಿಂಟ್ ಸಂಖ್ಯೆಗೆ 21 ಬಿಟ್‌ಗಳಲ್ಲಿ 32 ಅನ್ನು ಹಂಚಲಾಗುತ್ತದೆ - ಮೂರು ಬೈಟ್‌ಗಳು (ಒಟ್ಟು 24 ಬಿಟ್‌ಗಳನ್ನು ನೀಡುತ್ತದೆ) ಸಾಕು ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಸೇವಾ ಗುರುತುಗಳು ಹೆಚ್ಚು ತಿನ್ನುತ್ತವೆ.

ಇದು ಕೆಟ್ಟದ್ದೇ? ನಿಜವಾಗಿಯೂ ಅಲ್ಲ. ಒಂದೆಡೆ, ನಾವು ಬಾಹ್ಯಾಕಾಶದ ಬಗ್ಗೆ ಹೆಚ್ಚು ಕಾಳಜಿ ವಹಿಸಿದರೆ, ನಾವು ಸಂಕುಚಿತ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಅದು ಎಲ್ಲಾ ಹೆಚ್ಚುವರಿ ಎಂಟ್ರೊಪಿ ಮತ್ತು ಪುನರಾವರ್ತನೆಯನ್ನು ಸುಲಭವಾಗಿ ತೆಗೆದುಹಾಕುತ್ತದೆ. ಮತ್ತೊಂದೆಡೆ, ಯುನಿಕೋಡ್‌ನ ಗುರಿಯು ಅತ್ಯಂತ ಸಾರ್ವತ್ರಿಕ ಕೋಡಿಂಗ್ ಅನ್ನು ಒದಗಿಸುವುದು. ಉದಾಹರಣೆಗೆ, ನಾವು UTF-8 ನಲ್ಲಿ ಎನ್‌ಕೋಡ್ ಮಾಡಲಾದ ರೇಖೆಯನ್ನು ಈ ಹಿಂದೆ ASCII ನೊಂದಿಗೆ ಮಾತ್ರ ಕೆಲಸ ಮಾಡಿದ ಕೋಡ್‌ಗೆ ವಹಿಸಿಕೊಡಬಹುದು ಮತ್ತು ASCII ಶ್ರೇಣಿಯಿಂದ ನಿಜವಾಗಿ ಇಲ್ಲದ ಅಕ್ಷರವನ್ನು ಅದು ನೋಡುತ್ತದೆ ಎಂದು ಭಯಪಡಬೇಡಿ (ಎಲ್ಲಾ ನಂತರ, UTF-8 ನಲ್ಲಿ ಎಲ್ಲಾ ಶೂನ್ಯ ಬಿಟ್‌ನಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಬೈಟ್‌ಗಳು - ಇದು ನಿಖರವಾಗಿ ASCII ಆಗಿದೆ). ಮತ್ತು ನಾವು ಮೊದಲಿನಿಂದಲೂ ಡಿಕೋಡ್ ಮಾಡದೆಯೇ ದೊಡ್ಡ ದಾರದಿಂದ ಸಣ್ಣ ಬಾಲವನ್ನು ಕತ್ತರಿಸಲು ಬಯಸಿದರೆ (ಅಥವಾ ಹಾನಿಗೊಳಗಾದ ವಿಭಾಗದ ನಂತರ ಮಾಹಿತಿಯ ಭಾಗವನ್ನು ಮರುಸ್ಥಾಪಿಸಿ), ಅಕ್ಷರ ಪ್ರಾರಂಭವಾಗುವ ಆಫ್‌ಸೆಟ್ ಅನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ನಮಗೆ ಸುಲಭವಾಗಿದೆ (ಇದು ಸಾಕು. ಸ್ವಲ್ಪ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಹೊಂದಿರುವ ಬೈಟ್‌ಗಳನ್ನು ಬಿಟ್ಟುಬಿಡಲು 10).

ಹಾಗಾದರೆ ಹೊಸದನ್ನು ಏಕೆ ಆವಿಷ್ಕರಿಸಬೇಕು?

ಅದೇ ಸಮಯದಲ್ಲಿ, ಡಿಫ್ಲೇಟ್‌ನಂತಹ ಕಂಪ್ರೆಷನ್ ಅಲ್ಗಾರಿದಮ್‌ಗಳು ಕಳಪೆಯಾಗಿ ಅನ್ವಯಿಸುವ ಸಂದರ್ಭಗಳು ಸಾಂದರ್ಭಿಕವಾಗಿ ಇವೆ, ಆದರೆ ನೀವು ತಂತಿಗಳ ಕಾಂಪ್ಯಾಕ್ಟ್ ಸಂಗ್ರಹಣೆಯನ್ನು ಸಾಧಿಸಲು ಬಯಸುತ್ತೀರಿ. ವೈಯಕ್ತಿಕವಾಗಿ, ಕಟ್ಟಡದ ಬಗ್ಗೆ ಯೋಚಿಸುವಾಗ ನಾನು ಈ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಿದೆ ಸಂಕುಚಿತ ಪೂರ್ವಪ್ರತ್ಯಯ ಮರ ಅನಿಯಂತ್ರಿತ ಭಾಷೆಗಳಲ್ಲಿನ ಪದಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ದೊಡ್ಡ ನಿಘಂಟಿಗಾಗಿ. ಒಂದೆಡೆ, ಪ್ರತಿ ಪದವು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ಕುಗ್ಗಿಸುವುದು ನಿಷ್ಪರಿಣಾಮಕಾರಿಯಾಗಿರುತ್ತದೆ. ಮತ್ತೊಂದೆಡೆ, ನಾನು ಪರಿಗಣಿಸಿದ ಮರದ ಅನುಷ್ಠಾನವನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ ಆದ್ದರಿಂದ ಸಂಗ್ರಹಿಸಲಾದ ಸ್ಟ್ರಿಂಗ್‌ನ ಪ್ರತಿಯೊಂದು ಬೈಟ್ ಪ್ರತ್ಯೇಕ ಮರದ ಶೃಂಗವನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅವುಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ತುಂಬಾ ಉಪಯುಕ್ತವಾಗಿದೆ. ನನ್ನ ಗ್ರಂಥಾಲಯದಲ್ಲಿ Az.js (ಇಲ್ಲಿರುವಂತೆ ಪೈಮಾರ್ಫಿ 2, ಇದು ಆಧರಿಸಿದೆ) ಇದೇ ರೀತಿಯ ಸಮಸ್ಯೆಯನ್ನು ಸರಳವಾಗಿ ಪರಿಹರಿಸಬಹುದು - ತಂತಿಗಳನ್ನು ಪ್ಯಾಕ್ ಮಾಡಲಾಗಿದೆ DAWG- ನಿಘಂಟು, ಅಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ ಉತ್ತಮ ಹಳೆಯ CP1251. ಆದರೆ, ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸುಲಭವಾದಂತೆ, ಇದು ಸೀಮಿತ ವರ್ಣಮಾಲೆಗೆ ಮಾತ್ರ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ - ಅಂತಹ ನಿಘಂಟಿಗೆ ಚೈನೀಸ್‌ನಲ್ಲಿರುವ ಸಾಲನ್ನು ಸೇರಿಸಲಾಗುವುದಿಲ್ಲ.

ಪ್ರತ್ಯೇಕವಾಗಿ, ಅಂತಹ ಡೇಟಾ ರಚನೆಯಲ್ಲಿ UTF-8 ಅನ್ನು ಬಳಸುವಾಗ ಉದ್ಭವಿಸುವ ಇನ್ನೊಂದು ಅಹಿತಕರ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸವನ್ನು ನಾನು ಗಮನಿಸಲು ಬಯಸುತ್ತೇನೆ. ಮೇಲಿನ ಚಿತ್ರವು ಅಕ್ಷರವನ್ನು ಎರಡು ಬೈಟ್‌ಗಳಾಗಿ ಬರೆಯುವಾಗ, ಅದರ ಸಂಖ್ಯೆಗೆ ಸಂಬಂಧಿಸಿದ ಬಿಟ್‌ಗಳು ಸಾಲಾಗಿ ಬರುವುದಿಲ್ಲ, ಆದರೆ ಜೋಡಿ ಬಿಟ್‌ಗಳಿಂದ ಬೇರ್ಪಡುತ್ತವೆ. 10 ಮಧ್ಯದಲ್ಲಿ: 110xxxxx 10xxxxxx. ಈ ಕಾರಣದಿಂದಾಗಿ, ಎರಡನೇ ಬೈಟ್‌ನ ಕೆಳಗಿನ 6 ಬಿಟ್‌ಗಳು ಅಕ್ಷರ ಕೋಡ್‌ನಲ್ಲಿ ಉಕ್ಕಿ ಹರಿಯುವಾಗ (ಅಂದರೆ, ಪರಿವರ್ತನೆ ಸಂಭವಿಸುತ್ತದೆ 10111111 → 10000000), ನಂತರ ಮೊದಲ ಬೈಟ್ ಕೂಡ ಬದಲಾಗುತ್ತದೆ. "p" ಅಕ್ಷರವನ್ನು ಬೈಟ್ಗಳಿಂದ ಸೂಚಿಸಲಾಗುತ್ತದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ 0xD0 0xBF, ಮತ್ತು ಮುಂದಿನ "r" ಈಗಾಗಲೇ ಆಗಿದೆ 0xD1 0x80. ಪೂರ್ವಪ್ರತ್ಯಯ ಮರದಲ್ಲಿ, ಇದು ಮೂಲ ನೋಡ್ ಅನ್ನು ಎರಡಾಗಿ ವಿಭಜಿಸಲು ಕಾರಣವಾಗುತ್ತದೆ - ಪೂರ್ವಪ್ರತ್ಯಯಕ್ಕೆ ಒಂದು 0xD0, ಮತ್ತು ಇನ್ನೊಂದು 0xD1 (ಆದರೂ ಸಂಪೂರ್ಣ ಸಿರಿಲಿಕ್ ವರ್ಣಮಾಲೆಯನ್ನು ಎರಡನೇ ಬೈಟ್‌ನಿಂದ ಮಾತ್ರ ಎನ್‌ಕೋಡ್ ಮಾಡಬಹುದು).

ನನಗೆ ಏನು ಸಿಕ್ಕಿತು

ಈ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಿದಾಗ, ನಾನು ಬಿಟ್‌ಗಳೊಂದಿಗೆ ಆಟಗಳನ್ನು ಆಡುವುದನ್ನು ಅಭ್ಯಾಸ ಮಾಡಲು ನಿರ್ಧರಿಸಿದೆ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಒಟ್ಟಾರೆಯಾಗಿ ಯೂನಿಕೋಡ್‌ನ ರಚನೆಯೊಂದಿಗೆ ಸ್ವಲ್ಪ ಚೆನ್ನಾಗಿ ಪರಿಚಯ ಮಾಡಿಕೊಳ್ಳುತ್ತೇನೆ. ಫಲಿತಾಂಶವು UTF-C ಎನ್‌ಕೋಡಿಂಗ್ ಸ್ವರೂಪವಾಗಿದೆ ("C" ಫಾರ್ ಕಾಂಪ್ಯಾಕ್ಟ್), ಇದು ಪ್ರತಿ ಕೋಡ್ ಪಾಯಿಂಟ್‌ಗೆ 3 ಬೈಟ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಖರ್ಚು ಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ಆಗಾಗ್ಗೆ ನಿಮಗೆ ಖರ್ಚು ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ ಸಂಪೂರ್ಣ ಎನ್ಕೋಡ್ ಮಾಡಿದ ಸಾಲಿಗೆ ಒಂದು ಹೆಚ್ಚುವರಿ ಬೈಟ್. ಇದು ಅನೇಕ ASCII ಅಲ್ಲದ ವರ್ಣಮಾಲೆಗಳಲ್ಲಿ ಅಂತಹ ಎನ್ಕೋಡಿಂಗ್ ಆಗಿ ಹೊರಹೊಮ್ಮುತ್ತದೆ ಎಂಬ ಅಂಶಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ UTF-30 ಗಿಂತ 60-8% ಹೆಚ್ಚು ಕಾಂಪ್ಯಾಕ್ಟ್.

ರೂಪದಲ್ಲಿ ಎನ್ಕೋಡಿಂಗ್ ಮತ್ತು ಡಿಕೋಡಿಂಗ್ ಅಲ್ಗಾರಿದಮ್ಗಳ ಅನುಷ್ಠಾನದ ಉದಾಹರಣೆಗಳನ್ನು ನಾನು ಪ್ರಸ್ತುತಪಡಿಸಿದ್ದೇನೆ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಮತ್ತು ಗೋ ಲೈಬ್ರರಿಗಳು, ನೀವು ಅವುಗಳನ್ನು ನಿಮ್ಮ ಕೋಡ್‌ನಲ್ಲಿ ಮುಕ್ತವಾಗಿ ಬಳಸಬಹುದು. ಆದರೆ ಒಂದು ಅರ್ಥದಲ್ಲಿ ಈ ಸ್ವರೂಪವು “ಬೈಸಿಕಲ್” ಆಗಿ ಉಳಿದಿದೆ ಎಂದು ನಾನು ಇನ್ನೂ ಒತ್ತಿಹೇಳುತ್ತೇನೆ ಮತ್ತು ಅದನ್ನು ಬಳಸಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುವುದಿಲ್ಲ ನಿಮಗೆ ಇದು ಏಕೆ ಬೇಕು ಎಂದು ತಿಳಿಯದೆ. ಇದು ಇನ್ನೂ ಗಂಭೀರವಾದ "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 ನಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ.

ಆದಾಗ್ಯೂ, ಇಲ್ಲಿ ಒಂದು ತೊಂದರೆ ಉಂಟಾಗುತ್ತದೆ: ಮುಖ್ಯ ವರ್ಣಮಾಲೆಯಿಂದ ಸಹಾಯಕವನ್ನು ಹೇಗೆ ಪಡೆಯುವುದು? ನೀವು ಅದೇ ಆಫ್‌ಸೆಟ್ ಅನ್ನು ಬಿಡಬಹುದು, ಆದರೆ - ಅಯ್ಯೋ - ಇಲ್ಲಿ ಯುನಿಕೋಡ್ ರಚನೆಯು ಈಗಾಗಲೇ ನಮ್ಮ ವಿರುದ್ಧ ಆಡುತ್ತಿದೆ. ಆಗಾಗ್ಗೆ ವರ್ಣಮಾಲೆಯ ಮುಖ್ಯ ಭಾಗವು ಬ್ಲಾಕ್ನ ಆರಂಭದಲ್ಲಿ ಇರುವುದಿಲ್ಲ (ಉದಾಹರಣೆಗೆ, ರಷ್ಯಾದ ರಾಜಧಾನಿ "A" ಕೋಡ್ ಅನ್ನು ಹೊಂದಿದೆ 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 ಕೆಬಿ - ನಂತರ, ನೀವು ಗಡಿಯನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕಾದರೆ, ಇದೇ ರೀತಿಯ ಮಾರ್ಕರ್ ಕಂಡುಬರುವವರೆಗೆ ಆಯ್ದ ತುಣುಕನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಲು ಸಾಕು. ಕೊನೆಯದನ್ನು ಅನುಸರಿಸಿ 0xBF ಒಂದು ಪಾತ್ರದ ಆರಂಭ ಎಂಬ ಭರವಸೆ ಇದೆ. (ಡಿಕೋಡಿಂಗ್ ಮಾಡುವಾಗ, ಮೂರು ಬೈಟ್‌ಗಳ ಈ ಅನುಕ್ರಮವನ್ನು ನಿರ್ಲಕ್ಷಿಸಬೇಕಾಗುತ್ತದೆ.)

ಸಾರಾಂಶ

ನೀವು ಇಲ್ಲಿಯವರೆಗೆ ಓದಿದ್ದರೆ, ಅಭಿನಂದನೆಗಳು! ಯೂನಿಕೋಡ್ ರಚನೆಯ ಬಗ್ಗೆ ನೀವು ನನ್ನಂತೆಯೇ ಹೊಸದನ್ನು (ಅಥವಾ ನಿಮ್ಮ ಸ್ಮರಣೆಯನ್ನು ರಿಫ್ರೆಶ್ ಮಾಡಿ) ಕಲಿತಿದ್ದೀರಿ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ಡೆಮೊ ಪುಟ. ಹೀಬ್ರೂವಿನ ಉದಾಹರಣೆಯು UTF-8 ಮತ್ತು SCSU ಎರಡರಲ್ಲೂ ಅನುಕೂಲಗಳನ್ನು ತೋರಿಸುತ್ತದೆ.

ಮೇಲೆ ವಿವರಿಸಿದ ಸಂಶೋಧನೆಯನ್ನು ಮಾನದಂಡಗಳ ಮೇಲಿನ ಅತಿಕ್ರಮಣವೆಂದು ಪರಿಗಣಿಸಬಾರದು. ಆದಾಗ್ಯೂ, ನನ್ನ ಕೆಲಸದ ಫಲಿತಾಂಶಗಳೊಂದಿಗೆ ನಾನು ಸಾಮಾನ್ಯವಾಗಿ ತೃಪ್ತನಾಗಿದ್ದೇನೆ, ಆದ್ದರಿಂದ ನಾನು ಅವರೊಂದಿಗೆ ಸಂತೋಷವಾಗಿದ್ದೇನೆ ಪಾಲು: ಉದಾಹರಣೆಗೆ, ಮಿನಿಫೈಡ್ JS ಲೈಬ್ರರಿಯು ಕೇವಲ 1710 ಬೈಟ್‌ಗಳನ್ನು ತೂಗುತ್ತದೆ (ಮತ್ತು ಯಾವುದೇ ಅವಲಂಬನೆಗಳನ್ನು ಹೊಂದಿಲ್ಲ, ಸಹಜವಾಗಿ). ನಾನು ಮೇಲೆ ಹೇಳಿದಂತೆ, ಅವಳ ಕೆಲಸವನ್ನು ಇಲ್ಲಿ ಕಾಣಬಹುದು ಡೆಮೊ ಪುಟ (UTF-8 ಮತ್ತು SCSU ನೊಂದಿಗೆ ಹೋಲಿಸಬಹುದಾದ ಪಠ್ಯಗಳ ಒಂದು ಸೆಟ್ ಕೂಡ ಇದೆ).

ಅಂತಿಮವಾಗಿ, UTF-C ಅನ್ನು ಬಳಸುವ ಸಂದರ್ಭಗಳಲ್ಲಿ ನಾನು ಮತ್ತೊಮ್ಮೆ ಗಮನ ಸೆಳೆಯುತ್ತೇನೆ ಇದು ಮೌಲ್ಯದ ಅಲ್ಲ:

• ನಿಮ್ಮ ಸಾಲುಗಳು ಸಾಕಷ್ಟು ಉದ್ದವಾಗಿದ್ದರೆ (100-200 ಅಕ್ಷರಗಳಿಂದ). ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಡಿಫ್ಲೇಟ್ ನಂತಹ ಕಂಪ್ರೆಷನ್ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಬಳಸುವ ಬಗ್ಗೆ ನೀವು ಯೋಚಿಸಬೇಕು.
• ನಿನಗೆ ಬೇಕಾದರೆ ASCII ಪಾರದರ್ಶಕತೆ, ಅಂದರೆ, ಎನ್‌ಕೋಡ್ ಮಾಡಲಾದ ಅನುಕ್ರಮಗಳು ಮೂಲ ಸ್ಟ್ರಿಂಗ್‌ನಲ್ಲಿಲ್ಲದ ASCII ಕೋಡ್‌ಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ ಎಂಬುದು ನಿಮಗೆ ಮುಖ್ಯವಾಗಿದೆ. ಮೂರನೇ ವ್ಯಕ್ತಿಯ API ಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವಾಗ (ಉದಾಹರಣೆಗೆ, ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ), ನೀವು ಎನ್‌ಕೋಡಿಂಗ್ ಫಲಿತಾಂಶವನ್ನು ಬೈಟ್‌ಗಳ ಅಮೂರ್ತ ಸೆಟ್‌ನಂತೆ ರವಾನಿಸಿದರೆ ಮತ್ತು ಸ್ಟ್ರಿಂಗ್‌ಗಳಾಗಿಲ್ಲದಿದ್ದರೆ ಇದರ ಅಗತ್ಯವನ್ನು ತಪ್ಪಿಸಬಹುದು. ಇಲ್ಲದಿದ್ದರೆ, ನೀವು ಅನಿರೀಕ್ಷಿತ ದೋಷಗಳನ್ನು ಪಡೆಯುವ ಅಪಾಯವಿದೆ.
• ಅನಿಯಂತ್ರಿತ ಆಫ್‌ಸೆಟ್‌ನಲ್ಲಿ ಅಕ್ಷರ ಗಡಿಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಕಂಡುಹಿಡಿಯಲು ನೀವು ಬಯಸಿದರೆ (ಉದಾಹರಣೆಗೆ, ಸಾಲಿನ ಭಾಗವು ಹಾನಿಗೊಳಗಾದಾಗ). ಇದನ್ನು ಮಾಡಬಹುದು, ಆದರೆ ಮೊದಲಿನಿಂದಲೂ ಸಾಲನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುವ ಮೂಲಕ (ಅಥವಾ ಹಿಂದಿನ ವಿಭಾಗದಲ್ಲಿ ವಿವರಿಸಿದ ಮಾರ್ಪಾಡುಗಳನ್ನು ಅನ್ವಯಿಸುವ ಮೂಲಕ).
• ನೀವು ತಂತಿಗಳ ವಿಷಯಗಳ ಮೇಲೆ ತ್ವರಿತವಾಗಿ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮಾಡಬೇಕಾದರೆ (ಅವುಗಳನ್ನು ವಿಂಗಡಿಸಿ, ಅವುಗಳಲ್ಲಿ ಸಬ್ಸ್ಟ್ರಿಂಗ್ಗಳನ್ನು ಹುಡುಕಿ, ಜೋಡಿಸಿ). ಇದಕ್ಕೆ ಮೊದಲು ಸ್ಟ್ರಿಂಗ್‌ಗಳನ್ನು ಡಿಕೋಡ್ ಮಾಡುವ ಅಗತ್ಯವಿದೆ, ಆದ್ದರಿಂದ UTF-C ಈ ಸಂದರ್ಭಗಳಲ್ಲಿ UTF-8 ಗಿಂತ ನಿಧಾನವಾಗಿರುತ್ತದೆ (ಆದರೆ ಸಂಕೋಚನ ಕ್ರಮಾವಳಿಗಳಿಗಿಂತ ವೇಗವಾಗಿರುತ್ತದೆ). ಒಂದೇ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಯಾವಾಗಲೂ ಒಂದೇ ರೀತಿಯಲ್ಲಿ ಎನ್ಕೋಡ್ ಮಾಡಲಾಗಿರುವುದರಿಂದ, ಡಿಕೋಡಿಂಗ್ನ ನಿಖರವಾದ ಹೋಲಿಕೆ ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು ಬೈಟ್-ಬೈ-ಬೈಟ್ ಆಧಾರದ ಮೇಲೆ ಮಾಡಬಹುದು.

ಅಪ್ಡೇಟ್: ಬಳಕೆದಾರ ತಯೋಮಿಚ್ ಕೆಳಗಿನ ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ UTF-C ಯ ಅನ್ವಯಿಕ ಮಿತಿಗಳನ್ನು ಹೈಲೈಟ್ ಮಾಡುವ ಗ್ರಾಫ್ ಅನ್ನು ಪೋಸ್ಟ್ ಮಾಡಲಾಗಿದೆ. ಪ್ಯಾಕ್ ಮಾಡಲಾದ ಸ್ಟ್ರಿಂಗ್ ಚಿಕ್ಕದಾಗಿರುವವರೆಗೆ UTF-C ಸಾಮಾನ್ಯ ಉದ್ದೇಶದ ಸಂಕುಚಿತ ಅಲ್ಗಾರಿದಮ್ (LZW ನ ಬದಲಾವಣೆ) ಗಿಂತ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿರುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. ~140 ಅಕ್ಷರಗಳು (ಆದಾಗ್ಯೂ, ಹೋಲಿಕೆಯನ್ನು ಒಂದು ಪಠ್ಯದಲ್ಲಿ ನಡೆಸಲಾಗಿದೆ ಎಂದು ನಾನು ಗಮನಿಸುತ್ತೇನೆ; ಇತರ ಭಾಷೆಗಳಿಗೆ ಫಲಿತಾಂಶವು ಭಿನ್ನವಾಗಿರಬಹುದು).


ಮೂಲ: www.habr.com