ユニコードをgit-bash(windows 7)で動作させるのに問題があります。私は多くのことを試みましたが成功しませんでした。しかし、私はこれに何が責任があるのかよく分からないので、間違った方向で作業している可能性があります。
Cmd.exeのエンコードを「chcp 65001」でUnicodeに変更できるため、これは実際に可能になるはずです。
ここに、私が試したいくつかのことを示します(GUIの構成オプションに目を通すことは明らかです)。
「.bashrc」で環境変数を設定します。私はそれがLinuxのものだと思うので、これが機能しないことは理にかなっていると思います。 「ロケール」コマンドは存在しません。
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
export LANGUAGE=en_US.UTF-8
Cmd.exeで開始し、「chcp 65001」でエンコードをUnicodeに変更してから、git-bashを起動します。これにより、Unicodeテストファイルをcatしようとすると、許可が拒否されます。ただし、Unicodeなしでファイルをcattingすることは問題なく機能します。示されているように、cmd.exeにドロップアウトすると、ファイルを「cat」できます。デフォルトのエンコーディング(437)を使用して、bashでファイルをcatできます(許可は拒否されませんが、出力はファッジされます)。
S:\>chcp 65001
Active code page: 65001
S:\>"C:\Program Files (x86)\Git\bin\sh.exe" --login -i
zarac@TOWELIE /z
cat /s/unicode.txt
cat: write error: Permission denied
zarac@TOWELIE /z
cat /s/nounicode.txt
abc
zarac@TOWELIE /z
L /s/unicode.txt
-rw-r--r-- 1 zarac Administ 7 May 18 10:30 /s/unicode.txt
zarac@TOWELIE /z
whoami
towelie\zarac
zarac@TOWELIE /z
exit
Z:\>type S:\unicode.txt
abc£
シェルを起動するときに/ Uフラグを使用します(if-i-understand-correctの目的とはまったく異なるため機能しないことは理にかなっていますが、Unicodeに関係しているので試してみました)。
C:\Windows\SysWOW64\cmd.exe /U /C "C:\Program Files (x86)\Git\bin\sh.exe" --login -i
Console2を使用したいので、[HKEY_CURRENT_USER\Console]および[HKEY_CURRENT_USER\Console\Git Bash]の下のWindowsレジストリに、値65001(10進数)のCodePageという名前のdword値を追加しようとしました。これは、「chcp 65001」を「自動」に設定するのと同じ効果があるようです。 (http://stackoverflow.com/questions/379240/is-there-a-windows-command-Shell-that-will-display-unicode-characters)
JPSoftのTCC/LE
PowerCMD
スタックオーバーフロー
ダックダック
ixquick/google
そのため、その許可の問題を修正できる場合、方法2は実行可能と思われます。ただし、Console2を使用できる場合は好まれますが、ほとんどすべてのソリューションを受け入れています(主にその優れたタブ機能のため)。おそらく1つの解決策は、SSHサーバーをセットアップしてからPuTTY/Kittyを使用して接続することですが、それは間違っています! ; )
PS。 git-bashの公式ドキュメントはありますか?
CharlesBがコメントで述べたように、msysgit 1.7.10はUnicodeを正しく処理します。まだいくつかの問題がありますが、更新によって問題が解決したことを確認できます。
参照: https://github.com/msysgit/msysgit/wiki/Git-for-Windows-Unicode-Support
MSYS Git 2.8.0で同じ問題に直面しましたが、判明したのは構成を変更するだけでした。
$ git --version
git version 2.8.0.windows.1
私のシステムのGit Bashコンソールのデフォルト構成では、ギリシャ語のファイル名が表示されませんでした。
$cd ~
$ls
AppData/
'Application Data'@
Contacts/
Cookies@
Desktop/
Documents/
Downloads/
Favorites/
Links/
'Local Settings'@
NTUSER.DAT
.
.
.
''$'\316\244\316\261'' '$'\316\255\316\263\316\263\317\201\316\261\317\206\316\254'' '$'\316\274\316\277\317\205'@
最後の行には、「My Documents」のギリシャ語訳「Ταέγγραφάμου」が表示されます。それを修正するために、私は以下の手順に従いました。
既存のロケール構成を確認してください
$locale
LANG=en
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=
上記のように、私の場合はUTF-8ではありませんでした
ロケールをUTF-8エンコードに変更します。 MINGWタイトルバーの左側にあるアイコンをクリックし、[オプション]を選択して、[テキスト]カテゴリで[UTF-8]文字セットを選択します。デフォルトの「Lucida Console」などのUnicodeフォントも選択する必要があります。私の設定は次のようになります:
現在のウィンドウの言語を変更します(手順2の設定で作成されるため、将来のウィンドウでこれを行う必要はありません)
$ LANG='C.UTF-8'
Lsコマンドが正しく表示されるようになりました
AppData/
'Application Data'@
Contacts/
Cookies@
Desktop/
Documents/
Downloads/
Favorites/
Links/
'Local Settings'@
NTUSER.DAT
.
.
.
'Τα έγγραφά μου'@
Git 2.1でも問題が解決するかどうかを確認してください(2014年8月)。
commit 617ce96 または commit 1c950a5 by Karsten Blees(kblees
) を参照
WriteConsoleW
が、ユニコードをコンソールに確実に印刷する唯一の方法であるようです(奇妙なコードページ変換なしで)。
vfprintf
もwinansi.c
バージョンにリダイレクトします。
Unicode変換関数を追加して、WindowsのネイティブUTF-16LEエンコーディングとUTF-8の間の変換を行います。
レガシーエンコードされたファイル名を持つリポジトリをサポートするために、UTF-8からUTF-16への変換関数は、無効なUTF-8バイトシーケンスに対しても有効で一意のファイル名を作成しようとするため、これらのリポジトリはエラーなしでチェックアウトできます。
Msysgitにすでに統合されているものの移植版になる可能性がありますが、少なくともそれは、GitのWindowsバージョンがメインのGitリポジトリソースコードからそれらの改善を含めるために分岐/パッチする必要がないことを意味します。
Windowsのgit bashを使用した文字エンコードには、いくつかの問題があることがわかります。 git自体と付属のツール(curl、cat、grepなど)を使用した作業は少なくなります。私はこれらの文字エンコーディング関連の問題を何年も経験していませんでした。
通常、新しいバージョンの問題が発生するたびに、問題が解決されます。例えば。 1年前のバージョンでは、「ä
」などの文字をシェルに入力できなかったため、書くことができませんでした
echo "ä"
UTF-8がサポートされているかどうか、およびそのレベルですばやくテストするため。回避策は、バイトシーケンスを8進数で記述することです。
$ echo -e "\0303\0244"
ä
Windowsのphp.exeバイナリを実行してテキストを出力すると、まだ問題が発生します。
$ php -r 'echo "\xC3\xA4";'
ä
これは、ターミナルに「ä
」を与えませんが、代わりに「├ñ
」を出力します。そのための回避策は、php
を介して出力を処理するbashスクリプトでcat
コマンドをラップすることです。
#!/bin/bash
{ php.exe "$@" 2>&1 1>&3 | cat 1>&2; } 3>&1 | cat
これにより、魔法のようにphp
が再び機能するようになります。
$ php -r 'echo "\xC3\xA4";'
ä
に適用されます
$ git --version
git version 1.9.4.msysgit.1
なぜこれがすべてなのかを深く理解していないことを認めなければなりません。しかし、ついにUTF-8をサポートするgit bashでphpを使用する回避策を見つけてうれしく思います。
Chcp 65001の問題は、コードページ65001で実行したときにstdio呼び出しが一貫性のない結果を返すCランタイム(MSVCRT)のバグがあることです。
それはGit 2.23(2019年第3四半期)で改善されるはずです
コミット090d1e8 (2019年7月3日)by Karsten Blees(kblees
) を参照してください。
( C Hamano-gitster
- in commit 0328db 、2019年7月11日)
gettext:ネイティブWindowsでは常にUTF-8を使用します
ネイティブWindowsでは、Gitはコンソール出力にUTF-8のみを使用します(MinTTYとネイティブWin32コンソールの両方)。
Gettextは
setlocale()
を使用して、翻訳されたテキストの出力エンコーディングを決定します、ただし、MSVCRTのsetlocale()
はUTF-8をサポートしません。その結果、翻訳されたテキストはシステムエンコーディング(GetAPC()
による)でエンコードされ、非ASCII文字はコンソール出力でマングルされます。サイドノート:実際にはUTF-8のコードページがあります:65001。
実際には、少なくともWindows 7では期待どおりに動作しません。そのため、Gitでは使用できません。さらに、コードページをオーバーライドした場合、Gitから生成されたプロセスは(現在のユーザー用に構成されたコードページとは対照的に)そのコードページを継承します。差分またはマージヘルパー。 したがって、実際にコードページをオーバーライドすることはできません。
init_gettext_charset()
では、Gitはbind_textdomain_codeset()
で取得した文字セットを使用してgettextのlocale_charset()
を呼び出します。後者の関数をオーバーライドして、ネイティブWindowsでエンコードを強制的にUTF-8にしましょう。Git for WindowsのSDKには_
libcharset.h
_があり、したがって_HAVE_LIBCHARSET_H
_のMINGW固有のセクションで_config.mak.uname
_を定義します。したがって、条件付きでコンパイルされたコードの前にオーバーライドを追加する必要がありますブロック。ただし、単に_
"UTF-8"
_を返すようにlocale_charset()
を定義するのではなく、_LC_ALL=C
_を壊さないように注意します。たとえば、_ab/no-kwset
_パッチシリーズはGitがUTF-8エンコードされた入力を予期しないようにする方法。
そして:
commit 697bdd2 (2019年7月4日)、および commit 9423885 、 commit 39a98e9 (2019年6月27日)by Johannes Schindelin(dscho
) 。
( C浜野順夫-gitster
- in commit 0a2ff7c 、2019年7月11日)
mingw
:Unicode関数を明示的に使用する多くのWin32 API関数は、実際には2つのバリアントに存在します。1つはANSIパラメーターを受け取る
A
サフィックス(_char *
_または_const char *
_)、もう1つはUnicodeパラメーターを受け取るサフィックスW
(_wchar_t *
_または_const wchar_t *
_)。ANSIバリアントでは、現在のロケールに応じて文字列がエンコードされていると想定しています。
これはGitがWindowsで使用したいものではありません。_char *
_変数はUTF-8でエンコードされた文字列を指すと仮定します。Windowsには擬似UTF-8ロケールがありますが、期待どおりに機能しません。さらに、ユーザーのロケールをオーバーライドすると、Gitによって生成されたプログラム(エディター、difftoolsなど)の動作が変更されるため、その擬似ロケールを使用できません。
さらに、実際にはANSIバージョンの代わりにUnicodeバージョンを使用することを強くお勧めします。
注:Win32 API関数withoutサフィックスなしで呼び出す場合、関連するヘッダーが#include'dされる前に
UNICODE
定数が定義されているかどうかによって異なります。
その定数がないと、ANSIバリアントが使用されます。
はっきりさせて、あいまいさを避けましょう。