Is my approach to creating my own JSON, XML, HTML, CSS parsing engine algorithm good? And what about parsing the code in PL?

Question

Algorithms

It’s not that it’s even mine, it’s just that I haven’t seen any other solutions anywhere. And they don't get in your head.
In general, we take the source code (in the form of a string) and simply go through all its characters in a loop, checking with if's what the character is, and making the appropriate decision (for HTML: if "<", then create a branch, then parse the tag and attributes; if ">", then further we parse the content, also closing the branch, etc.; all this auxiliary stuff - that is, creation, closing, etc. - separate functions are occupied so as not to clutter up the parsing code itself)
Well, in order to remember on each character exactly where we are and what characters we should expect (whether we are inside an attribute with quotes, or inside an attribute without quotes, or we are after "<" and should expect ">", or inside a branch, etc.) for this there is an enumeration variable (location options) + more variables.
Questions:
1) Is this approach good for JSON, XML/HTML, CSS?
2) How to call it, so that it would be "scientifically" and understandable?
3) Is its use justified for parsing not a markup language, but a real PL, say JS?
Or is it too "bicycling" for this task?
4) Nothing better comes to mind, neither for PL, nor even for JSON, XML/HTML, CSS...
Может, регулярки в прямых руках будут лучше? Почему тогда их не применяют в подобных движках?

Answer 1

Для начала изучите то, что было придумано до вас. Начните, например, с книги красного дракона.

Answer 2

То что вы описали называется state_machine и это обычный подход для парсинга xml. Тьюринг полный ЯП так не распарсить, например не распарсить goto. ЯП описываются EBNF или другими достаточно варазительными грамматиками и парсятся в абстрактное_синтаксическое_дерево. Парсеры EBNF могут к примеру подсматривать вперед или назад.

Answer 3

1) Нет, плох. Ничего у вас с этим подходом хорошего не выйдет.
2) Конкретно этот подход - детерминированный конечный автомат
3) Нет, не оправдано. Не получится.
4) Почитайте что-нибудь на тему теории формальных языков и грамматик. Конструирование компиляторов. Теория интерпретации компьютерных программ.
Регулярное выражение эквивалентно детерминированному конечному автомату, так что не выйдет.

Answer 4

VZVZ: человек, прочитайте пожалуйста книги Колмогорова Андрея Николаевича по математической логике, а также труды Чёрча по лямбда-вычислениям, а затем Интерпретация Лисп(Lisp) и Ским(scheme). Потом уже переходите к алгоритмам. Как Вам правильно посоветовали: "Изучите ТО что было ДО ..."

Answer 5

Местоположения мало.
Взять к примеру json - {"name": "value"}
Если обрабатываешь символ "n", то находишься в документ/обьект/наименование атрибута обьекта/текст
А если символ "v", то документ/обьект/значение атрибута обьекта/текст
И таких тонкостей много.