04/02/07 01:45
>>213
さっそくの回答ありがとうございます。
コードはどーやって変えるんでしょうか？
215:デフォルトの名無しさん
04/02/07 01:50
>>212
ここはそんなレベルの低い質問をするスレッドではない。
Windows XPなら、メモ帳がUTF-8に対応しているので
1, Shift JISで書かれたテキストファイルをメモ帳で開く
2, 「名前を付けて保存」のダイアログで、「文字コード」に「UTF-8」を指定
216:デフォルトの名無しさん
04/02/07 01:51
>>214
URLﾘﾝｸ(pc2.2ch.net)
217:デフォルトの名無しさん
04/02/07 01:57
>>214>>215
本当にありがとうございます。
後一個だけおねがいです。
Shift JISで書くのもメモ帳ですか？
それとも何かありますか？
218:デフォルトの名無しさん
04/02/07 02:01
メモ帳はデフォルトで ShiftJIS だ。
219:デフォルトの名無しさん
04/02/07 02:03
よごしてすんませんでした。
本当助かりました、ありがとう！
220:長いと言われたので分割
04/02/07 13:13
遅レスだけど
もし参考になれば
>>181
自分のHPからの抜粋今のところうまくは行ってるけど・・・(C#で作ってます)
最近文字コードの勉強しだしたんで間違えてたらｽﾏｿ
あとわかりづらいとおもうけどｽﾏｿ
■1 ISO-2022-JPの判別
各ESC(0x1B～)が出た場合はISO-2022-JP(確定)
■2 UTF-8の判別
0xC0<->0xFDが出た場合はUTF-8の強い可能性
第2バイト以降が全て0x80<->0xBF内であればUTF-8の強い可能性、そうでない場合は他コード
第1バイトで指定された長さ以下の場合は他コード
■3 EUC半角の判定
第1バイトが0x8Eで第2バイトが0xA1<->0xDFな場合はEUC半角カナの可能性
ただし既に他の文字コードの強い可能性ありと判断されてない場合に限る
第2バイトがEUC半角カナ範囲外で0x80<->0xA0であるならばSJIS(確定)
以上に当てはまらない場合は不明コード
221:長いと言われたので分割2
04/02/07 13:14
■4 EUC補助漢字の判定
第1バイトが0x8Fで第2・3バイトが0xA1<->0xFEな場合はEUC補助漢字の強い可能性
ただし既に他の文字コードの強い可能性ありと判断されてない場合に限る
第2・3バイトどちらかが0xFD・0xFEであるならばEUC補助漢字(確定)
第2・3バイトがEUC補助漢字範囲外で0x80<->0xA0であるならばSJIS(確定)
以上に当てはまらない場合は不明コード
■5 SJISの判定
0x80<->0xA0であるならばSJIS
■6 SJIS半角カナの判定
0xA1<->0xDFが出た場合はSJIS半角カナ・EUC全角かな・カナの強い可能性
ただし既に他の文字コードの強い可能性と判断されてない場合に限る
第1バイトが0xA4か0xA5で第2バイトが[かな]0xA1<->0xF3[カナ]0xA1<->0xF6であるならば
EUC全角ひらがな・カタカナの弱い可能性
第2バイトをチェックして0xE0<->0xFEであるならばEUCの強い可能性で0xFD・0xFEの場合はEUC(確定)
第2バイトが存在しない場合はSJISの強い可能性
以上に当てはまらない場合はSJIS半角カナの強い可能性
■7 EUCの判定
0xA1<->0xFEの場合はEUCの強い可能性で0xFD・0xFEの場合はEUC(確定)
当てはまらない場合は不明コード
222:長いと言われたので分割3
04/02/07 13:15
[１]→ ISO-2022-JP確定
↓
[２]→UTF-8強可能性→UTF-8強可能性→次ループ(ポインタ=+UTF8サイズ)
｜ ＋→他コードの強可能性→[３]へ
↓
[３]→EUC半角カナ強可能性→EUC半角カナ強可能性→次ループ(ポインタ=+1)
｜ ＋→EUC半角カナ確定
｜ ＋→SJIS確定
｜ ＋→不明コード→次ループ(ポインタ=+1)
↓
[４]→EUC補助漢字強可能性→EUC補助漢字強可能性→次ループ(ポインタ=+1)
｜ ＋→EUC補助漢字確定
｜ ＋→SJIS確定
｜ ＋→不明コード→次ループ(ポインタ=+1)
↓
[５]→SJIS確定
↓
[６]→SJIS半角カナ強可能性→SJIS半角カナ強可能性→次ループ(ポインタ=+1)
｜ ＋→EUC全角かなカナ弱可能性→次ループ(ポインタ=+2)
｜ ＋→EUC強可能性→次ループ(ポインタ=+1)
｜ ＋→EUC確定
↓
[７]→EUC強可能性→次ループ(ポインタ=+1)
＋→EUC確定
↓
不明コード→次ループ(ポインタ=+1)
223:デフォルトの名無しさん
04/02/07 13:31
BOMは無視？
224:デフォルトの名無しさん
04/02/07 13:37
utf-8 → Shift_JIS （Shift_JISに無い文字はTeXのutf package用に\UTF{xxxx}）
がほしい
225:220
04/02/07 14:13
>>223
BOMと言うものを知らなかったので・・・
今検索してみてわかりました
UTF-8に関しては
変換するときは消したほうがよさそうですが
判別の時は特に考えなくてもいいかと
判断された文字コードをスコア化して１番多いものをその文字コードと判断してるんですが
それに対して重みをつける(通常+1を+2ぐらい)でいいかなと
そのうちUTF-16とかにも対応したいので非常に勉強になりました
ありがとうございます
226:220
04/02/07 15:18
とおもったらUTF-8・UTF-8Nと区別するんですね＿|￣|○
.NETのEncodingクラスには無さそうだけどためしに変換してみたら
ゴミデータが付いてきたから標準でUTF-8Nなのかなぁ
227:デフォルトの名無しさん
04/02/07 15:43
>>220
> 0xC0<->0xFDが出た場合はUTF-8の強い可能性
0xC0, 0xC1 が出た場合はUTF-8ではない(確定)
Unicode(U+10FFFFまで)はサポートするけどISO10646の
UCS-4(U+7FFFFFFF)はサポートしないなら0xF5-FDも除外できる
RFC2279/3629参照
228:220
04/02/07 16:35
>>227
RFC読みました
C0、C1がセキュリティ上禁止されていることがわかりましたので
早速条件に入れたいとおもいます
UCS-4に関してはとりあえずサポートして置きたいので入れて起きます
ありがとうございます
奥が深い・・・
229:デフォルトの名無しさん
04/02/07 22:00
>> 220
どこかのHPにまとまっている？
230:220
04/02/07 22:25
>>229
はいまとまってるとおもいますが２ｃｈで晒すほど度胸無いので・・・
最近ページ追加したばっかりでgooglebotは数回きてるんですが反映はまだ見たいです
231:デフォルトの名無しさん
04/02/08 03:44
予言：
1 0 年 後 に は 、 U T F - 6 4 が 標 準 に な り ま す 。
＿|￣|○
232:デフォルトの名無しさん
04/02/10 10:27
>>211
どの場合も、事前に必要バッファ長を取得してから、
バッファ長指定して呼び出せば大丈夫じゃない？
233:デフォルトの名無しさん
04/02/10 17:20
>>232
セキュリティの問題というのは>>227-228でもちょっと触れてるけど
たとえばディレクトリトラバーサル対策で「2E 2E」という文字列を
フィルタリングしても、「C0 AE 2E」とか書くと貫通してしまうという問題。
URLﾘﾝｸ(altba.com)
あるいは「<」をnon-shortest formで送ることでXSSを発動させるとか。
URLﾘﾝｸ(www.cert.org)
対策としてXPではC0 AEのようなシーケンスを削除するようになった
わけだが、今度は「2E C0 AE 2E」とか書くと貫通する。
もう少しモノを考えて修正してくれMicrosoftと小一時間(ry
ただしMB_ERR_INVALID_CHARSを付けるとエラーになってくれる。
234:デフォルトの名無しさん
04/02/10 17:46
>>233
おお、なるほど。
勉強になります。
結局のところ、有効な対策の一つとしては、
「API側の対策をあてにせず、UTF-16 or UCS-2に変換した後に危険な文字をチェックしろ」
ってことですかね？
235:デフォルトの名無しさん
04/02/10 18:28
逆では?
UTF-16 or UCS-2 のままでのチェックだけではなく、
API に渡される実際の引数レベルでもチェックをするって感じ？
236:デフォルトの名無しさん
04/02/11 05:47
>>235
違う。
237:デフォルトの名無しさん
04/02/11 23:12
Shift_JISやEUC-JPやRFC1468に直接Unicode文字や補助漢字、JIS第3・第4水準の文字を
埋め込める規格を考案したけど、実用価値あるんだろうか？
Shift_JISで直接Unicode文字が使えたら機種依存文字の問題はなくなると思うんだけどね…
238:デフォルトの名無しさん
04/02/11 23:29
>>237
> Shift_JISやEUC-JPやRFC1468に直接Unicode文字や補助漢字、JIS第3・第4水準の文字を
> 埋め込める規格を考案したけど、実用価値あるんだろうか？
率直にいって無いだろう。でもせっかくだから言ってみたらどうだろう?
目新しいアイデアなら、ほかのところで生かせるかもしれない。
まさか制御文字の一部を使って符号化する、なんてアイデアじゃないだろうな……
それと、文字コードの話するなら
> Unicode文字
> ？
> 機種依存文字
この辺は直した方がいいよ。
239:デフォルトの名無しさん
04/02/11 23:36
>>237
イオさんという人が昔「拡張シフトJIS」「拡張EUC-JP」「拡張ISO-2022-JP」
とかいうの考案してましたね。サイト消えちゃったけどWayBack Machineから発掘
URLﾘﾝｸ(web.archive.org)
> Shift_JISで直接Unicode文字が使えたら機種依存文字の問題はなくなると思うんだけどね…
GBK/GB18030はGB2312と上位互換を保ったままUnicodeの文字を
全部使えますね。
Unicodeに移行しようと思ったら既存のデータを全部変換するか
捨てる必要があるシフトJISやBig5圏から見たらうらやましい限り。
240:デフォルトの名無しさん
04/02/12 12:14
>>238
端的にいうと、JIS X 0208の未定義領域を利用して、Unicodeのサロゲートペアみたいに、
面サロゲート、区サロゲート、点サロゲートの3文字(合計6バイト)を組み合わせて
(サロゲートトリオと呼ぶことにします)JIS X 0208にない文字を表現するんです。
たとえば面サロゲートは09区～12区、14区～15区、85区～88区のどこか、
区サロゲートは93区、点サロゲートは94区を使用することにします。
13区と89区～92区はWindowsの外字と衝突するので使用しません。
多分面サロゲートは940文字も要らない(*1)と思うので85区～88区だけでいい
(*2)とは思いますが。
(*1)使える総文字数は940*94*94-(940+94+94)=8304712文字
(*2)使える総文字数は376*94*94=(376+94+94)=3321772文字
>>238
すみません。「?」はJIS X 0201/ASCIIのほうを使用しろということでしょうか。
「機種依存文字」は「JIS X 0208未定義文字」、「Unicode文字」は
「Unicodeに含まれてJIS X 0208に含まれていない文字」のほうが正しい言い方ですね。
上のほうでも「Windowsの外字」なんて怪しげな言葉を使っていますが、ご勘弁を…
241:デフォルトの名無しさん
04/02/12 13:18
>>240の続きです。
85区01点はJIS X 0213第1面(第3水準)に収録されている文字のうち、
JIS X 0208に含まれない文字を区点番号はそのままで収録します。
JIS X 0208に含まれている文字の場所は空けておき、使用禁止にします。
同じように、85区02点はJIS X 0213第2面(第4水準)に収録されている
文字を収録します。
85区03点はJIS X 0212(補助漢字)を収録します。
Unicodeに収録されている文字は0x000000～0x10FFFFの1114112文字
(サロゲートペアは使用を禁止するが、文字数には含めておく)ですが、
これを94進法でサロゲートトリオの各サロゲートを求めます。
面サロゲートは全部で127個必要になりますので、85区04点～86区36点を
使用することにします。
86区37点～89区94点はとりあえず保留領域にしますが、将来の拡張として
大漢和辞典に収録されている漢字でJISやUnicodeにない文字や、
人名・地名用の異体字を収録する領域にしておきます。
同じ文字がJIS X 0201、JIS X 0208、JIS X 0213、JIS X 0212、Unicodeに
重複して収録されていることもありますが、この場合、
JIS X 0201 > JIS X 0208 > JIS X 0213 > JIS X 0212 > Unicode
の順番に優先して文字コードを使用することにします。
たとえばJIS X 0213、JIS X 0212、Unicodeに重複して収録されている文字は
JIS X 0213の文字コードを使用することになります。
242:デフォルトの名無しさん
04/02/12 13:24
・・・Unicode使うよ。。。
243:デフォルトの名無しさん
04/02/12 13:26
>>240-241の続きです。
これだけの文字(>>240参照)を使用することになると、すべての文字を
収録したフォントを製造することが難しくなります。
そこで、フォントに「収録基準」を設け、それをフォントのパッケージに
明示することによってフォントの収録文字数を明らかにします。
収録基準0 JIS X 0201(またはASCII) + JIS X 0208
収録基準1 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213
収録基準2 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213 + JIS X 0212
収録基準3 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213 + JIS X 0212 + Unicodeの漢字(BMPのみ)(*3)
収録基準4 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213 + JIS X 0212 + Unicodeの漢字(BMP以外を含む)(*3)
収録基準5 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213 + JIS X 0212 + Unicodeのすべての文字
(*3)CJK統合漢字、CJK互換漢字、CJK互換文字のうちの漢字
説明は以上です。長文ご容赦ください。
244:デフォルトの名無しさん
04/02/12 14:13
1バイト部分がJIS X 0201かASCIIかによって使用禁止の区点が
変化しますがそこは曖昧なままですか?
245:デフォルトの名無しさん
04/02/12 16:14
>>240の総文字数が誤っていたので訂正します。
(*1)使える総文字数は94*94-(940+94+94)+940*94*94=8313548文字
(*2)使える総文字数は94*94-(376+94+94)+376*94*94=3330608文字
>>244
だよねぇ。
1バイト英数字をASCIIにするのをやめてJIS X 0201にするとはっきり宣言してしまったほうが
Shift_JISとの互換性を考えるといいのかも。
246:デフォルトの名無しさん
04/02/12 16:25
> 1バイト英数字をASCIIにするのをやめてJIS X 0201にするとはっきり宣言してしまったほうが
イラネ。
247:デフォルトの名無しさん
04/02/12 16:32
> JIS X 0201にするとはっきり宣言してしまったほうが
それはセキュリティの問題が発生するので
すくなくともWindowsのコードページとしては採用不可能
248:デフォルトの名無しさん
04/02/12 17:12
すなおにUTF32使おうよ・・・
249:デフォルトの名無しさん
04/02/12 18:05
ということは1バイトの英数字がASCIIで、1バイトのカタカナがJIS X 0201なのが
一番いいということなのかな。
1バイトのカタカナなんて廃止してしまえ!!という強硬な意見はあると思うけど、
互換性を考えるとどうしても廃止できないと思う。
250:デフォルトの名無しさん
04/02/12 18:13
シフトJISの上位互換こそが特長なんだから
1バイトカナを廃止したら話にならん
互換性がなくていいならそれこそ>>248だ
251:デフォルトの名無しさん
04/02/13 01:17
UTF32 って何が嬉しいのでしょうか。固定長ではないのですよね?
252:デフォルトの名無しさん
04/02/13 01:39
BOM...かな？
253:デフォルトの名無しさん
04/02/13 01:53
UTF32は固定長ですがなにか？
254:デフォルトの名無しさん
04/02/13 02:11
合成があんだろ
255:デフォルトの名無しさん
04/02/13 02:20
どうせ固定長じゃないならUTF-8のほうがいい
256:デフォルトの名無しさん
04/02/13 02:29
utf32が固定長じゃないとかUCS4もびっくりだな
何文字使う気なんだ
257:デフォルトの名無しさん
04/02/13 04:09
誰か>>256を翻訳してください
258:デフォルトの名無しさん
04/02/13 07:45
Even UCS4 looks conventional; utf32 dosn't have the fixed size etc.
How many characters does it plan to use?
259:デフォルトの名無しさん
04/02/13 11:07
>>257
He said,
"UNICODE -> UNI-WORD -> UNI-LANGUAGE -> UNI-PEOPLE -> UNI-NATIONAL
-> UNI-WORLD -> UNI-PLANET -> UNI-COSMOS -> UNI-SPACE-TIME -> UTF-32"
260:デフォルトの名無しさん
04/02/13 12:28
UNKO
261:デフォルトの名無しさん
04/02/13 12:51
CPU等が速くなってんのにアプリの体感速度が変わらないとう現象の
原因を作っている人たちはココにいたんですね。。
262:デフォルトの名無しさん
04/02/13 13:26
NTではUnicode化したほうが速くなるが
PC初心者にお帰り
263:デフォルトの名無しさん
04/02/13 13:58
つーか >>261 は何を言いたいのかよくわからん
264:デフォルトの名無しさん
04/02/13 14:05
>>263
IT産業を支えてくれてありがとうと言っているのですよ
265:デフォルトの名無しさん
04/02/13 16:40
┏┓┏┳┓
┏┛┗┻╋┛ ＼ i
┗┓┏┓┃ ─ ＋ ─>>1-1000
┃┃┃┃ ┏┳┳┓ ／/ | ＼
┗┛┗┛ ┗╋┛┃ ／ / |
┗━┛ ／ /
￣ 二─ ＿
￣ ､ - ､
-､＼ ＼
／ ＼＼ ＼
／／ ＼ヾ ヽ ヽ
／／／ ＼ ヾ、 | i
／__( |! `i |
<_,へ ＞- 、 ,.-､_ | |
＼ノ人＼ ／ ､ }! ＼ | |
＼へ〃＼／ヾ＼_ﾉ､ﾉ人 ,.-､ | |
＼|＼rj＼ヾ / ＼_ﾌ ,／ |! ﾘ |
rm＼ノ _ Y Lノ / | |
|ヽ-r＜￣`ヾr'￣ヽ / / / /
| └､ノ/￣`,-`┐ { _／ / ／ ／／
ﾚ⌒＼!_ ｰ -{ ﾉ ｝ ／ ／ ／
￣`ー一 'ﾞ _／／_ ／
＿二─ "
266:デフォルトの名無しさん
04/02/25 00:01
おい、お前ら字形が変わりましたよ。
URLﾘﾝｸ(www.forest.impress.co.jp)
コードは関係ないからスレ違いかもしれんが、改正前の字形で書いてると
ｵｻｰﾝ扱いになる悪寒。俺には改正後の文字が、なんか昔の字に
見えるんだけど。。。
267:デフォルトの名無しさん
04/02/25 00:30
経緯
１．旧字体のうち一部を新字体に「正式に」改正
２．改正されていない旧字体の一部を１．の改正からの「類推で勝手に」変更 (どこが主導でやったのかは知らないが)
３．今回２．で勝手に変更されていたのを「もともとの旧字体」に訂正
なので今回の改正で「改正後の文字が昔の字に見える」のは当たり前。
268:デフォルトの名無しさん
04/02/25 00:42
殆どが「書き文字としては間違いだけど、コンピュータ上では許されていた字形」を
正しい字形に戻したって感じを受けるな。
中には違いがさっぱり分からんのもあるんだが...。蟹とか灸とか粂とか。
個人的には進捗の捗の字が正しくなるのがうれしい。
269:デフォルトの名無しさん
04/02/25 00:58
>268
「正しさ」って何？
頻、賓、濱、捗
270:デフォルトの名無しさん
04/02/25 01:01
歩 渉 陟 捗 濱 瀕
271:デフォルトの名無しさん
04/02/25 01:12
歩 と
272:デフォルトの名無しさん
04/02/25 01:19
うぉ、『倶舎論』の本来の「倶」が入ってる！
産業省ﾏﾝｾｰ！
273:デフォルトの名無しさん
04/02/25 01:24
>>269
紙媒体の辞書に載せられるかどうか。
（載ってるかどうかとは言わないでおく）
274:デフォルトの名無しさん
04/02/25 01:52
DTP、フォント関連の連中は
忙しくなるな(w
275:デフォルトの名無しさん
04/02/25 02:58
DTP業界のフォントは78JIS字形をサポートし続けてきたから
実はほとんど影響なかったり。印刷物に使われ続けてきたん
だからまあ当然といえば当然だが。
276:デフォルトの名無しさん
04/02/25 03:14
何かスラドで激しくデジャヴを感じる投稿が多数あるような。
> 中には違いがさっぱり分からんのもあるんだが...。蟹とか灸とか粂とか。
そのへんは、例示字形にデザイン差を残しておくと規格がデザイン差に
関して何らかの価値判断を行ったと誤解されるおそれがあるから、
表外漢字字体表に一致させたもの(と解説に書かれてる)。
厳密にその通りのデザインで実装することを要求するものではないし、
そのような解釈はかえって表外漢字字体表の趣旨に沿わない。
何がデザイン差で何が包摂の範囲内での字体変更かも解説には
書かれてる。
277:デフォルトの名無しさん
04/02/25 10:49
蟹は「角」の右下と「虫」の上がくっついてるかどうかだな
微妙杉
278:デフォルトの名無しさん
04/02/25 13:05
鯖と鰯は良いね！
279:デフォルトの名無しさん
04/02/27 02:23
JIS X 0213が改正されても、JIS X 0208も一緒に改正されなければ無意味。
JIS X 0213なんて新JISキーボードと同じで、ほとんど使われていない規格なんだから。
ところで、法務省の人名用漢字追加はJIS漢字の字体をベースにするといっていたけど、
今回の改正でどう影響するんだろう？
今のところ、常用漢字・人名用漢字には2点しんにょうの字体はないけど（許容漢字を除く）、
場合によっては2点しんにょうに改正された文字が人名用漢字に追加される可能性がある。
280:デフォルトの名無しさん
04/02/27 04:15
後、気になったのは「辻」の字が2点しんにょうになっていること。
「表外漢字字体表」に従えば当然そうなるんだが、実際の人名（というか人の姓）で
使われているのは1点しんにょうの方が圧倒的多数。
2点しんにょうは文芸家（wが好んで使う（綾辻行人とか辻仁成など）けど、
表札とかに2点しんにょうの方が使われているのは見たことがない。
辻さんが「自分の名字の文字が『勝手に』正字に矯正されている」ことを知ったらどう思うだろうか。
人名にはまず使われていない迂とか迄とか謎とかは2点しんにょうのみにしてもいいけど、
辻は1点しんにょうと2点しんにょうの両方を規格に入れるべきだったと思う。
包摂規準に例外を作ってまでも。
281:デフォルトの名無しさん
04/02/27 04:23
正式には難しい字が使われてても
普段は簡単な字で書いてたりするので
（例：濱本を浜本と書いてたり）、
普段簡単な字で書いてるからといって、
その字で登録されているとは限んないけどね。
282:デフォルトの名無しさん
04/02/27 09:15
>>279
JIS X 0208を改正しなかった理由も解説に書かれてるね。
変更をほとんど使われていない規格だけにとどめたことで
混乱を最小限に抑えたとかいう角度の見方もある。
283:デフォルトの名無しさん
04/02/27 09:21
戸籍に登録されている「辻」が1点しんにょうということはありえない。
現時点で人名用漢字にも常用漢字にもないから戦後追加された
ことはないし、戦前の活字は当然すべて2点だし、
法務省は1点の「辻」は俗字扱いにしていて正字からの変更を
認めていないから既存の「辻」を持つ苗字が変えられた可能性もない。
したがって表札とかには戸籍にない略字を勝手に使っているだけだと
思われ
284:デフォルトの名無しさん
04/02/27 09:24
というか表札はふつう明朝体活字で書いたりしないから
1点しんにょうになるのはむしろ当然なような。
それとも点の下がグネグネした「辻」も追加すべきですかね。
285:デフォルトの名無しさん
04/02/27 09:28
> ところで、法務省の人名用漢字追加はJIS漢字の字体をベースにするといっていたけど、
読売の記事だとそれは去年の検討の話で
いったんご破算になったらしいんだが
今回も結局JIS漢字を元にしてるの?
286:デフォルトの名無しさん
04/02/27 09:52
imadoki kanji tukatteru yasi kimoi
287:デフォルトの名無しさん
04/02/27 10:15
>>283
電算化前の戸籍って和文タイプで打ったのもあるけど、手書きもあるよ。
たとえば漏れの本籍地は京都市だけど、戸籍謄本を取ってみたら手書きだった。
手書きの「辻」のすべてが2点しんにょうになっているとは思えない。
288:デフォルトの名無しさん
04/02/27 11:34
ああそうか、戸籍の電算化を阻んでるのは手書きの誤記を
これが自分の名前の字だと主張する連中だったな
> 手書きの「辻」のすべてが2点しんにょうになっているとは思えない。
むしろ手書きでは1点が普通だろ。それが活字では2点になるという
常識が戦前はあったわけだが
289:デフォルトの名無しさん
04/02/27 15:50
で、ののたんの名字は１点なの？２点なの？
場合によっちゃ幕の字書き換えなきゃならんのだけど
290:デフォルトの名無しさん
04/02/27 17:16
さすがプログラム版のスレだけあって、
漢字の話題になるといきなりレベルが低くなるな。
291:デフォルトの名無しさん
04/02/27 17:39
そもそも>>266が自分で言ってるがスレ違いっぽいし
292:デフォルトの名無しさん
04/02/27 22:10
>290
レベルの高い漢字の話題はどこでやってますか？
煽りじゃなく本当に知りたい。
293:デフォルトの名無しさん
04/02/27 22:16
格調高く感じを論ずるスレ四
ｽﾚﾘﾝｸ(kobun板)
294:デフォルトの名無しさん
04/02/27 22:17
>>293
感じって・・・
295:デフォルトの名無しさん
04/02/27 22:21
＿|￣|○ やられた。 古文・漢文板なんていったこと無かったから、無防備だった。
296:デフォルトの名無しさん
04/02/27 22:53
旧字体・別字体について
ｽﾚﾘﾝｸ(gengo板)
【朝日】文字を徹底的に略すスレ【JIS】
ｽﾚﾘﾝｸ(gengo板)
【ゐゑ】舊字、舊假名遣ひで話すスレッド 三箇目
ｽﾚﾘﾝｸ(gengo板)
【常用漢字表にない漢字の代わりの漢字について
ｽﾚﾘﾝｸ(gengo板)
◆◆漢字専用スレｐａｒｔ2◆◆
ｽﾚﾘﾝｸ(kobun板)
旧かな旧漢字は伝統的でしょうか
ｽﾚﾘﾝｸ(kobun板)
●教育漢字、常用漢字を有志で作り直すスレ●
ｽﾚﾘﾝｸ(kobun板)
JIS漢字
ｽﾚﾘﾝｸ(kobun板)
ちょっと集めてみたがレベルがそう違うとも思えんがね
297:デフォルトの名無しさん
04/02/27 23:09
ここも。
JISをもう1度、最初から作りなおせるとしたら
ｽﾚﾘﾝｸ(gengo板)
298:292
04/02/27 23:20
サンクスコ。
なるほど、レベルの違うスレもあれば、そうでないのもあって面白い。
結局、バカのせいなんだよな。
「かほる」なんて名前が昔から使われていると思うようなバカと一緒。
スレ違いなのでAC。
299:デフォルトの名無しさん
04/02/29 03:37
さ、
300:デフォルトの名無しさん
04/02/29 03:37
さんびゃくー！！
301:デフォルトの名無しさん
04/02/29 20:02
m17n-libがもうすぐ公開だな
使い物になるのだろうか
302:290
04/03/01 13:22
いや、どこのスレだって無責任なレスがほとんどなんだけどさ、
言語学版あたりの文字コード関連スレだと、
かなーり詳しい奴が張り付いてて、すぐに突っ込みが入る。
しょーがないから俺が突っ込んでおくと、
戸籍での「辻」は一点も二点もありだ。っつーか、
しんにょうはすべて一点でも二点でも認められているわけだが。
303:LightCone ◆sSJBc30S5w
04/03/03 21:26
UNICODEのUTF-8の日本語向けの符号を考えてみました:
URLﾘﾝｸ(www.nowsmartsoft.or.tv)
UTF-8と違って、JIS第一、第二までは、2BYTEで表せます。
まだ、仕様を考えている途中なので、この符号を用いたプログラムは一つ
もありません。
何か問題点や、嘘を書いてる点などが見つかりましたらご指摘頂ければ幸い
です（つまり添削お願いします）。
304:デフォルトの名無しさん
04/03/04 03:07
>>303
変換にテーブルが必要な時点でUTFと名乗るのは問題がある。
俺コードとかって名前なら別にどうでもいいんだけど。
305:デフォルトの名無しさん
04/03/04 07:40
>>303
>多バイト文字途中への検索ヒットを簡単に回避可能
正規表現で回避しているようだけど、回避のための
修正が必要な時点で、UTF-8と比べて汎用的とはいいがたいなぁ。
(strcmpを使っているなら細工をして再コンパイル等が必要だけど
UTF-8は修正の必要もない)
306:デフォルトの名無しさん
04/03/04 09:25
>>303
> 何か問題点や、
単にまた混乱の元を追加するだけってことかな。
307:デフォルトの名無しさん
04/03/04 11:16
みんなUTF-8で結構おなか一杯だからなぁ。
308:デフォルトの名無しさん
04/03/04 11:32
>>303
Unicodeを混ぜることができる,EUC-JP/シフトJISの一種と考えたら
そこそこ面白い。
309:デフォルトの名無しさん
04/03/04 12:43
>>308
その手の拡張は>>239にもあるし>>240-にもあるしおなかいっぱい
310:デフォルトの名無しさん
04/03/04 13:21
主にどういう局面で利用される事を想定してるんだろうか。
UTF-8でも少しサイズが大きい程度で、そんなに気にならないんだけど。
独自にやる苦労に見合うだけの結果が得られるかは微妙だ。
打算計算を抜きにすれば、自作のOSで自作の文字コード使って
色々実験するのは楽しそうとは思うけどね。(^^;
311:LightCone ◆sSJBc30S5w
04/03/04 16:31
>>308, >>309
「Unicodeを混ぜることの出来るEUC-JP/SJIS」に、「簡単に逆戻り可能」な
性質を取り入れたような感じなんです。
ちなみに、>>239の符号では、逆戻りは出来ないと思いますが、
さらに、「\」コードを含んでいるので、色々と問題があると思います。
というわけで、いかがでしょうか。
新しいコードは、みんなが使い始めるか、よっぽど良い性質がない限り、
抵抗感がある物かも知れませんが。
312:LightCone ◆sSJBc30S5w
04/03/04 16:42
>>310
>主にどういう局面で利用される事を想定してるんだろうか。
>UTF-8でも少しサイズが大きい程度で、そんなに気にならないんだけど。
そう思われる人が多いのであれば、せっかくでしたが、余り意味がないかも
知れません。
でも、今まで2BYTE表せていた文字に3BYTEを当てるのに抵抗がある人には、
需要があるのではないかと思うんです。
その点だけでは、>>239の符号もいいと思いますが、UTF-JAPANの方は、
逆戻り可能の性質を持っている点や、多バイト文字に\コード等を含んで
ない点で、解析やエディタ作りなどにおいて、真価を発揮する場面がある
のではないかと思います。
EUCも、2バイトの範囲では逆戻り可能ですけど。>>239に書かれている拡張EUC:
URLﾘﾝｸ(web.archive.org)
においては、UTF-16,UTF-32対応する3バイト以上のコードでは、逆戻りが
出来なくなっているようですし。
313:LightCone ◆sSJBc30S5w
04/03/04 16:46
>>304
この符号の場合、基本的に地域や言語ごとに違う変換テーブルを用意する
必要がありますね。それをOSがサポートして、欲しいフォーマットに
まで変換を世話してくれればアプリの負担は減るとは思うんですが。
全世界で全く同じコードを用いたいのであれば、漢字が３バイトになって
しまうのは、元々やむを得ないかも知れない。
314:LightCone ◆sSJBc30S5w
04/03/04 16:53
>>305
UTF-8の場合、strcmp()は、単純な昔ながらの1バイト単位の比較のまま
無修正で利用できてしまうんですよね。
それは凄い性質ではあると思いますが、結局、コードを無修正で済ました
いばっかりに、データサイズが大きくなる犠牲を払っているんだと思うん
です。
315:LightCone ◆sSJBc30S5w
04/03/04 16:54
なお、
UTF-JAPANを、「UTF-COMPACT-JAPAN」と改名して、
「UTF-COMPACT-ARABIA」
「UTF-COMPACT-CHINA」
なども定義すれば、strcmp()等の修正は、言語数分まで及ばずに
一回だけで済むかも知れませんね。
316:LightCone ◆sSJBc30S5w
04/03/04 16:57
>>237 から続く発言は、なんと先月のものなんですね！
うまく合併できないかな。
317:LightCone ◆sSJBc30S5w
04/03/04 17:02
>>261の
>CPU等が速くなってんのにアプリの体感速度が変わらないとう現象の
>原因を作っている人たちはココにいたんですね。。
これは、今まで2バイトで表現できていた物を3バイトにしようとすることとも
その一つかな。
全世界の文字を使えるのはいいことではあるけれど、日本人が、英語と
JIS第一,第二以外の言語を使用する頻度は低いし、文字集合はUNICODEを
使うにしても、地域ごとに違った符号があってもいいのではないかな。
318:LightCone ◆sSJBc30S5w
04/03/04 17:04
UTF-COMPACTの変換テーブルは、OSが提供するだろうから、
UTF-COMPACT-xxxxx用のアプリは、いずれのxxxxx言語にも
無修正で対応できるのではないだろうか?
319:LightCone ◆sSJBc30S5w
04/03/04 17:10
例えば、HTMLヘッダに、
<meta http-equiv="Content-Type" content="text/html;
charset=
utf-compact-japan">
~~~~~~~~~~~~~~~~~
を書いておけばいいんじゃないかな。
SJISや、EUC-JPでやってることと何ら変わりないと思うし。
320:デフォルトの名無しさん
04/03/04 17:25
アメ公がUTF-16嫌ってUTF-8に走るのとまったく同じ論法だよね
自分たちが使いもしない文字のことなんてどうでもいいと思うのは
世界共通というか
321:LightCone ◆sSJBc30S5w
04/03/04 17:34
>>320
でも、自分たちの地域で効率を上げることにも、一利はあると思うんです。
UNICODEを全否定しているわけではなく、符号長に地域ごとに偏りを
持たせるだけですし。
322:LightCone ◆sSJBc30S5w
04/03/04 17:36
SFみたいな世界になって、文字種が爆発的に増えた場合、やっぱり、
地球では地球語に短い符号を割り当てるんじゃないかな。
そういう意味で、偏りを持たせる発想は、古くさい考えではないと思う。
323:デフォルトの名無しさん
04/03/04 17:38
だったらローカルコードでいいし
地域の数だけ馬鹿でかい変換テーブル持つなんて馬鹿の極み
324:デフォルトの名無しさん
04/03/04 17:41
日本語が多くてサイズが増えるのが嫌なら、UTF-16を使えばいいのでは？
325:デフォルトの名無しさん
04/03/04 17:41
> 制御コード、特殊記号、\コードを含まず
C1文字は制御コードじゃありませんか
そうですか
326:デフォルトの名無しさん
04/03/04 17:43
> JIS X 0213 2000 JIS第三、第四 4344字
今さら2000年版かよ
327:デフォルトの名無しさん
04/03/04 17:43
> 情報交換用漢字符号系
つーかずいぶんと古い資料参照してるな
328:デフォルトの名無しさん
04/03/04 17:44
そもそもたった一つのインプリで他言語をカバーしようとしたのがUnicodeじゃないの？
それを地域ごとに独自テーブル作ったら意味ないじゃん
329:デフォルトの名無しさん
04/03/04 17:44
> /[^\x81-\xde]任意の文字列/
「任意の文字列」が先頭だったらヒットしなくなるね
330:328
04/03/04 17:45
失礼
X他言語
O多言語
331:328
04/03/04 17:47
そもそも
UTF-JAPAN
ってのがかっこわるいよね
せめて
UTF-JPとかUTF-jaとかにすればいいのに
332:デフォルトの名無しさん
04/03/04 17:48
せめてもう少し間隔おいて自演したら？
333:デフォルトの名無しさん
04/03/04 17:49
> SJISや、EUC-JPでやってることと何ら変わりないと思うし。
なんら変わりなく欠点を引き継いでどうするんだよ
334:デフォルトの名無しさん
04/03/04 17:51
>>332
誰に言ってるんですか?
335:デフォルトの名無しさん
04/03/04 18:41
ちょっと考えてはみたけど、UTF-8越えは難しいな。
使っててあまり不満ねーもの。（慣れたのもある）
その俺コードで外人と文書のやり取りする時はどうする気なんだ？
>>331
確かに微妙な名前だ。
>>333
文字集合がUnicodeでやろうと思えば多くの文字を表現出来る点が重要なんじゃね？
サイズを気にするなら圧縮で十分って気がするけど。
336:LightCone ◆sSJBc30S5w
04/03/05 00:09
中国には、JIS第一水準と同様に、「第一級漢字」が定まっていて:
URLﾘﾝｸ(www.kishugiken.co.jp)
このようになってます↑
ご覧の通り、JIS第一、第二水準と重複する部分も多く、興味深いのです。
これと、JIS第一水準を合わせた部分を2BYTEで表せるような、UNICODE符号を
作れば、中国人と日本人の両方にメリットがあるかも知れないと思うのですが、
いかがですか?
337:LightCone ◆sSJBc30S5w
04/03/05 00:17
ちなみに、UNICODEのCJK統合漢字部分は、頻度の低い漢字も何も考えずに
並べてあり、頻度毎に分類できないので、どうしても22000文字程度
をまとめて符号化する必要があります。ASCII符号と互換性を持たせ
つつ、これら全ての文字集合を2BYTEで表現しきることは、ほぼ不可能
です。
しかし、中国の第一級、第二級漢字と、日本のJIS第一、第二水準漢字
には重複する部分が多く、それらの「和集合」の文字なら、2BYTEで
表せる範囲の数ではないかと踏んでるんです。
338:デフォルトの名無しさん
04/03/05 00:19
各文字に割り振るコードの順番にも意味があるから、単に足し合わせれば良いという物でも
ないと思うけど。
339:LightCone ◆sSJBc30S5w
04/03/05 00:23
大体の目安としては、一万五千字程度の文字なら、ASCII符号と互換性
を持たせ、「逆戻り可能」で、しかも、後続バイトを付ければUCS-4全体
を表現しきれるような、2BYTEの符号を作る事が出来ると見ています。
340:LightCone ◆sSJBc30S5w
04/03/05 00:27
>>338
せっかく、JIS第一水準で五十音順、第二水準で部首順になってるのが、
中国の文字セットと合成した際に失われると言うこと?
341:デフォルトの名無しさん
04/03/05 00:28
GB18030は何文字格納できるんだっけか？
342:LightCone ◆sSJBc30S5w
04/03/05 00:29
UNICODEでは、部首順らしいので、統合する際にそれにならえばいい
のでは?
343:LightCone ◆sSJBc30S5w
04/03/05 00:30
>>341
わても知らんので、調べて。
344:デフォルトの名無しさん
04/03/05 00:30
>>342
コテハンには聞いていない。
345:デフォルトの名無しさん
04/03/05 02:12
150万文字ぐらい入るんだっけか＞GB18030
346:デフォルトの名無しさん
04/03/05 13:18
>>345
うん。約1,611,668文字かな。
347:デフォルトの名無しさん
04/03/05 13:49
ちなみに、GB18030は、逆戻り不可だし、検索も複数バイト文字の途中で
ヒットする。
348:LightCone ◆sSJBc30S5w
04/03/06 00:44
UNICODEの新符号「UTFCP」を発案しました:
URLﾘﾝｸ(nowsmartsoft.or.tv)
2バイトの符号で1万5千文字以上を表せて、なおかつ、文字列を文字単位で
正確に逆戻りできる、UNICODE符号です。UCS-4全体を表現できます。
また、多バイト符号にASCII符号を一切含まないので、英大文字小文字変換に
対しても安定です。
理論上、日本語のJIS第一、第二水準漢字、中国語の第一級、第二級漢字の両方
をコードページの切り替えなしに2BYTE符号で表せますので、
UTF8に比べ、頻度の高い日本語や中国語の文章が2/3に(50%減)コンパクトに
なります。
いかがでしょう？ (^_^;)
349:デフォルトの名無しさん
04/03/06 01:44
ハードディスクが何百GBになる時代に、テキストファイルの容量が数十%減ったくらいでは
あまり利点を感じないけどなぁ。
むしろ、>>240-243みたいに(書いたの漏れだけど)EUC-JPやShift_JISの完全上位互換規格を
考えたほうがまだ意味があると思う。
350:デフォルトの名無しさん
04/03/06 07:53
情報の冗長性を取り除いて小さくまとめようとすると
たいてい少し複雑な演算が必要になるよね。
UTF8と張り合うなら演算量も念頭にいれる必要があるかも。
UCS4とUTF8の変換では１～２個の条件分岐と
長さ*(シフト、OR、AND)演算＋入出力程度で変換してる。
351:デフォルトの名無しさん
04/03/06 08:13
>>348
各文字コードの主要な正規表現エンジン各々での探索コストの大まかな比較をやってみてほしい。
352:デフォルトの名無しさん
04/03/06 12:06
ただでさえ混乱している文字コード周りの処理をさらに混乱させないでくれ。
353:デフォルトの名無しさん
04/03/06 12:21
>>348
「俺コード」を作るな。
有用だと信じるなら、IETFとかUnicode.orgにでも提案しろ。
354:デフォルトの名無しさん
04/03/06 13:50
>>352-353
作るのは勝手なんじゃね？
気に入らないなら使わなけりゃ良いだけ。
案が未熟だというだけで作る事自体を否定するものではないかと。
因みに俺もUTF8で不満は無い。
文字コードみたいなもので冒険せずに他で頑張った方が良いんじゃないかと。
高いリスクを冒した結果、成功したところで見返りは小さい。
355:デフォルトの名無しさん
04/03/06 14:12
まあ、独自Unicode系CESなんて、普及するわけもないから、
悪影響も少ないわな。機種依存文字なんかはすぐに悪影響が出るけど。
356:デフォルトの名無しさん
04/03/06 19:34
俺アプリのベースエンコーディングに使う為の独自エンコーディングの開発ならオケですか？
357:デフォルトの名無しさん
04/03/06 20:49
俺OSのベースエンコーディングに使う為の独自エンコーディングの開発ならオケです。
358:デフォルトの名無しさん
04/03/06 21:35
>>350
1つの文字を複数の表現で符号化できる規則は可能なら避けたほうがいい
UTF-8で避けようとすると加減算が余分に入るけど
359:デフォルトの名無しさん
04/03/07 01:11
お前ら釣られるなよw
360:デフォルトの名無しさん
04/03/07 03:20
>>358
UTF-8は一つのコードに対して複数の表現は許していないはずだけど
文字とか字形の話…？
361:デフォルトの名無しさん
04/03/07 04:05
>>360
・・・・は？
362:LightCone ◆sSJBc30S5w
04/03/07 19:28
UTFCPについて、詳しく書いておきました。
符号の読み取りや、逆戻りの状態遷移図やソースプログラムもあります。
また、1バイト単位の正規表現ルーチンでも検索に利用できることも分かったので
書いておきました。
URLﾘﾝｸ(www.nowsmartsoft.or.tv)
363:デフォルトの名無しさん
04/03/07 19:34
2chで宣伝とは・・・
364:デフォルトの名無しさん
04/03/07 22:20
>>362
gobackUTFCP が動くとは思えないのだが。
365:LightCone ◆sSJBc30S5w
04/03/07 22:54
>>364
動くと私は思います。
動かないと思われる例を挙げてみて下さい。(^_^;)
366:デフォルトの名無しさん
04/03/07 23:02
>>362
だから○とか×じゃなくて探索コストで比較しろって。
あんたが主張する利点は対象データの処理がUTF8に比べて
速いということだろ。今の状態では説得力0だ。
367:デフォルトの名無しさん
04/03/07 23:05
>>366
いい加減放置しろって・・・
明らかな宣伝ということで削除依頼もしておいた。
368:LightCone ◆sSJBc30S5w
04/03/07 23:09
>>366
速いという事じゃなく、サイズがコンパクトと言うこと。
ディスクに保存するときは速いだろうけど。
369:デフォルトの名無しさん
04/03/07 23:19
>>368
んなんだから、院試に落ちるんだよ。
偉そうなお題目なんてのは後にしろ。時間の無駄だ。
370:LightCone ◆sSJBc30S5w
04/03/07 23:24
>>369
どの大学の、何学科の院試か知りませんが、工学部の院で良ければ、
東大でも受かります。
371:LightCone ◆sSJBc30S5w
04/03/07 23:25
第一、京大の理学部物理学科だって、研究室によれば簡単に受かるし。
372:デフォルトの名無しさん
04/03/08 00:13
>>365
動く動かないは別として、初期状態が符号列の最後のバイトに
なければならないというのがダメダメ。
そんな前提を置いた上でなら、EUCだってSJISだって
「複数バイト文字の最後のバイトから高々符号長分遡るだけで、
その符号の先頭バイトを発見可能」
って言えてしまうんだが。
373:LightCone ◆sSJBc30S5w
04/03/08 00:36
>>372
>そんな前提を置いた上でなら、EUCだってSJISだって
>「複数バイト文字の最後のバイトから高々符号長分遡るだけで、
>その符号の先頭バイトを発見可能」
>って言えてしまうんだが。
言えません。
例えば、SJISでは、
全角「キ」のコードは、0x83, 0x4c
全角「ャ」("キャ"などの小さい"ヤ")のコードは、0x83,0x83
半角「c」のコードは、0x63
全角「宴」のコードは、0x89, 0x83
全角「ツ」のコードは、0x83, 0x63
となり、
キャc ---> 0x83, 0x4c, 0x83, 0x83, 0x63
宴ツ ---> 0x89, 0x83, 0x83, 0x63
となるので、cにあるとき遡ると、0x63,0x83,0x83と
なり、ツの最後のバイトにあるとき遡ると、0x63,0x83,0x83となり、
全く同一になり、cなのか、ツなのか区別が付かない。
EUCでは、最後尾バイトからスタートする限りは大丈夫。
UTF8では、どこからスタートしても大丈夫。
UTFCPでは、最後尾バイトからスタートする限りは大丈夫。
374:LightCone ◆sSJBc30S5w
04/03/08 00:44
ちなみに、SJISでは、例えば、
ラャc ---> 0x83, 0x89, 0x83, 0x83, 0x63
宴ツ ---> 0x89, 0x83, 0x83, 0x63
のように、最悪のケース、1000バイトも遡っても、遡り始めた文字が、
半角なのか全角なのか判断付きかねる文字列を作れる。
つまり、「ツ」なら全角、「c」なら半角なのだが、その区別が長く遡っても
なかなか付かないような文字列が存在し得リますです。
375:デフォルトの名無しさん
04/03/08 00:50
>>374
UTF8より優れているにしろ使われなきゃどうしようもない。
こんなとこよりもっと有効なところで発表すれば？
376:デフォルトの名無しさん
04/03/08 01:02
>>374
自分のコードがまったくおんなじ問題を抱えているのに
気付いていないんだろうか？
＃こういうのリアルタイムで見たの久しぶりだな...
377:デフォルトの名無しさん
04/03/08 01:46
>>365
符号が DBA で、現在位置が A のとき。
378:デフォルトの名無しさん
04/03/08 01:57
> LightCone
まずは自分のOSで使用してみたら？
せっかく独自のOSを開発しているんだから。
379:デフォルトの名無しさん
04/03/08 02:14
結論: wchar_t使えやボケ
380:デフォルトの名無しさん
04/03/08 02:17
>>358
UTF-8では禁止されたはず。
確かそれ周りのセキュリティーホールもあったような。
（特定文字のチェックをすり抜けるようなやつ）
381:デフォルトの名無しさん
04/03/08 03:33
>>380
イチから作るなら「禁止」じゃなくて理論上重複符号化がありえない
設計にしたほうがいいって趣旨。UTF-8の場合は互換性の問題から
不可能だったわけだが。
セキュリティホールの話は>>232-あたりで出てるね
382:デフォルトの名無しさん
04/03/08 05:07
UTF-8はtransformation format of ISO 10646なんだから
UCSに戻して使うのが本来の使い方。
それを正しく把握していれば重複符号化が可能でも何ら問題無い。
383:デフォルトの名無しさん
04/03/08 07:02
>>363
宣伝ではなくて、突っ込み貰うのが目的なんだろ。
叩き台出してみてマシになるかどうかという。
置き換えるには既にUTF-8が広がり過ぎていると思うが。
384:LightCone ◆sSJBc30S5w
04/03/08 08:45
>>377
>符号が DBA で、現在位置が A のとき。
そんなのは全く問題ありませんよ。あなたが全く理解してないだけです。
URLﾘﾝｸ(www.nowsmartsoft.or.tv)
↑の図を見てもすぐ分かることだし、下の関数冒頭を見ても分かる通り、
*ptr <= 0x7f の判定が真になるので、すぐに、「A」に場合分けできて、
1バイト符号に分類されます。
unsigned char *gobackUTFCP( unsigned char *ptr )
{
if ( *ptr <= 0x7f ) {
//(1) A
ptr--;
}
...
385:デフォルトの名無しさん
04/03/08 10:20
>>382
> UTF-8はtransformation format of ISO 10646なんだから
> UCSに戻して使うのが本来の使い方。
まったくです。
情報交換用コードと情報処理用コードは分けて考えるべきなのに、
UTF-8をそのまま処理することを考えているのは愚かすぎます。
> それを正しく把握していれば重複符号化が可能でも何ら問題無い。
それはどうかと思いますが。
見識の低い人が実装することもあるわけですし。
386:LightCone ◆sSJBc30S5w
04/03/08 10:58
逆戻りがなぜ可能か分かりにくい人が多いようですので、
解説しておきます。ご覧アレ:
URLﾘﾝｸ(www.nowsmartsoft.or.tv)
これで。UTFCP符号が間違いなく逆戻りできることの証明になって
いると思います。
387:385
04/03/08 10:58
>>386
そもそも情報交換用コードで逆戻りする必要がありません。
388:LightCone ◆sSJBc30S5w
04/03/08 11:00
>>387
ASCIIもオンメモリで、32BITで保持するつもりなんでっしゃろか?
389:デフォルトの名無しさん
04/03/08 11:11
>>388
必要ならそうするんでは?
ASCIIだけでよい文脈なら1バイトで処理すればいいし、
そうでないなら4バイトで処理すればいいですし。
あと保持というのがよく分かりません。UTF-*とUCS*の
どちらで保持するかは文脈によるのでは。
390:デフォルトの名無しさん
04/03/08 11:14
ときどきいるよね。自称大発見とか大発明とか。
そろそろ春も近いしね。
391:LightCone ◆sSJBc30S5w
04/03/08 11:20
>>385
そもそも、情報交換用なら、BOCU圧縮を使えば、UTF8よりコンパクトに
なる:
URLﾘﾝｸ(www-6.ibm.com)
UTF8は、情報処理用としてもかなり考慮されていて、ASCII用に書かれ
た古い検索ルーチンや文字処理ルーチンを無修正でUnicodeに対応でき
る特徴をっている。こんな特性は、よく知られている他の可変長符号に
はない。
392:デフォルトの名無しさん
04/03/08 11:28
別に内部コードとしてUTF-8を採用することが
禁止されてるわけでもないのに愚か過ぎるだの見識が低いだの
とまで言われなければならない理由は何ですか
393:デフォルトの名無しさん
04/03/08 11:32
>>383
意見を求めているふりをして人の話などぜんぜん
聞くつもりがないところを見る限り違うような気がします。
では何が目的なのかと言われてもさっぱり分かりませんが
394:デフォルトの名無しさん
04/03/08 11:34
>>391
> UTF8は、情報処理用としてもかなり考慮されていて、ASCII用に書かれ
> た古い検索ルーチンや文字処理ルーチンを無修正でUnicodeに対応でき
> る特徴をっている。こんな特性は、よく知られている他の可変長符号に
> はない。
それはEUC-JPでも普通に行われてきたのでは?^^;
「問題が出ないようにしてある」のと「情報処理用に作ってある」のとは別です。
EUC-JPでもShift JISでもISO-2022-JPでも、内部処理用に使おうと思えば
可能です。実際そういうソフトウェアもあるわけですし。
ただ、その場合処理が複雑になるしその分エンバグする可能性も高いわけです。
> そもそも、情報交換用なら、BOCU圧縮を使えば、UTF8よりコンパクトに
> なる:
> URLﾘﾝｸ(www-6.ibm.com)
ここまでするなら、レイヤーを分けて普通にハフマン符号化した方が良いと思うんだけど。
395:LightCone ◆sSJBc30S5w
04/03/08 11:38
>>394
>それはEUC-JPでも普通に行われてきたのでは?^^;
多分、UTF8の特性をご存じない。
EUC-JPでは、全角文字をASCII用のstrstr()で探そうとすると、
別の全角文字の途中にヒットしてしまうことがあるが、UTF8では
ない。
396:デフォルトの名無しさん
04/03/08 11:43
>>395
> EUC-JPでは、全角文字をASCII用のstrstr()で探そうとすると、
> 別の全角文字の途中にヒットしてしまうことがあるが、UTF8では
> ない。
確かにそうですね。失念していました。
397:396
04/03/08 11:48
ですが情報処理コードとして適切でないのは明らかです。
strstr()して得た開始位置は、全体の何文字目なのでしょうか?
398:デフォルトの名無しさん
04/03/08 11:53
ところで疑問なのは
なんでUTFCPとUTF-JAPANと言う二つの符号化方式を用意したかだ。
399:デフォルトの名無しさん
04/03/08 11:56
それを言うならUCSの一単位は一文字とは限りませんが。
結合音節文字とかご存知ありませんか。
固定長によるインデックスアクセスですべて済まそうと
考えること自体が漢字文化圏の幻想です。
400:デフォルトの名無しさん
04/03/08 12:03
400get
盛り上がってきました
401:デフォルトの名無しさん
04/03/08 12:11
>>384
「if ( ptr[-1] <= 0x7f )」だろマヌケ。
それとも、DBA の B を指すのが正解なのか?
402:デフォルトの名無しさん
04/03/08 12:30
>>399
> 固定長によるインデックスアクセスですべて済まそうと
> 考えること自体が漢字文化圏の幻想です。
この考えは「どうせAという処理をしなければならないのだから
Bという処理が増えてもかまわない」と言っているようで奇妙
です。問題を分割することは基本なのに。
403:デフォルトの名無しさん
04/03/08 12:46
>>398
自分のOS作るのにどういう文字コードをメインに据えるかを考えているらしい。
UTF-8だと漢字のサイズが大きいから気に入らないそうだ。
OSとセットでもなけりゃ独自コードの生き残りは辛そうだから、
良い機会と言えば良い機会なんだろうが。
超漢字が無かったらTRONコードなんて……。
404:デフォルトの名無しさん
04/03/08 12:52
>>402
「どうせ文字数を数えなくてはいけないのだから文字の間に
マッチしたかどうか判定する必要があっても構わない」
というのは奇妙ですよね。要は程度の問題です。
そもそもUCS*ではstrstr()一切使えないし
(charが16ビットや32ビットでない限り)
405:LightCone ◆sSJBc30S5w
04/03/08 13:10
>>401
マヌケなのはあなたです。Aを指すのが正解で、*ptr <= 0x7fのままで
間違ってません。
406:LightCone ◆sSJBc30S5w
04/03/08 13:13
>>398
最初思いついたのが、UTF-JPで、複数バイト文字に、A-Z, a-zなどを
含んでいるのが、欧米人が何も考えずにstrupr()する人が多い事情を
考えると良くないと指摘されて、頭を悩めて作ったのが、UTFCPです。
UTFCPは苦労して導きました。0x80以上だけを使って逆戻り出来る
符号としては、これ以上コード・ポイントは増やせないかも。
407:デフォルトの名無しさん
04/03/08 13:16
てかコテハンでうだうだやるのもほどほどに。
俺様規格考えた～まではまぁ、いいかもしれないが、その先はここでやらんと自サイトに掲示板でも
作ってそこで勝手にやってて欲しいな。
面白いとおもった香具師はそっちで反応するだろう。少なくともここでやられては迷惑なだけだ。
408:デフォルトの名無しさん
04/03/08 13:22
>>407
どうせ余所でやっても見ないし。俺はここでやってくれてかまわないよ。
別のネタを話すにしても並行して話せばいいだろう。今までもそうやって
きたんだから。
409:LightCone ◆sSJBc30S5w
04/03/08 13:24
>>407
分かりました。
UTFCP符号について興味のある人は、下記の「UTFCP符号について」ス
レッドで議論を継続するようにして下さい:
URLﾘﾝｸ(www.nowsmartsoft.or.tv)
410:デフォルトの名無しさん
04/03/08 13:24
俺もここでやるのは構わないけど、コテハンでやるなら
多少煽り口調で言われても落ち着いてキレずにやって欲しいのぅ。
411:LightCone ◆sSJBc30S5w
04/03/08 13:26
>>410, >>408, >>407
個人的にはどっちでもいいです。
412:デフォルトの名無しさん
04/03/08 13:37
だんだん本性を現してきたな。
自分の巣に帰りなよ。貴公子さんよ。
ｽﾚﾘﾝｸ(os板)
413:デフォルトの名無しさん
04/03/08 13:43
>>403
でもそのOSがあんな前時代的な仕様ではねぇ・・・
414:デフォルトの名無しさん
04/03/08 13:48
>>413
？
何か困る事でも？
415:デフォルトの名無しさん
04/03/08 13:51
>>414
>>403 生き残りは辛そうだから、
416:デフォルトの名無しさん
04/03/08 13:59
そういや、中国のGB2312って、日本のひらがな、カタカナが含まれるって
本当?
417:デフォルトの名無しさん
04/03/08 14:07
>>416
らしいね。
big5にも入ってるって話だぞ。
418:デフォルトの名無しさん
04/03/08 14:29
>>416
>>336
419:デフォルトの名無しさん
04/03/08 14:48
ここで UTF-8 以外のコードを提案してる人って、
SQL とかそーいうものも全部これから用意しよう、用意されるはずだ、というような
主張も imply してるって考えていいのかな。
それとも既存ライブラリやシステムと関連しない小規模な自作PG用としての提案なのかな。
そのへんはっきりさせてくれないと、批判とか批評とかしにくいと思うんだけど。
420:328
04/03/08 15:02
ねぇねぇ最初UTF-JPじゃなくてUTF-JAPANじゃなかった？
421:デフォルトの名無しさん
04/03/08 15:06
UTF-ｼﾞｬﾍﾟｰﾝ
422:デフォルトの名無しさん
04/03/08 15:07
COMPJAPAN互換？
423:デフォルトの名無しさん
04/03/08 16:22
大多数にとっては標準化を考えているのかどうか、それだけが問題じゃないのか？
こんなん考えました～ だけだと誰もついてこないと思われ。
424:デフォルトの名無しさん
04/03/08 16:26
俺エンコーディング大流行の予感。
425:デフォルトの名無しさん
04/03/08 17:34
>SQL とかそーいうものも全部これから用意しよう、
>用意されるはずだ、というような
8bit目がonであればたいていOKなんだが。
あと再コンパイルが許されるならUCS-4が一番楽だろ。
C++ならインターフェース変更するだけでロジックは変わらんのだから。
426:デフォルトの名無しさん
04/03/08 18:40
質問させてください。
PHPで、EUCでソースを保存して、
CHARSETをShift_jisでブラウザ出力させたいのですが、
どうやったら出力させることができるでしょうか？
教えて下さい。お願いします。
427:デフォルトの名無しさん
04/03/08 18:41
PHPで、ソースをEUCで保存して、
Shift_jisでブラウザに表示したいのですが、
どうしたらうまくいくでしょうか？
ご存知の方、おしえてください。お願いします。
428:デフォルトの名無しさん
04/03/08 18:47
俺も新しいコードを考えてここの住人を煽ろうかな。
429:デフォルトの名無しさん
04/03/08 19:37
>>425
>8bit目がonであればたいていOKなんだが。
いや、エラー無く通るってだけじゃなくて、検索とかさ・・・
430:デフォルトの名無しさん
04/03/08 20:20
lexとかgrep関係はいろいろとあるんだけど、
それは適切なアルゴリズムでちゃーんとビルドフロムスクラッチすればOK。
431:デフォルトの名無しさん
04/03/08 20:30
>>430
面倒
432:デフォルトの名無しさん
04/03/08 20:38
>>431
ポマエラ、公開しても落としに来ないくせに。
433:デフォルトの名無しさん
04/03/08 21:39
既存のアルゴリズムで速くなければ意味ない。
434:デフォルトの名無しさん
04/03/08 22:55
古いアルゴリズムでマルチバイト対応のパターンマッチング処理は
恐ろしくムダ。
文字クラスの対応パッチなんて組み合わせが爆発するロジックのがある。
435:デフォルトの名無しさん
04/03/08 23:19
>>391
そういう優れたUTF-8というものが既に存在しているのに、なんで
新しくわざわざ欠点の多い符号化法を提唱するのかねぇ？
436:デフォルトの名無しさん
04/03/08 23:34
Unicodeの合成文字って、合成する順序は決まってるんですか?
必ず。Group-1 ---> Group-2 ---> Group3 の順序で符号を並べる
のか、それとも、順序は動でもいいのか。
順序がどうでもいいなら、完成形としては同じになるのに、符号としては
異なる文字もあることになる。
ハングル文字なんかも、合成済みの物と、素片(?)のものとがあったから、
検索するときは配慮しないと行けないような。
437:LightCone ◆sSJBc30S5w
04/03/08 23:41
>>435
日本語の文字に対するバイト数の増加が納得できないため。
438:デフォルトの名無しさん
04/03/08 23:48
>>436
順序どうでもいいよ。
配慮しないといけないよ。
現実ってこんなもん
439:デフォルトの名無しさん
04/03/08 23:51
>>438
ということは、合成文字に関しては、1バイト単位での検索ルーチンでは
対応できないということですね。
ちゃんとしたロジックを組まないと行けないんでしょうね。
440:デフォルトの名無しさん
04/03/08 23:59
>>436
URLﾘﾝｸ(www.unicode.org)
の2.10辺りとかを参照。
> 完成形としては同じになるのに、符号としては異なる文字
も「あり」。
じゃあ文字を比較するときどうすんだ、というのは
URLﾘﾝｸ(www.unicode.org)
辺りとかを参考にどうぞ。
441:デフォルトの名無しさん
04/03/09 01:18
もう面倒くさいから一文字64bitでいいよ
でかけりゃgz
442:デフォルトの名無しさん
04/03/09 01:43
合成文字は終端記号として処理すべきかギモンヌ。
なぜtexのようなシンタックスとして扱わんのかと。
443:デフォルトの名無しさん
04/03/09 09:29
>>441
さんせー
444:さっきゅん ◆GG1SfzBGbU
04/03/09 09:33
＿
/～ヽ
(｡･-･) ｡oO( 64bitじゃぜんぜん足りませんが何か
ﾟし-Ｊﾟ
445:デフォルトの名無しさん
04/03/09 09:40
256bitでどうだコンチクショー
446:デフォルトの名無しさん
04/03/09 10:03
>>445
どんだけ使えば気が済むんですか。
447:さっきゅん ◆GG1SfzBGbU
04/03/09 13:22
＿
/～ヽ
(｡･-･) ｡oO( 最初からグリフでデータ交換すれば文字コードなんて概念消滅するんだけど
ﾟし-Ｊﾟ
448:デフォルトの名無しさん
04/03/09 13:29
utf-2000とかどうか。
449:デフォルトの名無しさん
04/03/09 13:41
>>447
お前さんの言う「グリフ」ってのは「グリフイメージ」のことか？
450:デフォルトの名無しさん
04/03/09 13:42
>>448
古い。
451:デフォルトの名無しさん
04/03/09 14:34
検索どうするんだよ
452:LightCone ◆sSJBc30S5w
04/03/09 15:00
>>447
それだと、フォントが変えられないし、HTMLブラウザやコンパイラや
インタプリタに光学文字読み取り機を内蔵しなきゃならないし。
453:LightCone ◆sSJBc30S5w
04/03/09 15:02
合成文字まで考えるとやはり、結局固定長符号でも可変長符号でやる場合と
余り手間が変わらないのかな。
454:LightCone ◆sSJBc30S5w
04/03/09 15:06
合成文字がある場合は、UCS4符号を使っていたとしても、例えば「n文字目」の
ポインタを得たいとき、言わずもがな、いきなり
ptr = &linebuf[n-1]
みたいなことをやるわけにも行かず、普通は、カレント位置から順番にたどって
行くことになるだろうらら。
455:LightCone ◆sSJBc30S5w
04/03/09 15:07
合成文字まで考えると、結局、UTF8でも、ASCIIしか考慮していない
strstr()では正しく検索できないね。
456:デフォルトの名無しさん
04/03/09 16:59
>>444
この世の中に180京文字以上もあるのか？
1つの言語ごとに1億文字分のスペースあたえても余裕だと思うが。
>>合成文字
手抜きせず全部展開これ最強。
もっと富豪になれいつまでも貧乏性はｲｶﾝ
457:デフォルトの名無しさん
04/03/09 17:14
>>456
8文字しか表現できないと思ったのか？
458:LightCone ◆sSJBc30S5w
04/03/09 17:23
>>456
>この世の中に180京文字以上もあるのか？
64BITじゃ足りないというのは、合成文字も含めてのことでは?
459:デフォルトの名無しさん
04/03/09 19:56
⑳の大きいやつとか㍍とか合成顔文字とか、
そんなのをどんどん含めていくとして
まあそれでも一億は越えないよな。
460:LightCone ◆sSJBc30S5w
04/03/09 23:52
日中混合漢字テーブルを作ってみました:
URLﾘﾝｸ(www.nowsmartsoft.or.tv)
461:デフォルトの名無しさん
04/03/10 01:33
文字コード変換について語りましょう♪
462:デフォルトの名無しさん
04/03/10 03:08
たぶん24ビット（1677万文字）もあれば、合成なしで世界中の全部の文字を収録することが
出来そうな気がするが…
463:デフォルトの名無しさん
04/03/10 07:47
>>462
DecompositionやNFDを使うのは派生形や辞書順での扱いを容易に
するためであって、文字が足りないからではない。
464:デフォルトの名無しさん
04/03/10 10:37
>>463
465:デフォルトの名無しさん
04/03/10 15:11
>>464
466:デフォルトの名無しさん
04/03/10 15:15
>>465?
467:デフォルトの名無しさん
04/03/10 18:36
>>467
468:467
04/03/10 18:36
_|￣|●
469:デフォルトの名無しさん
04/03/11 16:20
Webアプリでhtmlで漢字入力した場合、サーブレットを通して最終的にJSPで表示する際、
どうしても文字化けが起こってしまいます。この場合に対処する方法としての
プログラムの記述の仕方を知っている方がいらっしゃたら教えてください。
470:デフォルトの名無しさん
04/03/11 17:30
そんなDQN言語使うからだ
471:デフォルトの名無しさん
04/03/11 18:38
言語がDQNなのではなく（ｒｙ
WebProg
URLﾘﾝｸ(pc2.2ch.net)
472:デフォルトの名無しさん
04/03/11 21:18
俺の知らない新言語が出来てるのかと思った。
473:デフォルトの名無しさん
04/03/12 00:38
質問です。
VBscriptを使って
「UTF-8」→「base64」→「UTF-8」のデコードを行いたいのですが、
ｇoogleでヒットするいろいろなサンプル関数をためしましたが、例えばこれでも
URLﾘﾝｸ(www.geocities.co.jp)
どれもbase64→SJISにデコしようとしてる？のか、日本語が文字化けします。
とんでもない見たこともないような特殊漢字に化けます。英数は正常です。
なんとかUTF-8にデコードする方法はありませんでしょうか。
y = decodeStreamSJIS(l, k) ' シフト JIS として解釈する場合。
' y = decodeStreamEUC(l, k) ' EUC として解釈する場合。
の部分に、unicode(UTF-8)にデコードするものを作ればいいのですが、いかんせん知識不足です。
目的としてはエンコードがかかったファイルをvbscriptバッチをはさみデコードするというものです。
ちなみにbasp21のデコード機能でさえ文字化けしました。
どれもみなSJISには直してくれるのですが、エンコ前の元データがUTF-8で、UTF-8にもどす
となると見つかりません。
なにか良い方法はないでしょうか。
474:デフォルトの名無しさん
04/03/12 01:05
すみません、質問です。
JSP画面で漢字表記するために必要なセンテンスって
何でしょうか？教えてください！！
475:デフォルトの名無しさん
04/03/12 06:29
>>473
base64ってバイナリをそのままエンコード、デコードするものだと思うのだが。
文字コードと何の関係が？
476:LightCone ◆sSJBc30S5w
04/03/12 22:52
URLﾘﾝｸ(www.nowsmartsoft.or.tv)
477:LightCone ◆sSJBc30S5w
04/03/12 22:55
投稿ミス(早走)りました。↑は、JIS第1水準+中国第一級。
↓が、JIS第1第2+中国第一級、第二級
URLﾘﾝｸ(www.nowsmartsoft.or.tv)
ついでに、Unicodeが、西洋の言語にヒイキ気味なことは、↓の最後の
方に書いてあります。異論あればどうぞ。
URLﾘﾝｸ(www.nowsmartsoft.or.tv)
478:473
04/03/13 12:34
>>475
確かにそうなんですけど。
479:デフォルトの名無しさん
04/03/13 12:44
>>478
VBScriptの内部コードがUTF-8だからSJIS(EUC-JP)->UTF-8変換が入ってるんじゃないか?
おそらく不要なコード変換部分をカットすれば良いだけだろう
480:デフォルトの名無しさん
04/03/13 13:14
あ、しまったマルチになってしまいました。
えっと>>479
URLﾘﾝｸ(www.geocities.co.jp)
を使っているのですが、見た感じ、
SJIS→UTF-8ってのは無いかんじですが、どのあたりでしょうか。
481:デフォルトの名無しさん
04/03/13 13:26
>>480
だからUTF-8とかSJISとかは実際のところ問題ではなくて
バイト列->内部コード変換をカットしろという話なんだが…
482:デフォルトの名無しさん
04/03/13 20:41
> 455 ：LightCone ◆sSJBc30S5w ：04/03/09 15:07
> 合成文字まで考えると、結局、UTF8でも、ASCIIしか考慮していない
> strstr()では正しく検索できないね。
お前、 wcsstr/wcswcs って知ってる？
483:LightCone ◆sSJBc30S5w
04/03/13 20:47
>>482
あなたは全く意味分かってないね。
484:LightCone ◆sSJBc30S5w
04/03/13 20:50
>>482
要するに、そういうものを使えば、あらゆる文字コードに対応できるのは
当たり前なので言うまでもないことなんだよ。
だけど､UTF8は、strstr()でさえも、合成文字以外は正しい結果を出すように
工夫されていると言うこと。
人を馬鹿にする前に自分が勉強すること。
485:デフォルトの名無しさん
04/03/14 00:08
string.h、ctype.h、regex.hなどの文字(列)に関係する関数全てが
UTF-8を使えば国際化されるのであれば話は別だが、strstrとか一部の結果だけ
取り上げて既存の文字コードより優れてると主張するのは、木を見て森を見ない馬鹿か
Markus Kuhnのような確信犯。まあ>>484は前者だろう。
486:デフォルトの名無しさん
04/03/14 01:05
OS 板に帰ってくれ。
487:LightCone ◆sSJBc30S5w
04/03/14 01:09
>>485
>UTF-8を使えば国際化されるのであれば話は別だが、strstrとか一部の結果だけ
>取り上げて既存の文字コードより優れてると主張するのは、木を見て森を見ない馬鹿か
>Markus Kuhnのような確信犯。まあ>>484は前者だろう。
UTF8の場合、何も修正しなくても大丈夫なことが多いと言うことが言えるわけで、
それが理解できないなら、UTF8について理解できてない。
488:LightCone ◆sSJBc30S5w
04/03/14 01:16
>>485
試しに、UTF8に変えたとき破綻する例上げてみなはれ。
例えば、人が解釈するなら、「文字数を出す」という関数を、
「バイト数を返す」に「意味の解釈」を修正しないと駄目だけど、
コンピュータ内部では、何も修正せずに矛盾無く辻褄が合う。
はっきり言えば、ある意味変な解釈のまま、関数同士がお互いに間違い続ける
から矛盾が生じないという事になる。
489:LightCone ◆sSJBc30S5w
04/03/14 01:17
自分が理解できないのを他人のせいにするのが流行ってまんな。2chは
大体そんなものだけど（笑）。
490:LightCone ◆sSJBc30S5w
04/03/14 01:32
というより、専門の「煽り屋」の仕業だな。多分。
なぜなら、こんな馬鹿で失礼な人、自分の周りではあったこと無いから。
よく考えたら、実際問題、こんな失礼な人間、町歩いて手もいないもんな(笑)。
491:LightCone ◆sSJBc30S5w
04/03/14 01:33
やっぱり1chの西さんの言うように、専門の煽り屋が居るって言う噂は、
本当なんだね。
492:デフォルトの名無しさん
04/03/14 03:00
最近放置気味だったのが、相手にしてもらえてうれしいようだ。
493:デフォルトの名無しさん
04/03/14 03:09
>>485 の言うとおり regex は随分変更を受けると思うが。
標準関数じゃないが、よく使われるので重大だ。
あと、１文字のバイト数が固定じゃなくなるので、
strchr は strstr で代用できるとしても、
strrchr は使えなくなってしまう。
他にも strpbrk や strtok も改変が必要。
isleadbyte も改変が必要で、
後続バイト数を返すようにする必要がある。
あとは、標準関数だけじゃなく、
独自のライブラリの関数も軒並みアウトだろうな。
まぁ、想定する文字コードが違うんだから、
１文字１文字処理していくタイプの処理が使いまわせないのは
当然っちゃー当然だけど、
Shift-JIS か EUC かって程度なら
isleadbyte 使ってりゃ何とかなることを考えると UTF-8 は随分面倒だ。
UTF-8 だと日本語は３バイト以上だし、どうやっても誤魔化せないな。
494:デフォルトの名無しさん
04/03/14 03:11
お願いします。これ以上構うと閣下の病状が極端に悪化してしまいますので
このあたりで勘弁してあげてもらえませんでしょうか。。。
495:LightCone ◆sSJBc30S5w
04/03/14 07:35
>>493
>strrchr は使えなくなってしまう。
ASCIIに対しては無修正で使えるので、これも人間側の解釈の問題で、
コンピュータ内部では全く問題が発生しません。
それに対して、これがもし、Shift_JISであったならばそうは行きません。
>regex は随分変更を受けると思うが。
どのように変更を受けるんでしょうか?(笑)
496:LightCone ◆sSJBc30S5w
04/03/14 07:36
多分、>>493も、UTF8の特性を理解してませんね。
試しに、regexの修正点を上げてみて下さい。
497:デフォルトの名無しさん
04/03/14 08:34
>>496
文字単位でマッチングしないと使い物にならないからじゃないか?
mblenなどをしっかり使っていればあまり問題は出ないはずなのだが
実際のアプリではロケールの初期化すらまともにされていなかったりする
498:LightCone ◆sSJBc30S5w
04/03/14 08:45
>>497
>文字単位でマッチングしないと使い物にならないからじゃないか?
何故?
regexの主たる目的は置換。
それに何故、文字数が必要? バイト位置で足りるはず。
せっかく、何もしなければ辻褄が合ってるのに、mblen()なんて使うと
破綻します。
499:デフォルトの名無しさん
04/03/14 08:50
単純に、こんな場所で偉ぶっていい気になってる「LightCone ◆sSJBc30S5w」が
可哀相に思えるのは私だけですか？
500:デフォルトの名無しさん
04/03/14 09:18
>>498
この界隈のｺﾃﾊﾝは相手が誤解していると思いこむ傾向が強いように見えるけど
実際は両方が誤解している場合が多そうだよ
この件も問題にしている部分が違うだけ
501:デフォルトの名無しさん
04/03/14 09:37
アホコテさらしage
502:LightCone ◆sSJBc30S5w
04/03/14 09:43
>>500
それは、違いますな。
何故かというと、ワテと話していて全く誤解が生じない人種と
あったことがあるからです。
すんなり話が通じて楽しかった。
はっきり言って、一般人と話すのは苦手です。バカの壁を感じるから。
503:LightCone ◆sSJBc30S5w
04/03/14 09:47
ワテと話していてワテが間違っていると思う人は、
まず、99.99%位、あんたの間違いだと思って大丈夫。
それに大抵の優秀な人は、深読みするのでそうそう簡単に相手の間違いを
断定しない。
はっきり言って、間違ったことを行ったときでさえ、それなりに意味の
通じる解釈をする人が多い。
2chラーで批判ばかりしている人は全くの逆で、知能の低さがすぐに分
かる。
結局、辻褄の合う解釈法が重い浮かばなくて、理解できないんだよ（笑）。
アホ
504:LightCone ◆sSJBc30S5w
04/03/14 09:49
はっきり言って、邪魔になるから、そういう人達には勉強などさせずに、
遊ばせてやったらいいんじゃないかと思ってる。
505:デフォルトの名無しさん
04/03/14 09:52
>>503
相手の発言の意図を読む意志がないと指摘しているだけなんだが
無駄な発言をして悪かったよ
506:デフォルトの名無しさん
04/03/14 09:55
>>502
> 何故かというと、ワテと話していて全く誤解が生じない人種と
> あったことがあるからです。
M-x doctorかい？
507:デフォルトの名無しさん
04/03/14 10:00
>>503
＞それに大抵の優秀な人は、深読みするのでそうそう簡単に相手の間違いを
＞断定しない。
＞
＞はっきり言って、間違ったことを行ったときでさえ、それなりに意味の
＞通じる解釈をする人が多い。
あんたはアホウだということだね。自認しているとは謙虚なやつだ（ｗ
508:デフォルトの名無しさん
04/03/14 10:04
とりあえずUnicodeいらね＞自分コード作ったという所らしいけどさ、中共政府並みの強制力とか
影響力がない個人でやるのはきついだろうねぇ。
LightConeて人がどういう人か知らんのでOS板見て来たら自分でOS作ってる人なんだね。
それならそこでの実装に限定してそっちで話してればいいんじゃなかろうか？って思う訳だが。
ム板に来てやってんのはどういうあれなんだろう？
このスレは最初は単発質問スレっぽい雰囲気だったけども、ほとんど既存のOSの上で規格として
動いてるUnicodeとローカルエンコードの変換とかの話してたと思うんだが。
なんで、このスレなんだろう？
自分コードを自分OSに実装したよの宣伝だとしたらちょっといただけないんだが。
自分で掲示板作ってそっちでやってるもんだとばっかり思ってたんだが、ここにきて煽りに対抗
するためだけに書き込みしてるみたいでちょっと痛いぞ。
ここでやってないでそっちでちゃんとした議論してた方がいいんじゃなかろうか？
老婆心だけどね。
509:LightCone ◆sSJBc30S5w
04/03/14 10:09
>>507
なんか、なんでも基準を曖昧にしたがるようだけど、取りあえず、
悪いけど、そういう人種の人たちには、ワテ自身が確信していることに
対して批判を受けたことは未だにないんだよ。
もう、答えが出てしまって、証明済みで、なんの迷いもない結論に
達しているのに、まだ反論してくる人が居るのは、ネットのみの経験
だから、違いが如実。
510:デフォルトの名無しさん
04/03/14 10:13
発作age!
511:LightCone ◆sSJBc30S5w
04/03/14 10:14
はっきり言うとね、ワテだって、結構間違うことはあるんだよ。
でも、そういう場合、
「そんなことがあったんですかいな!?」
「まいった、見落としてた!!」
「また、アホなミスをしった!!」
と思うわけ。
結局、指摘が的を射てるわけなんですよ、そういう連中は。
512:デフォルトの名無しさん
04/03/14 10:23
宣伝なら業者みたいに黙々とコピペしまくればいいのに。
513:デフォルトの名無しさん
04/03/14 10:48
すいません、コーンたんはこういう人なんです。
すごくやる気があります。それは確かです。
でも、いつも車輪をダウングレードして再発明する人なんです。
しかも、人の指摘や忠告を聞く気はサラサラなく、一方的に放送した挙句、
最後はいつも「おまえらアホだ、俺は正しいのに」で終わるのです。
514:デフォルトの名無しさん
04/03/14 12:07
正規表現の . がある。
これは任意の１文字にマッチングする。
ASCII の１文字は１バイト固定だが、
UTF-8 の１文字は１バイトとは限らない。
sed の書き方になるが、
s/a.a/aa/g
の場合、UTF-8 の "aあa" を置換しようとしても、
ASCII の regex を使うと ''あ' は３バイトなため、マッチしない。
515:デフォルトの名無しさん
04/03/14 12:14
2chは、確かに引きこもりやら、学生やらが多い。（俺も学生です・・・。）
確かにろくに分かっていないことでも、分かっているように言っている人も多いだろう。
ただし問題は時々有り得ないほど知識を持った人が紛れ込んでいること。
引きこもりばっかだと思えば、イケメンやら美人やらが紛れ込んでいるという事実。
不特定多数が集う匿名掲示板である以上、言葉遣いには気をつけるべし。
「車輪の再発明」という言葉を多用して批判する人がいるが、
こいつ自分の言葉に酔っているんだなぁと思うことはある。
516:デフォルトの名無しさん
04/03/14 12:15
で、ﾗｲﾄなんたら氏は そのあり得ないほど知識を持った人だと？
517:デフォルトの名無しさん
04/03/14 12:18
声を大にしていいたい。
日本が戦争に負けたとき、マッカーサーにより
日本は日本語を廃止し、すべて英語になるべきだった。
あまりにくだらないロスがおおすぎる。
当時まさかコンピューターでこんなロスが発生するとは
考えてもいなかったろうが。
すべて英語だったら、モジコードうんぬんなんて
こんなくだらない苦労しなくてすむのに。
518:デフォルトの名無しさん
04/03/14 12:19
暴言ｷﾀｰ
519:らいとこうん
04/03/14 12:21
ワテはOSを作れるほど知識を持った優秀な人間です。
520:LightCone ◆sSJBc30S5w
04/03/14 12:25
>>514
>正規表現の . がある。
>これは任意の１文字にマッチングする。
>ASCII の１文字は１バイト固定だが、
>UTF-8 の１文字は１バイトとは限らない。
なるほど、それは確かにそうです。
UTF-8でも無修正で完全対応とは行かない例の一つですね。
考えるまでもなく、「文字数」が意味を成している部分はことごとく
駄目になります。今の場合でも、1文字ではなく「任意の文字の列」
でいいなら、「a.*a」で行けると思います。つまり、1「文字」と
いう「文字数を数える行為」に失敗しているのが原因なのですね。
521:デフォルトの名無しさん
04/03/14 12:25
>517
お前は効率のために生きてるのか？
文化には多様性が必要だと思わないのか？
まあ始皇帝も文字と秤を統一したがったけど、
アメリカみたいなインチが主流の国も世の中にはあるからな。
当分ラクにはならんよ。
522:LightCone ◆sSJBc30S5w
04/03/14 12:36
>>514
ついでなので、「.」以外にもありますか?
523:デフォルトの名無しさん
04/03/14 12:38
文字数に関わるもの全て。 {n,m} とか。
524:デフォルトの名無しさん
04/03/14 12:41
あと文字種の考え方自体もunicodeとそれ以外じゃ違う。
perlunicodeとか見たらそれなりの準備されてるのがわかるはずだ。
525:LightCone ◆sSJBc30S5w
04/03/14 12:45
>>523
a{2,5}
とか、
(あ){2,5}
とかなら問題ないのでは?
526:デフォルトの名無しさん
04/03/14 12:46
>525 なんすかその不自然な括弧は？
527:デフォルトの名無しさん
04/03/14 12:47
あまり適当なことを言うと
> 484 名前：LightCone ◆sSJBc30S5w 投稿日：04/03/14 01:41
> 2chって、詳しい人が多いのかと思ってたけど、かなり勘違いみたいですね。
>
> そういう勘違いが起きてしまう理由は、いくつかの可能性がありますね。
>
> 一つには、来る人が多いから、全然詳しくなくて断片的な知識を持ったいさま
> ざまな人が来るため、一見もの凄く詳しい人が居るように見えるだけで、実際は、
> 断片知識の烏合の衆の集まりに過ぎない可能性。
こんな事言われちゃうよｗ
528:LightCone ◆sSJBc30S5w
04/03/14 12:48
>>526
そりゃしゃあない。
529:デフォルトの名無しさん
04/03/14 12:49
そのカッコをつければできるとしても、
そのカッコはつけたくないなぁ。
530:デフォルトの名無しさん
04/03/14 12:53
相手にしすぎると
> 515 ：デフォルトの名無しさん ：04/03/14 12:14
> 2chは、確かに引きこもりやら、学生やらが多い。（俺も学生です・・・。）
> 確かにろくに分かっていないことでも、分かっているように言っている人も多いだろう。
> ただし問題は時々有り得ないほど知識を持った人が紛れ込んでいること。
> 引きこもりばっかだと思えば、イケメンやら美人やらが紛れ込んでいるという事実。
>
> 不特定多数が集う匿名掲示板である以上、言葉遣いには気をつけるべし。
>
> 「車輪の再発明」という言葉を多用して批判する人がいるが、
> こいつ自分の言葉に酔っているんだなぁと思うことはある。
こんな事言われちゃうよｗ
531:デフォルトの名無しさん
04/03/14 12:55
そして雪崩れ込むように
> 517 名前：デフォルトの名無しさん 投稿日：04/03/14 12:18
> 声を大にしていいたい。
> 日本が戦争に負けたとき、マッカーサーにより
> 日本は日本語を廃止し、すべて英語になるべきだった。
> あまりにくだらないロスがおおすぎる。
>
> 当時まさかコンピューターでこんなロスが発生するとは
> 考えてもいなかったろうが。
> すべて英語だったら、モジコードうんぬんなんて
> こんなくだらない苦労しなくてすむのに。
こんな事言われちゃうよｗ
532:デフォルトの名無しさん
04/03/14 12:56
>>529
つけたくないなぁと言われても。
533:デフォルトの名無しさん
04/03/14 13:01
論旨は「バイト単位の正規表現モジュールでutf8も問題なく扱える」だったと思うが、
. や [] のことも考えてない「全然詳しくなくて断片的な知識を持った」人だったと。
まあ間違えたのは仕方ない。しかし間違った後にうだうだいってるのは無様だし、
間違いを書く前に自分で検証する姿勢が足りてないのが暴言の数々から読み取れる。
頭冷やしてきなよ。
534:デフォルトの名無しさん
04/03/14 13:01
>>525
つまり世界中のregular expressionを使ったプログラムを修正して回れってこと？
普通の人は、regular expressionのライブラリのほうを修正すると思うが。
535:デフォルトの名無しさん
04/03/14 13:04
LightCone様の足下にも及ばない厨房のくせにいきがってんじゃねーよ。
536:デフォルトの名無しさん
04/03/14 13:06
>>535
何故そこでよく分からない横槍が入るｗ
537:デフォルトの名無しさん
04/03/14 13:06
いや正規表現側で工夫してきたのが今までの日本のperl文化だからなぁ。
どこにでもあるからって理由でperl使ってた人はそこに適応するようにスクリプト側で工夫してたわけ。
それも普通じゃないってこと？
まあLightCornが破綻してるのは既に明らかだが。
538:デフォルトの名無しさん
04/03/14 13:06
>>534
普通の人はOSなんか作らないよ！
とフォローにもならない暴言を吐いてみる
539:デフォルトの名無しさん
04/03/14 13:09
話は変わるけど俺はucs2よりもutf8の方が寿命が長そうだから好きだ。
何度も書き直したくないじゃん？なら可変長のエンコーディングで通した方が将来性がある。
\0があまり登場しないから既存OSとの親和性も悪くないし。
540:デフォルトの名無しさん
04/03/14 13:10
既にucs2対応のOSでしか動かないとか、
システムコールの度にエンコード変換するとか、
そういうのはイヤですわ。
541:デフォルトの名無しさん
04/03/14 13:15
Ruby は正規表現に日本語が使えるよ！
やっぱ使えたほうが便利だよ。
542:デフォルトの名無しさん
04/03/14 13:17
文字コード総合スレあっても良かったんかなぁ。
このスレの主旨って元々はピンポイントに「変換」だし。
543:デフォルトの名無しさん
04/03/14 13:19
ひまわりなら日本語だけで書けるよ！
544:LightCone ◆sSJBc30S5w
04/03/14 13:22
正規表現ルーチンは、UTF8を使っても要修正でした。
すんません、訂正します。
これで気が済むんでっか?
545:デフォルトの名無しさん
04/03/14 13:23
自分が独りワイワイと騒いどいて何いじけてんの？子供だね。
546:デフォルトの名無しさん
04/03/14 13:26
>>544
こっちはコーンたんが何言おうともはや気にしてないけど。
547:デフォルトの名無しさん
04/03/14 13:29
という訳で終ー了ー。
548:デフォルトの名無しさん
04/03/14 13:29
見てて不憫になってきた。
549:デフォルトの名無しさん
04/03/14 13:32
文字が UTF-8 が表現されるとすると、
strrchr("あいあい", 'あ');
とかいう１文字逆検索ができない。
'あ' は３バイトだし、UTF-8 は最長６バイトだから、
こういう表記自体に問題があるかもな。
文字列の逆検索があれば代用できるんだけど...。
あと、strpbrk, strtok, strspn, strcspn の第二引数も改変が必要。
こういう１文字＝１バイトを仮定されると困る処理は軒並みアウトだ。
550:デフォルトの名無しさん
04/03/14 13:51
ungetc()とかきっと1バイトしか戻せないよ……。
551:デフォルトの名無しさん
04/03/14 14:25
英語圏のプログラムで、設定ファイルを読んだりログを書いたりする程度ならまあ改造なしでも通るけどさ。その程度だよな。
552:デフォルトの名無しさん
04/03/14 14:28
結局書き直しまくりだねぇ
553:デフォルトの名無しさん
04/03/14 16:14
regexはcharacter classとcollation orderも扱うのだが、
何故UTF-8など修正無しでOKだと思ったんだろう。
554:デフォルトの名無しさん
04/03/14 16:32
Perlなんかでも正規表現は漢字1文字が2バイトになるって分かって書いてきたからね。
そういう感覚を前提にしたら、検索で誤マッチしないだけで充分ってことでは。
555:デフォルトの名無しさん
04/03/14 17:06
collationなんてやりだしたら修正どころじゃないな
556:デフォルトの名無しさん
04/03/14 17:28
glibcのregex国際化
URLﾘﾝｸ(lc.linux.or.jp)
URLﾘﾝｸ(lc.linux.or.jp)
557:デフォルトの名無しさん
04/03/14 20:07
>上述の通り、我々の実装はDFA をベースとしている。
>このため、NFA ベースの実装では避けられないback tracking の問題
>が生じない。
NFAベースでもバックトラック無しの実装をアップしとるのに。
複数の状態変数のパラレルな遷移という例で。
>しかし、Single UnixSpecification[3] などの規格において、
>あるコードポイントに文字が割り当てられているかどう
>かをエンコーディングから独立に調べる方法が用意されていない。
着眼点が悪い。
実は既に正規表現式から必要最小限な集合を抽出する方式がある。
つまり、入力値の範囲ではなく、パターン自体にその答えがある。
オーバーヘッド無し、むしろ従来より高性能な実装は可能。
と、ここで書いてみる。
どうせダウンロードとしてないんだろうな。
従来と違うアプローチの実装例をいくつも出したのに。
558:デフォルトの名無しさん
04/03/15 00:10
>>554
いつの時代のperlの話だよ。.を1byteと見做すなんて。
PCRE is short for Perl Compatible Regular Expressions.
URLﾘﾝｸ(www.regular-expressions.info)
559:デフォルトの名無しさん
04/03/15 00:15
それから、printf系がUTF-8で問題ないって言う人いるけど、
%c, %lcが全く駄目じゃん。範囲限定で使えないことはないレベル。
560:デフォルトの名無しさん
04/03/15 00:34
複数回 %c すればー、ということじゃない？
改変するとすれば、アドレス渡すようにしないといかんのかな。
そもそも文字リテラルの仕様をどうすればいいんだろうか？
561:デフォルトの名無しさん
04/03/15 01:04
>>558
現状ではこの手のツールの漢字対応って大抵無理やり動かすパッチだけど。
ggrepの日本語対応パッチで比較回数が爆発したりとかするやつあったし。
562:デフォルトの名無しさん
04/03/15 01:10
漢字対応って一体何の話? ここはUnicodeのスレですよ?
>>553の言っていること理解できる?
563:デフォルトの名無しさん
04/03/15 01:12
ああ、すまん、マルチバイト対応だ。打ち間違い。
564:デフォルトの名無しさん
04/03/15 09:43
>>558
一般人にもっとも馴染みの深いプロバイダのおまけCGI環境だと今でも普通だが。
565:デフォルトの名無しさん
04/03/15 09:49
>>559
さすがにそれは言いがかりだろ。
マルチバイトでcharに入らない時点でどう転んでも無理。
wchar_tでwprintf使ってなさいってこった。
566:デフォルトの名無しさん
04/03/15 09:50
>>564
まさかそれが正しいことだと思ってるんじゃなかろうな・・・
567:デフォルトの名無しさん
04/03/15 09:51
>>565
いや、だから>>559は「どう転んでも無理」という話をしているのだが・・・
568:デフォルトの名無しさん
04/03/15 09:55
>>564
その環境100%信頼してバッチジョブで
漢字ファイル名の自動リネームに使うとあぼーん。
Rubyも1.8になるまで不具合連発だったし、今でも警戒してる。
569:デフォルトの名無しさん
04/03/15 10:00
そこはバッドノウハウで回避ですよ。
570:デフォルトの名無しさん
04/03/15 10:06
バッドノウハウ？
ちゃんと再設計すりゃいいじゃんか、アルゴリズムを変えて。
マルチバイトの対応は10年たっても20年たっても不完全。
571:デフォルトの名無しさん
04/03/15 10:12
>>570
おつむの弱い人ですか?
アルゴリズムて 誰がregexライブラリ設計の話してるの…
572:デフォルトの名無しさん
04/03/15 11:16
>>571
551から554,556,558の流れなんだけど。
573:デフォルトの名無しさん
04/03/15 14:51
571はLightCone
574:デフォルトの名無しさん
04/03/15 21:00
彼は名無しで煽らないよ。
575:デフォルトの名無しさん
04/03/15 22:12
いやぁ、ときたま名無しのLightConeがまぎれているような気がするんだが。
なぁ、>>574
576:デフォルトの名無しさん
04/03/16 01:28
>>562
誰も突っ込んでないようだが、
このスレは別に Unicode のスレじゃない。
577:デフォルトの名無しさん
04/03/16 02:12
文字コード総合スレあった方が良かったかな？
僅かな需要はあるのかも。
578:Shift_JIS
04/03/16 02:24
私の頃忘れないで…
古い欠点ばかりの女とお思いでしょう。けどわたし…(ﾓｼﾞﾓｼﾞ
579:デフォルトの名無しさん
04/03/16 07:59
UTF8とSJISのスレだと勘違いされてもしかたないタイトルだな。
580:デフォルトの名無しさん
04/03/16 15:43
java厨ならその2つだけでなんとかなるからな
581:デフォルトの名無しさん
04/03/16 23:12
なるかボケ
582:デフォルトの名無しさん
04/03/16 23:52
質問です。
VBscriptでUTF8からSJISに変換という
関数や方法はあるのでしょうか。
583:デフォルトの名無しさん
04/03/17 01:00
>582
ふつーに変換DLLをインポートできねーの？サーバサイドだよね？
584:デフォルトの名無しさん
04/03/18 00:11
できれば、VBscript内で行いたいです。
そのＶＢscriptファイルををダブルクリックすると
指定したUTF8のファイルを読み込み、SJISに変換したものを
別ファイルとして吐き出す
っていうのを作りたいのです。
585:デフォルトの名無しさん
04/03/18 00:42
んー、UTF8からUCS2への変換はふつーに書けるよね。
UCS32からCP932への変換はAPI呼ぶとか自前でテーブル持つとかでできるね
586:デフォルトの名無しさん
04/03/18 00:50
>>585
basp21
の「kconv」を使ってはみたのですが、どうもうまくいきません。
使い方間違っているのでしょうか・・
587:デフォルトの名無しさん
04/03/18 03:00
UTF8 ─自前ルーチン→ UCS2 ─WideCharToMultiByte→ SJIS
UTF8 → UCS2
URLﾘﾝｸ(www.linux.or.jp)
588:デフォルトの名無しさん
04/03/18 23:20
やはりこれってのはスレがたつほどなんで
文字コード知識ある人でも難しい問題なんですか？
basp21でできそうだったんですが・・・できないものですね。
589:デフォルトの名無しさん
04/03/18 23:40
ﾜﾗﾀ
590:デフォルトの名無しさん
04/03/18 23:40
普通の人でもある程度書けるけど正確さを目指すと規格の曖昧さで苦労する問題です。
588はもーちょっと修行すれ。もしくはちゃんとコードとエラー内容を出して質問すれ。
591:デフォルトの名無しさん
04/03/19 11:21
>>587
WideCharToMultiByte使うなら、Win95での動作を想定しなくてよければ
MultiByteToWideCharでUTF-8＞UCS-2変換すればいいと思うが。
592:デフォルトの名無しさん
04/03/19 12:36
MSLU入れてもその辺アップデートされないの？
593:デフォルトの名無しさん
04/03/19 13:13
>>592
unicow.dll(だっけ?)をリンクしているアプリからしか使えない。
VBScriptからという条件じゃ無理
594:デフォルトの名無しさん
04/03/19 22:04
すみません、全くの初心者なのですが、perl 5.8.2での質問です。
test.txtという、shift-jisで保存されたテキストファイルがあります。
（ファイル名も、置かれているディレクトリも常に同じ。）
このファイルを、utf-8に変換したいのですが、やり方がわかりません。
いろんなサイトを参考にして、何種類かやり方があるようなことがわかり、
試しに、
use utf8;
$input_filename ='C:\hoge\test.txt';
$output_filename ='C:\hoge\test.txt';
open my $in,'<:encoding(shift_jis)',$input_filename or die "open $input_filename: $!\n";
open my $out,'>:encoding(utf8)',$output_filename or die "open $output_filename: $!\n";
while(<$in>){print $out $_;
}
close($in) or die "read $input_filename: $!\n";
close($out) or die "write $output_filename: $!\n";
という風に書いてみましたが、結果はtest.txtの中が空になるだけでした。
また、別のやり方として、
use utf8;
$input_filename ='C:\hoge\test.txt';
$output_filename ='C:\hoge\test.txt';
use Encode qw(from_to);
open my $in, "<", $input_filename or die;
open my $out, ">", $output_filename or die;
while(<$in>){
from_to($_, "shift_jis", "utf8");
print $out $_;
}
という風なやり方も試してみましたが、結果は同じでした。
どこがいけないのでしょうか？
どなたか詳しい方、よろしくお願いします。