Безопасно ли использовать случайный Юникод для сложных последовательностей-разделителей в строках?

Question

Вопрос: С точки зрения стабильности программы и обеспечения фактической работы системы, насколько безопасно использовать символы типа ¦, § или ‡ для сложных последовательностей-разделителей в строках ? Могу ли я достоверно поверить, что я не столкнусь с какими-либо проблемами в программе, которая неправильно их читает?

---

Я работаю в системе, использующей код C #, в котором мне нужно хранить довольно сложный набор информации в одной строке. Удобочитаемость этой строки необходима только на стороне компьютера, конечные пользователи должны видеть информацию только после ее анализа соответствующими методами. Поскольку некоторые данные в этих строках будут коллекциями переменного размера, я использую разные разделители, чтобы определить, какие части строки соответствуют определенному уровню организации. Достаточно случаев, когда стандартные наборы;, | и аналогичных им подобных были исчерпаны. Я рассматривал разделители с двумя символами, как; # или; |, но чувствовал, что это будет очень неэффективно. Вероятно, нет такой большой разницы в производительности при хранении с одним символом по сравнению с двумя символами, но когда у меня есть возможность выбрать меньший вариант, просто неправильно выбрать больший.

Итак, наконец, я подумал об использовании набора символов, таких как двойной кинжал и раздел. Они занимают только один символ, и они определенно не будут отображаться в реальном тексте, который я буду хранить, поэтому они ни для чего не будут смущены.

Но кодировка символов привередлива. Хотя видимость для конечного пользователя не имеет смысла (поскольку он, по сути, не увидит его), я недавно стал беспокоиться о том, как программы в системе будут читать его. Строка хранится в одной базе данных, в то время как отдельная программа отвечает как за кодирование, так и за декодирование строки в различные типы объектов для работы с остальной частью приложения. И если ожидается, что что-то будет написано одним способом, возможно, будет написано другим, то, возможно, вся система выйдет из строя, и я не могу этого допустить. Так безопасно ли использовать эти типы символов в качестве разделителей фона?

Answer 1

Поскольку вы должны закодировать данные в строку, я предполагаю, что это потому, что вы взаимодействуете с другими системами.Почему бы не использовать что-то вроде XML или JSON , а не придумывать собственный формат данных?

С помощью XML вы можете указать используемую кодировку, например:

<?xml version="1.0" encoding="UTF-8"?>

Answer 2

Существует очень небольшая опасность того, что любая система, которая хранит и извлекает текст Unicode, изменит эти конкретные символы.

Основными символами, которые можно изменить в процессе передачи текста, являются маркеры конца строки. Например, FTP-файл из системы Unix в систему Windows в текстовом режиме может заменить символы LINE FEED для пар CARRIAGE RETURN + LINE FEED.

После этого некоторые системы могут выполнять каноническую нормализацию текста. Объединение символов и символов с диакритическими знаками на них не должно использоваться, если не принимается во внимание каноническая нормализация (составление или разложение). База данных символов Unicode содержит информацию о том, какие преобразования требуются при этих схемах нормализации.

Это подводит итог самых важных вещей, на которые стоит обратить внимание, и ни одна из них не является проблемой для персонажей, которых вы перечислили.

Другие преобразования, которые могут быть сделаны, но менее вероятны, - это изменения регистра и нормализация совместимости. Чтобы избежать этого, просто держитесь подальше от букв алфавита или чего-либо похожего на буквы алфавита. Некоторые символы также преобразуются в нормализацию совместимости, поэтому вы должны проверить свойства в базе данных символов Unicode, чтобы быть уверенными. Но маловероятно, что какая-либо система выполнит нормализацию совместимости без явного указания на то, что она это сделает.

В таблицах кодов Unicode канонические нормализации обозначены "≡", а нормализации совместимости - "≈".

Answer 3

Можно использовать тот же подход, что и для кодирования URL или HTML, и заменить ключевые символы на последовательности символов. То есть & становится &.

Хотя это приводит к увеличению числа символов, оно может быть довольно эффективно сжато из-за повторения этих последовательностей.

Answer 4

В наборе Unicode есть более редкие символы. Насколько я знаю, только символы ниже 0x32 (пробел) имеют особые значения, все, что следует сохранить в столбце данных NVARCHAR.

Это никогда не будет абсолютно безопасно, если у вас нет точного определения, какие символы могут и не могут быть частью ваших данных.

Answer 5

Ну, UNICODE - это стандарт, поэтому, пока все участники (код, БД и т. Д.) Используют UNICODE, у вас не должно быть никаких проблем.

Answer 6

Помните некоторые законы Мерфи:

«Все, что может пойти не так, будет».

"Все, что не может пойти не так, будет в любом случае ".

Те символы, которые определенно не будут использоваться, могут в конечном итоге использоваться. Когда они будут, приложение определенно потерпит неудачу.

Вы можете использовать любой символ, который вам нравится, в качестве разделителя, если вы только экранируете значения, чтобы этот символ гарантированно не появлялся в них. Некоторое время назад я написал пример, показывающий, что в качестве разделителя можно даже использовать общий символ, такой как «а».

Экранирование значений курса означает, что некоторые символы будут представлены как два символа, но обычно это будет меньше затрат, чем использование разделителя из нескольких символов. И что еще более важно, это абсолютно безопасно.