I only have a fairly basic understanding of encodings, but is this one by any chance in one of the smaller “standard” character sets and not in the huge Unicode “emoji” set?
There's not really a "standard" character set and an "emoji" one. There is an emoji block (U+1F600 to U+1F64F), and this heart (U+2665) is not in that. But this heart is an emoji, in that the data file emoji-data.txt for contains `Emoji=Yes` ("=Yes for characters that are emoji", —UTS #51) for this character. However, this heart has `Emoji_Presentation=No`, which "=Yes for characters that have emoji presentation by default" (—UTS #51).
So basically, it should present, by default, in its non-emoji appearance. (Though there seem to be a number of readers for whom that isn't true. I think that's macOS being badly behaved.) There are some characters that can flip/flop between a "text" (normal monochrome) presentation and an emoji presentation; all of the card suit characters are. Unadorned (e.g., just U+2665 alone) then, you have to follow the emoji default presentation rules. In some contexts, such as web pages, that's "just do what that Emoji_Presentation flag says" for those characters, but see [§Presentation Style](https://www.unicode.org/reports/tr51/proposed.html#Presentat...) for exceptions to the rule. (HN is not an exception.) But you can also follow the character with a variation selector, to try to force either text (U+FE0E) or emoji (U+FE0F) presentation.
There are a number of what I'd call "yeah that's definitely an emoji" outside the Emoji block, too. Like U+2705 "white check in green box" (which HN disallows me posting); that one is Emoji=Yes but also Emoji_Presentation=Yes)
(IDK if Emoji=Yes Emoji_Presentation=Yes is HN's filter … but that'd be what I would do, if I wanted to filter out emoji like HN does.)
UTS #51 is your friend.
There's not really a "standard" character set and an "emoji" one. There is an emoji block (U+1F600 to U+1F64F), and this heart (U+2665) is not in that. But this heart is an emoji, in that the data file emoji-data.txt for contains `Emoji=Yes` ("=Yes for characters that are emoji", —UTS #51) for this character. However, this heart has `Emoji_Presentation=No`, which "=Yes for characters that have emoji presentation by default" (—UTS #51).
So basically, it should present, by default, in its non-emoji appearance. (Though there seem to be a number of readers for whom that isn't true. I think that's macOS being badly behaved.) There are some characters that can flip/flop between a "text" (normal monochrome) presentation and an emoji presentation; all of the card suit characters are. Unadorned (e.g., just U+2665 alone) then, you have to follow the emoji default presentation rules. In some contexts, such as web pages, that's "just do what that Emoji_Presentation flag says" for those characters, but see [§Presentation Style](https://www.unicode.org/reports/tr51/proposed.html#Presentat...) for exceptions to the rule. (HN is not an exception.) But you can also follow the character with a variation selector, to try to force either text (U+FE0E) or emoji (U+FE0F) presentation.
There are a number of what I'd call "yeah that's definitely an emoji" outside the Emoji block, too. Like U+2705 "white check in green box" (which HN disallows me posting); that one is Emoji=Yes but also Emoji_Presentation=Yes)
(IDK if Emoji=Yes Emoji_Presentation=Yes is HN's filter … but that'd be what I would do, if I wanted to filter out emoji like HN does.)
UTS #51: https://www.unicode.org/reports/tr51/proposed.html#Emoji_Pro...
(Also, note that the title was changed; the original HN title was "I ♥ RSS")