アカウント名:
パスワード:
日本語のhello, worldが普通に表示できる! (なおソースファイルの文字コードはUTF-8)
- hello.pl -------------say 'こんにちは、世界♥';------------------------> perl6 hello.plこんにちは、世界♥
日本語のファイル名が普通に開ける!
- file.pl --------------
これ [qiita.com]
------------------------- 日本語.txt -----------こんにちは、世界♥------------------------> perl6 file.pl 日本語.txtこんにちは、世界♥
さっきから何を当たり前のことで感動してるんだとか何がすごいのかわからないとか思った人は幸せです。きっとWindowsのPerl 5で日本語 [developers.srad.jp]を扱ったことがないのでしょう。惜しむらく
惜しむらくは、コマンドラインからUnicode文字列を受け取れないこと。
Windowsでperl5使ってる者だが、結局なんじゃないかと。
一つ目と二つ目はUTF8な文字列(perl5だとutf8フラグ付き)でもSTDOUTへの出力の際にcp932に変換してくれているように見える。二つ目は更にファイルシステムの読み込みの際も変換かけてくれているのかな。その癖、最後のを見るとSTDINからは駄目。というかWindowsだからと勝手に変換かけられても困るのだがね。実行はcmd.exeだけじゃないのよ。
Encodeかますのが面倒は解るが、実装が中途半端な方がもっと面倒じゃないか。単なる不具合で修正されるというならともかく、幻滅もんじゃないか、これ。
> 一つ目と二つ目はUTF8な文字列(perl5だとutf8フラグ付き)でもSTDOUTへの出力の際にcp932に変換してくれているように見える。
CP932に♥は含まれていないからそれはありえない。もしcp932に変更されているなら3つ目のように?に変換されて出力されるはず。だからWin32::Unicode::Consoleのように、最終的にWriteConsoleWを使っているはず。わざわざサンプルに♥を含めたのはそれを確認するため。
> 二つ目は更にファイルシステムの読み込みの際も変換かけてくれているのかな。
これも違う。コマンドラインから渡せなかったのでわかりにくくなってるけど、たとえば
print "日本語♥.txt".IO.slurp;
とすれば、ちゃんとUnicode文字を含むファイルを開ける。つまりWin32::Unicode::Fileのように最終的にCreateFileWを呼び出している。
単にcp932に変換している程度だったらここまで感動していないよ。
> その癖、最後のを見るとSTDINからは駄目。
あのーSTDINとコマンドライン引数の区別もついてないんですか?とりあえずこれ [stackoverflow.com]で確認。
ああああRead: ああああ日本語♥Read: 日本語♥
STDINはちゃんとUnicode文字にも対応している。コマンドライン引数が対応していないのは確かに残念だけど、Perl 5のように修正不可能な根本的な制約ではないから修正の望みがある。
> というかWindowsだからと勝手に変換かけられても困るのだがね。実行はcmd.exeだけじゃないのよ。
WindowsのコンソールAPIでやり取りする限りPowerShellでもbashでも同じだよ。と思ったけどperl6のブートストラップはバッチで実装されてるから今のところCMDからじゃないと実行できねえぞ。UNIXの実装(UNIXではシェルスクリプトをブートストラップにすることはよくある)を単純に移植したからこうなるんだな。やっぱWindowsは開発環境として軽視されてるな。これはさすがにちょっとアレだが、個人的にはCMDしか使わないから問題ない。
> Encodeかますのが面倒は解るが、実装が中途半端な方がもっと面倒じゃないか。
面倒ってのは理由の一部にすぎない。そもそもEncodeを使う限りUnicode文字に対応できない中途半端な処理しかできない。Win32::UnicodeやWin32::Longnameを使えば移植性がなくなる。つーかリンク先の記事 [developers.srad.jp]に全部書いてあるから読んでくれないかな。
> 単なる不具合で修正されるというならともかく、幻滅もんじゃないか、これ。
Perl 5の根本的な欠陥(文字列が内部表現かどうかPerl側で識別することができないのでそれを管理する手間を短気で無精で傲慢なプログラマー様に押し付けている)だけど、互換性の理由からPerl 5で修正されることはありえないことがわかってるから喜んでるんしuse v5;に期待してるんだよ。
> perl6のブートストラップはバッチで実装されてるから今のところCMDからじゃないと実行できねえぞ。UNIXの実装(UNIXではシェルスクリプトをブートストラップにすることはよくある)を単純に移植したからこうなるんだな。やっぱWindowsは開発環境として軽視されてるな。
この件だけど、ビルドガイドにPowerShell上でビルド方法も書かれていたから、PowerShell上でビルドすればcmdlet版のperl6ができるんじゃないかな(未確認)。
CygwinやMinGW上でビルドできるかどうかは知らないけど、そもそもCygwinのPerl 5はUnicode文字も普通に使えるから問題ない(なぜCygwin Perlを使わないのかもリンク先 [developers.srad.jp]に書いてある。UNIX likeに閉じた環境ならCygwinもいいけどね)。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
Perl6ちょおすごい (スコア:5, 参考になる)
日本語のhello, worldが普通に表示できる! (なおソースファイルの文字コードはUTF-8)
日本語のファイル名が普通に開ける!
これ [qiita.com]
さっきから何を当たり前のことで感動してるんだとか何がすごいのかわからないとか思った人は幸せです。きっとWindowsのPerl 5で日本語 [developers.srad.jp]を扱ったことがないのでしょう。
惜しむらく
Re: (スコア:0)
惜しむらくは、コマンドラインからUnicode文字列を受け取れないこと。
Windowsでperl5使ってる者だが、結局なんじゃないかと。
一つ目と二つ目はUTF8な文字列(perl5だとutf8フラグ付き)でもSTDOUTへの出力の際にcp932に変換してくれているように見える。
二つ目は更にファイルシステムの読み込みの際も変換かけてくれているのかな。
その癖、最後のを見るとSTDINからは駄目。
というかWindowsだからと勝手に変換かけられても困るのだがね。実行はcmd.exeだけじゃないのよ。
Encodeかますのが面倒は解るが、実装が中途半端な方がもっと面倒じゃないか。
単なる不具合で修正されるというならともかく、幻滅もんじゃないか、これ。
Re:Perl6ちょおすごい (スコア:2, 参考になる)
> 一つ目と二つ目はUTF8な文字列(perl5だとutf8フラグ付き)でもSTDOUTへの出力の際にcp932に変換してくれているように見える。
CP932に♥は含まれていないからそれはありえない。もしcp932に変更されているなら3つ目のように?に変換されて出力されるはず。だからWin32::Unicode::Consoleのように、最終的にWriteConsoleWを使っているはず。わざわざサンプルに♥を含めたのはそれを確認するため。
> 二つ目は更にファイルシステムの読み込みの際も変換かけてくれているのかな。
これも違う。コマンドラインから渡せなかったのでわかりにくくなってるけど、たとえば
とすれば、ちゃんとUnicode文字を含むファイルを開ける。つまりWin32::Unicode::Fileのように最終的にCreateFileWを呼び出している。
単にcp932に変換している程度だったらここまで感動していないよ。
> その癖、最後のを見るとSTDINからは駄目。
あのーSTDINとコマンドライン引数の区別もついてないんですか?
とりあえずこれ [stackoverflow.com]で確認。
STDINはちゃんとUnicode文字にも対応している。
コマンドライン引数が対応していないのは確かに残念だけど、Perl 5のように修正不可能な根本的な制約ではないから修正の望みがある。
> というかWindowsだからと勝手に変換かけられても困るのだがね。実行はcmd.exeだけじゃないのよ。
WindowsのコンソールAPIでやり取りする限りPowerShellでもbashでも同じだよ。と思ったけどperl6のブートストラップはバッチで実装されてるから今のところCMDからじゃないと実行できねえぞ。UNIXの実装(UNIXではシェルスクリプトをブートストラップにすることはよくある)を単純に移植したからこうなるんだな。やっぱWindowsは開発環境として軽視されてるな。
これはさすがにちょっとアレだが、個人的にはCMDしか使わないから問題ない。
> Encodeかますのが面倒は解るが、実装が中途半端な方がもっと面倒じゃないか。
面倒ってのは理由の一部にすぎない。そもそもEncodeを使う限りUnicode文字に対応できない中途半端な処理しかできない。Win32::UnicodeやWin32::Longnameを使えば移植性がなくなる。つーかリンク先の記事 [developers.srad.jp]に全部書いてあるから読んでくれないかな。
> 単なる不具合で修正されるというならともかく、幻滅もんじゃないか、これ。
Perl 5の根本的な欠陥(文字列が内部表現かどうかPerl側で識別することができないのでそれを管理する手間を短気で無精で傲慢なプログラマー様に押し付けている)だけど、互換性の理由からPerl 5で修正されることはありえないことがわかってるから喜んでるんしuse v5;に期待してるんだよ。
Re: (スコア:0)
> perl6のブートストラップはバッチで実装されてるから今のところCMDからじゃないと実行できねえぞ。UNIXの実装(UNIXではシェルスクリプトをブートストラップにすることはよくある)を単純に移植したからこうなるんだな。やっぱWindowsは開発環境として軽視されてるな。
この件だけど、ビルドガイドにPowerShell上でビルド方法も書かれていたから、PowerShell上でビルドすればcmdlet版のperl6ができるんじゃないかな(未確認)。
CygwinやMinGW上でビルドできるかどうかは知らないけど、そもそもCygwinのPerl 5はUnicode文字も普通に使えるから問題ない(なぜCygwin Perlを使わないのかもリンク先 [developers.srad.jp]に書いてある。UNIX likeに閉じた環境ならCygwinもいいけどね)。