З причин кодування, які можуть вас жахнути (мені це дуже соромно сказати), мені потрібно зберігати ряд текстових елементів в одному рядку.
Я розмежую їх за допомогою символу.
Який символ найкраще використовувати для цього, тобто який символ найменше з’являється в тексті? Має бути для друку і, можливо, менше 128 в ASCII, щоб уникнути проблем із мовою.
|в своєму тексті, я насправді мав такий випадок, коли мені потрібно було якомога менше зводити символи до мінімуму. Оскільки більшість полів містять рядки з цікавим текстом, CSV не працює через велику кількість екранувань. Наш роздільник поля /|. Коса риса є лише помірною, але в парі з трубою, на яку ви ніколи не натрапляєте. Я використовую механізм, який отримує багато даних через нього щодня. Це ніколи не ламалося, і мені ніколи не потрібно було інкапсулювати жодний рядок або уникати спеціального символу. В середньому цей механізм заощадив нам кілька відсотків тексту.
Відповіді:
Якщо припустити, що з якоїсь незручної причини ви не можете використовувати CSV, я б сказав, перейдіть із даними. Візьміть кілька зразків даних і зробіть простий підрахунок символів для кожного значення 0-127. Виберіть один із тих, який не відбувається. Якщо вибору занадто багато, отримайте більший набір даних. Писання не займе багато часу, і ви отримаєте найкращу для вас відповідь.
Відповідь буде різною для різних проблемних доменів, тому | (pipe) є загальним у сценаріях оболонки, ^ є загальним у математичних формулах, і те саме, ймовірно, справедливо для більшості інших символів.
Я особисто думаю, що пішов би на | (трубопровід), якщо вибрати вибір, але найбезпечнішим є використання реальних даних.
І що б ви не робили, переконайтесь, що ви розробили схему втечі!
additional_attributes.
\tяк роздільник?
Я вибрав би "Розділювач одиниць" 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.
Unit Separator знаходиться в ASCII, і для його відображення є підтримка Unicode (як правило, це "us" у тому самому гліфі), але багато шрифти його не відображають.
Якщо вам потрібно відобразити його, я б рекомендував відображати його в додатку, після того, як він буде проаналізований на поля.
При використанні різних мов цей символ: ¬
виявився найкращим. Однак я все ще тестую.
Ви сказали "для друку", але це може містити такі символи, як вкладка (0x09) або стрічка форми (0x0c). Я майже завжди вибираю вкладки, а не коми для розділених файлів, оскільки коми іноді можуть з'являтися в тексті.
(Цікаво, що таблиця ascii має символи GS (0x1D), RS (0x1E) та US (0x1F) для розділювачів груп, записів та одиниць, якими б вони не були.)
Якщо під поняттям "для друку" ви маєте на увазі символ, який користувач міг розпізнати і легко ввести, я б пішов за конвеєром | символ першої, з кількома іншими дивними персонажами ( @або ~чи ^або \чи лапки , які я не можу увійти тут) як можливість. Ці символи +=!$%&*()-'":;<>,.?/здаються такими, що вони, швидше за все, траплятимуться під час введення користувачем. Щодо підкреслення _та хешування #та дужок, {}[]я їх не знаю.
28 FSРозділювач файлів, Розділювач 29 GSгруп, Розділювач 30 RSзаписів, Розділювач 31 USодиниць. На жаль, майже ніхто їх не використовує, хоча саме для цього вони були призначені. Особисто я ненавиджу файли формату CSV, тому що так багато людей не продумують щось і роблять безлад, з яким нам, програмістам, доводиться стикатися, якщо ми хочемо підтримувати їх формати файлів.
Як щодо того, щоб використовувати формат стилю CSV? Символи можна екранувати у стандартному форматі CSV, і вже створено багато парсерів.
Для швидкого втечі я використовую такі речі: скажімо, ви хочете об'єднати 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","@");
Примітка: порядок заміни важливий
його незламний і простий у реалізації
Це може бути добре чи погано (як правило, погано) залежно від ситуації та мови, але майте на увазі, що ви завжди можете Base64 кодувати все це. Тоді вам не доведеться турбуватися про втечу та скасування різних шаблонів на кожній стороні, і ви можете просто відокремити та розділити рядки на основі символу, який не використовується у вашій коди коду Base64.
Мені довелося вдатися до цього рішення, стикаючись із розміщенням документів XML у властивостях / вузлах XML. Властивості взагалі не можуть мати блоків CDATA, а вузли не працюють, оскільки CDATA, очевидно, не може мати в собі подальших блоків CDATA без порушення структури.
CSV, мабуть, є кращою ідеєю для більшості ситуацій.
Не думаю, що я коли-небудь бачив амперсанд, за яким слідує кома в природному тексті, але ви можете спочатку перевірити файл, чи не містить роздільник, і якщо так, скористайтеся альтернативою. Якщо ви хочете завжди мати можливість знати, що використовуваний вами роздільник не спричинить конфлікту, виконайте цикл, перевіряючи файл на потрібний вам роздільник, а якщо він існує, подвойте рядок, поки файл більше не має відповідності . Не має значення, чи є подібні рядки, оскільки ваша програма буде шукати лише точні збіги роздільників.
І труба, і карет - очевидний вибір. Я б зауважив, що якщо від користувачів очікується набрати повну відповідь, Caret легше знайти на будь-якій клавіатурі, ніж pipe.