Models names containing / and ~ are displayed with ~1 and ~0 instead

[hkosova]

Q	A
Bug or feature request?	Bug
Which Swagger/OpenAPI version?	2.0
Which Swagger-UI version?	3.9.1
How did you install Swagger-UI?	http://editor.swagger.io
Which browser & version?	Chrome
Which operating system?	Windows 7

This is a minor display issue related to #4152.

/ and ~ are special characters in JSON Pointers, so when they need to be used literally (as part of a node name) they are encoded as ~1 and ~0, as per https://tools.ietf.org/html/rfc6901#section-3.

# Referencing a model named "foo/bar"
$ref: '#/definitions/foo~1bar'

definitions:
  foo/bar:
   ...

However, in places where the model is referenced, the UI displays the model name incorrectly - still encoded using ~1 and ~0 instead of the actual name with / ~.

Demonstration API definition

swagger: '2.0'
info:
  version: 0.0.0
  title: test
paths:
  /foo:
    post:
      parameters:
        - in: body
          name: body
          schema:
            $ref: '#/definitions/x~1Foo'
      responses:
        200:
          description: OK
          schema:
            $ref: '#/definitions/x~1Foo'
        404:
          description: OK
          schema:
            $ref: '#/definitions/x~0Bar'
definitions:
  x/Foo:
    type: object
    properties:
      bar:
        $ref: '#/definitions/x~0Bar'
  x~Bar:
    type: object

Expected Behavior

Model names everywhere are displayed as x/Foo and x~Bar.

Current Behavior

In places where the models are $referenced, the model names are displayed as x~1Foo and x~0Bar instead of x/Foo and x~Bar.

Possible Solution

N/a

Context

Model names containing / and ~ are displayed correctly in Editor v2:

[heldersepu]

Should those chars even be allowed as model names?
From a C# perspective (WebAPI) those chars are not possible, the models are coming from the name of the classes ...

[hkosova]

@heldersepu / and ~ are not allowed in component names in 3.0, but 2.0 does not have any limitations.

Anyway, I assume it's a very low-priority issue due to the reasons you mentioned, and I would be totally fine with a "wontfix" on this.