[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 05/09 21:44 / Filesize : 262 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



1 名前:デフォルトの名無しさん [03/09/10 16:04]
文字コード変換について語りましょう♪

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

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

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

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

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

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

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

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

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

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

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



605 名前:デフォルトの名無しさん [04/03/20 22:01]
www.vector.co.jp/soft/win95/util/se314832.html
これを元に、なんとかできないかな

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

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

608 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [04/03/24 00:52]
↑のX0202はX0201のことな

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

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

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

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

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



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

>>613
そのつもり。


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

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

618 名前:デフォルトの名無しさん mailto:sage [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を自動識別できるから(w
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 名前:デフォルトの名無しさん mailto:sage [04/05/05 20:14]
>>620
Byte Order Mark の何たるかをご存知でない
お間抜けちゃんがこの業界を仕切っているからでぬるぽ。

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

624 名前:デフォルトの名無しさん mailto:sage [04/05/06 07:38]
~→〜のこと?



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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

636 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [04/05/07 09:48]
Safariの ~ が 〜 になっちゃうよ問題とか。

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

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


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

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

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

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

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

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

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



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

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

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

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

649 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [04/05/19 02:37]
8859-22 なんてあったのか?
16までなら聞いたことがあるが。


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

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



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

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

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

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

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

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

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

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


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

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

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

664 名前:デフォルトの名無しさん mailto:sage [04/05/22 22:37]
たしかに↓とか読んでると気が遠くなってくるな。
www.horagai.com/www/moji/devnag.htm

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

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

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



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

666 名前:デフォルトの名無しさん mailto:sage [04/05/24 02:59]
pc関係詳しい方!
ぜひこの暗号解けないものでしょうか!?

325argf493rdtr521styh075artg625agfa113ller041fsre.2122ffj7343qer7813fda

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

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

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


670 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [04/06/07 11:25]
BASE64?

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

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


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



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

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

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

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

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

679 名前:デフォルトの名無しさん mailto:sage [04/07/08 21:18]
¥ でいいよ

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

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

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

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


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



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


686 名前:デフォルトの名無しさん mailto:sage [04/10/02 21:36:08]
SJIS、EUC、JIS、UTF-8を判別するアルゴリズムを紹介しているページってどっかある?
ttp://kasumi.sakura.ne.jp/~gm/gpj/dev/tips/other/kanji.shtml
を参考にしているんだけどイマイチはっきりしないところがあるので…

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

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

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

ググルさんのデカチンコ!ヽ(`Д´)ノ世界最早男!

690 名前:686 mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [04/10/05 02:22:48]
文字コード判別・変換クラスてのがあるけど
ttp://kasumi.sakura.ne.jp/~gm/gpj/dev/tips/net/txtenc.shtml

692 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [04/10/05 13:11:27]
そこでUnicodeの再設計ですよ



695 名前:デフォルトの名無しさん mailto:sage [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をバックスラッシュで表示してくれないのが困る。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<262KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef