Skip to content

[FIX] escape special characters ( < > & ) to HTML context #1703

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
AlvinLi-harmonicinc wants to merge 2 commits into from
Closed

[FIX] escape special characters ( < > & ) to HTML context #1703

AlvinLi-harmonicinc wants to merge 2 commits into from

Conversation

@AlvinLi-harmonicinc
Copy link

@AlvinLi-harmonicinc AlvinLi-harmonicinc commented Jun 13, 2025 •
edited
Loading

In raising this pull request, I confirm the following (please check boxes):

  • I have read and understood the contributors guide.
  • I have checked that another pull request for this purpose does not exist.
  • I have considered, and confirmed that this submission will be valuable to others.
  • I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
  • I give this submission freely, and claim no ownership to its content.
  • I have mentioned this change in the changelog.

My familiarity with the project is as follows (check one):

  • I have never used CCExtractor.
  • I have used CCExtractor just a couple of times.
  • I absolutely love CCExtractor, but have not contributed previously.
  • I am an active contributor to CCExtractor.

The <, >, & is not suppose to be appeared in SRT, because SRT supports HTML tags.
So, the content of SRT should be treated as HTML content with those characters being escaped.
As a result, this pull request intends to do the following:

  • convert & to &amp;
  • convert < to &lt;
  • convert > to &gt;

@ccextractor-bot
Copy link
Collaborator

ccextractor-bot commented Aug 24, 2025

CCExtractor CI platform finished running the test files on linux. Below is a summary of the test results, when compared to test for commit a34ba0f...:
Report Name Tests Passed
Broken 10/13
CEA-708 14/14
DVB 7/7
DVD 3/3
DVR-MS 0/2
General 26/27
Hauppage 2/3
MP4 3/3
NoCC 10/10
Options 26/86
Teletext 21/21
WTV 8/13
XDS 27/34

Your PR breaks these cases:

NOTE: The following tests have been failing on the master branch as well as the PR:


It seems that not all tests were passed completely. This is an indication that the output of some files is not as expected (but might be according to you).

Check the result page for more info.

@ccextractor-bot
Copy link
Collaborator

ccextractor-bot commented Aug 24, 2025

CCExtractor CI platform finished running the test files on windows. Below is a summary of the test results, when compared to test for commit a34ba0f...:
Report Name Tests Passed
Broken 10/13
CEA-708 14/14
DVB 2/7
DVD 3/3
DVR-MS 0/2
General 26/27
Hauppage 2/3
MP4 3/3
NoCC 10/10
Options 26/86
Teletext 7/21
WTV 7/13
XDS 27/34

Your PR breaks these cases:

NOTE: The following tests have been failing on the master branch as well as the PR:

  • ccextractor --stdout --quiet --no-fontcolor 79a51f3500..., Last passed:

    Never

  • ccextractor --stdout --quiet --no-fontcolor 767b546f96..., Last passed:

    Never

  • ccextractor --autoprogram --out=srt --latin1 --quant 0 85271be4d2..., Last passed:

    Never

  • ccextractor --out=srt --latin1 f23a544ba8..., Last passed:

    Never

  • ccextractor --out=srt --latin1 10f0f77cf4..., Last passed:

    Test 5993

  • ccextractor --out=srt --latin1 df3b4d62d3..., Last passed:

    Never


It seems that not all tests were passed completely. This is an indication that the output of some files is not as expected (but might be according to you).

Check the result page for more info.

cfsmp3
cfsmp3 requested changes Dec 16, 2025
View reviewed changes
Copy link
Contributor

@cfsmp3 cfsmp3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the contribution and for thinking about edge cases in subtitle output!

After researching the SRT format specification and testing player behavior, I have concerns about this change:

The SRT Format Does Not Require HTML Entity Escaping

SRT supports a limited set of HTML-like formatting tags (<b>, <i>, <u>, <font>), but this does not mean SRT content should be treated as HTML requiring entity escaping.

From Wikipedia's SubRip article:

"Unofficially the format has very basic text formatting... Formatting is derived from HTML tags"

The key word is "unofficially" - SRT has no formal specification, and the HTML-like tags are just for formatting, not full HTML parsing.

Most Players Display Entities Literally

The bigger problem is that most SRT players (VLC, older Kodi, etc.) do NOT decode HTML entities. If we escape characters:

Original Escaped What Players Show
Tom & Jerry Tom &amp; Jerry "Tom & Jerry"
x < y x &lt; y "x < y"

This would break subtitle display for most users.

Kodi only added entity decoding in v18.7, and that was specifically for WebVTT subtitles from Netflix, not SRT.

WebVTT vs SRT

You may be thinking of WebVTT, which DOES require escaping per its specification. But CCExtractor has separate handling for WebVTT output.

Potential Buffer Issues

The ascii_to_html() function can expand 1 character to 5 (&amp;), but the calling code may not have allocated sufficient buffer space for the expansion.

If there's a specific use case where you need HTML-escaped output, we could consider:

  1. Adding escaping only for WebVTT output format
  2. Adding an optional --escape-html-entities flag

Could you share more about the specific problem you encountered that led to this PR?

@AlvinLi-harmonicinc
Copy link
Author

AlvinLi-harmonicinc commented Dec 18, 2025 •
edited
Loading

Hi @cfsmp3,

Thanks for putting effort to review my changes!
You are right that SRT only supports a limited set of HTML-like formatting tags which I overlooked.

My use case was feeding the SRT files to gpac for further conversion like outputing WEBVTT / TTML.
We have test stream includes special characters in the CC and gpac treating all <anything> as HTML tag and hide it.
I think rather than modifying ccextractor, I will do some post processing instead before feeding gpac for my case.

Anyway, I will close this pull request. Thanks for your input here!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@cfsmp3 cfsmp3 cfsmp3 requested changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@AlvinLi-harmonicinc @ccextractor-bot @cfsmp3 @prateekmedia