【UTF8】文字コード変換【SJIS】

【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 $_;
}
という風なやり方も試してみましたが、結果は同じでした。
どこがいけないのでしょうか？
どなたか詳しい方、よろしくお願いします。

595:デフォルトの名無しさん
04/03/19 22:53
perlは門外漢なんだが、入力と出力が同じファイル名でいいの？
ファイルが空になるような。

596:デフォルトの名無しさん
04/03/19 23:01
windowsだと確実にダメなはず。出力を開いた時点でファイルサイズが０になる。

597:デフォルトの名無しさん
04/03/20 01:24
結局のところ
UTF8→ShiftSJIS
直変換は無理ってこと？

598:デフォルトの名無しさん
04/03/20 01:25
BASP使っては無理？

599:デフォルトの名無しさん
04/03/20 02:24
結局変換コード自前で書いたとしても、
UTF8 から UCS2 のコードを求めて
それを SJIS に変換するってコードを書くことになるしな。
まぁ、１文字１文字変換した方が
余計なバッファが要らない分効率はいいかとは思うけど、
変換に MultiByteToWideChar/WideCharToMultiByte を使うと
呼び出しコストが高そうなので、全部自前で組まないと意味が無いかも。

ただ、使用言語が VBScript なので、ひょっとしたらひょっとするかも？

600:デフォルトの名無しさん
04/03/20 06:22
ShiftSJIS 。

ムリでもなんでもねーよ。てめーがヘタなだけだ

601:594
04/03/20 08:57
594です。
無理なのでしょうか？できるのでしょうか？
perlのスレとかに行ったほうがわかるのでしょうか？

602:デフォルトの名無しさん
04/03/20 09:59
>601 inとoutで開くファイル名変えれ。それだけだ。

603:デフォルトの名無しさん
04/03/20 13:08
簡単に変換する方法ないですか？

604:デフォルトの名無しさん
04/03/20 13:34
つかお前誰だ

605:デフォルトの名無しさん
04/03/20 22:01
URLﾘﾝｸ(www.vector.co.jp)
これを元に、なんとかできないかな

606:デフォルトの名無しさん
04/03/20 22:21
パイナリファイル

607:デフォルトの名無しさん
04/03/24 00:06
JISの半角カナなんだけどさ
ESCJ と shift-out と 7bit が続く場合と ESC I の後に 7bitが続く場合は ASCII扱いでOK?
7bitの場合で他（というとESC I +shift-out+7bitのことだが）はX201扱いでOK?

608:デフォルトの名無しさん
04/03/24 00:50
やや意味不明。ESC J って、ESC ( J のことか？

そうだとして、SO の後は G1 に何が入っているかによる。
日本ではX0202の右側を入れることが多いかな。

ESC ( I の後は X0201右側が G0 に designate されているから、
7bitならX0201右側しかない。

「7bitの場合で他」って、なんで一通りに決まる？
ESC ( I SO の後は、最初の場合と同じで G1 に何が入っているかによる。

609:デフォルトの名無しさん
04/03/24 00:52
↑のX0202はX0201のことな

610:デフォルトの名無しさん
04/03/24 01:02
JIS の半角カナって、M$ の仕様拡張じゃなかった？

611:デフォルトの名無しさん
04/03/24 01:13
おまえはこのスレにいる資格なし

612:デフォルトの名無しさん
04/03/24 09:27
いまどきこんなDQNエンコード使ってるほうが悪いんだよ

613:デフォルトの名無しさん
04/03/24 09:50
>>608
X0201右側って何? 片仮名用図形文字集合のこと?

614:デフォルトの名無しさん
04/03/24 10:06
> ESC ( I の後は X0201右側が G0 に designate されているから、
> 7bitならX0201右側しかない。
これ以前にG1～G3がGLに呼び出されていれば
そこに何が入っているかによる。
ESC 2/8 FでG0に何が指示されようと関係ない。
(一意な符号化が要求されている場合は使用可能な文字が
変わるかもしれないけど)

615:デフォルトの名無しさん
04/03/24 10:18
>>614
> これ以前にG1～G3がGLに呼び出されていれば
> そこに何が入っているかによる。
そうだった。SOとかLS2/LS3が先行してる場合があるか。

>>613
そのつもり。

616:デフォルトの名無しさん
04/03/24 10:26
>>615
7bitで「右側」という表現に違和感を感じたので。
確かにX0201に規定されている8ビット符号は片仮名をGRに
呼び出すものしかないけど

617:デフォルトの名無しさん
04/03/24 22:29
>612 悪いな。IRC関連なんだよ

618:デフォルトの名無しさん
04/03/29 10:48
IRCの日本語文字コードってISO-2022-JPじゃなかったっけ?

619:デフォルトの名無しさん
04/03/30 01:46
age

620:デフォルトの名無しさん
04/05/05 19:26
BOMありUTF-8などというばかげたものが禁止されていないのはなぜですか？

621:デフォルトの名無しさん
04/05/05 20:13
>>620 UTF-8を自動識別できるから(ｗ
ASCII/ANSI互換がメリットなのだから、BOMは付けるべきではないというのが
一般論。でも付けて違反とはISO 10646にもRFCにも規定はないですね
Use caseによるんじゃないですか？
XMLやHTMLなら、encodingパラメータでコードセットを取得できるので不要、
でもそうでないものやencoding指定が無い場合は識別方法が7fhコードが
含まれているかとかあやふやな、確実に特定する手段無いし・・・
それはS-JIS、GB 2312、Big5、KS C5601(KS X1001)、CNS 11643等でも
同様ですが

622:デフォルトの名無しさん
04/05/05 20:14
>>620
Byte Order Mark の何たるかをご存知でない
お間抜けちゃんがこの業界を仕切っているからでぬるぽ。

623:デフォルトの名無しさん
04/05/05 22:54
いきなりレベルの低い話になりますが、～問題は皆どうやって
回避してますか？

624:デフォルトの名無しさん
04/05/06 07:38
~→～のこと?

625:デフォルトの名無しさん
04/05/06 07:59
WAVE DASH(～)が\u301cにマッピングされる問題でしょ。

626:625
04/05/06 08:02
失礼、「U+301C」の方が良いですね。

627:デフォルトの名無しさん
04/05/06 10:13
iconvもglibcも使うときはSJISじゃなくてCP932を指定してる。
emacsもCP932変換テーブルを作って、さらにutf-8 decode部分を書き換え。

実際どうなんだろう、SJISが必要な人って、どれぐらいいるんだろう？
大部分の人はCP932が欲しいわけで、SJISじゃないと思うのだけど、
そうでもない？

628:デフォルトの名無しさん
04/05/06 11:28
>>621
> でも付けて違反とはISO 10646にもRFCにも規定はないですね
どういう場合に付けてはいけないか(というか付いてたときZWNBSP
ではなくBOMであると解釈してはいけないか)はRFC 3629で
明確化された

629:デフォルトの名無しさん
04/05/06 13:54
>>627
Unicode→SJISで、「どっちが来てもいいように」対応することは可能だけど
SJIS→Unicodeだと、どっちにするか決めないといけない
という問題がありますね。
それと、OracleのNLSのような、ハック不可能な領域だとかなりどうしようも
ない気が。

そういえば、JavaはもうShift_JISがWINDOWS-31JじゃなくてSJISのエイリアス
になってるんでしたっけ。これ、困る人が多いんじゃないのかなあ。

630:デフォルトの名無しさん
04/05/06 16:46
> Unicode→SJISで、「どっちが来てもいいように」対応することは可能だけど
U+005CとかU+007Eが来たときどう変換する?
Shift_JISがX0208の附属書1どおりじゃなくて
1バイト部分はASCIIであるとみなせば対応は可能だけど

631:デフォルトの名無しさん
04/05/06 20:09
>>630
実際問題として、ASCIIと見なさないと、使い物にならないでしょう。
\にどういうグリフが当てられていようと、日本人もそれをエスケープ記号や
パスのデリミタとして(バックスラッシュと同じ意味で)使っているんだから、
他のコードポイント割り当てたら、はっきり言って実用上はお話にならない。

従来通りFontの問題として対応するのが「今のところは」現実的じゃないの。

632:デフォルトの名無しさん
04/05/06 23:53
エスケープ記号はともかくパスのデリミタはWindowsの場合だから
それは単にエンコーディングとしてCP932を想定しているというだけの
話だと思うんだけど。
実際Appleの変換表は円記号をU+00A5に割り当てるし

633:デフォルトの名無しさん
04/05/07 00:26
そのエスケープ記号が大問題だと思うが。
世の多くのプログラミング言語だのTeXだのシェルだのにおいて
メタキャラクタとして使われてるんだから。既存のソースの類が突然にして
コンパイル不能な屑の山になるでしょ。

無論DOS, Windowsユーザにとっちゃパス区切りであることの方が
さらに問題だが。

634:デフォルトの名無しさん
04/05/07 03:27
>>631
そりゃ、プログラマ至上主義だね。
普通の文書に半角円記号使ってた人は困る。

635:デフォルトの名無しさん
04/05/07 08:16
>>634
そしてTerminal上でバックスラッシュと円記号の混乱でうめき、SafariでWebの円記号がバックスラ
ッシュになってもがくOSXユーザが湧いてでてくると。

636:デフォルトの名無しさん
04/05/07 09:14
>>632
Mac OS Xだと、Shift JISのprogramを、
UTF-8で保存して、REVERSE SOLIDUS(0x5c)のつもりが、
YEN SIGN(0xa5)になって悩んでいる学生さんが、
既にいらっしゃいますよ。

Terminal.appで、YEN SIGNが出力されていても、(\nとか)
教科書にYEN SIGN書いてあんだもん、初級の人はわけが分からないよね。

637:デフォルトの名無しさん
04/05/07 09:48
Safariの ~ が～になっちゃうよ問題とか。

638:デフォルトの名無しさん
04/05/07 09:53
「どっちが来てもいいように」対応するというのも
そんな簡単じゃない。
たとえばPARALLEL TOとDOUBLE VERTICAL LINEしか違わない
名前のファイルが同じディレクトリにあると、どちらか片方しか
開けないとかどっちが開かれるかわからないとか、
どっちが作成されるか分からないとか。
そもそも両者を同一視したいというのは日本だけの都合であって、
たとえばGBKには両方とも存在するから勝手に同一視されたら
多分困る。

639:デフォルトの名無しさん
04/05/07 12:57
<item1 name="セーター" price="\500" image="c:\image\item1.jpg">
みたいなのをきちんと utf-8 にする処理は多言語対応では難しいよね・・・

640:デフォルトの名無しさん
04/05/07 13:15
>>639
> <item1 name="セーター" price="\500" image="c:\image\item1.jpg">

と記述するcoding systemがyenとbackslashを区別できていれば問題ないし、
区別できていないのなら、それはコード変換とは別ドメインの問題だろ。

641:デフォルトの名無しさん
04/05/07 13:24
見た感じXMLっぽいがそれなら
price="¥500"
と書くことで曖昧さがなくなる

642:デフォルトの名無しさん
04/05/07 13:33
>>640
Shift_JISは問題ないの?

643:デフォルトの名無しさん
04/05/07 16:13
>>641
xml 的には後半の \ は ¥ にするや否や、というような話。スレ違いだけど。

>>640
元のコードが Shift_JIS の場合、どんな風に変換されるべき？

644:デフォルトの名無しさん
04/05/07 16:56
>>643
後半はしたら駄目に決まってる

645:デフォルトの名無しさん
04/05/08 04:06
ところがShift JISで書いた場合は、両方でOKなわけだ。

646:デフォルトの名無しさん
04/05/08 04:07
両方HALFWIDTH YEN SIGNでOKなわけだ。

647:デフォルトの名無しさん
04/05/08 09:10
>>645
意味がわからん
「両方」って何と何のことで何が「OK」なの?
>>646
HALFWIDTH YEN SIGNなんてものはない
ただのYEN SIGNならある

648:デフォルトの名無しさん
04/05/09 05:04
LightConeは?

649:デフォルトの名無しさん
04/05/09 20:00
>>648
LightCone乙

650:デフォルトの名無しさん
04/05/18 10:46
書き込みがないな。
またLightConeが来てくれないかな。

651:デフォルトの名無しさん
04/05/18 18:31
iso-8859-22って、いわゆるなに？

iso-8859-1って、いわゆるLatin1でいいの？

652:デフォルトの名無しさん
04/05/19 02:37
8859-22 なんてあったのか？
16までなら聞いたことがあるが。

653:デフォルトの名無しさん
04/05/20 19:14
EZ端末からPOST形式でフォームをサブミットすると
x-up-destcharset=17
というのが勝手に送られるのですが、
これって何のためのものでしょうか？

654:デフォルトの名無しさん
04/05/20 19:20
で、それがなんの関係があると？

655:デフォルトの名無しさん
04/05/20 19:23
>>654
誤爆?

656:デフォルトの名無しさん
04/05/20 19:24
>>655
残念。ちゃんとした回答。

657:デフォルトの名無しさん
04/05/20 19:48
>>656
>>653への回答か? スレ違いだと言いたいのか?

658:デフォルトの名無しさん
04/05/21 18:41
>>220 さんのページってどこですか？

659:デフォルトの名無しさん
04/05/21 18:58
EUC補助漢字の判定でぐぐってみたらわかりました。
使える文字コード判定ってあんまり情報ないので助かります

660:デフォルトの名無しさん
04/05/22 01:41
>>399

UCS4で正規化すりゃ万事解決。

32ビットコードはMuleとかで先例もあるし。

661:デフォルトの名無しさん
04/05/22 02:12
wcschrでヒットしたその位置は何文字目? という問いに
簡単に答えられない点が問題。X0208の範囲に限定するなら
そうでもないがそれならそもそも4バイトもいらん
正規化がUnicode Normalizationのことを指してるなら
UTF-8の文字数を先頭から数えても大して変わらんような…

662:デフォルトの名無しさん
04/05/22 09:25
>>660
遅レス乙!

663:デフォルトの名無しさん
04/05/22 21:37
>>660
コードポイントと文字は１対１対応ではない。
NFCで正規化しても複数コードポイントの組合せで
１文字を表すケースはいくらでもある。

664:デフォルトの名無しさん
04/05/22 22:37
たしかに↓とか読んでると気が遠くなってくるな。
URLﾘﾝｸ(www.horagai.com)

アラビア語や上の例みたいに文字を分かち書きしない言語では
「一文字」っていう単位がそもそもそれほど明確じゃないのかも。

日本語は「単語」を分かち書きしないけど
時枝文法とか文法のとらえ方次第で「単語」も変わるしそもそも
日本人は単語の区切りなんてふだん意識してないみたいな感じか。
（助詞とか）

素人なので間抜けな事いってるかも知れないが。

665:デフォルトの名無しさん
04/05/22 23:31
>>663
というかそれはまさに>>399で言ってることそのものなわけで
文盲にマジレスしても無駄かと

666:デフォルトの名無しさん
04/05/24 02:59
ｐｃ関係詳しい方！
ぜひこの暗号解けないものでしょうか！？

325argf493rdtr521styh075artg625agfa113ller041fsre.2122ffj7343qer7813fda

667:デフォルトの名無しさん
04/05/24 08:55
それをこのスレにもってくる神経を疑う

668:デフォルトの名無しさん
04/05/24 09:33
>>667
その謎を解くのだ。

669:デフォルトの名無しさん
04/05/24 10:45
>>666
↓↓US-ASCII復号による解読結果です↓↓
325argf493rdtr521styh075artg625agfa113ller041fsre.2122ffj7343qer7813fda

670:デフォルトの名無しさん
04/06/04 22:06
325|argf
493|rdtr
521|styh
075|artg
625|agfa
113|ller
041|fsre
.
2122|ffj
7343|qer
7813|fda

671:デフォルトの名無しさん
04/06/07 11:25
BASE64?

672:デフォルトの名無しさん
04/06/09 06:26
英大文字をまったく含まないというのは
BASE64にしては不自然すぎるな

673:デフォルトの名無しさん
04/07/06 12:32
JISを元にした文字コードとunicodeとの変換表が複数ある状況は
なんとかならんのかね。それが正しかろうがなんだろうがとにかく
統一されてさえいれば楽に使えるのに、バラバラだからいらぬ変換
の手間がかかってわけわからん状況に。勘弁してくれよう。

674:デフォルトの名無しさん
04/07/06 13:31
なんともならんでしょうね。

675:デフォルトの名無しさん
04/07/08 04:21
JISは対応が存在するだけまだマシなほうですよ
Big5やKPS9566なんてそもそも変換できない場合があるし

676:デフォルトの名無しさん
04/07/08 11:52
まあ、応用によって変換表が違うのは当然って文字の組み合わせもあるでしょう。
*→＊,×, ※など。あまりいい例じゃないからもっといいのきぼん↓

677:デフォルトの名無しさん
04/07/08 16:43
printf("値段は \\%dです\n", Nedan);
\\は¥(¥)1文字に変換されるのが理想だし、\nはバックスラッシュとnに変換してくれないと困るし。

678:デフォルトの名無しさん
04/07/08 16:49
もう、面倒だから\記号使うのやめよう。
printf("値段は %d円です\n", Nedan);
で良いじゃないか。

ごたごたに巻き込まれたくないPGより。

679:デフォルトの名無しさん
04/07/08 21:18
￥でいいよ

680:デフォルトの名無しさん
04/07/28 08:02
age

681:デフォルトの名無しさん
04/07/28 08:33
>>679
I/Oライブラリに勝手に\に変換されたり…
最近2chでも~→～があるみたいだし。

682:デフォルトの名無しさん
04/07/28 09:10
文字のことは中国人に任せときゃいいんだよ
漢字のほんの一部を借りて使ってるだけの日本人なんかに何が出来るんだ

683:デフォルトの名無しさん
04/07/28 13:46
>>682
マッカーサーに従って、日本語で文章を書くのを止める、とか？

684:デフォルトの名無しさん
04/07/28 22:02
>>682
アルファベットも中国人任せか?

685:デフォルトの名無しさん
04/07/28 22:38
>>681
~→～はSafariの悪戯だろ

686:デフォルトの名無しさん
04/10/02 21:36:08
SJIS、EUC、JIS、UTF-8を判別するアルゴリズムを紹介しているページってどっかある？
URLﾘﾝｸ(kasumi.sakura.ne.jp)
を参考にしているんだけどイマイチはっきりしないところがあるので…

687:デフォルトの名無しさん
04/10/03 00:31:32
イマイチはっきりしないところを書いてくれないとはっきりしない。

688:デフォルトの名無しさん
04/10/04 04:34:15
age

689:デフォルトの名無しさん
04/10/04 13:53:50
ｸﾞｸﾞﾙさんのキャッシュは日本語サイトの \ を＼にするから激しく困る(`Д´)

ｸﾞｸﾞﾙさんのﾃﾞｶﾁﾝｺ！ヽ(｀Д´)ノ世界最早男！

690:686
04/10/05 02:18:46
遅レスｽﾏｿ
>>687
具体的には判定箇所が具体的に書かれていないところ

例：
> 0x80 <-> 0xA0であるならばSJIS
　SJISと言うことは第1バイトか？
> 0xA1 <-> 0xDFが出た場合はSJIS半角カナ・EUC全角かな・カナの強い可能性
　これも第1バイト？
> 0xA1 <-> 0xFEの場合はEUCの強い可能性で0xFD・0xFEの場合はEUC(確定)
　第1バイトと第2バイトの両方？

691:デフォルトの名無しさん
04/10/05 02:22:48
文字コード判別・変換クラスてのがあるけど
URLﾘﾝｸ(kasumi.sakura.ne.jp)

692:デフォルトの名無しさん
04/10/05 08:14:19
>>689
これいいなあ。でもどうせなら＼ではなく、逆に全角(じゃなくてU+00A5でもい
いが)の￥にするのが正しいと思う……それはさておき。

日本語圏、とりわけShift_JIS(とMSKK的Unicode)では
\ (0x5c) が文字として意味をなさない
(コードポイントとしての機能しかない) から、仕方ないとも言えるんだよ。
Shift_JISでは0x5cはYEN SIGNという定義なんだけど、実際の使われ方は
REVERSE SOLIDUS (ASCIIでの0x5c)でもあるという状態なんだから。

EUC-JPはShift_JISと違って0x5cがREVERSE SOLIDUSなんで、EUC-JPなページの
キャッシュでは0x5cは0x5cのままになってるよ。

ああなった理由を考察すると、クロールしたデータをキャッシュとして保存する
ときはUTF-8に変換するが0x5cは0x5cのまま通してしまった。一方、キャッシュ
を出力するときはShift_JISに変換するのだが、このときShift_JISでは0x5cが
YEN SIGNであってREVERSE SOLIDUSではないので、0x5c(REVERSE SOLIDUS)は仕方
ないから＼になる、ということではないかな。

不整合に見えるけど、単に時間差があるだけでしばらく待ってると保存時にも変
換されたものでデータが入れ替わって揃うのかも。それでもページが更新されな
いとキャッシュデータが書き換わらない可能性はあるが。

693:デフォルトの名無しさん
04/10/05 08:50:29
Perl6だとYEN SIGN(U+00A5)に演算子として意味を割り当てるので、
扱いとしては完全にREVERSE SOLIDUSと別にせざるを得ないらしいじゃん。
日本語Windowsユーザはどうするのか。
本当はUnicodeに移行してればこんなことで悩まなくなってるはずなんだが、
問題解決に絞るべき知恵のなかったMSKKが
「0x5cは見掛けYEN SIGN、意味は場合によって世界標準Unicodeにおける
U+005C(REVERSE SOLIDUS)かYEN SIGN」
なんつー考えナシUnicodeを始めてしまったもんだから、
21世紀になっても悩みがつきないわけだなあこれが。

694:デフォルトの名無しさん
04/10/05 13:11:27
そこでUnicodeの再設計ですよ

695:デフォルトの名無しさん
04/10/05 13:30:33
>>693
MS の CP932 では EUC-JP と同様に 0x5C は Unicode の \u005C にマッピングされてるわけで、
MS 的には CP932 <-> Unicode の相互変換で違う文字になるなんてことは無いはず。
Shift_JIS なんてやめて、CP932 に移行すべき。

しかしC# の XMLWriter で CP932 で書き出すと、encoding="Shift_JIS" になる orz...

696:デフォルトの名無しさん
04/10/05 14:26:23
0x5cは、全員バックスラッシュにすれば済む話じゃん。
￥マークは全角で使用して、半角の￥は存在しないと思えば良い。
それよりも、日本語Windowsで0x5cをバックスラッシュで表示してくれないのが困る。

697:デフォルトの名無しさん
04/10/05 14:58:38
勉強になりそうなので読んでいますが、
CP932? REVERSE SOLIDUS?…(´･ω･｀) もうついていけません…。

たとえばWindows環境では、フォントによって\がバックスラッシュで
表示されたり \のままだったりしますが、これというのはつまり
フォントごとに、その文字コードに対応する文字イメージが
異なっているというだけなんでしょうか。それともハードウェアの
レベルで何かが起こっているんでしょうか。

文字コードと、実際に画面に表示される文字イメージが
どこでどう関連づけられているのか、いまひとつ分かりません。

698:デフォルトの名無しさん
04/10/05 15:13:26
>>697
文字イメージが違うだけ。0x5cは0x5cのまま何も変わっていない。
フォントを書き換えれば、バックスラッシュにできるんだが、改造はしたくない。
マイクロソフトが強制的にバックスラッシュにしてくれればありがたいのだが。

699:デフォルトの名無しさん
04/10/05 15:45:15
>>697
Shift_JISの0x20～0x7FはASCIIに似てASCIIじゃない文字セット(JIS　X　0201)だというのが混乱の原因。
0xA5はASCIIではREVERSE　SOLIDUS(バックスラッシュ)なんだけど、JIS　X　0201ではYEN　SIGN。

で、「\」この文字をUnicodeに変換するとき、Shift_JISはYEN　SIGNに割り当てるのに、
cp932(Shift_JISをMSが拡張したもの)ではREVERSE　SOLIDUSに割り当てる。

MS的には、Unicodeに変換したときにパス区切り文字が使えなくなると困るから
こうせざるを得なかったようだ。JIS　X　0201がASCIIから変更した箇所と、
MSがパス区切り文字に使っていた文字が重なってしまった不幸な偶然を恨むしかない。

700:デフォルトの名無しさん
04/10/05 16:20:55
まあそれでも「～」あたりの混乱よりはマシだな。

701:697
04/10/05 16:31:42
>>698-699
なるほど、だんだん分かってきました。
もう少し分からないんですが、たとえばマルチバイトモードから
Unicodeモードに切り替えてコンパイル・実行したとすると、
文字コード自体は変わってしまっても見た目は(概ね?)同じ
ですよね。
同じフォントから同じ文字イメージを取り出すには、この
文字コードの違いを吸収する仕組みが必要だと思うのですが、
どのようになっているのでしょうか。

文字セットごとに「文字イメージ位置検索テーブル」のような
ものが用意されていて、文字コードからフォント内の文字イメージ
位置を検索できるようになっているのではと想像してみたのですが
実際のところはどうなっているのでしょうか。

702:デフォルトの名無しさん
04/10/05 16:39:23
>>701
最近のGUIベースのOSだと、フォントセットは大抵 Unicode でのコードポイントにたいして
タイプフェイスが割り当てられています。そうして文字コードから Unicode のコードポイントに
変換する仕組みも別途存在します。「どのようになっている」かは、OSやウィンドウシステムに
よって異なります。

703:697
04/10/05 17:02:28
>>702
なるほど、フォント内の文字の並びが何に従っているのか次に
質問しようと思っていたところなんですが、Unicode に合わせて
あるんですね。その上で、文字コードをUnicode の文字コードに
変換する仕組みが備わっている(仕組みは環境ごとに異なる)という
ことなんですね。納得致しました。
ご回答ありがとうございました。

704:デフォルトの名無しさん
04/10/05 18:05:15
>>703
欧文フォントなんかだと、Unicode ではなく ISO 8859-1 (Latin-1) で入ってたりするものもある。

705:686
04/10/05 23:45:34
>>691
できました。thx
サンプルコードあったのか…気が付かなかった…il||li ○|￣|＿

706:デフォルトの名無しさん
04/10/06 01:12:14
>>697
URLﾘﾝｸ(euc.jp)読めばあ?

707:697
04/10/06 17:50:44
>>704
Unicode とは並び方の異なるものもあるんですね。そのような
フォントの場合はどう扱っているのでしょう。Unicode のコード
ポイントに変換する方法では上手くいきませんよね…。使用する
フォントがどんな文字セットのコードポイントに一致しているか
という情報も、どこからか取り出しているのでしょうか。

>>706
ありがとうございます。
記号の読み方などバッチリ出てますね^^;
内容的にはまだよく分からない部分もありますが、
とりあえず最後まで読みすすめてみようと思います。

708:706
04/10/06 22:47:40
>>707
そんな難しいことは書いてないです。
良く書けているページなので何回も読んでみてください。
先入観を取り払えば、理解できるはずです。

ちなみに>>698は間違っているのでスルーしてください。
文字実体、グリフという概念を理解してない。

709:デフォルトの名無しさん
04/10/08 11:07:24
JIS X201はもはや業界のお荷物でしかない

710:デフォルトの名無しさん
04/10/08 11:45:03
和文フォントはWinの文字コード表でみると円記号の上に
ツールチップで"REVERSE SOLIDUS"と出るのが激しく間抜けだ。

せめてREVERSE SOLIDUSのグリフをどこかに突っ込んでおいてくれよう。

711:デフォルトの名無しさん
04/10/08 12:17:57
JIS　X　0208的には1区32点(＼)がREVERSE　SOLIDUSなんだけど、またもやMSが(略

712:デフォルトの名無しさん
04/10/08 12:32:42
>>711
Microsoft のは CodePage 932 っていう、彼らの定義したコーディングシステムなわけで、
文句言うのはよいけど「JISと違うやん」ってのは文句にすらなってないような･･･

日本のコンピュータ言語関連の書籍でも、ソースコードのREVERSE SOLIDUSを \ で
印字してるものが結構あるよね。あれってどういう習慣から来ているんだろう・・・

713:デフォルトの名無しさん
04/10/08 13:21:16
PC-9801

714:デフォルトの名無しさん
04/10/08 15:04:37
>>712
X0201の影響じゃ？てかISO/IEC646だかであのあたりは国毎に勝手にしる！ってのが未だに尾を引いてるだけかと。

715:デフォルトの名無しさん
04/10/09 14:58:11
>>712
> 日本のコンピュータ言語関連の書籍でも、ソースコードのREVERSE SOLIDUSを \ で
> 印字してるものが結構あるよね。あれってどういう習慣から来ているんだろう・・・

凄い文章だな。

716:デフォルトの名無しさん
04/10/12 18:04:57
>>712
でもさー、JISとCP932って相互変換できるのに、対応する文字が
それぞれ別のunicodeへマッピングされるのってすごい使いにくい
んだよね。なんとかしてくれよ...

717:デフォルトの名無しさん
04/10/12 19:26:18
>>712
そう思うんならMS明朝の0x5cのグリフが円記号なのは納得いかん。

718:デフォルトの名無しさん
04/10/14 00:32:17
ISO-2022-JPとEUC-jpとShift JIS(JISに載ってるやつ)とCP932は含む文字の集合が違うのに、
たいていの人はそれらの間で1対1の変換が出来ると思っている。
また、文字コード変換{ライブラリ, プログラム}もそうであるように見せかけている。この辺が混乱の元だろう。
「危ない文字(コード)は使わない」ということをリテラシーとして教えるべきだ。

719:デフォルトの名無しさん
04/10/14 02:48:47
「危ない文字(コード)は使わない」ってことなら
危ない文字(コード)を表にでもして教えてよ。（出来れば理由も）
あとお勧めの変換ソフトがあるなら教えて！

720:デフォルトの名無しさん
04/10/14 02:56:32
その環境で、何の文字コードを使うかは何処で決定されるのでしょうか？
windos環境とunix環境のそれぞれの決定のされかたを簡単でいいんで教えてください。

721:デフォルトの名無しさん
04/10/14 02:57:41
man locale

722:デフォルトの名無しさん
04/10/14 04:28:43
>>719
論外:
・いわゆる環境依存文字(丸付き数字など)
・JIS X 0201 片仮名(いわゆる半角カタカナ)
・CP932でJIS X 0201のRVERSE SOLIDUSを円記号として扱う

避けた方が無難:
・JIS X 0208でASCIIと同じ名前のもの(いわゆる全角英数記号類。疑問符とか)
・和字間隔(いわゆる全角スペース)
・JIS X 0208のYEN SIGN(漢字の「円」を使う)

723:デフォルトの名無しさん
04/10/14 11:24:06
>>722
しかしunicodeはさむと従来は何の問題もなく同じだった「～」なんかも
違う文字になっちゃうからな～。

724:デフォルトの名無しさん
04/10/15 03:39:30
ちょっと話題からずれてしまうかもしれませんが
teknap URLﾘﾝｸ(masternap.org) で
UTF-8 のファイル名を Shift-JIS に変換して共有したいのですが
ソースコードへのパッチの当て方が分かるかたいませんか。

725:デフォルトの名無しさん
04/10/16 15:00:13
age

726:デフォルトの名無しさん
04/10/17 03:19:24
age

727:デフォルトの名無しさん
04/10/18 20:31:59
関係ないけど、WindowsがJIS X 2013:2004に完全対応すると言われている2006年以降に
JIS X 2013:2004に完全対応したISO-2022-JP-3
（あるいは、ISO-2022-JP-3-StrictやISO-2022-JP-3-Compatible）って
メールの文字コードの主流になるのでしょうか？

一足飛びにUTF-7に移行するような気もしないでもないのですが、
メールソフトが間違えて（あるいは対応していなくて）ISO-2022-JPでデコードしてしまうと
ひどいことになってしまうのですが…

P.S.
>>722によると、この文章で使っている、いわゆる全角丸括弧や全角疑問符も
いけないことになってしまいますね。
いわゆる半角丸括弧や半角疑問符は幅が詰まりすぎているから使いたくないんですけどね。

728:デフォルトの名無しさん
04/10/18 20:57:15
何度も書くようだけど、このままWindowsにJIS X 0213:2004が採用されたら、
辻さんや樋口さんや榊原さんの大半が困ってしまう事態が起きるということは
もっと世間に認知されていてもよいと思うんですけどね。

「字体が変わる」のは防げないにしても（防げるに越したことはないが）、
「以前の字体が（事実上）出せない」のは固有名詞にも配慮していないので、
固有名詞にも対応すべきである工業規格としてまずいと思います。（※1）

（※1）この点で、「現に地名・人名などの固有名詞に用いられている字体にまで
及ぶものでもない」としている表外漢字字体表とは軌を異にします。
なお、表外漢字字体表では「現に」と表記しているとおり、表外漢字字体表発表以降の
地名・人名は表外漢字字体表に従うことを要望している（そして、実際に表外漢字字体表に
沿う形で人名用漢字が追加された）のですが、なんと市町村合併で最近誕生した
「葛城市」（奈良県）と「薩摩川内市」（鹿児島県）はそれに従っていません
（官報に記載された「葛」と「薩」の字体が、表外漢字字体表の印刷標準字体と異なっている）。

幸い、1面1区から1面13区までの間に40字弱の保留領域（ただし非漢字領域ですが）が
ありますので、ここに「互換用漢字」としてJIS X 0208:1997の例示字体どおりの
「辻」「樋」「榊」などを追加するのもよいでしょう。あと、「葛」「薩」もですね。
できればJIS X 0208:1997の例示字体ではなく、JIS X 0213:2004で変更されたほうの字体
（つまり、表外漢字字体表の印刷標準字体）のほうを「互換用漢字」にしたいのですが、
再々変更は避けたいので、いかんともしがたいところです。

729:デフォルトの名無しさん
04/10/18 21:12:49
>>727
詰まりすぎでないフォントを使えばいいのでは?

730:デフォルトの名無しさん
04/10/18 23:15:56
もうリッチな環境なんだからUTF-32で
CJKとか使えなすぎ

731:デフォルトの名無しさん
04/10/19 00:01:36
>>727
> 一足飛びにUTF-7に移行するような気もしないでもないのですが、
ぷっ
+MHcwYw-

732:デフォルトの名無しさん
04/10/19 00:36:12
>>694
そんなことしたら新旧混在して混乱に拍車を掛けますがな

733:デフォルトの名無しさん
04/10/19 00:42:00
>・CP932でJIS X 0201のRVERSE SOLIDUSを円記号として扱う
えーとすみません
煽りじゃ無しにこの一文の意味が本気で分かりません

734:デフォルトの名無しさん
04/10/19 04:01:43
>>727
確か UTF-7 は過渡期の産物で、MIME を併用した UTF-8 が本命じゃなかったけ？

735:デフォルトの名無しさん
04/10/19 07:52:39
主にメールのために考えられたはずだけど、
現実的にはUTF-8 + base64が多いな。無用の長物だな。

736:デフォルトの名無しさん
04/10/19 08:15:06
>>712
JIS C (JIS X 3010)に円記号を使っていいと書いてる

737:デフォルトの名無しさん
04/10/19 09:49:47
>>728
ケチケチせずに半角カナの領域削ればいい。
どうせWindowsは採用する気ないんだから
ISO/IEC 10646への追加要求のソースになってくれさえすれば
誰も実装しなくても問題はない

738:デフォルトの名無しさん
04/10/19 19:23:16
>>727
> 1段落目
なりません。

> P.S.
これについては >>729 の人が書いている通り。

>>733
値段をあらわすのに使うと、ひどい目に遭うかもしれないよということです。

739:デフォルトの名無しさん
04/10/19 19:44:51
そもそもJIS X 2013:2004に完全対応なら符号化表現の名称は
ISO-2022-JP-2004でなくてはならんし。
これはIANAに登録されていないのでメールで使ってはならない。

740:デフォルトの名無しさん
04/10/19 19:45:32
コピペしたら間違いまでコピペしてしまったorz
JIS X 0213:2004ね

741:デフォルトの名無しさん
04/10/19 23:54:35
>>722
>・CP932でJIS X 0201のRVERSE SOLIDUSを円記号として扱う
>>733
> えーとすみません
> 煽りじゃ無しにこの一文の意味が本気で分かりません
>>738
> 値段をあらわすのに使うと、ひどい目に遭うかもしれないよということです。

「JIS X 0201のREVERSE SOLIDUS」？？？
「CP932で(略)REVERSE SOLIDUS」？？？

742:デフォルトの名無しさん
04/10/20 01:48:46
>>741
後者。

743:デフォルトの名無しさん
04/10/20 10:03:35
・CP932で0x5cを円記号として扱う

って事ですか?

744:デフォルトの名無しさん
04/10/20 14:36:42
>>743
そうです。

745:デフォルトの名無しさん
04/10/22 03:57:53
> 値段をあらわすのに使うと、ひどい目に遭うかもしれないよということです。
ひどい目にあったところが実際にあるんでしょうか？
国内のインターネット通販やってる所って遭遇する可能性が．．．

746:デフォルトの名無しさん
04/10/22 09:57:55
Googleの検索結果上ではよく文字化けしてる

747:デフォルトの名無しさん
04/10/22 11:53:40
>>745
「ウリの環境だとウォンと書いてるニダ、それ以上は払わないニダ」

748:デフォルトの名無しさん
04/10/22 13:21:17
韓国語版WindowsのU+005CにはWON SIGNのグリフが入ってるから
円記号問題と似たようなことが起こるらしいな

749:デフォルトの名無しさん
04/10/22 13:40:26
>>747
日本側が中小だと実際にそれでごねて契約の十分の一しか支払われなかった
ケースもあるらしい。

750:デフォルトの名無しさん
04/10/22 16:05:33
>>749
嘘つきは泥棒の始まりか

751:デフォルトの名無しさん
04/10/25 17:55:53
>>728
「市町村合併字体」とかでぐぐると分かるけど
>当用漢字表以外の漢字についても、当用漢字字体表の字体に準じた
>字体を用いてもよい。
みたいですね。この時点ですでに表外漢字字体表とは
食い違っているという…

752:デフォルトの名無しさん
04/10/25 18:42:21
>>751
字体表は答申どまりで内閣告示にならなかったからな。
朝日新聞とかにも無視されてるし（内閣告示だったら無視できなかったはず）。
字体表を尊重しているのなんて、
国語審議会のメンバーを送り込まれたJIS X 0213:2004だけじゃねえか。

753:デフォルトの名無しさん
04/10/25 19:15:06
人名用漢字部会も。
「芦」はなぜか簡易慣用字体のほうが採用されたけど。

754:デフォルトの名無しさん
04/10/28 06:53:30
ひょろっと書いた自作のユニコードライブラリを
鬼門・合成に対応させようか迷っとります。
コンパクトな構造が崩れる悪寒。そこまでサポートする意味あるのか…。

欧米人の心境が１㍉㍑くらいわかったような気分す。

755:デフォルトの名無しさん
04/10/28 12:29:56
>>754
ISO 10646-1は全てのシステムが合字処理を実装することを要求
していないよ。実装レベル分けされていて、合字のない実装は
Level-1に分類される。

756:デフォルトの名無しさん
04/11/10 22:17:25
ここで質問して良いのか分かりませんが、
Unicodeでのエスケープシーケンス一覧はどこかにありますか？

次ページ