Poner Mensaje en Websphere MQ a través de C# tiene diferentes longitud de datos que poner manualmente el mismo mensaje

Question

MQMessage queueMessage = new MQMessage(); 
       queueMessage.WriteString(strInputMsg); 
       queueMessage.Format = MQC.MQFMT_STRING; 
       MQPutMessageOptions queuePutMessageOptions = new MQPutMessageOptions(); 
       Queue.Put(queueMessage, queuePutMessageOptions); 

Uso de C#, con el código anterior, cuando entrada el mensaje en la cola, la longitud de datos del mensaje es 3600.

Cuando introducir manualmente el mensaje en la cola haciendo clic derecho en la cola y seleccionando la opción mensaje de prueba Ponga, la longitud de los datos del mensaje es 1799.

estoy muy confundido por qué este es el caso. El mensaje en ambos casos es una cadena xml con declaración. En Notepad ++, hay 1811 caracteres, incluida la declaración. Cuando veo el mensaje en el depurador antes de ingresar en la cola, el mensaje se convierte en xml sin ninguna línea o carruajes de devolución.

creé la cadena XML usando:

//converts string message into xml by serializing it 
public string GetMessage(MyMessage messageInstance) 
{ 

// Serialize the request 
      XmlSerializer xsr = new XmlSerializer(typeof(MyMessage)); 
      MemoryStream memoryStream = new MemoryStream(); 
      XmlTextWriter xmlTextWriter = new XmlTextWriter(memoryStream, Encoding.UTF8); 
      xsr.Serialize(xmlTextWriter, messageInstance); 

      memoryStream = (MemoryStream)xmlTextWriter.BaseStream; 
      string XmlizedString = new UTF8Encoding().GetString((memoryStream.ToArray()); 


      // Encode the xml 
      Encoding utf = Encoding.UTF8; 
      byte[] utfBytes = utf.GetBytes(XmlizedString); 

      // Load the document (XmlResolver is set to null to ingore DTD) 
      XmlDocument xmlDoc = new XmlDocument(); 
      xmlDoc.XmlResolver = null; 
      xmlDoc.LoadXml(utf.GetString(utfBytes)); 
      return utf.GetString(utfBytes); 

Me estoy perdiendo algo en mi C# aplicación que agrega caracteres adicionales?

Gracias.

Answer 1

Como @Matten sugiere que un problema podría ser la codificación de caracteres.

El valor predeterminado para la propiedad CharacterSet es 1200 (UNICODE) y WriteString se convierte a la página de códigos especificada por CharacterSet.

La página de códigos 1200 es UTF-16 little-endian, por lo que es probable que obtenga dos bytes por carácter. Es posible que "Ponga mensaje de prueba" use alguna otra codificación que use un byte por carácter para los caracteres comunes.

Suponiendo que las longitudes 3600 y 1799 se cuentan en bytes, podrían representar 1800 caracteres UTF-16LE y 1799 caracteres UTF-8 (o 1799 caracteres ASCII o 1799 caracteres EBCDIC ...).

Eso todavía nos deja con una diferencia de un carácter en longitud. ¿Quizás WriteString incluye un carácter NULL de terminación en la cadena escrita?

¿Estás seguro de que confías en el conteo que Notepad ++ te ofrece? Si Put Test Message colocó 1799 caracteres en un mensaje, probablemente haya 1799 caracteres en los datos que le proporcionó.

Editar: Suponiendo que la teoría de la codificación es correcta, puede acortar el mensaje utilizando una codificación diferente. La brevedad que una codificación haría un mensaje particular dependería del contenido real de la cadena.

Por ejemplo, puede usar una codificación ASCII para obtener un byte por carácter.

MQMessage queueMessage = new MQMessage(); 
queueMessage.CharacterSet = 437; // Set code page to ASCII 

Eso acortaría su mensaje de 1800 bytes si todos los caracteres en la cadena XML tenían una representación ASCII.

Una alternativa sería usar la codificación UTF-8.

MQMessage queueMessage = new MQMessage(); 
queueMessage.CharacterSet = 1208; // Set code page to UTF-8 

Usando UTF-8 tiene la ventaja de que (a diferencia de ASCII) todos los caracteres tienen una representación (para ciertos valores de 'all'). La desventaja es que algunos personajes requieren dos, tres o incluso cuatro bytes para representarlos.Los caracteres más comunes están codificados en un byte, luego los siguientes caracteres más comunes están codificados en dos bytes, y así sucesivamente.

En el mejor de los casos, una codificación UTF-8 también le daría 1800 bytes. En el peor de los casos, le daría 7200 bytes, pero eso parece muy poco probable a menos que esté usando algo como Klingon.