web-dev-qa-db-ja.com

git、msysgit、アクセント、utf-8、決定的な答え

私はいくつかの場所でgit（または単にmsysgit？）と文字エンコーディングに問題があることを読みました-私信じるこれはファイル名の問題だけです。

私が欲しいのは、以下についての「決定的な」（または少なくとも信頼できる）情報です。

  1. 「問題」とは正確には何ですか？ （症状）
  2. 原因は何ですか？ （簡単）
  3. これはどのような状況でショーストッパーですか？
  4. 解決策はありますか、それとも回避策はありませんか？

この質問が漠然としていないことを願っています。この情報をすべて1か所に集めて、人々にそれを示してもらえるといいと思います...

gitutf-8msysgit
46
Benjol

2017年2月更新（Git 2.12）：文字幅テーブルがUnicode 9.0に一致するように更新されました。
_update_unicode.sh_ は それを_contrib/update-unicode_ に移動しました： its README を参照してください。

2014年8月の更新（git 2.1）： commit a67c821 （ TorstenBögershausen（tboegi） ）は、Unicode 7.0のサポートを追加します。

2014年4月の更新： commit d813ab9 （ TorstenBögershausen（tboegi） ）はUnicode 6.3のサポートを追加します
（git 1.9.2）：

Unicode 6.3では、より多くのコードポイントが結合またはアクセント記号として定義されています。
たとえば、文字 "_ö_"は、 "o"の後に_U+0308 COMBINING DIARESIS_（別名ウムラウト、二重ドットの上）を続けて表すことができます。
このような2つのコードポイントのシーケンスは、位置合わせの目的で1つの表示列を占めることを考慮する必要があります。そのためには git_wcwidth() それらに対して0を返す必要があります。

影響を受けるコードポイントは次のとおりです。

_U+0358..U+035C
U+0487
U+05A2, U+05BA, U+05C5, U+05C7
U+0604, U+0616..U+061A, U+0659..U+065F
_

以前のユニコード標準では、これらを「予約済み」として定義していました。

このコミットの準備中に、範囲_0..U+07FF_のみがチェックされ、どのコードポイントを0幅としてマークする必要があるかが確認されました。さらに更新が必要になる場合があります。

2012年4月の更新：Unicodeサポートはバージョン1.7.10でリリースされています。設定する必要があるメモと設定については、 このページ を参照してください。

つまり：

_git config [--global] core.quotepath off
git config [--global] i18n.logoutputencoding utf8
git config [--global] i18n.commitencoding utf8
git config [--global] --unset svn.pathnameencoding
_

_recodetree check_ コマンドは、gitリポジトリの履歴全体をスキャンし、非ASCIIファイル名をすべて出力します。出力が空の場合、移行は必要ありません。

2012年2月の更新：UTF-8サポートのパッチは msysgit repo on GitHub のブランチ 'devel'で提供されています TF-8の設定を少なくする を含みます。

Git for WindowsのGoogle+ページには次のように記載されています。

Karsten BleesのGit for Windows用のUTF-8パッチが「devel」にマージされました。
これは、今後のリリースでUnicodeファイル名がサポートされることを意味します！

2011年5月

msysgit issue 8 にはそのバグに関する最新の情報があると思います。
issue 376 にも記載されています。

例えば：

これは何が起こるかです：

  1. windowsのgitはファイル名を操作し、それらを基本的にバイトストリームとして扱います。あなたの場合、ストリームはたまたまUTF8でエンコードされたテキストです。

  2. windowsのgitはランタイムにファイルの作成を要求し、バイトストリームに渡します。

  3. Windowsの内部ではすべてがUnicodeであるため、ランタイムは現在設定されているロケール（「コードページ」）を使用してバイトストリームをUTF16に変換します。
    つまり、バイトストリームがCP949（韓国語）でエンコードされたテキストとして効果的に解釈されます。
    どうやら、一部のUTF8バイトシーケンスは無効なCP949シーケンスであり、変換は失敗します（ "無効な引数"）;または、UTF8シーケンスが正しいCP949シーケンスである場合、結果は（ほとんどの場合）別の文字になります。

真の修正 mingWにあるはずです：

1つの解決策はこれだと私は思います。GCCCランタイムライブラリレベルで解決します。
つまり、Windows上のmingw GCCランタイムライブラリの場合、ビルド時のオプションを介して、コマンドラインパラメータ（main()に渡される）およびファイルI/O関数は、基盤となるWindows Unicode API呼び出しを使用し、バイト文字列を使用するCの標準関数APIのUTF-8エンコーディングとの間で変換を行います。
それはおそらくgitで「うまくいく」でしょうし、Windows環境を実行している他のLinux由来のオープンソースプロジェクトに役立つかもしれません。

ak2 コメント MingW はこの修正に適していない：

「MinGWコンパイラは、Microsoft Cランタイムおよび一部の言語固有のランタイムの機能へのアクセスを提供します。
MinGWはミニマリストであるため、MS-WindowsでのPOSIXアプリケーションの展開にPOSIXランタイム環境を提供することはありません。
このプラットフォームでPOSIXアプリケーションを導入する場合は、代わりにCygwinを検討してください。」

nicodeをサポートするmsysgitバリアント については、いくつかの作業が進行中です。

40
VonC