# Unicode block character (�) appears in recording.completed webhook

**URL:** <https://devforum.zoom.us/t/unicode-block-character-appears-in-recording-completed-webhook/87196>\
**Category:** Cloud Recordings\
**Created:** [April 22, 2023, 12:30am UTC](https://devforum.zoom.us/t/unicode-block-character-appears-in-recording-completed-webhook/87196 "2023-04-22T00:30:22Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![tech-zoom\_zp](https://avatars.discourse-cdn.com/v4/letter/t/5fc32e/32.png) [@tech-zoom\_zp](https://devforum.zoom.us/u/tech-zoom_zp)\
**Post date:** [April 22, 2023, 12:30am UTC](https://devforum.zoom.us/t/unicode-block-character-appears-in-recording-completed-webhook/87196/1 "2023-04-22T00:30:22Z")

</div>

### Format Your New Topic as Follows:

**API Endpoint(s) and/or Zoom API Event(s)**  
recording.completed webhook

**Description**  
_Details on your question, workflow or the problem you’re trying to solve._  
Since April 17th JST, unicode block character (�) has started to appear in request body of recording.completed webhook, inside `payload.object.participant_audio_files[0].file_name`.

e.g. set the user’s display name to `プロフィット` and start a meeting and cloud recording, the file\_name used to have been `Audio only - プロフィッ㲁` before April 14th, but after April 17th it’s become `Audio only - プロフィッ�`.  
The unicode block character appears in many other cases and is causing our app to skip processing this participant\_audio\_file and our users are not being able to use our app correctly.

Is this change done intentionally, or is it a bug?  
If it’s a bug, please fix it as soon as possible.

Sample

```auto
{
    "payload": {
        "object": {
            "participant_audio_files": [
                {
                    "id": "c7f88d6f-4ab5-4338-8db9-1056e3396b3d",
                    "recording_start": "2023-04-22T00:23:12Z",
                    "recording_end": "2023-04-22T00:23:20Z",
                    "file_name": "Audio only - プロフィッ�",
                    "file_type": "M4A",
                    "file_extension": "M4A",
                    "file_size": 111758,
                    "play_url": "edited",
                    "download_url": "edited",
                    "status": "completed"
                }
            ]
        }
    },
    "event_ts": 1682123090696,
    "event": "recording.completed"
}

```

**How To Reproduce**  
_Steps to reproduce the behavior:_  
_1. Request URL / Headers **(without credentials or sensitive info like emails, uuid, etc.)** / Body_  
_2. Authentication method or app type_  
_3. Any errors_

1. Set the user’s display name to “プロフィット”
2. Turn on setting “Setting \> Recording \> Cloud recording \> Record audio-only files \> Record a separate audio file of each participant”
3. Start a meeting and cloud recording.
4. Wait for recording.completed webhook.
5. Check payload.object.participant\_audio\_files[0].file\_name. The last character is Unicode block character.

---

<div class="post-metadata">

**Author:** ![tech-zoom\_zp](https://avatars.discourse-cdn.com/v4/letter/t/5fc32e/32.png) [@tech-zoom\_zp](https://devforum.zoom.us/u/tech-zoom_zp)\
**Post date:** [April 22, 2023, 1:59am UTC](https://devforum.zoom.us/t/unicode-block-character-appears-in-recording-completed-webhook/87196/2 "2023-04-22T01:59:27Z")

</div>

In further investigation, it started to appear around April 16th noon JST.

---

<div class="post-metadata">

**Author:** ![tech-zoom\_zp](https://avatars.discourse-cdn.com/v4/letter/t/5fc32e/32.png) [@tech-zoom\_zp](https://devforum.zoom.us/u/tech-zoom_zp)\
**Post date:** [May 20, 2023, 3:34am UTC](https://devforum.zoom.us/t/unicode-block-character-appears-in-recording-completed-webhook/87196/3 "2023-05-20T03:34:11Z")

</div>

I have not gotten any reply but will anyone answer if it’s a bug or not?

---

<div class="post-metadata">

**Author:** ![MultiplayerSession](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/multiplayersession/32/66446_2.png) [@MultiplayerSession](https://devforum.zoom.us/u/MultiplayerSession)\
**Post date:** [May 23, 2023, 3:48pm UTC](https://devforum.zoom.us/t/unicode-block-character-appears-in-recording-completed-webhook/87196/4 "2023-05-23T15:48:37Z")

</div>

This definitely feels like a character encoding problem where the display name is getting truncated and then additional portions of the file name, like the file extension, are being appended, resulting in an invalid sequence of characters that results in a validation step swapping in the Unicode replacement character (U+FFFD) you’re seeing in an attempt to recover from the problem.

I don’t feel that Zoom is very transparent or accurate about character length limitations — for example, they’ll document “[Max 64 chars](https://developers.zoom.us/docs/api/rest/reference/zoom-api/methods/#operation/meetingRegistrantCreate)” or “[This value cannot exceed more than 12 Chinese characters.](https://developers.zoom.us/docs/api/rest/reference/zoom-api/methods/#operation/webinarPanelistCreate)” which I doubt accurately reflects the actual limitation, or they wouldn’t be using those measurement units.

I’m guessing UTF-8 encoding is being used at some point.

Aside from getting official changes, perhaps you can ask people to use shorter display names, or express it as romaji (or at least the last few characters that are likely to be truncated) so that truncation will always result in a valid UTF-8 sequence?

---

<div class="post-metadata">

**Author:** ![tech-zoom\_zp](https://avatars.discourse-cdn.com/v4/letter/t/5fc32e/32.png) [@tech-zoom\_zp](https://devforum.zoom.us/u/tech-zoom_zp)\
**Post date:** [May 24, 2023, 1:43am UTC](https://devforum.zoom.us/t/unicode-block-character-appears-in-recording-completed-webhook/87196/5 "2023-05-24T01:43:39Z")

</div>

Thanks for sharing your thoughts!

> Aside from getting official changes, perhaps you can ask people to use shorter display names, or express it as romaji (or at least the last few characters that are likely to be truncated) so that truncation will always result in a valid UTF-8 sequence?

I hope we could do like you suggest, but in Japan, it’s not very common to use romaji and we cannot enforce our customers to use only valid alphabets. (More difficult as our customer’s customers names are often Chinese characters.)

For the time being, we have changed our app not to stop process on unicode block characters. But with 1 character less information, the file name has only 5 valid characters and it serves almost no meaning in identifying who’s audio file it is.

I hope I can get a good answer from Zoom. (Hopefully, they can extend the length or offer user\_id.)
