По причинам, связанным с кодированием, которые приведут вас в ужас (я слишком стесняюсь говорить), мне нужно хранить несколько текстовых элементов в одной строке.
Я ограничу их, используя символ.
Какой символ лучше всего использовать для этого, то есть какой символ наименее вероятно появится в тексте? Должно быть напечатано и, вероятно, меньше 128 в ASCII, чтобы избежать проблем с локалью.
Предполагая, что вы не можете использовать CSV, я бы сказал, что нужно использовать данные. Возьмите некоторые данные образца и сделайте простой счетчик символов для каждого значения 0-127. Выберите один из тех, который не встречается. Если есть слишком большой выбор, получите больший набор данных. Это не займет много времени, чтобы написать, и вы получите ответ лучше всего для вас.
Ответ будет различным для разных проблемных областей, поэтому | (pipe) распространена в сценариях оболочки, ^ распространена в математических формулах, и то же самое, вероятно, верно для большинства других символов.
Я лично думаю, что поеду | (труба), если выбор возможен, но с реальными данными безопаснее.
И что бы вы ни делали, убедитесь, что вы разработали схему экранирования!
Я бы выбрал "Разделитель единиц" ASCII-код "US": 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, и есть поддержка Юникода для его отображения (обычно это "мы" в одном и том же глифе), но многие шрифты не отображают его.
Если вы должны отобразить его, я бы порекомендовал отобразить его в приложении, после того, как он был разобран в поля.
Вероятно | или ^ или ~ вы могли бы также объединить два символа
При использовании разных языков этот символ: ¬
оказался лучшим. Однако я все еще тестирую.
Как насчет формата CSV? Символы могут быть экранированы в стандартном формате CSV, и уже уже написано много парсеров.
Вы сказали "printable", но могут включать в себя такие символы, как вкладка (0x09) или фид формы (0x0c). Я почти всегда выбираю вкладки, а не запятые для файлов с разделителями, поскольку иногда запятые могут появляться в тексте.
(Интересно, что таблица ascii содержит символы GS (0x1D), RS (0x1E) и US (0x1F) для группы, записи, и разделители единиц, независимо от того, были ли они/были.)
Если по "printable" вы имеете в виду символ, который пользователь мог распознать и легко ввести, я бы пошел на трубу | сначала символ с несколькими другими странными символами (@ или ~ или ^ или \, или обратный ход, который я не могу представить здесь). Эти символы +=!$%&*()-'":;<>,.?/ кажутся похожими на то, что они будут чаще встречаться во вводе пользователя. Что касается подчеркивания _ и hash #, а скобки {}[], я не знаю.
Можете ли вы использовать символ трубы? Это обычно следующий наиболее распространенный разделитель после запятой или табуляции с разделителями. Маловероятно, что в большинстве текстов будет содержаться труба, а 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 очень часто встречается в тексте.
Я не думаю, что когда-либо видел амперсанд, за которым следует запятая в естественном тексте, но сначала вы можете проверить файл, чтобы увидеть, содержит ли он разделитель, и если да, используйте альтернативу. Если вы хотите всегда знать, что используемый ограничитель не приведет к конфликту, выполните цикл проверки файла для разделителя, который вы хотите, и если он существует, затем удвойте строку до тех пор, пока файл больше не будет соответствовать, Не имеет значения, есть ли подобные строки, потому что ваша программа будет искать только точные соответствия.
Оба канала и каретка - очевидный выбор. Я хотел бы отметить, что если ожидается, что пользователи будут вводить весь ответ, каретку легче найти на любой клавиатуре, чем на трубе.
Я не уверен, что вам нужно использовать ASCII, но если вы можете кодировать его в UTF-8, вы можете найти действительно неясный символ: ╡ (U + 2561) - что я много использую в своих программах.
Вы также можете просмотреть сериализацию объектов и просто создать новые поля для всех элементов, которые могут вам понадобиться.