@alfredo.brito01

Thank you for reaching out to us.

I tested it on Postman and found that Postman can display the PRCTCK_1 field properly.

The hex value is "E2 87 A9" which is a down arrow in UTF8.

Hello @alfredo.brito01

I did a quick test with various RICs and the results are different.

• The FX RIC like JPY=, EUR= does not have the PRCTCK_1 field data
• The .L RICs like LSEG.L, VOD.L have the PRCTCK_1 field data

Example Data:

RECEIVED: 
[
  {
    "Fields":{
      "52WK_HIGH":79.5,
      "52WK_LOW":62.59,
      "52W_HDAT":"2024-09-17",
      ...
      "PRCTCK_1":"\u21e7",

This "\u21e7" value represents "Upwards White Arrow" Unicode character (see Unicode Character “⇧” (U+21E7)). Then the client needs to write an application to display this "\u21e7" as an upwards arrow.

Please be informed that the WebSocket API is the server-side API. I strongly suggest you contact the Real-Time content team to verify if the RICs requested by the client has this PRCTCK_1 field data. You can contact the team via https://myaccount.lseg.com/en/productsupport website.

Hi,

The situation is now slightly different, because the field PRCTCK_1 is being delivered but the content is "???" and not the unicode.

This test was done with RIC EDP.LS that has this field PRCTCK_1 available.

Please see below the request and the response.

{

"TRDPRC_1": 3.764,

"NETCHNG_1": 0.018,

"HIGH_1": 3.774,

"LOW_1": 3.724,

"PRCTCK_1": "???",

"TRADE_DATE": "2024-10-25",

"TRDTIM_1": "09:26:44",

"OPEN_PRC": 3.727,

"HST_CLOSE": 3.746,

"BID": 3.762,

"ASK": 3.765,

"BIDSIZE": 6295,

"ACVOL_1": 501157,

"PCTCHNG": 0.48,

"CLOSE_BID": 3.732,

"CLOSE_ASK": 3.746,

"YRHIGH": 4.64,

"YRLOW": 3.45,

"TURNOVER": 1878434,

"TRDVOL_1": 1300,

"YRHIGHDAT": "2023-12-14",

"YRLOWDAT": "2024-04-09",

"SALTIM": "09:26:44",

"YR_PCTCH": -17.76,

"EPYR_PCTCH": -2.17

}

Do you have an explanation to this behavior and what should be checked to transform the "???" in related Unicode content?

Thanks in advance.

Best Regards

Hello @alfredo.brito01,

The ??? that you see in the display is most likely because your application is unable to process/display the unicode characters. Please ask the customer to use one of the example applications on a console prompt and check the output.

Python example.