【Perl上級者コーナーPart01】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
02/06/22 19:21ID:V3u7Ppd00497nobodyさん
2011/08/25(木) 03:06:54.04ID:???そんなんだから、外国製なのに日本語にも対応している
ソフトやライブラリがどんどん広まるんだよ。
で、最終的に世界中の情報が利用できない。
圧倒的情報弱者になる。
0498nobodyさん
2011/08/25(木) 03:12:58.74ID:???UTF8フラグがわかんないんだよね？
UTF8フラグはPerlの機能だから
これがわからないとPerlがわかってないも同然だよ。
UTF8フラグがわかっていれば、Encodeは
実に素直な設計。
0499nobodyさん
2011/08/25(木) 10:37:19.31ID:???UTF8フラグなし → Latin-1
UTF8フラグあり → UTF8
0500nobodyさん
2011/08/25(木) 22:03:04.96ID:???>実に素直な設計。
その前提が怪しいと思ってる。というのは、
>Perlから見れば文字コードは2つしかないよね
>UTF8フラグなし → Latin-1
>UTF8フラグあり → UTF8
のどっちも使わないから。
身近なスクリプト書くのに Latin-1 や UTF-8 が
必要となるのだろうか？
利用者からしてみると後退しているように見えて
しまう。
0501nobodyさん
2011/08/25(木) 23:47:39.38ID:???符号化方式(US-ASCII or Latin-1 or UTF-8)
と
utf8フラグの値(on or off)
と
内部コード or 外部コード
はすべて直交してて、全部で３×２×２＝１２の組合せが
あり得る(以下の表)
utf8flag internal
-----------------------------------
1. US-ASCII on yes
2. US-ASCII on no
3. US-ASCII off yes
4. US-ASCII off no
5. Latin-1 on yes
6. Latin-1 on no
7. Latin-1 off yes
8. Latin-1 off no
9. UTF-8 on yes
10. UTF-8 on no
11. UTF-8 off yes
12. UTF-8 off no
-----------------------------------
0502nobodyさん
2011/08/25(木) 23:52:16.35ID:???しておらず、今、何になっているのか把握しづらい。
なぜかと言うと、プログラマが相手しているのは、書いている、
あるいは書かれている、静的なコードであるのに対して、上記は
プログラムの実行時に動的に変化するからだ。
これらの状態・動作を確認するという手間は、これまでになかっ
たわけだから、純粋に負担が増えてしまっている。
多言語に対応することに反対してないので、こういう負担が増え
ない方法で行えないものかと思う。
0503nobodyさん
2011/08/26(金) 02:37:40.52ID:???難しく考えすぎ。難しいと勘違いしているのなら、その原因はutf8（フラグ）という名称についてだけ
Perlには ”Perl文字列”（命名俺）と "バイナリ" の二つしか無い。（数値やオブジェクトはまあとりあえず忘れて）
"Perl文字列"は、その名の通りPerl言語専用の文字列。だからこの文字列をPerlの世界の外に存在しないし、外に出すことはない。
それはつまり、ネットワーク通信やファイル読み書きで外部に流してはいけないということを意味する。
"バイナリ"はただのバイトの並び。ネットワークやファイルから読み取るものは全部"バイナリ"（PerlIOという自動変換機能を使わない限り）
テキストファイルだろうがなんだろうが、それはPerlから見ればただのバイトの並びでしか無い。
Perlにおいて文字列を扱う関数や正規表現は すべて"Perl文字列"を引数に取る。
"バイナリ"も引数にとれるがそれは古いPerlとの互換性用の機能と考える。
じゃあその"Perl文字列"はどうやって作るかというとそれがEncodeモジュール。
ネットワークやファイルから与えられた"バイナリ"をEncodeモジュールを使って"Perl文字列"に変換する。
(utf8::*もあるが忘れていい。utf8.podにはことごとくEncodeモジュールを
使ってくださいと書いてある http://perldoc.jp/docs/perl/5.8.1/utf8.pod）
ちなみにソースコードに書いてある文字列。これもデフォルトでは "バイナリ" 。
互換性のことを考えると理由はわかると思う。use utf8;をするとソースコードの文字は"Perl文字列"になる。
文字コードはたくさんあるが、"Perl文字列"は一種類しかない。Encodeモジュールを使って
いろんな"バイナリ"を"Perl文字列"に変換できる。もちろんその逆も出来る。
US-ASCIIだろうが、Latin-1 だろうが、UTF-8だろうが、Shift-JISだろうが、EUC-JPだろうが
外部にあるものはみんな"バイナリ"。それをEncodeモジュールは"Perl文字列"に変換してくれる
0504nobodyさん
2011/08/26(金) 02:38:03.50ID:???UTF8フラグという名前が良くないが、これはPerl文字列フラグと読み替えればいい。
Perl文字列フラグがついていればPerl文字列（繰り返すが中身がUTF8なのは知らなくていい）
http://perldoc.jp/docs/perl/5.10.0/perlunifaq.pod
> 内部表現は何か分からないエンコーディングで、常に明示的にエンコードと
> デコードが必要ということにしておいた方がよいです。
だからPerl文字列フラグ付きのUTF8やLatin-1などというものはない。
Perl文字列フラグがついていれば、それはすべて同じPerl文字列。
あとは自分のプログラムは文字列を扱うとき、"Perl文字列"を基本として使うのか（統一された文字のモダンなやり方）
"バイナリ"を基本として使うのか（互換性重視の古いやり方）を決める。"Perl文字列"なら文字と1文字として扱える。
"バイナリ"だとそうはいかない。
Perl文字列を基本として使うなら、Perl外部のネットワーク、ファイルの読み書き時にすぐに変換して
Perl文字列メインでコードを書くことになる。
もし古いモジュールがPerl文字列対応になっていなければ、バイナリに変換して呼び出すラッパーを書くことになるだろう。
反対にバイナリを基本として使うのなら、バイト数ではなく文字数を知りたい時など、
文字として扱いたいところでPerl文字列に変換して関数を呼び出す。
そういうラッパーを書くことになるだろう。
どちらを基本にするかをしっかりと自覚しているのなら、あとはラッパーが変換し、関数を呼び出し、ラッパーがもとに戻す。
ラッパーが違いを吸収して、Perl文字列だろうがバイナリだろうが、自分で決めた基本に統一できるのだから状態を確認する手間はない。
0505nobodyさん
2011/08/26(金) 02:38:14.84ID:???多言語対応で作るとなったとき、プログラムで使う文字はひとつに統一したほうがいいだろう？
それがPerlでは、"Perl文字列"になる。本当はPerl外も巻き込んで一つに統一されたほうが
いいんだけど、統一という言葉に一番近いUnicodeでさえ、文字集合は同じでも、文字を表すビット列には
UTF8、UTF16、UTF32などがある。近いうちに一つに統一されることは無いだろう。
だからPerl外部からPerl内部に渡って来る時の変換機能は絶対になくせない。
（もちろんこのアプリはこの文字コードだけを使いますと決めれば変換機能を
なくせはするだろうけど、それはPerlという言語の開発者が決めることではない）
古い互換性を保つコード・機能を忘れれば、Perl文字列はPerl文字列という物一つに統一されている。実にシンプル
逆にPerlの外ではいろんな文字コードが存在し変換の必要があるが、それはPerlのせいではない。
NKFやJcodeといったPerl文字列が存在しなかった時代に作られた「"バイナリ"を無理やり
文字列とみなして操作する」古いモジュールのことを忘れればこんなにシンプルなんだ。
長々と書いたが、結論はこれだけ。
Perl外部に存在する"バイナリ" と Perl内部に存在する"Perl文字列"
"バイナリ"を○○コードとみなして、"Perl文字列"に変換するのがEncodeモジュール
0506nobodyさん
2011/08/26(金) 02:40:07.58ID:???US-ASCII
Latin-1
UTF-8 いくつものエンコードがある
Shift-JIS 混沌とした世界
EUC-JP
その他
↑Perl外の世界の文字 (UTF-8フラグ 全部OFF)
----------------------Encodeモジュール等で変換
↓Perl内の世界の文字 (UTF-8フラグ ON)
Perl文字列 （ないしょだけど実装はUTF-8フラグ付きのUTF-8エンコード）
たった一つのシンプルな世界
Encodeモジュールで変換しなかった文字はどうなるかって？
それは文字ではない。ただのバイナリ、バイトの配列だ。
0507nobodyさん
2011/08/26(金) 17:45:56.27ID:???公式ドキュメントでは、Unicode文字列という名称は削除されている。
perlunitut - perldoc.perl.org
http://perldoc.perl.org/perlunitut.html#Definitions
perlunitut - Perl における Unicode のチュートリアル 【perldoc.jp】
http://perldoc.jp/docs/perl/5.10.0/perlunitut.pod#Text32strings32character32strings41
0508nobodyさん
2011/08/27(土) 20:42:35.80ID:???内容にはあんまり同意できないけど、とりあえず全部バイナリ
で処理して、それで困ったら文字列で処理することにする。
(そしてあんまり困らなそうな予感がする)
"Perl文字列フラグ" が「このデータは文字列だ」ということを
表わしているときと表わしていないときとがありそうに思える
ので自分が理解するまでは手が出せない。
他の言語、例えばC言語やVBだとかにも文字列フラグってあるん
かな？多言語処理をするにあたって不可欠なものなのかな？
0509nobodyさん
2011/08/28(日) 00:22:09.84ID:???VB6は文字列はString型に入れるものでバイナリはbyte型配列に入れるもの。
Javaにもstringがある。VB.NETはしらん。
変数に型がある言語では、文字列型に入れた時点で文字列として扱われる。
その時にフラグやらなんやらいろんな情報が追加されるだろうが、それは気にすることじゃない。
そういう意味でPerよりも厳格に文字列とそうでないものが型として区別されている。
> 多言語処理をするにあたって不可欠なものなのかな？
不可欠。なぜなら「一文字」を認識できないことには、文字列処理はできない。
どうしても文字型というものが必要。それが型あり言語では型そのものであり、
型なし言語では、変数に入っている物にフラグをつけるしかない。
変数にバイナリデータだけ入っていては、バイナリと文字の区別はつかないからね。
だから少なくともこの2つを区別するためのフラグは必要になる。
0510nobodyさん
2011/08/29(月) 00:05:56.67ID:???アプリを書く利用者にとって、ということなら同意できないな。
古今東西、これまでのコンピュータ言語で文字列フラグが
必要だったことがない。Unicodeだから必要になったと主張する
のなら、何かを間違えていると直感する。
0511nobodyさん
2011/08/29(月) 01:21:52.14ID:???> 必要だったことがない。
それは他の言語に文字列フラグに相当するものがあっただけの話。
多くの静的型付け言語では、文字列型というものがあった。そしてその文字列型は○○コードと
決まっており、文字列型の○○コードと、外部から渡される文字コードが違えばそのコードに変換して扱う。
それが文字列フラグを付けることに相当するものだ。
文字列フラグを付けるのは、データの文字列型へのキャストとも言えるな。
フラグというものを意識しすぎ。文字列型がバイナリ型かこの2つを意識すればいい。
言語側で文字列型は○○コードと決まってない言語では、プログラマが、
今、変数に入っているのは、何コードかを意識しないといけない面倒な言語になってる。
そういう言語はたとえ文字型と名乗っていても実質1バイト固定のバイナリ型であり
ほんとうの意味での文字列型ではない。Ｃ言語がそう。そしてその一つが昔のPerl。
今は、Perlは簡単になった。それは文字列型というものができたため。
動的型付け言語では変数に型がないから、データの方に型情報をもたせるしか無い。
それは文字列として扱いたければ、バイナリから文字列に変換する関数が必要になるということ。
これまでのコンピュータ言語を含め、”プログラマが文字コードを意識したくないのであれば”、
言語側で標準文字コードを決め、それに変換する処理が必要になり、そして実際にあるんだよ。
Unicodeだから必要になったのではない。文字の扱いを簡単にする → 文字列型が必要 → 変換処理が必要。
今のPerlのように文字型は○○コードと決まっている言語では、文字列として扱うとき
Javaなども含めて読み込み時に○○コードに変換してるよ。
重要な所を繰り返すね。Javaと同様、今のPerlは文字コードが決まってるよ。だから変換が必要だよ。
> のなら、何かを間違えていると直感する。
お前のプログラマ直感能力の限界だよそれはｗ
0512nobodyさん
2011/08/30(火) 22:43:53.56ID:???0513nobodyさん
2011/08/30(火) 22:50:23.11ID:???うわｗ それはお前個人の感想だろ。
なんで賛同とか言っちゃってるの？ｗ
周りはみんな賛同を得ている。だから反論はない。
お前一人が、わかってないだけｗ
0514nobodyさん
2011/08/31(水) 03:06:54.06ID:???こんな超絶過疎スレで
>周りはみんな賛同を得ている。だから反論はない。
は、ねーだろw
自分定義の用語が出た瞬間から、数少ない住人は、
生暖かい目で見てるだけだ。
0515nobodyさん
2011/08/31(水) 22:12:11.60ID:???「見てるなら、反論はしてない」の間違いだろｗ
0516nobodyさん
2011/09/04(日) 14:32:29.75ID:???ならないし、世間のはやり・廃りの影響を受けたくない気持は
分かる。
ついこの間まで、モダンPerlはutf8フラグといっていたものが
これからは文字列フラグの時代！utf8フラグはもう消した。
となってはついていけなくなってしまう。
日本はガラパゴスなので代々、ソースがつぎ足しつぎ足し
でいい味が出ている場合もあると思う。
結局、はやり・廃りを糧とするのか、組み上がってるシス
テムを大黒柱としているかの違いなんだと思う。
大黒柱組に流行を押し付けようとしてもうまくいかないと
思うんだ。
0517nobodyさん
2011/09/04(日) 15:18:09.35ID:???"文字列フラグ" perl 約 114 件 （0.07 秒）
0518nobodyさん
2011/09/04(日) 21:09:35.36ID:???文字列フラグって、UTF8フラグが紛らわしいから
言い換えて説明したほうがわかりやすいってことで
このスレの中でとりあえずそう呼んでただけだろ。
一般的にはUTF8フラグだ。
0519nobodyさん
2011/09/04(日) 21:33:51.14ID:???本人はそれで説明した気分になってるんだろうけど
0520nobodyさん
2011/09/04(日) 21:35:13.73ID:???例えを使った説明ってそんなもんだろ・・・
勝手にじゃなくて、ちゃんと断ってたし、
お前、何が気にくわないんだ？
0521nobodyさん
2011/09/04(日) 21:38:02.34ID:???文字列フラグという一般的でない言い換えによって何かが分かりやすくなることもない
utf8フラグ→文字列フラグ
はそもそも「たとえ」にもなんにもなってない
0522nobodyさん
2011/09/04(日) 21:45:55.66ID:???それと"文字列フラグ"とが、同一のものか別のものか、本人以外
分らんし
途中からレス読んだら超絶意味不明。
0523nobodyさん
2011/09/04(日) 22:00:30.90ID:???言い換えても別になんの問題もないでしょ。
utf8フラグがわかりにくいと言っている人にとって
Perl文字列フラグはわかりやすい例えだったよ。
君はutf8フラグでわかるんだから、utf8フラグでもわかるという君の意見は
utf8フラグで混乱している人にとっては、なんの参考にもならないってわかるよね？
0524nobodyさん
2011/09/04(日) 22:02:51.40ID:???じゃあ、最初からレスよんでください・・・
>>504から今ままで20レスもないし。
0525nobodyさん
2011/09/04(日) 22:19:38.02ID:???思い込めるなんて幸せな人だな
>Perl文字列フラグはわかりやすい例えだったよ。
自画自賛？w
0526nobodyさん
2011/09/04(日) 22:39:35.88ID:???“utf8フラグ”で混乱している人は、
まず“utf8フラグ”で混乱しないよう知識を整理することが肝要。
ローカルルールの勝手な言い換えで済ましていては先には進めません。
0528nobodyさん
2011/09/05(月) 00:35:55.56ID:???0529nobodyさん
2011/09/05(月) 00:48:58.21ID:???気に食わなかったからでは？
0530nobodyさん
2011/09/05(月) 00:56:14.11ID:???0532nobodyさん
2011/09/06(火) 06:06:26.98ID:???他の人に対してレスったのでは無いって事だろ
0533nobodyさん
2011/09/06(火) 22:46:19.68ID:???0535nobodyさん
2011/09/10(土) 11:08:41.03ID:???UTF8であるかどうかを表わしていないように思え、
言い直したPerl文字列フラグが、これまたその変数
に格納されているものが本当に文字列なのかどうか
表わしていないように思える。
例えばこれからフラグを立てようとしている変数、
（あ〜、今立てようと思ってたのにぃ〜）
という(人間にとって)文字列を格納してある変数
は、格納してある内容とフラグが(まだ)一致して
いない。
UNIX は出来てから40年も経つんだけど、
・文字列はバイト列、かつ
・バイト列は文字列(として扱える)
・全てはファイル、なので
・システム的にテキストファイルとバイナリファイルを区別せず扱える
というところが新しいアイディアなのだと思う。
（もちろん他にも長所はあるけど）
UNIX 以前のオペレーティングシステムは、大抵
文字列とバイナリデータを区別して扱わないといけ
ない。
だから○○○フラグというものは、その頃のシステム
に逆戻りしているようで、使うおじさんとしては辛い。
0536nobodyさん
2011/09/10(土) 11:36:12.87ID:???何文字か？っていう質問にどうやって答えればいいんだ？
それに一文字づつ処理をする場合
バイト列では処理できんだろ。
UNIXは、成り立っているように見えるが、
ASCIIコードだけしか考慮してないだけで
ASCII以外の文字を扱おうと考えたら、ボロボロだよ。
0537nobodyさん
2011/09/10(土) 11:47:05.75ID:???それ以前のオペレーティングシステムって
一体どれの話をしてるんだ？
ちなみにC言語ができたのは1972年な。
0538nobodyさん
2011/09/10(土) 11:52:02.10ID:???文字列なのかバイナリなのかを分ける方法もあるねw
Unicodeなら使える文字も増えるからASCIIの記号を
使い切ったからって困ることはないw
上の方で出ていた、
プログラマが相手しているのは静的なコード
とも合致するし。
0539nobodyさん
2011/09/10(土) 12:05:47.91ID:???半角の場合はバイト数が文字数
（だって先輩がそういってたもん）
0540nobodyさん
2011/09/10(土) 12:12:38.07ID:???UTF8にもつながっていてね。
それは、UNIX（C言語）がASCII、つまり1バイト文字で
ある前提のライブラリばかりだから1文字が2バイト以上だと
文字列を引数に取る関数が使いものにならないんだよね。
具体的にはUTF16でABCの文字コードは00 41 00 42 00 43 になる。（今はエンディアンキニシナイ）
文字列の途中に\0がくるから、そこで文字が終了してしまう。
だからUNIX（Linux）系ではUTF8以外のUnicode符号化方式の採用が極めて困難になってる。
UNIXは昔も今も文字というより、1バイト単位で処理してるにすぎないんだよ。
0541nobodyさん
2011/09/10(土) 12:20:50.54ID:???ジジルねぇ。 $strの代わりに頭ではなく、
後ろにつけてstr$としたらどうだ？
詳しい人なら、これは昔のBASICで用いられていた
文字列型を表す記号に見えるだろう。ちなみに整数型は%
結局、あんたが言ってるのは型作れって話になってるよ。
Perlにおいてジジルは値の型ではなく値の構造、
つまり配列であるとか、ハッシュであるとか、
そういうことを区別するために使うもんだ。
まあ、Perl文化にはそわないだろうが、文字列型でも
問題が解決するというのは、先に書いてあるとおりで
実際コンパイラ言語ではそのようにして解決している。
0543nobodyさん
2011/09/10(土) 12:43:25.11ID:???それは初恋のひとの名を世界に向けて公表するのと
同じことなので、おじさんとしてはほっぺたが真っ赤
になってしまう。
もしどうしてもというのなら言うけど。
0544nobodyさん
2011/09/10(土) 12:59:35.08ID:???0545nobodyさん
2011/09/10(土) 13:08:06.50ID:???シジルに選びそうだなw
0546nobodyさん
2011/09/10(土) 17:32:19.00ID:???シジルでutf8フラグを可視化するということでしょうか？
例えばそのシジルを ! とした場合、
$binary1 = "あいう"; # 単なるバイナリ
$binary2 = !string; # utf8バイナリとして代入？
!string1 = "あいう"; # utf8フラグ付き文字
!string2 = decode("euc-jp", $binary);
!string3 = $binary; # utf8フラグを立てて代入？
0547nobodyさん
2011/09/10(土) 18:01:56.11ID:???PerlのUTF8フラグってのはデータの側じゃなくて処理系内部に持ってるんじゃないの?
なんかutf8フラグを「データの側」が持ってるようなことを書いてる人が
いるようにも読めるんだけど…。
>>541
ジジル じゃなくて シジル (sigil) ね。爺汁はイヤン。
0548nobodyさん
2011/09/10(土) 20:37:14.16ID:???Devel::Peekを使って、データの状態を見てみればわかるように、
UTF8フラグはデータ側に持っている状態のこと。
http://blog.livedoor.jp/xaicron/tag/Devel::Peek
0549nobodyさん
2011/09/10(土) 20:57:48.62ID:???0550nobodyさん
2011/09/10(土) 21:02:00.04ID:???0551nobodyさん
2011/09/10(土) 21:05:10.62ID:???なるほどDevel::Peekね。あとで試してみる。
Perlのデータの保持の仕方ってこんなだったのね。勉強にナッタワ。
0552nobodyさん
2011/09/10(土) 21:05:11.27ID:???ようするに文字列というデータの状態を表すデータ、つまりメタデータだよ。
処理系内部ってのは、use utf8のことを言ってるんじゃないか？
use utf8というのは、ソースコードに書かれた文字、
その文字を変数に代入したときにutf8を立てるかどうかの話。
my $str = 'あいうえお';
ってコードがあったとき、$strにutf8を立てるかどうかの制御。
これはあくまでソースコードの話であって
ソースコード外から読み込んだデータには関係ない。
0553nobodyさん
2011/11/05(土) 11:22:03.88ID:???だろう？ASCIIはUTF-8なわけだから例外としないで立ってくれればいい
のに。それにASCIIはもちろん文字列なわけで、文字列フラグがこれ
また機能と名称が一致しないのはなぜなんだろう？
0554nobodyさん
2011/11/05(土) 14:46:04.84ID:???ActivePerl5.8.9では、UTF8フラグが立つけど、>>553の環境は何ですか？
use Encode;
my $s = decode ascii => "a";
print utf8::is_utf8($s) ? "UTF8" : "Latin-1";
0555nobodyさん
2011/11/07(月) 04:11:38.05ID:???my $s = decode("ascii", "a");
0556nobodyさん
2012/05/28(月) 13:15:05.39ID:???0557nobodyさん
2012/06/09(土) 23:12:24.84ID:TbTUrfm1UTF8フラグって、要するにCや他の言語で言うところのワイド文字列(wchar_t)だろ。
お前ら難しく考えすぎ。
対応表を作っておいたよ。
Perl ↔ C
UTF8フラグ付き文字列 ↔ wchar_t * (ワイド文字列)
UTF8フラグなし文字列 ↔ char * (マルチバイト文字列)
decode() ↔ mbstowcs(3)
encode() ↔ wcstombs(3)
Cならマルチバイト文字列を扱っているのか、ワイト文字列を扱っているのか
変数の型を見れば一目瞭然だが、Perlではどっちもスカラ変数に入っていて
データの方に型がついているので、慣れていないと混乱しやすいってことだろうね。
あと、「UTF8フラグ」って名前は最悪だな。素直にワイド文字列って言えばいいのにね。
そういや今ググったらEncode::Localeなんてモジュールもあるし、
Cで正しくI18Nなコードが組めるなら、Perl 5.8でもそのまま同じ考え方で
いけるようになってる、ってことだろう。
まだ混乱してるやつは、他の言語で勉強してから戻ってきた方がすんなり理解できるかもね。
0558nobodyさん
2012/06/10(日) 03:33:39.97ID:???0559nobodyさん
2012/06/10(日) 04:10:15.96ID:???0560nobodyさん
2012/06/11(月) 05:14:40.23ID:???バカすぎｗ
UTF8フラグというのは、変数に追加された属性だ。
C言語のような型がある言語と一緒にしてはいけない。
変数に型がない言語では、型による判別が不可能だから
フラグを付けないといけない。
数値と文字までは、"123"と123を同一視することで
対応できた、文字列とバイナリ列は、文字を8bitで解釈することで
同じように扱えた。
しかしな、Unicode文字列とバイナリ列は型がないから区別ができないんだよ。
だから追加属性としてUTF8フラグを作ることになった。
型が無い言語でマルチバイト文字列をちゃんと扱おうとしたら
似たような仕組みが必要になる。
型があったらそんなこと考えずに済むのにね。
0561nobodyさん
2012/06/11(月) 19:49:11.59ID:???UTF8フラグがあれば型のことを考えずに済む
という話でもあるな
0563nobodyさん
2012/06/13(水) 18:17:38.34ID:???UTF8フラグ付き文字列は実装としては単なるchar *型であり
本当にフラグで見分けてるだけだよ。何が最悪のネーミングだよアホか。
0565nobodyさん
2012/06/15(金) 01:52:56.74ID:???区別しなくていいよ。latin1だって区別しないだろ。
0566nobodyさん
2012/06/15(金) 23:16:32.83ID:???がそれは間違いで、正しくはUTF-8とLatin-1の区別をするためのもの。
どちらもASCIIをもとに拡張されていて、その拡張部分を区別するため
にUTF8フラグが生まれた。2つの符号化方式を同時にサポートしようとした
結果の産物。
0567nobodyさん
2012/06/16(土) 02:57:47.31ID:???型が存在しないから
フラグで区別するしか無い。
型なし言語の宿命。
0568nobodyさん
2012/06/16(土) 07:55:29.94ID:???いつからchar *がLatin-1になったんだ？
お前らEncode.pmが出来る前は普通にEUC-JPとかのバイナリ列をスカラに
当たり前のように突っ込んでただろ。ん？
0569nobodyさん
2012/06/16(土) 12:14:54.41ID:???> 当たり前のように突っ込んでただろ。ん？
面倒くさい時代だったよ。簡単なところでは文字列の長さを調べるのに
Perl非標準の関数を使わないといけないし、正規表現でも正しくマッチさせるために
工夫が必要になる。
さらに日本語以外はどうすんの？ 今はUTF8が事実上の標準だよね。
ってときに対応できない方法。
つまり以前は人間が、別々に用意されているバイナリ用関数と文字列用関数を
使い分けていたんだよ。
今は文字を扱うのに、Perlの標準関数がそのまま使えるようになった。
0570nobodyさん
2012/06/16(土) 21:02:19.19ID:???0572nobodyさん
2012/06/16(土) 23:34:24.80ID:???てことか。とんでもなくばかな話だ。ゴメンナサイものだな。
ゴメンナサイ
0573nobodyさん
2012/06/17(日) 03:39:04.76ID:???不必要な苦労だと思わないんだなｗ
これだからゆとりは。
0574nobodyさん
2012/06/17(日) 10:36:45.24ID:???使わない。
0575nobodyさん
2012/06/17(日) 13:13:27.08ID:???UTF8フラグが不必要な苦労とか言うなら単に文字コード問題について
何も分かってないと言われても仕方ないな。
0576nobodyさん
2012/06/17(日) 15:50:12.39ID:???買ったままのパソコンにはパールすら入っていないけどねｗ
0577nobodyさん
2012/06/17(日) 15:59:37.97ID:???0578nobodyさん
2012/06/17(日) 16:48:39.78ID:???今Perl入れたら、最新版が入ってしまう。
これだと、UTF8フラグに対応していないなどと言えない！
0579nobodyさん
2012/06/17(日) 16:52:32.62ID:???らしい。パールとは違ってCP932でのプログラミングが楽になるそうだ。
待ち遠しい。ただしホームエディションには付属しないらしい。
0580nobodyさん
2012/06/17(日) 18:38:00.23ID:???0581nobodyさん
2012/06/17(日) 18:54:55.85ID:???0583nobodyさん
2012/06/18(月) 21:28:28.57ID:???0584nobodyさん
2012/06/19(火) 13:31:01.98ID:???予想外の文字列が来たら面倒だから一応やっとくだけって感じで
ただ、今はその手間すらかからない言語あるからね。Rubyとか
文字列処理で後塵を拝するPerlを見るのはちょっと寂しい感じ
0585nobodyさん
2012/06/19(火) 14:49:14.95ID:???移植性とか再利用を考えるとEncode対応にしとくけどね。
ワンライナーでEncode使うほど律儀ではないけど。
Rubyと違ってPerlはガイジン作で我らがダンコガイ様が無理くり実装したのが
Encodeなんだから仕方ない。最近のバージョンがどうなってるのかぶっちゃけ
知らないけど。
0586nobodyさん
2012/06/19(火) 14:51:10.15ID:???Windowsはオレオレ実装のCP932を普及させたいだけだろ。
Macと違って全部UTF-8にする度胸のなさが丸見え。
まあUTF-8-MACの面倒臭さも大概にしろと思うが。
0587nobodyさん
2012/06/19(火) 19:18:18.86ID:???CP932はあくまで日本語版において
Unicodeに対応していないアプリ用
つか、海外版もあるのに日本語文字コード専用なわけないじゃんｗ
で、騙されやすい人っているよねｗ
0588nobodyさん
2012/06/19(火) 22:14:56.43ID:???0589nobodyさん
2012/06/20(水) 07:00:35.91ID:???0590nobodyさん
2012/06/22(金) 02:04:02.14ID:???フラグに気を使わないといけないなんて、ゆとりの俺には
まず不可能。
0591nobodyさん
2012/06/22(金) 02:25:43.76ID:???そんなんで、多言語対応できるの？
0593nobodyさん
2012/06/22(金) 22:11:46.63ID:???同様に、$str_euc、$str_sjisなどがある。
0594nobodyさん
2012/06/22(金) 22:41:34.52ID:???ハングリアン記法か。
0595nobodyさん
2012/06/22(金) 23:00:28.32ID:???符号化方式を変えただけで多言語に対応できると考えてるのなら
シフトJISでも十分多言語に対応できるんじゃないの？
多言語対応っていうのはそんなに甘くないと思うんだけどね
0596nobodyさん
2012/06/22(金) 23:53:39.69ID:???レガシーだなお前。読み込む時に文字コード指定するのがデフォだろ
>>595
お前日本文字がJIS X 0208に収まるとでも思ってんの？おめでてーな。
つかもうShift_JISやCP932のヤケクソ仕様に振り回されるのはゴメンだよ。
MSとMacのせいでUnicodeもメンドクサイことになってるけど
■ このスレッドは過去ログ倉庫に格納されています