Наименее используемый символ-разделитель в обычном тексте <ASCII 128

Из соображений кодирования, которые вас ужаснули бы (мне стыдно сказать), мне нужно хранить несколько текстовых элементов в одной строке.

Я выделю их символом.

Какой символ лучше всего использовать для этого, т.е. какой символ с наименьшей вероятностью появится в тексте? Должен быть доступен для печати и, вероятно, меньше 128 в ASCII, чтобы избежать проблем с локалью.

Предполагая, что по какой-то неловкой причине вы не можете использовать CSV, я бы сказал, что используйте данные. Возьмите несколько примеров данных и выполните простой подсчет символов для каждого значения 0–127. Выберите один из тех, которых не происходит. Если есть слишком большой выбор, возьмите больший набор данных. Написание не займет много времени, и вы получите лучший ответ.

Ответ будет разным для разных проблемных областей, поэтому | (вертикальная черта) часто встречается в сценариях оболочки, ^ - в математических формулах, и то же самое, вероятно, верно для большинства других символов.

Я лично думаю, что пошел бы на | (труба), если есть выбор, но использование реальных данных является наиболее безопасным.

И что бы вы ни делали, убедитесь, что вы разработали схему побега!

Я бы выбрал «Разделитель единиц», код ASCII «США»: ASCII 31 (0x1F)

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

ASCII 28 (0x1C) File Separator - Used to indicate separation between files on a data input stream.
ASCII 29 (0x1D) Group Separator - Used to indicate separation between tables on a data input stream (called groups back then).
ASCII 30 (0x1E) Record Separator - Used to indicate separation between records within a table (within a group).  These roughly map to a tuple in modern nomenclature.
ASCII 31 (0x1F) Unit Separator - Used to indicate separation between units within a record.  The roughly map to fields in modern nomenclature.

Разделитель единиц находится в ASCII, и есть поддержка Unicode для его отображения (обычно это «нас» в том же глифе), но многие шрифты не отображают его.

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

Наверное | или ^ или ~ вы также можете объединить два символа

При использовании разных языков этот символ: ¬

оказался лучшим. Однако я все еще тестирую.

Вы сказали «для печати», но это может включать такие символы, как табуляция (0x09) или подача формы (0x0c). Я почти всегда выбираю табуляцию, а не запятую для файлов с разделителями, поскольку запятые иногда могут появляться в тексте.

(Интересно, что в таблице ascii есть символы GS (0x1D), RS (0x1E) и US (0x1F) для разделителей групп, записей и единиц, какими бы они ни были.)

Если под «печатным» вы имеете в виду символ, который пользователь может распознать и легко ввести, я бы выбрал трубу | символ первого, с несколькими другими странными персонажами ( @или ~или ^или \или кавычка , которые я не могу войти здесь) как возможность. +=!$%&*()-'":;<>,.?/Кажется, что эти символы чаще встречаются при вводе пользователем. Что касается подчеркивания, _хеша #и скобок, {}[]я не знаю.

Как насчет того, чтобы использовать формат стиля CSV? Символы можно экранировать в стандартном формате CSV, и уже написано множество синтаксических анализаторов.

Вы можете использовать символ трубы? Обычно это следующий по распространенности разделитель после строк, разделенных запятыми или табуляциями. Маловероятно, что большая часть текста будет содержать вертикальную черту, и ord ('|') возвращает 124 для меня, так что, похоже, это соответствует вашим требованиям.

Для быстрого экранирования я использую такие вещи: скажем, вы хотите объединить str1, str2 и str3, что я делаю:

delimitedStr=str1.Replace("@","@a").Replace("|","@p")+"|"+str2.Replace("@","@a").Replace("|","@p")+"|"+str3.Replace("@","@a").Replace("|","@p");

затем восстановить исходное использование:

splitStr=delimitedStr.Split("|".ToCharArray());
str1=splitStr[0].Replace("@p","|").Replace("@a","@");
str2=splitStr[1].Replace("@p","|").Replace("@a","@");
str3=splitStr[2].Replace("@p","|").Replace("@a","@");

примечание: порядок замены важен

его нерушимый и простой в реализации

Труба на победу! |

Мы используем ascii 0x7f, который можно использовать для псевдопечати, и он практически никогда не используется.

Это может быть хорошо или плохо (обычно плохо) в зависимости от ситуации и языка, но имейте в виду, что вы всегда можете кодировать Base64 целиком. Тогда вам не нужно беспокоиться об экранировании и отмене экранирования различных шаблонов с каждой стороны, и вы можете просто разделять и разбивать строки на основе символа, который не используется в вашей кодировке Base64.

Мне пришлось прибегнуть к этому решению, когда я столкнулся с помещением XML-документов в свойства / узлы XML. В свойствах вообще не может быть блоков CDATA, а узлы, экранированные, поскольку CDATA, очевидно, не могут иметь внутри других блоков CDATA без нарушения структуры.

Однако CSV, вероятно, лучше для большинства ситуаций.

Что ж, это в некоторой степени будет зависеть от характера вашего текста, но вертикальная полоса 0x7C не часто появляется в тексте.

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

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