処理系と文字コードの関係にはふたつの側面があります。ライブラリが文字列を処理するときの振る舞いと、処理系がソースコードを解釈するときの振る舞いとです。今回は処理系の側の話です。10646:2017に更新されました。Unicodeのバージョン番号で言うと10.0相当になります。整備していた漢字が全て収録されたバージョンでもあります。https://www.ipa.go.jp/about/press/20171225.htmlソースコードのUnicode表現¶しかしまあ、普通に考えればUnicodeのバージョンの違いなんてUTFの定義が変わったみたいなレベルでなければ処理系には関係なさそうなものです。普通はコメントと文字列リテラル以外はASCIIやLatin-1の範囲で書きますよね。2005以降はUnicode識別子が認められました。それどころか空白や改行等も全てUnicodeを通じて定義されるようになりました。SPACE(U+3000、全角スペース)が使えたりするのです。Zsに含まれる文字が増えたら空白文字として使える文字も増えることになってしまいます。insensitiveです。foldingを行わなければなりません。いうわけで頭が痛くなるような話ではありますがUnicodeのバージョンが処理系の振る舞いに影響を与えてしまうわけです。ソースコードの正規化形式¶Unicode識別子に使える文字には次の条件があります。先頭はカテゴリLu、Ll、Lt、Lm、Lo、Nlの文字が使用できます。2文字目以降は加えてカテゴリMn、Mc、Nd、Pcの文字が使用できます。NFKC正規化を行って変化してしまう文字の扱いは実装依存です。実装はUnicode識別子にNFKC正規化を行っても行わなくても構いません。実装依存ですのでコンパイルエラーにするのもありです。(全角)は同じ識別子かもしれませんし違うかもしれません。同じ識別子かもしれませんし違うかもしれません。Soですので確実にコンパイルエラーです。(全角)が同一視されるようなNFKCとかけ離れたクソ変換、例えば全て同じ文字に置き換える等、をする処理系はないでしょう......と思いたいです。ソースコード上に出現できる全ての文字には次の条件があります。NFC正規化を行って変化してしまう文字の扱いは実装依存です。文字列リテラルの中であっても互換文字やNFD形式で書いた文字がそのままコンパイル後の文字列定数になる保証はありません。勝手に正規化されているかもしれません。(U+795E)に変化するかもしれませんししないかもしれません。等とする必要があります。いうわけでポータブルなソースコードを書こうと思えば、識別子はNFKCで変化しない文字のみ、文字列リテラルはNFCで変化しない文字のみで書く必要があります。2005では文字列リテラルの中であってもNFKC正規化が行われるかもしれませんでした。2020でNFKCは識別子のみ、それ以外はNFCとなりました。GNATでは¶ちなみにGNATではUnicodeをソースコード上に使えはします。