在現代編程中使用ASCII分隔符（29-31）

我目前正在構建一個哈希鍵字符串（從地圖摺疊），其中由特殊ASCII單元分隔符31（1F）分隔的值。在現代編程中使用ASCII分隔符（29-31）

這很好地解決了試圖猜測ASCII字符不會在字符串值中使用的問題，我並不需要擔心轉義或引用值等

但是閱讀的歷史這似乎是從20世紀60年代的遺物，我還沒有看到很多使用這個特殊字符構建和標記字符串的例子，所以這一切似乎都很簡單。

在現代應用程序中使用此分隔符有任何問題嗎？

我目前正在做一個非Unicode的C++應用程序，但我很想知道這一般如何適用於其他語言，如Java，C＃和Unicode。

2012-12-30 TownCube

維基百科上有一篇描述這些角色的[關於分隔符的文章]（https://en.wikipedia.org/wiki/Delimiter#ASCII_delimited_text）。 –

ASCII的低128字符映射完全按照Unicode標準設置，這包括字符0-> 31。您在字符串中看不到特殊ASCII字符的唯一原因往往僅僅是由於人機界面的限制：在顯示屏幕或寫入文件時，它們的可視化效果不佳（如果有的話），並且您無法輕鬆從鍵盤輸入它們。它們也不允許以各種流行的「人類可讀」文件格式（如XML）以未轉義形式出現。

但是，對於不需要終端用戶交互的程序中的邏輯處理任務而言，它們完全適用於您可以爲其找到的任何用途。你的特殊用途聽起來新穎而有效，我認爲你應該肯定會用它來運行。

來源

2012-12-30 18:27:02 jstine

您的應用程序可以自由接受任何二進制格式它喜歡。但是，如果您需要在輸入中嵌入任意二進制數據，則需要轉義格式使用的任何分隔符或其他特殊代碼。無論您選擇哪一個，都是如此。

我也不會忽略Unicode。現在到2012年，與處理文本的過時模型一起工作是相當愚蠢的。如果您的輸入數據是文本的，請按照原樣處理。

想到的一個問題是爲什麼要發明另一種格式，而不是使用XML或JSON;或者如果你需要一個緊湊的編碼，這兩個（Fast Infoset，msgpack，誰知道還有什麼）或ASN.1的「二進制」變體？當你自己翻譯那些已經解決的格式的設計和工具時，你可能會遇到很多其他的問題。

來源

2012-12-30 18:22:03 millimoose

這個答案讓我困惑。（a）ASCII 29-31確實是Unicode字符。他們的Unicode名稱分別是信息分隔符四，三，二和一（分別）。（b）使用這些字符不是[二進制格式]（https://en.wikipedia.org/wiki/Binary_format）。（c）使用這些字符不會創造出新的格式。他們的目的是促進數據交換，明確界定。 –

@BasilBourque也許如果你在一年前問過這個問題，我會記得提供這個答案的原因。這些天我只是反對錶格問題「有問題嗎？」沒有很好地描述用例，因爲它很模糊。這就是說：你的評論其實就是我的觀點。 'U + 0029'-'U + 0031' *是*有效字符，因此可能出現在字符串值本身中，除非您指定允許的內容，否則將它們用作分隔符不是「安全的」。通過「文本格式」，我傾向於理解手動輸入合理可行的內容。 – millimoose

在現代編程中使用ASCII分隔符（29-31）

回答

相關問題