# Input fields involuntarily convert character combinations into unicode, like "\<-" or "=\>" into ← and ⇒

**URL:** <https://discuss.elastic.co/t/input-fields-involuntarily-convert-character-combinations-into-unicode-like-or-into-and/290870>\
**Category:** Kibana\
**Created:** [December 3, 2021, 10:52am UTC](https://discuss.elastic.co/t/input-fields-involuntarily-convert-character-combinations-into-unicode-like-or-into-and/290870 "2021-12-03T10:52:24Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![grin](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/grin/32/80387_2.png) [@grin](https://discuss.elastic.co/u/grin)\
**Post date:** [December 3, 2021, 10:52am UTC](https://discuss.elastic.co/t/input-fields-involuntarily-convert-character-combinations-into-unicode-like-or-into-and/290870/1 "2021-12-03T10:52:24Z")

</div>

I can't search for "-\>" or "\<-" or "=\>" and probably other combinations in Kibana since input gets converted to → ← ⇒ and like.

Even if it isn't **input** : creating a filter by pressing `(+)` on a "-\>" field creates a filter for "→", and I see no way to trick it not to.

It obviosuly makes it impossible to search for "=\>", for example.

Any idea why is it this way and how to force Kibana not to screw up input?

---

<div class="post-metadata">

**Author:** ![grin](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/grin/32/80387_2.png) [@grin](https://discuss.elastic.co/u/grin)\
**Post date:** [December 3, 2021, 11:11am UTC](https://discuss.elastic.co/t/input-fields-involuntarily-convert-character-combinations-into-unicode-like-or-into-and/290870/2 "2021-12-03T11:11:31Z")

</div>

**[UPDATE]**: it is an interesting (and pretty uncalled for) effect: it seems to be a _displaying_ problem. If I edit the _Query DSL_ then it _displays_ wrong but does the search.

However it was failing for me since `Discover » Details » Filter for value` (aka `+`) uses the plain field instead of `field.keyword` and the former cannot search for "=\>", but as it turned out the keyword subfield indeed can.

So I see two (or three) problems here:

1. -\> and like gets displayed incorrectly
2. _Expanded document_ shows fields (that is okay) but filters for them instead of `field.keyword`, which may result a non-working search
3. some search on `field` doesn't work which works on `field.keyword`. I guess this is not a _bug_, since I believe that's the way it works, but this creates weird effects for the first two cases.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [December 31, 2021, 11:12am UTC](https://discuss.elastic.co/t/input-fields-involuntarily-convert-character-combinations-into-unicode-like-or-into-and/290870/3 "2021-12-31T11:12:26Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.