Najrzadziej używany znak separatora w zwykłym tekście <ASCII 128

Z powodów związanych z kodowaniem, które mogłyby cię przerazić (jestem zbyt zawstydzony, by powiedzieć), muszę przechowywać wiele elementów tekstowych w jednym ciągu.

Wyznaczę je za pomocą znaku.

Którego znaku najlepiej użyć do tego, tj. Który znak ma najmniejsze prawdopodobieństwo pojawienia się w tekście? Musi być możliwy do wydrukowania i prawdopodobnie mniej niż 128 w ASCII, aby uniknąć problemów z lokalizacją.

Zakładając, że z jakiegoś zawstydzającego powodu nie możesz używać CSV, powiedziałbym, że idź z danymi. Weź przykładowe dane i oblicz prostą liczbę znaków dla każdej wartości od 0 do 127. Wybierz jedną z tych, które nie występują. Jeśli wybór jest zbyt duży, uzyskaj większy zestaw danych. Pisanie nie zajmie dużo czasu, a otrzymasz najlepszą dla siebie odpowiedź.

Odpowiedź będzie inna dla różnych dziedzin problemowych, więc | (pionowa kreska) jest powszechna w skryptach powłoki, ^ jest powszechna w formułach matematycznych i to samo jest prawdopodobnie prawdą w przypadku większości innych znaków.

Osobiście uważam, że wybrałbym | (potok), jeśli masz wybór, ale korzystanie z prawdziwych danych jest najbezpieczniejsze.

I cokolwiek robisz, upewnij się, że opracowałeś schemat ucieczki!

Wybrałbym „Separator jednostek”, kod ASCII „US”: ASCII 31 (0x1F)

W dawnych czasach większość rzeczy była wykonywana seryjnie, bez przypadkowego dostępu. Oznaczało to, że kilka kodów kontrolnych zostało osadzonych w 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.

Separator jednostek jest w formacie ASCII i jest obsługiwany przez Unicode do jego wyświetlania (zazwyczaj „nas” w tym samym glifie), ale wiele czcionek go nie wyświetla.

Jeśli musisz go wyświetlić, polecam wyświetlenie go w aplikacji, po przeanalizowaniu go na pola.

Prawdopodobnie | lub ^ lub ~ możesz też połączyć dwa znaki

W przypadku używania różnych języków ten symbol: ¬

okazały się najlepsze. Jednak wciąż testuję.

Powiedziałeś „drukowalny”, ale może to obejmować takie znaki, jak tabulacja (0x09) lub wysuw strony (0x0c). Prawie zawsze wybieram tabulatory zamiast przecinków dla plików rozdzielanych, ponieważ przecinki czasami pojawiają się w tekście.

(Co ciekawe, tabela ascii zawiera znaki GS (0x1D), RS (0x1E) i US (0x1F) dla separatorów grup, rekordów i jednostek, cokolwiek to jest / były.)

Jeśli przez „drukowalny” masz na myśli znak, który użytkownik mógłby rozpoznać i łatwo wpisać, wybrałbym potok | najpierw symbol, z kilkoma innymi dziwnymi znakami ( @lub ~lub ^lub \, lub lewym przyciskiem, których nie mogę tutaj wprowadzić) jako możliwą. +=!$%&*()-'":;<>,.?/Wydaje się, że te znaki będą częściej pojawiać się podczas wprowadzania danych przez użytkownika. Jeśli chodzi o podkreślenie _i hash #oraz nawiasy {}[], to nie wiem.

A może używasz formatu CSV? Znaki mogą zostać zmienione w standardowym formacie CSV, a jest już napisanych wiele parserów.

Czy możesz użyć symbolu fajki? Zwykle jest to następny najpopularniejszy separator po ciągach rozdzielanych przecinkami lub tabulatorami. Jest mało prawdopodobne, że większość tekstu zawiera pionową kreskę, a ord ('|') zwraca dla mnie 124, więc wydaje się, że pasuje do twoich wymagań.

Do szybkiego ucieczki używam takich rzeczy: powiedz, że chcesz połączyć str1, str2 i str3, co robię to:

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

następnie, aby odzyskać oryginalne użycie:

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","@");

uwaga: kolejność wymiany jest ważna

jest niezniszczalny i łatwy do wdrożenia

Rura za zwycięstwo! |

Używamy ascii 0x7f, który jest pseudo-drukowalny i prawie nigdy nie pojawia się w regularnym użyciu.

Może to być dobre lub złe (zwykle złe) w zależności od sytuacji i języka, ale pamiętaj, że zawsze możesz zakodować całość w Base64. Nie musisz się wtedy martwić o ucieczkę i cofanie różnych wzorów z każdej strony, a możesz po prostu oddzielić i podzielić ciągi na podstawie znaku, który nie jest używany w twoim zestawie znaków Base64.

Musiałem uciekać się do tego rozwiązania, gdy miałem do czynienia z umieszczaniem dokumentów XML we właściwościach / węzłach XML. Właściwości nie mogą w ogóle zawierać bloków CDATA, a węzły uciekły, ponieważ CDATA oczywiście nie może mieć w sobie dalszych bloków CDATA bez uszkodzenia struktury.

Jednak CSV jest prawdopodobnie lepszym pomysłem w większości sytuacji.

Cóż, będzie to w pewnym stopniu zależeć od natury twojego tekstu, ale pionowy pasek 0x7C nie pojawia się zbyt często w tekście.

Wydaje mi się, że nigdy nie widziałem znaku ampersand, po którym następuje przecinek w tekście naturalnym, ale możesz najpierw sprawdzić plik, aby zobaczyć, czy zawiera separator, a jeśli tak, użyj alternatywy. Jeśli chcesz zawsze wiedzieć, że separator, którego używasz, nie spowoduje konfliktu, wykonaj pętlę sprawdzającą plik pod kątem żądanego separatora, a jeśli istnieje, podwajaj ciąg, aż plik nie będzie już pasował . Nie ma znaczenia, czy istnieją podobne ciągi, ponieważ Twój program będzie szukał tylko dokładnych dopasowań separatora.

Zarówno fajka, jak i daszek są oczywistym wyborem. Chciałbym zauważyć, że jeśli oczekuje się, że użytkownicy wpiszą całą odpowiedź, daszek jest łatwiejszy do znalezienia na dowolnej klawiaturze niż potok.