Agreed. Added a comment about the meaning of \xA9.

I'm just curious in your codepage what does © look like

It comes down to how the codepage of the file is (mis)detected/-interpreted by the editor/viewer at hand.

E.g. in my regular editor (mcedit), I've set the default encoding to UTF-8, so it looks like this:

In the browser (Safari) this particular github.com PR diff looks like this for the first hunk (and appears fine for the second hunk):

It's generally difficult to predict how 8-bit codepages behave using default configurations in different environments, so one solution I found to work is to stick to 7-bit ASCII or UTF-8 (where 7-bit ASCII is not enough) for text files. In case of Windows Resources this may not always be practical due to the spotty support for UTF-8 encoded .rc files, though it can work with the more popular C toolchains.

FWIW, here's a commit that implements UTF-8 Windows Resources for another project:
vszakats/hb@10d2537

Looking at that makes me wonder why our resource file translation field is currently set to 1200 (Unicode) if the block is not in any Unicode encoding. Is that a mistake and should it be 1252 (ANSI/Latin1) instead?

Also, though there's no hard-and-fast rule for this the traditional practice for PR branches is to go on your origin instead of upstream. An exception would be multiple project collaborators working on a branch like recall the https proxy branch that was around for a while or now to a much lesser extent generate-curl-1. A small change like this will be transient though and not that.

@jay As for 1200 vs 1252 I think it's fine as it as, and although I've yet to find definitive information, my experience is that this value doesn't influence how resource compilers interpret the .rc file in any particular codepage. For that, most RC tools offer a command-line option (usually -c). Nor does it seem to control how values are stored inside the PE image, which is always UTF-16. So what does it control? Hard to tell. Maybe \xA9 works because it means copyright symbol in Unicode as well.

I've updated the patch to leave out guesses about the codepage being used in relation to \xA9.

The branching is noted, again something that crossed my mind, but decided this is such a simple change that the branch will be short lived.

Converted hex to lowercase to match rest of file and cleaned the comment further.

Ok LGTM, please make sure to reference this discussion in the body of the upstream commit message with a Ref: or Closes: line, for example one of these
Ref: <url>
Ref: https://github.com/curl/curl/pull/1217
Closes https://github.com/curl/curl/pull/1217
Closes #1217 etc

Thank you @jay. I hope I got it right!

A code \xA9 is defined in CP1252 and Unicode but is not defined in CP936 that cause a compilation problem on Chinese and other non-English Windows that "default language for non-unicode application" is non-Unicode.
MSVC toolset assumes source code is DBCS on such windows environment, and it cause a compilation problem. That is why vcpkg project comment refers here.

the suggested solution in that issue is use (c) instead, does anyone object to that?

(c) is fine of course. Copyright is another option.

BTW, to avoid relying on default codepages used by the resource compiler in various environments, it may help to explicitly specify the .rc codepage by passing the -c65001 option (for UTF-8) to the resource compiler. This exact option works with MSVC, windres, Borland C, Pelles C, ICC. It would be interesting to see if this resolves the problem on Chinese Windows.

IINAL, but my understanding is that (c) doesn't have the same legal significance that © does, in those jurisdictions where a copyright notice is still required.

it may help to explicitly specify the .rc codepage by passing the -c65001 option (for UTF-8) to the resource compiler

@miurahr can you try that

@dfandrich INAL but, Berne Convention contract among 175 countries takes a way not to require formal registration or representation, that is because it is not mandatory to add © except for one who were living out of Berne Convension, or one who authored in USA before 1989 when US joined to Berne convention.

@jay I'd like try -c65001