SAX против XmlTextReader - SAX в C#

Если вы говорите о SAX для .NET, похоже, что проект не поддерживается. Последний выпуск был более 2 лет назад. Может быть, они сделали это идеально на последнем выпуске, но я бы не стал на это ставить. Автор, Карл Вацлавек, похоже, исчез из сети.

Что касается SAX под Java? Готов поспорить, это здорово. К сожалению, SAX никогда не разрабатывался как стандарт, поэтому все порты, отличные от Java, адаптировали Java API для своих нужд. Хотя DOM - довольно паршивый API, он имеет то преимущество, что он был разработан для нескольких языков и сред, поэтому его легко реализовать на Java, C#, JavaScript, C и др.

Я считаю, что использование SAX не приносит никаких преимуществ, по крайней мере, по двум причинам:

1. SAX - это модель «проталкивания», а XmlReader - анализатор опрашивания с ряд преимуществ.
2. Зависимость от сторонней библиотеки вместо использования стандартного .NET API.

Если вы просто хотите быстро выполнить работу, для этой цели существует XmlTextReader (в .NET).

Если вы хотите изучить стандарт де-факто (и доступный на некоторых других языках программирования), который является стабильным и заставляет вас писать код очень эффективно и элегантно, но который также является чрезвычайно гибким, тогда изучите SAX. Однако не тратьте время зря, если только вы не собираетесь создавать очень сложные синтаксические анализаторы XML. Вместо этого поищите парсеры, которые являются парсерами следующего поколения (например, XmlTextReader) для вашей конкретной платформы.

Ресурсы SAX
SAX изначально был написан для Java, и вы можете найти исходный проект с открытым исходным кодом, который был стабильным в течение нескольких лет, здесь: http://sax.sourceforge.net/

Здесь есть порт C# того же проекта (с документацией HTML как частью исходной загрузки); он также стабилен: http://saxdotnet.sourceforge.net/

Если вам не нравится реализация C#, вы всегда можете прибегнуть к ссылке на COM-библиотеки DLL через COMInterop, используя MSXML3 или более позднюю версию: http://msdn.microsoft.com/en-us/library/ms994343.aspx

Статьи из мира Java, которые, вероятно, иллюстрируют концепции, необходимые для успешного использования этого подхода (также может быть загружаемый исходный код Java, который может оказаться полезным и может быть достаточно простым для преобразования в C#):

• Вывод больших XML-документов, часть 1 (http://www.ibm.com/developerworks/xml/library/x-tipbigdoc.html)
• Вывод больших XML-документов, часть 2 (http://www.ibm.com/developerworks/xml/library/x-tipbigdoc2.html)
• Используйте фильтр SAX для управления данными (http://www.ibm.com/developerworks/xml/library/x-tipsaxfilter/)

Это будет громоздкая реализация. Я использовал SAX только в те дни, когда еще не было .NET, но для этого требуются довольно продвинутые методы кодирования. На данный момент это просто не стоит проблем.

Интересная концепция гибридного парсера
В этом потоке описывается гибридный синтаксический анализатор, который использует .NET XmlTextReader для реализации синтаксического анализатора, который обеспечивает комбинацию преимуществ DOM и SAX ...
http://bytes.com/groups/net-xml/178403-xmltextreader-versus-dom

Лично я предпочитаю модель SAX, поскольку у XmlReader есть несколько действительно раздражающих ловушек, которые могут вызвать ошибки в вашем коде, которые могут привести к пропуску элементов в вашем коде. Большая часть кода будет структурирована вокруг модели while (rdr.Read ()), но если у вас есть «ReadString» или «ReadInnerXml ()» в этом цикле, вы обнаружите, что пропускаете элементы на следующей итерации.

Поскольку SAX основан на событиях, этого никогда не произойдет, поскольку вы не можете выполнять какие-либо операции, которые заставили бы ваш синтаксический анализатор искать вперед.

Лично я считаю, что Microsoft изобрела представление о том, что XmlReader лучше объясняет модель push / pull, но я на самом деле не покупаю это. Итак, Microsoft думает, что вам не нужно создавать конечный автомат с XmlReader, для меня это не имеет смысла, но в любом случае это всего лишь мое мнение.