unicode: ToUpper fail for German ß character

[lordofscripts]

No

What version of Go are you using (go version)?

$ go version
go version go1.25.0 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN='/home/lordofscripts/go/bin'
GOCACHE='/home/lordofscripts/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/lordofscripts/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3576437392=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/dev/null'
GOMODCACHE='/home/lordofscripts/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/lordofscripts/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/lordofscripts/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.25.0'
GOWORK=''
PKG_CONFIG='pkg-config'
uname -sr: Linux 6.12.41+deb13-amd64
Distributor ID:	Debian
Description:	Debian GNU/Linux 13 (trixie)
Release:	13
Codename:	trixie
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Debian GLIBC 2.41-12) stable release version 2.41.
gdb --version: GNU gdb (Debian 16.3-1) 16.3

What did you do?

First of all I want to say something IMPORTANT. I think it is GREAT that the GO language is consistent in this: that the German Es-tzet character ß (a single-character rune) has an equivalent uppercase ẞ single-character rune rather than SS. I say it because THAT is consistent, if your algorithm is handling runes it expects runes as return. Why? because Lowercase ß (rune) has uppercase ẞ (also a rune) is programmatically correct, whereas saying lowercase ß is uppercase SS (double-rune i.e. string) is not programmatically correct. We don't want to break algorithms with exceptions.

Now, it so happens I spent hours debugging (long live unit tests!) an application where German was one of the input languages. I found out that the culprit was
that the standard GO library is not quite consistent in its doings when it comes
to this special characters: ßẞ

I prepared a Test Case that shows strings.ToUpper does not follow the correct GO assumption (speaking as a programmer, not a linguist!):

func Test_GermanCharacter(t *testing.T) {
	const LOWER_RUNE rune = 'ß' // 223
	const UPPER_RUNE rune = 'ẞ' // 7338
	const LOWER_STRING string = "daß"
	const UPPER_STRING string = "DAẞ"

	// just to make sure, these two PASS
	if LOWER_RUNE == UPPER_RUNE { // passes
		t.Errorf("This isn't supposed to happen in 1.25")
	}
	if LOWER_STRING == UPPER_STRING { // passes
		t.Errorf("This isn't supposed to happen in 1.25")
	}

	fmt.Printf("Lowercase es-tzet: %c (%U)\n", LOWER_RUNE, LOWER_RUNE)
	fmt.Printf("Uppercase es-tzet: %c (%U)\n", UPPER_RUNE, UPPER_RUNE)

	// Now the STD Lib inconsistencies
	var gotS, expectS string

	// (a) strings.ToUpper("daß") should be "DAẞ"
	expectS = UPPER_STRING
	gotS = strings.ToUpper(LOWER_STRING)
	if gotS != expectS { // FAILS with Std. Lib. v1.25
		t.Errorf("strings.ToUpper failure Got:'%s' Expect:'%s'", gotS, expectS)
	}

	// (b) strings.ToLower("DAẞ") should be "daß"
	expectS = LOWER_STRING
	gotS = strings.ToLower(UPPER_STRING)
	if gotS != expectS {
		t.Errorf("strings.ToLower failure Got:'%s' Expect:'%s'", gotS, expectS)
	}

	var gotR, expectR rune

	// (c) unicode.ToUpper('ß') should be 'ẞ'
	expectR = UPPER_RUNE
	gotR = unicode.ToUpper(LOWER_RUNE)
	if gotS != expectS {
		t.Errorf("unicode.ToUpper failure Got:'%c' Expect:'%c'", gotR, expectR)
	}

	// (d) unicode.ToLower('ẞ') should be 'ß'
	expectR = LOWER_RUNE
	gotR = unicode.ToLower(UPPER_RUNE)
	if gotS != expectS {
		t.Errorf("unicode.ToLower failure Got:'%c' Expect:'%c'", gotR, expectR)
	}
}

Even better, here is a different non-test version: a Go Play example demonstrating the findings.

What did you expect to see?

Conversions of unicode.ToUpper(), unicode.ToLower() and strings.ToUpper(), strings.ToLower() should be consistent that a lower to upper must be uppercased, and that an upper to lower should result in lowercase.

What did you see instead?

Given the CORRECT programming-wise assumption that a conversion of a rune to/from Upper/Lowercase must also be a RUNE type, the library functions must be consistent in its translations. For the German ß character I observed:

• unicode.ToUpper() gives an incorrect value (does not convert)
• strings.ToUpper() gives an improper conversion if it contains ß in the string

[gabyhelp]

Related Issues

• unicode: use unicode.ToUpper on the result of unicode.ToLower returns the wrong rune if it is a Greek rune: ẞ and ϴ #56448 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[randall77]

The bug is that

fmt.Printf("ToUpper(%x)=%x\n", 0xdf, unicode.ToUpper(0xdf))

prints

ToUpper(df)=df

where you want it to do

ToUpper(df)=1e9e

Unicode standard says (in 16.0. Go is currently on 15.0), for df:

• uppercase is “SS” (standard case mapping),
alternatively 1E9E ẞ

In Go we can't do the standard mapping because it results in multiple characters.
So maybe we should do the alternate? Seems reasonable to me, although it was kind of rejected in #56448. But maybe that was in relation to an earlier unicode standard?

[adonovan]

According to https://www.unicode.org/Public/16.0.0/ucd/CaseFolding.txt, the latest case folding table, U+DF still uppercases to "SS".

[prattmic]

cc @golang/security @robpike @mpvl

[lordofscripts]

Related Issues

• unicode: use unicode.ToUpper on the result of unicode.ToLower returns the wrong rune if it is a Greek rune: ẞ and ϴ #56448 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

Do note that the Greek letter BETA looks very similar to the German ß but it is NOT the same character.

No, the Greek lowercase beta (β) is not the same as the German "eszett" (ß) or "sharp S". Although they may look similar in some fonts, especially in isolation, they are distinct characters with different origins, pronunciations, and Unicode values (Greek β is U+03B2, German ß is U+00DF). The ß is a ligature of "ss" or "sz" from medieval German, while beta is a letter of the Greek alphabet.

[lordofscripts]

In go the uppercase is also a rune and I think GO should stick to that. Making the uppercase a string would wreak havoc and not be consistent.

The bug is that

fmt.Printf("ToUpper(%x)=%x\n", 0xdf, unicode.ToUpper(0xdf))

prints

ToUpper(df)=df

where you want it to do

ToUpper(df)=1e9e

Unicode standard says (in 16.0. Go is currently on 15.0), for df:

• uppercase is “SS” (standard case mapping),
alternatively 1E9E ẞ

In Go we can't do the standard mapping because it results in multiple characters.
So maybe we should do the alternate? Seems reasonable to me, although it was kind of rejected in #56448. But maybe that was in relation to an earlier unicode standard?

[lordofscripts]

BTW. While strings.ToUpper() always leaves ß in lowercase, strings.ToLower() does convert the uppercase esset to its lowercase.

The same happens with their rune counterparts in the Unicode package.

However, I should add that I noticed that sometimes unicode.ToUpper() works but under what circumstances it still escapes me. What I know is that I cannot trust the ToUpper function when it comes to that character.Seemed to work well with the Greek and Cyrillic alphabets though.

[randall77]

Do note that the Greek letter BETA looks very similar to the German ß but it is NOT the same character.

The title of #56448 talks about the Greek beta, but that title is misleading. One of the actual runes shown in the reproduction code is the same one here.

[lordofscripts]

Actually, strings.ToUpper() also show the same anomaly. Look at both the attached test case and the attached To Play examples.

According to https://www.unicode.org/Public/16.0.0/ucd/CaseFolding.txt, the latest case folding table, U+DF still uppercases to "SS".

[andig]

strings.ToLower() does convert the uppercase esset to its lowercase.

Which breaks round-tripping and is a good argument (native German here) for doing the alternate mapping when standard is not doable.

[ianlancetaylor]

I just want to mention that code that wants to handle this kind of thing correctly should be using the golang.org/x/text/cases package.

[jfrech]

I would like to add that the behaviour presently exhibited in this regard matches the Unicode standard; the Unicode consortium has even written about precisely the letter 'ß' in their FAQ: Cf. https://web.archive.org/web/20251007201402if_/https://www.unicode.org/faq/casemap_charprop#1 [2025-11-09]

See also The Unicode® Standard ; Version 17.0 – Core Specification, section 5.18.2:

(...) when using the default Unicode casing operations, capital sharp s will lowercase to small sharp s, but not vice versa: (...)

Cf. https://web.archive.org/web/20250920055001if_/https://www.unicode.org/versions/Unicode17.0.0/core-spec/chapter-5/#G36881 [2025-11-09]

And strings.ToUpper cannot turn 'ß' into "SS" without breaking its doc-comment-claimed property to be equal to strings.Map(unicode.ToUpper, •).

One final note: the word "daß" doesn't exist anymore in German for now over two decades. I'd use a word like "Späßle", "Maßeinheit" or "aß" in my tests.