#url #unicode #utf-8 #uri
#url #Юникод #utf-8 #uri
Вопрос:
Мне нужно сопоставить целочисленный счетчик с кодовыми точками Юникода, удобными для URI (я пишу средство сокращения URL, не ограниченное типичной базой ASCII-62, 0-9a-zA-Z ). У меня уже есть работающий прототип; веб-сервер получает запросы GET для значения кодовой точки Unicode в кодировке UTF-8 в% (во всяком случае, из Firefox), поэтому с ним очень легко справиться.
Теперь, самая сложная часть, которой я достиг, — это преобразование первичного ключа сокращаемого URL-адреса — целого числа — в пригодные кодовые точки Unicode (кодовые точки, когда я превышаю количество отдельных кодовых точек, которые я могу использовать, и мне приходится использовать несколько кодовых точек). Прямо сейчас мой счетчик иногда создает неправильные кодовые точки, которые невозможно использовать. Я немного почитал о Unicode и понимаю, что есть много вещей, которые следует принимать во внимание:
- Не отображаемые символы
- Несимволы
- Управляющие коды
- Высокие / Низкие суррогаты
- Кодовые точки частного использования
- Форматирование, символы Bidi
- Комбинирование символов / диакритических знаков
- Пробел
- Повторяющиеся символы
- Символы, зарезервированные в схеме URI, такие как
/,.,?(не в Юникоде)
Мое простое решение — создать набор кодовых точек для сопоставления, который охватывает как можно больше полезных, избегая диапазонов «плохих символов» выше, а также включая только кодовые точки, которые сами по себе также являются границами кластера графем, т. Е. не изменяются путем объединения символов / диакритических знаков (хотя я полагаю, что если я внесу в черный список диакритические кодовые точки, это не будет иметь значения). Это справедливое предположение? Существует ли относительно простой способ сгенерировать такой набор кодовых точек?
Я видел ссылки на такие инструменты, как unichars и uniprops, но я не думаю, что я достаточно разбираюсь в свойствах Юникода, чтобы понять, помогут ли они мне в этой ситуации или нет. Меня не интересует полностью исчерпывающий список используемых кодовых точек, но покрытие > 70% было бы потрясающим. Я гораздо больше заинтересован в том, чтобы не указывать «плохие» кодовые точки.
Еще одна проблема, о которой я задаюсь вопросом, заключается в том, следует ли также отфильтровывать зарезервированные кодовые точки и / или выделенные кодовые точки без отображаемых представлений (которые выглядят как прямоугольное поле с шестнадцатеричным значением внутри). Как ни странно, они, похоже, работают, поэтому я планирую оставить их. Есть веская причина не делать этого?
Заранее приношу извинения, если моя терминология Юникода неверна.
TL; DR
Как я могу сгенерировать набор всех отображаемых кодовых точек Юникода (без кодовых точек управления / форматирования), *** исключая *** пробелы, повторяющиеся символы и комбинирование символов / диакритических знаков?
Комментарии:
1. Почему, о, почему вы это делаете? Это просто ненужное усложнение, так как байт, отличный от ASCII, в UTF-8 может содержать не более 6 бит. Вы уже можете сделать лучше в ASCII. en.wikipedia.org/wiki/Ascii85
2. Ну, очевидно, что если вы говорите в необработанных битах / байтах, это не имеет смысла. Однако большинство современных сервисов больше не считают байты — они считают нормализованные кодовые точки Unicode. Посмотрите, например, Twitter . Кроме того, ваш пример включает в себя зарезервированные символы схемы URI
Ответ №1:
Часть того, что вы просите, может быть невозможной. Ни один шрифт не содержит глифов для всех символов Юникода, и в большинстве систем недостаточно шрифтов, чтобы охватить весь Юникод. Итак, если под «отображаемым» вы подразумеваете, что пользователь действительно может видеть глиф, это проблема.
Также нет гарантии, что глифы для двух разных символов Юникода на самом деле выглядят по-разному, но этот файл предоставляет информацию о похожих символах (например, знак числа и знак музыкальной резкости). Это, вероятно, максимально близко к фильтрации повторяющихся символов.
В противном случае база данных символов Юникода должна предоставить вам достаточно информации о каждом символе, чтобы вы могли отфильтровать те, которые вам не нужны (управляющие символы, комбинирующие символы, пробелы).
Комментарии:
1. 1 Спасибо за ответ и ссылки. Эти файлы выглядят многообещающе… но человек — это плотный бюрократический материал. Вероятно, я ошибся, когда сказал отображаемый. Меня действительно не волнует, есть ли прямоугольные поля с шестнадцатеричными кодами внутри. Меня больше беспокоит перезапись / нормализация последовательностей, поэтому я, возможно, также немного не разбираюсь в повторяющихся символах (мне казалось, я читал, что набор Latin повторяется в каком-то блоке). Все кажется немного запутанным; это не похоже на ASCII, где вы можете просто сравнить значения двоичных символов. 🙂
2. Смотрите также стр. 16-18 ch02 . Не должно быть никаких дубликатов, за исключением случаев, когда предварительно составленный символ эквивалентен другому символу плюс объединяющий знак ударения. Однако, как вы, возможно, заметили, существует большое разделение функций.
Ответ №2:
Самое простое решение, которое я нашел, было тем, на которое я просто случайно наткнулся: это официальное веб-приложение JSP с свойствами Юникода. Я полагаю, что это запрос, который я использовал:
[:Diacritic=No:]amp;[:Noncharacter_Code_Point=No:]amp;[:Deprecated=No:]amp;[:White_Space=No:]amp;[:General_Category=Math_Symbol:]|[:General_Category=Symbol:]|[:General_Category=Letter:]|[:General_Category=Punctuation:]|[:General_Category=Currency_Symbol:]|[:General_Category=Number:]amp;[:General_Category!=Modifier_Letter:]amp;[:General_Category!=Modifier_Symbol:]
Что дает 107 401 кодовую точку. Затем я отфильтровал зарезервированные символы URI и пару других на всякий случай, прежде чем сохранять их в своей базе данных. Вот мой рабочий прототип в нерекламированной бета-версии.
Некоторые другие вещи, которые я безуспешно пробовал:
Я попробовал утилиту Perl unichars , которая, как я полагаю, способна делать то, что мне нужно, но моя версия Perl (5.10.1) связана со стандартом Unicode 5.x; Я не смог быстро найти какие-либо инструкции по обновлению до стандарта Unicode 6.0.0. Я рассматривал возможность написания приложения Ruby, похожего на unichars , но моя установка Ruby также основана на стандарте Unicode 5.2 (Ruby 1.9.2, ActiveSupport 3.0.8). Я нашел способ, по-видимому, загрузить другую таблицу Юникода, но для этого нет документации, а unicode_tables.dat файл в моей системе является двоичным файлом, поэтому простого ответа нет.
Я также рассматривал возможность синтаксического анализа стандарта Unicode 6.0.0 UnicodeData.txt запишите сам, но, по-видимому, отсутствуют диапазоны кодовых точек, такие как Han, что потребовало бы от меня синтаксического анализа еще одного файла в его собственном формате.