Escapaing FINDSTR Characters

I have been unsucessful in escapaing a combination of letters within my FINDSTR search query. My query contains a quote mark (") and a chvron (>).

My search query = findstr /N /C:"font-size:10px">" inputfile.txt > outpputfile.txt

I have serached the web and this site for solutions. I have managed to successfully escape the quote mark by placing my quote within two other quotes i.e. "font-size:10px""""

Can I get some help in determineing how I can escape the BOTH the quote and chevron to make my query successful.

PS - Ultimately, I am trying to develop a search to find all matches for the string font-size:10px">AAAA. where the letters AAAA represent any number between 1-9999 followed by a period (.) - if you can provide some solution/support with that I would be even more greatful (if that is possible :)

The escape character of the findstr command is the backslash, so " must be expressed by \". However, you need to regard, that the Command Interpreter cmd.exe also recognises quotation marks, and that it uses another character for escaping, namely the caret symbol, leading to this:

findstr /N /R /C:"font-size:10px\"^>[0-9][0-9]*\.^" "inputfile.txt" > "outputfile.txt"

In this command line, the portion font-size:10px\ appears quoted to cmd.exe. The subsequent characters appears unquoted, that is why the > character must be escaped like ^>. The . is a special character for findstr, so we must escape it like \.. The closing quotation mark for the search expression must be escaped like ^" in order to hide it from cmd.exe, because there is an unbalanced number of quotation marks, which would otherwise affect the remaining command line.

Note, that [0-9] may also match characters like ¹, ², ³, depending on the current code page. To avoid that, use the following expression instead:

findstr /N /R /C:"font-size:10px\"^>[0123456789][0123456789]*\.^" "inputfile.txt" > "outputfile.txt"

As you may have noticed, I have quoted all file names. this is not necessary in this particular situation, but it is best practice to avoid troubles with file paths/names containing white-spaces or other special characters.