WPF PostgreSQL 9.6 C#
Después de pasar lo mejor de hoy leyendo lo que hay en Internet, todavía no he descubierto cómo se hace esto.
Estoy tratando de codificar una etiqueta de "formato" antes de una cadena de texto. Algo como:
\u0002 (Esta es el área de formato) \u0003 "Esta es la cadena de texto" \u0002 (Esta es otra área de formato) \u0003 "Esta es otra cadena de texto" (.....)
Es decir, cada área de formato está encerrada por un código de control (es decir, un carácter no imprimible) seguido de un mensaje de texto. Esto luego se repetirá para tantos mensajes como necesite.
Lo que quiero hacer (no sé cómo) es enviar este bloque completo de código de control + mensaje a un método WCF que luego lo enviará al backend de PostgreSQL.
Llevarlo a WCF es fácil, pero ¿cuál es el mejor método para almacenar esto en PostgreSQL?
Una vez almacenado, necesito devolverlo al cliente, momento en el que espero usar un analizador de dos partes (probablemente con Regex) para primero dividir el bloque en subcadenas de [formato]+[Mensaje] y luego finalmente para aplicar cada formato a su mensaje adjunto. (Piense en bucle).
Pero no entiendo cómo obtener códigos de control fuera de PostgreSQL de modo que pueda usar Regex para aislar cada cadena de [formato]+Message en el cliente.
Cualquier ayuda u orientación sería muy apreciada.
TIA.
Con versiones recientes de PostgreSQL, puede usar secuencias de escape \uXXXX o \UXXXXXXXX en literales de cadena si precede el literal de cadena con E para indicar que contiene secuencias de escape:
SELECT E'\u0002part 1\u0003\part 2'; ┌──────────────────────┐ │ ?column? │ ├──────────────────────┤ │ \x02part 1\x03part 2 │ └──────────────────────┘ (1 row)Es fácil dividir una cadena en partes a lo largo de estas líneas, consulte la documentación sobre las funciones de cadena de PostgreSQL.
Por ejemplo, si desea dividir una cadena de este tipo en una matriz en \u0002 o \u0003 , puede hacerlo así:
SELECT regexp_split_to_array( E'\u0002part 1\u0003\part 2', E'[\u0002\u0003]' ); ┌────────────────────────┐ │ regexp_split_to_array │ ├────────────────────────┤ │ {"","part 1","part 2"} │ └────────────────────────┘ (1 row)Para los novatos (como yo), que vienen aquí, una lectura detallada de la documentación de PgAdmin muestra que el comportamiento de PgAdmin depende en gran medida de la definición de columna utilizada en PostgreSQL. La documentación de PostgreSQL (si la leí correctamente) establece que casi cualquier codificación puede llamarse campo de "texto" ya que internamente PostgreSQL tiene como valor predeterminado la codificación UTF-8.
A modo de ejemplo,
CREATE TABLE progress_note_drawing_transcription ( encounter_recid integer NOT NULL, transcription text, strokes bytea ) insert into progress_note_drawing_transcription (encounter_recid, transcription, strokes) values (111421,E'\u0009 This is a message',E'\u0009 This is a message')Pero tenga en cuenta las siguientes diferencias:
Cuando la columna de postreSQL se define como "texto", por ejemplo, "transcripción" es una columna de texto, entonces
seleccione la transcripción de progreso_nota_dibujo_transcripción;
mostrará "Este es un mensaje" donde el \u0009 inicial se reemplaza por un espacio.
Cuando la columna de PostgreSQL se define como bytea, como en "trazos", PgAdmin mostrará:
seleccione trazos de progreso_nota_dibujo_transcripción;
como "\011 Este es un mensaje"
donde 9 se escribe como octal de escape (base 8).
Además, para ver los valores "hexadecimales" directos, el campo "texto" en PgAdmin requiere:
SELECT encode(convert_to(transcription, 'UTF-8'), 'hex') FROM progress_note_drawing_transcription;mientras que el campo "bytea" puede verse simplemente como:
SELECT encode(strokes, 'hex') FROM progress_note_drawing_transcription;Espero que esto ayude a alguien.
(Así que supongo que lo que se usa depende principalmente de la preferencia personal, con la única advertencia de que creo que las operaciones de lectura en el tipo de datos "texto" en PostgreSQL son aproximadamente un 15% más rápidas que los tipos de datos "bytea". Sin embargo, podría estar equivocado).