texto para nick letras convertir caracteres art ascii delimiter delimited-text

ascii - para - text art



El carácter de delimitador menos utilizado en texto normal<ASCII 128 (16)

Por motivos de codificación que podrían horrorizarlo (me da vergüenza decirlo), debo almacenar una cantidad de elementos de texto en una sola cadena.

Los delimitaré usando un personaje.

¿Qué personaje es mejor usar para esto, es decir, qué personaje es el menos propenso a aparecer en el texto? Debe ser imprimible y probablemente menos de 128 en ASCII para evitar problemas de configuración regional.


¿Puedes usar un símbolo de tubería? Suele ser el siguiente delimitador más común después de cadenas delimitadas por comas o tabulaciones. Es poco probable que la mayoría del texto contenga una tubería, y ord (''|'') devuelve 124 para mí, por lo que parece ajustarse a sus requisitos.


Asumiendo por alguna razón vergonzosa que no puedas usar CSV, yo diría que ve con los datos. Tome algunos datos de muestra y haga un recuento de caracteres simple para cada valor 0-127. Elija uno de los que no ocurre. Si hay demasiadas opciones, obtenga un conjunto de datos más grande. No tomará mucho tiempo escribir, y obtendrá la mejor respuesta para usted.

La respuesta será diferente para diferentes dominios problemáticos, entonces | (tubería) es común en las secuencias de comandos shell, ^ es común en las fórmulas matemáticas, y lo mismo es probable que sea cierto para la mayoría de los demás caracteres.

Personalmente creo que iría por | (tubería) si se le da una opción, pero ir con datos reales es más seguro.

Y hagas lo que hagas, ¡asegúrate de haber elaborado un plan de escape!


Bueno, va a depender de la naturaleza del texto hasta cierto punto, pero una barra vertical 0x7C no aparece en el texto muy a menudo.


Pipe para la victoria! |


Probablemente | o ^ o ~ también puede combinar dos caracteres


Dijiste "imprimible", pero eso puede incluir caracteres como una pestaña (0x09) o alimentación de formulario (0x0c). Casi siempre elijo pestañas en lugar de comas para los archivos delimitados, ya que algunas veces las comas pueden aparecer en el texto.

(Curiosamente, la tabla ascii tiene los caracteres GS (0x1D), RS (0x1E) y EE. UU. (0x1F) para separadores de grupos, registros y unidades, cualquiera que sean / were).

Si por "imprimible" te refieres a un personaje que un usuario podría reconocer y escribir fácilmente, yo iría por el tubo | símbolo primero, con algunos otros personajes extraños ( @ o ~ o ^ o / , o retroceso que no puedo entrar aquí) como una posibilidad. Estos caracteres +=!$%&*()-''":;<>,.?/ Parecen que es más probable que ocurran en la entrada del usuario. En cuanto a los guiones bajos _ hash # y los corchetes {}[] I no lo sé


Usamos ascii 0x7f que es pseudoimpresible y casi nunca aparece en el uso regular.


Esto puede ser bueno o malo (generalmente malo) dependiendo de la situación y el idioma, pero recuerda que siempre puedes codificar todo Base64. Entonces, no tiene que preocuparse por escaparse y desempaquetar varios patrones en cada lado, y simplemente puede separar y dividir cadenas en función de un carácter que no se usa en su juego de caracteres Base64.

Tuve que recurrir a esta solución cuando tuve que poner documentos XML en propiedades / nodos XML. Las propiedades no pueden tener bloques CDATA en absoluto, y los nodos se escaparon, ya que obviamente CDATA no puede tener más bloques CDATA dentro sin romper la estructura.

CSV es probablemente una mejor idea para la mayoría de las situaciones.


No creo que haya visto un ampersand seguido de una coma en texto natural, pero puedes verificar el archivo primero para ver si contiene el delimitador, y si es así, usa una alternativa. Si desea saber siempre que el delimitador que utiliza no causará un conflicto, haga un ciclo revisando el archivo para el delimitador que desea y, si existe, duplique la cadena hasta que el archivo ya no coincida. . No importa si hay cadenas similares porque su programa solo buscará las coincidencias de delimitador exactas.


¿Qué tal si usas un formato de estilo CSV? Los caracteres se pueden escapar en un formato CSV estándar, y ya hay muchos analizadores escritos.


Cuando utiliza diferentes idiomas, este símbolo: ¬

demostrado ser el mejor Sin embargo, todavía estoy probando.


Para escapar rápidamente utilizo cosas como esta: digamos que quieres concatinate str1, str2 y str3 lo que hago es:

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

luego para recuperar el uso original:

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

nota: el orden del reemplazo es importante

es irrompible y fácil de implementar


Probablemente tengas que elegir algo e ignorar sus otros usos.

+

podría ser un buen candidato


Tanto la tubería como el cursor son las opciones obvias. Me gustaría señalar que si se espera que los usuarios escriban toda la respuesta, es más fácil encontrar el cursor en cualquier teclado que el tubo.


Yo elegiría el código ascii "separador de unidades" "US", ascii 30 (0x1F)

En los viejos tiempos, la mayoría de las cosas se hacían en serie, sin acceso aleatorio. Esto significaba que algunos códigos de control estaban integrados en 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.

El Separador de unidades está en ASCII, y hay compatibilidad con Unicode para mostrarlo (normalmente un "nosotros" en el mismo glifo), pero muchas fuentes no lo muestran.

Si debe mostrarlo, le recomendaría mostrarlo en la aplicación, después de que se haya analizado en los campos.


No estoy seguro si está obligado a utilizar ASCII, pero si puede codificarlo en UTF-8, puede encontrar un símbolo realmente oscuro como: (U + 2561) - que uso mucho en mis programas

También puede ver la serialización de objetos y simplemente crear nuevos campos para todos los elementos que pueda necesitar.