Что такое хороший и хороший способ производительности для обработки строки - PullRequest
1 голос
/ 10 марта 2011

У меня есть строка в следующем формате: <b>*GTPersonnel</b><table border=1><tr><td>&#115;&#115;&#50;&#49;&#49;&#49;</td></tr></table>

Я хочу обработать эти данные, которые находятся между тегами <td>, и заменить каждое вхождение &#Blah; его равным символом, поэтому дляНапример, &#115; Я хочу, чтобы он был заменен только символом a, потому что 115 - это код символа для этого.

Я могу просмотреть всю строку, найти индекс &#, найти; индекс, прочитайте символ между ними и найдите символ для этого кода ... ну, это немного алгоритмически ... Мне было интересно, есть ли лучшие вещи с .NET, которые я могу использовать для этой цели.

Ответы [ 2 ]

2 голосов
/ 10 марта 2011

Если вы используете XHTML, вы можете просто изменить свойство EntityHandling в XmlTextReader объекте, чтобы указать ему обрабатывать символьные объекты автоматически:

XmlTextReader reader = new XmlTextReader( "temp.xml" );
reader.EntityHandling = EntityHandling.ExpandCharEntities;

Затем вы можете прочитать ваш файл с помощью XmlTextReader или с помощью LINQ to XML. Например, если у вас есть XML-файл, подобный этому:

<?xml version="1.0" encoding="utf-8" ?>
<document>
    <td>&#115;&#115;&#50;&#49;&#49;&#49;</td>
</document>

И вы пишете код ниже и следующую пару строк:

while ( reader.Read() )
    if ( reader.NodeType == XmlNodeType.Text )
        Console.WriteLine( reader.Value );

В окне консоли вы получите значение ss2111.

1 голос
/ 10 марта 2011

Высокопроизводительным, достаточно простым способом было бы установить построитель параллельных строк (инициализировать его длину такой же, как у оригинала) и продолжать добавлять к нему с первого раза последовательные вызовы IndexOf ("#") и соответствующие преобразования. Таким образом, вы не делаете никаких вставок или удалений, вы не изменяете размер массива поддержки строителя строк (кроме как в конце), и вы читаете первую строку только вперед. LINQifying это возможно с Aggregate (), но будет больше проблем, чем стоит, и, вероятно, менее ясно.

...