GLB import incorrectly handles texture paths containing Unicode escape characters

[hakanai]

Describe the bug

While importing a GLB file, if texture names contained Unicode escapes such as "\u8868\u60c5", UniVRM appears to treat the "\" as if it's a path separator, attempts to write the texture to "u8868/u60c5.png" and then fails the import.

To Reproduce

e.g. Steps to reproduce the behavior:

1. Have a GLB file where at least one of the textures contains at least two escaped Unicode characters.

   In the JSON, this should look something like this:

    {"bufferView":189,"mimeType":"image/png","name":"\u8868\u60c5"}
   

2. Drag that GLB into the project and wait while UniVRM attempts to import it.

What happens:

• You get an error in the console that it couldn't write the file. This happens because the parent directory does not exist. (If you manually create the directory it will then write the file, albeit with the wrong name.)
• The import is aborted.

Expected behavior

The Unicode characters should have been escaped by the JSON parser before they even got to the import code. The files should be written to disk with the correct Unicode characters, instead of the escape sequence.

Screenshots

N/A

Environments (please complete the following information):

• OS: macOS 10.15
• Unity version: 2018.4.20
• UniVRM version: 0.56.3_3b68

[hakanai]

I should note that one way to reliably get a GLB file with character escapes in it is to have Japanese characters in your texture names and do the GLB export from Blender. Blender escapes the Japanese characters instead of leaving them as Unicode.

[ousttrue]

UniGLTF serializer not implemented unicode escape.
like \u8868 .

This will reproduce.
Cube.glb.zip

[ousttrue]

v0.66.0