일반 텍스트에서 가장 적게 사용 된 구분 문자 <ASCII 128

일반 텍스트에서 가장 적게 사용 된 구분 문자 <ASCII 128

---

끔찍한 코딩 이유 때문에 (말하기에는 너무 부끄럽습니다) 여러 텍스트 항목을 단일 문자열에 저장해야합니다.

문자를 사용하여 구분하겠습니다.

이를 위해 어떤 문자를 사용하는 것이 가장 좋습니까? 즉, 텍스트에 나타날 가능성이 가장 적은 문자는 무엇입니까? 로케일 문제를 방지하려면 인쇄 가능해야하며 ASCII에서 128 미만이어야합니다.

---

당황스러운 이유로 CSV를 사용할 수 없다고 가정하면 데이터를 사용한다고 말하고 싶습니다. 샘플 데이터를 가져와 각 값 0-127에 대해 간단한 문자 수를 계산합니다. 발생하지 않는 것 중 하나를 선택하십시오. 선택의 여지가 너무 많으면 더 큰 데이터 세트를 얻으십시오. 글을 쓰는 데 많은 시간이 걸리지 않으며 가장 적합한 답변을 얻을 수 있습니다.

문제 영역에 따라 대답이 달라 지므로 | (파이프)는 셸 스크립트에서 일반적이고 ^는 수학 공식에서 일반적이며 대부분의 다른 문자에서도 마찬가지입니다.

나는 개인적으로 내가 갈 것이라고 생각한다 | (파이프) 선택권이 주어지면 실제 데이터를 사용하는 것이 가장 안전합니다.

그리고 무엇을하든 탈출 계획을 세웠는지 확인하세요!

---

"Unit Separator"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.

Unit Separator는 ASCII 형식이며이를 표시하기위한 유니 코드 지원 (일반적으로 동일한 글리프의 "us")이 있지만 많은 글꼴에서 표시하지 않습니다.

표시해야하는 경우 필드로 구문 분석 된 후 응용 프로그램에 표시하는 것이 좋습니다.

---

아마 | 또는 ^ 또는 ~ 두 문자를 결합 할 수도 있습니다.

---

다른 언어를 사용하는 경우이 기호 : ¬

최고로 입증되었습니다. 그러나 나는 여전히 테스트 중입니다.

---

CSV 스타일 형식을 사용하는 것은 어떻습니까? 문자는 표준 CSV 형식으로 이스케이프 될 수 있으며 이미 많은 파서가 작성되어 있습니다.

---

"인쇄 가능"이라고 말했지만 탭 (0x09) 또는 용지 공급 (0x0c)과 같은 문자를 포함 할 수 있습니다. 쉼표가 때때로 텍스트에 나타날 수 있기 때문에 나는 거의 항상 쉼표 대신 탭을 선택합니다.

(흥미롭게도 ascii 테이블 에는 그룹, 레코드 및 단위 구분 기호에 대해 GS (0x1D), RS (0x1E) 및 US (0x1F) 문자가 있습니다.

"인쇄 가능"이란 사용자가 인식하고 쉽게 입력 할 수있는 문자를 의미하는 경우 파이프 | 기호 먼저 몇 가지 이상한 문자 ( @또는 ~또는 ^또는 또는 \여기에 입력 할 수없는 백틱)를 가능성으로 사용합니다. 이러한 문자 +=!$%&*()-'":;<>,.?/는 사용자 입력에서 발생할 가능성이 더 높은 것처럼 보입니다. 밑줄 _과 해시 #와 {}[]내가 모르는 대괄호에 관해서는 .

---

파이프 기호를 사용할 수 있습니까? 일반적으로 쉼표 또는 탭으로 구분 된 문자열 다음으로 가장 일반적인 구분 기호입니다. 대부분의 텍스트에 파이프가 포함될 가능성은 거의 없으며 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 is probably a better idea for most situations, though.

---

Well it's going to depend on the nature of your text to some extent but a vertical bar 0x7C doesn't crop up in text very often.

---

I don't think I've ever seen an ampersand followed by a comma in natural text, but you can check the file first to see if it contains the delimiter, and if so, use an alternative. If you want to always be able to know that the delimiter you use will not cause a conflict, then do a loop checking the file for the delimiter you want, and if it exists, then double the string until the file no longer has a match. It doesn't matter if there are similar strings because your program will only look for exact delimiter matches.

---

Both pipe and caret are the obvious choices. I would note that if users are expected to type the entire response, caret is easier to find on any keyboard than is pipe.

참고URL : https://stackoverflow.com/questions/492090/least-used-delimiter-character-in-normal-text-ascii-128