約 1,716 件
https://w.atwiki.jp/kemonotani/pages/28.html
夏草、夢の跡 奥平の駅にある、枕木を数本束ねてレールの上に置いただけの粗末な車止め、その先にもしばらくレールは続いている。 放棄されて幾星霜、枕木はとうに朽ち果て土に還り、赤茶けた錆に覆われた二条のレールだけが、森の中を延びてゆく。 この鉄道が出来た頃は、鉄道を谷のさらに奥地へ向けて敷く計画があったと聞く。 鉄路の目指す先が鉱山なのか原生林なのか、はたまた山を越えて村や町を繋ぐ筈だったのか。 また、その計画がなぜ日の目を見なかったのか、今となってはそれすらもわからない。 ただただ、草叢に覆われ、森に呑まれゆく線路が、忘却の彼方に置き去りにされた計画の存在を語り継いでいく。
https://w.atwiki.jp/remote/pages/37.html
NTT西日本光プレミアム地域IPv6網の全体構成 PC-PJR(v6) ファミリー マンション 網 速度 名称 補足 PC PC V4 100M | | CTU CTU 加入者網終端装置 v6を利用する網終端装置へのIPsecトンネル生成実装 | | IP-SECによるトンネリングでのIPv6網通信 1G GE-ONU VDSLモデム VDSL(MDU) | | SP4分岐 GE-ONU SP8分岐 | GE-PON-OLT GE-PON-OLT | | SMD(K) SMD(M) | | SAR 10G 収容ビル装置 | AJR 収容ルータ | | PAR PAR | | PJR(v6) PJR(v6) PJR(v6)-ISP 網 速度 名称 補足 PJR(v6) PJR(v6) IP-SECによるトンネリングでのIPv6網通信 | | IAR(I) 収容ビル装置 | IGR(igra) V4網 網終端装置(v6) | AHU | ISP PJR(v6)-フレッツスクエア 網 速度 名称 補足 PJR(v6) PJR(v6) IP-SECによるトンネリングでのIPv6網通信 | | BJR(v6)大阪北 - BJR(v6)東淀川 | | 広域IAR(S) 収容ビル装置 | スクエア用IGR(igrb) V4網 網終端装置(v6) | スクエアサーバ群(V4)S-SW-D PJR(v6)-速度測定サイト 網 速度 名称 補足 PJR(v6) PJR(v6) IP-SECによるトンネリングでのIPv6網通信 | | IAR(I) 収容ビル装置 | 速度測定用IGR(igrc) V4網 網終端装置(v6) | 速度測定サーバ(bmsa) V6コンテンツ ファミリー マンション 網 速度 名称 補足 STBなど STBなど ピュアIPv6網通信 100M CTU CTU 加入者網終端装置 v6を利用する網終端装置へのIPsecトンネル生成実装 | | 1G GE-ONU VDSLモデム VDSL(MDU) | | SP4分岐 GE-ONU SP8分岐 | GE-PON-OLT GE-PON-OLT | | SMD(K) SMD(M) GE-PON-OLT GE-PON-OLT SAR 10G 収容ビル装置 | AJR 収容ルータ | | PAR PAR | | PJR(v6) PJR(v6) BJR(v6)大阪北 - BJR(v6)東淀川 | | 広域IAR(S) | | | | | V4-V6トランスレータ V6キャスト SFC V6ステージ V6マイディスク セキュリティ対策ツール
https://w.atwiki.jp/isoroku_be/pages/143.html
情報 作者名：五十六 引用元：なし 概要 フォルダ名を抽出します。 解説 引数 S：フォルダorファイルの絶対パス(フォルダの絶対パスの場合は\を付加しておくこと) 返り値 フォルダ名 サンプルプログラム 「C \aaa\bbb\ccc\」のフォルダ名抽出して言う。 //本体 ●フォルダ名抽出(Sから|Sの|Sを) S=Sのパス抽出。S=Sの終端パス追加。A=Sの一階層上。S=Sの終端パス削除。S=SのAを空に単置換。Sで戻る。 ●一階層上(Sの|Sを|Sから) S=「..\」をSで相対パス展開。S=Sの終端パス追加。戻る。 名前 コメント
https://w.atwiki.jp/wabu/pages/51.html
『鉄道』は平井喜久松さんの著書で，岩波書店から1936年（昭和11年)に第1刷が，1949年（昭和24年）に第7刷が発行されました。 このページには「第二編 停車場 第三章 旅客停車場」を収録。 目次 第二編 停車場 (p. 111) 第三章 旅客停車場 (p. 144) §1. 総説 (p. 144) §2. 旅客停車場の作業 (p. 144) §3. 中間旅客停車場 (p. 149) §4. 連絡旅客停車場 (p. 151) §5. 交叉旅客停車場 (p. 153) §6. 接触旅客停車場 (p. 155) §7. 旅客終端停車場 (p. 155)1. 配線 (p.156) 2. 本屋 (p. 158) 参考文献 関連ブログ コメント メール 第二編 停車場 (p. 111) 第三章 旅客停車場 (p. 144) §1. 総説 (p. 144) 普通運輸量があまり大きくない場合には旅客および貨物を同一駅で取扱うを常例とする。しかしながら大都市等で運輸量が多く双方を1箇所で扱うことが却(かえ)って相互の作業の障害となるような場合には貨物停車場と旅客停車場とを分離する方が得策である。また客車の収容線，貨車の入換線等の如き設備は広大なる地積を要する故，郊外の比較的地価の安い場所に設置した方が得策である場合もある。近来大都市附近にこの種の客車操車場，貨車操車場の設置せらるる所以(ゆえん)である(*1)。 東京駅，上野駅，大阪駅の如きは旅客停車場で，汐留駅，秋葉原駅，梅田駅の如きは貨車停車場である。また尾久（田端附近）宮原（大阪附近）は客車操車場で，新鶴見，品川，田端，吹田は貨車操車場である(*2)。 §2. 旅客停車場の作業 (p. 144) 旅客停車場（Passenger station, Personenbahnhof）の作業は列車の発著(*3)，旅客の乗降，手小荷物の取扱ならびに郵便物，新聞雑誌等の積卸等を行うものであって，これ等に必要なる設備即ち前章において述べたる本屋，ホーム等の諸設備は勿論，大停車場では電信，電話の設備，案内所，洗面所，売店，食堂等の営業も必要となる。なお以上のほか駅作業として関係事務室，構内列車取扱上の設備，通信関係設備等を必要とする。それ等の作業場所の配置は第135〜139図および第165〜168図の通りである(*4)。 §3. 中間旅客停車場 (p. 149) 中間駅における旅客扱設備としては出札室，手小荷物室，駅長室，待合室，改札口等が本の屋(*5)全部を占め（第135図参照），設計および作業は至極簡単である。なお旅客が列車に乗降するためにホームを必要とする(*6)。 中間駅のホーム形式には次の3種がある。 対向式ホーム（separate platform）を有するもの 島式ホーム（island platform）を有するもの 分離式ホーム：急行通過列車等と地方列車発著(*7)線と分離せるもの この内分離式は一方向に対してホーム2面を有し，前2者に較べ取扱量を異にする故，これを除き対向式，島式の2者につき優劣を比較して見ると第26表の如くである(*8)。 第26表 対向式 島式 用地ならびに建設費大 用地ならびに建設費小 線路は直線 線路に曲線が入る 運転上見透し良好 見透し不良 拡張容易 拡張困難 上下線同時発著の場合ホームが混雑せず 混雑す 本屋側の乗降客は線路を横断することなし 必ず線路を横断す 監視営業上不利 有利 列車回数多きとき不利 有利 即ち両者各利害得失あるのであるから中間旅客駅は乗降人員，列車回数等を考慮し，ホームの形式ならびに配線を決定すべきである。特に配線においては対向分岐器を可及的避くべきである(*9)。 本屋の位置 本屋の位置には次の4つの場合がある（第170図）。 主本屋を線路の側方で而(し)かも町側に置く。 出札所および手小荷物発送に必要なる建物を線路の側方に設け，更に待合室および従事員詰所は線路の間に独立建物とする。 本屋を線路の中間に設ける。 本屋を高架線路の下に設けるか，あるいは線路の上に跨って設ける。これは旅客の通路が短くてすむ利点がある。 一般に (1) および (4) を採用し，ホーム，道路，広場等の関係を考慮して定むべきである(*10)。 §4. 連絡旅客停車場 (p. 151) 2つ以上の線路が1箇所において連絡する場合の停車場を連絡停車場（junction station, Trennungsbahnhof）と言う。これの設計に当たり考慮すべき事柄は次の如くである。 主要運輸方向に連絡すべきでる。例えば第171図に示す如くS からW への旅客が多き場合は（a）図の如く連絡し，S からO への旅客が多い場合（b）図の如く接続する。 異った管理の鉄道の場合は停車場を互いに接近せしめ，できるならば完全なる連絡が望ましい，ただ本線の平面交差は絶対に避くべきである。 乗換旅客はできるだけホームを変更せず同一ホームで乗換できること。 各線各々到著(*11)線を有し，列車は連動装置により安全に同時進入をなし得ること（第172図）。 車輛の入換によって列車の進入出発を妨害せざること。 配線は線路別運転（第173図 a）または方向別運転（第173図 b）の何れかによることができるが，方向別運転を適当に用うることにより乗換を便にすることができる。 接続分岐器は到著(*12)列車が到著前に通らねばならないような位置に置く事を避けねばならぬ。また分岐器はできるだけ大なる半径を用うるべきである。一般に到著列車は直線で進入し，分岐で出発することとが望ましき事である。 第174図における新宿駅の如く方向変化のない乗換の場合方向別運転を適当とし，折返し乗換の場合（代々木駅の如く）は一般に中間ホームと外側ホームとを有する線路別運転が有利である。 幹線に支線が接続せる場合は一般に支線の旅客列車線は行止りとするか，幹線の第2本線に安全側線を附して結合する。 本屋の位置は線路の一方側に設けるのが合理的である。 なお詳細なる研究は Cauer Personenbahnhöfe, 2 Aufl(*13)。 §5. 交叉旅客停車場 (p. 153) 2つの鉄道が交差せる箇所に設ける連絡停車場を特に交差停車場（crossing station, Kreuzungsbahnhof）と言う。 例えば鹿児島本線と筑豊本線と交差せる折尾駅（第175図）および東京—上野間高架上を総武線が乗越せる秋葉原駅の如く純然たる交差停車場で立体交差であるときは flying junction とも言う。また山手線と中央線と交差せる代々木および新宿の両駅の如きも交差停車場の1種である（第174図参照）(*14)。 交差停車場においては一般に線路別運転より方向別運転の方が遥かに有利である。簡単な停車場で平面交差の場合は2つの進入列車の交差が省かれるから方向別運転が最も都合よき配線となる(*15)。 本屋は連絡停車場の場合と同様に一方側に設けるのが有利である。その他連絡停車場と同様の考慮を払うべきである(*16)。 §6. 接触旅客停車場 (p. 155) 接触旅客停車場（touch station, Berührungsbahnhof）は交差停車場と異なり2つの鉄道が相接近せる所に設ける停車場である(*17)。 接触停車場もまた連絡停車場と同様の原理が大切であり，旅客の流れ及び運転の状態を考慮し，相互間の乗換数夥(おびただ)しく運転回数頻繁なる時は立体交差による方向別を可とす。而(しか)して何れの場合にも2本の島式ホームによる配置を便とする（第178図）(*18)。 東海道本線と京浜電鉄線と接触せる横浜駅は接触停車場の一例である（第168図参照）(*19)。 §7. 旅客終端停車場 (p. 155) 旅客列車運転上終端駅に位する停車場を旅客終端停車場（passenger terminal station, Endbahnhof, Kopfbahnhof）と言う。旅客中間駅の設計は割合に簡単であるが終端駅は甚(はなは)だ複雑である。就中大都市における旅客運輸上の終端となるべき停車場附近は一種の都心の如き形態を備うるものであるから，単に停車場における列車取扱のみならず都心に似つかわしい各種の施設を設け，一般都市の交通を便にする用意を必要とする(*20)。 1. 配線 (p.156) 列車の終端となる場合の停車場形式は次の4つになる(*21)。 （a）頭端式の終端停車場（例：下関駅，門司駅，青森駅，第184図） （b）通過式の終端停車場（例：東京駅，大阪駅，第165図） （c）通過運輸のある頭端式停車場（例：今日はあまりなし。明治30年頃の横浜駅） （d）（a）と（b）と併用せる終端停車場（例：上野駅，第166図 両 図駅） （a）頭端式の終端停車場 頭端式の終端停車場は次の如き長所短所を有する。即ち運輸上からは列車の出入に交差を生じ，従って危険を伴い，また機関車の転向に困難を感ずる事等がその短所である。しかしながら一方長所としては見透し良好にして旅客が列車に近づくに地下道または跨線橋等を設くる事を要しない事である。この種の停車場としては門司，下関，青森，湊町等がこの適例である。頭端式停車場の配線は第179図の如きものがある。この図の（a）は極めて簡単なる場合。（b）は列車回数大なる場合。（c）は2つ以上の本線が頭端式停車場に線路別運転にて導かるる場合。（d）は方向別運転によって導かれる場合を示す。頭端式終端停車場においても連絡停車場の場合と同様に立体交差を行って方向別運転をなせば運転運輸上大なる利益がある(*22)。 （b）通過式の終端停車場 通過式の終端停車場は東京，大阪，神戸等がその例であって，中間停車場の配線と同様であるが，ただ急行列車，地方列車，始発列車，終著(*23)列車等種々の列車に備うるためホーム線を数多く要することが特異である（第165，167，180図）(*24)。 （c）通過運輸のある頭端式停車場 通過運輸のある頭端式停車場（頭端式の中間停車場）は極小部分の列車に対してのみ終端であり，他の大部分の列車に対しては中間停車場であるが，配線が通過式でなくて頭端式に接合せられたものであ(*25)。 列車回数の少ない場合は2本のホーム線を有する第181図の如き配線で充分であるが，頻繁なる場合はホーム線を増加する必要がある（第182図）。何れにしても渡り線の運転が頻繁で危険であるから平面交差を避け立体交差となすべきである。この際乗越の数を最小に制限することは勿論である(*26)。 （d）頭端式と通過式と併用せる終端停車場 頭端式と通過式と併用せる終端停車場の適例は上野および両国駅である（第166図および第183図参照）。即ち運転系統の一部分が終端をなせる停車場である(*27)。 終端線が通過線に対する位置および本屋の線路に対する位置等によって種々の配線が得られる(*28)。 この場合における長所および短所は（a）の場合と同様である(*29)。 2. 本屋 (p. 158) 大なる終端停車場としての本屋を設計するに当たり特に考慮すべき事項は次の如くである(*30)。 （a）乗車客と降車客との出入口を別にすること。 （b）乗車口と降車口との距離あまり遠からざること。 （c）乗車客と降車客に次ぎ急行列車客と地方列車客とを区別すること。 （d）本屋内の見透しを良くすること。 （e）なるべく階段を避けること。 （f）採光および換気法に注意すること。 本屋の位置 本屋の位置は頭端式の場合は線路の方向に直角に設けるのが普通であるが，他の場合は中間停車場と同一の考慮を払うべきである。本屋における作業場所の配置は第138，139，185，186図の如くである(*31)。 参考文献 （著者・編者の五十音順） 書籍 平井喜久松『鉄道』岩波書店，1936年5月15日 第1刷発行，1949年7月15日 第7刷発行 辞典 石井忠久，他『福武漢和辞典』福武書店，1991年11月1日 発行，初版 岩波書店『広辞苑』〈シャープ電子辞書 PW-9600 収録〉岩波書店，1998-2001年，第5版 （書名の五十音順） 関連ブログ #bf コメント アルバイトはじめました(*´ω`)＄ http //s.64n.co/ -- (age) 2011-12-29 07 08 15 名前 コメント すべてのコメントを見る メール 名前 メールアドレス 内容 更新日：2010年12月10日
https://w.atwiki.jp/s3study/pages/34.html
あまーり意味の無い整形ですが、shift_jisのテキストファイルを、Unicodeのテキスト ファイルに変換するプログラムを作ってみましょう。 ちなみに今回の課題ですので、答えは書きません。 最低限、以下の機能を盛り込んでください。 入力と、出力のファイル名を入力できるように バイナリファイルは考慮しなくて良い 入出力のファイル名が無記入であったり、ミスがあったりした場合はエラーを表示 テキストファイルは複数行もサポート 以上。 がんばって下さい……ではあんまりなので、恒例のヒント。 Unicodeでファイルを開く EncodingのUnicodeプロパティを使用します。 なので、Encoding.Unicodeですね。 ファイルを最後まで読む方法 ファイルストリームが、終端まで行ったかを調べます。 方法は二通り。 ReadLineは終端まで行くとnullを返すので、ReadLineを実行して読み込んだ文字列が nullかを調べれば、終端まで読み込んだことを確認できます。 nullってのは参照を行わない 例 最後まで読み込んだかの確認 text = sr.ReadLine(); if( text == null ) { } とか if( ( text = sr.ReadLine() ) == null ) { } とかですかねぇ。 もう一つは、ReadStreamにはそのなの通りEndOfStreamというプロパティがあります。 これがtrueだと、ストリームが終端まで行ったという事になります。 text = sr.ReadLine(); if( sr.EndOfStream ) { } というような感じでしょうかね。 ちなみにこれ、Framework 2.0で追加されたプロパティだそうで。 どちらの方法を使用するにせよ、複数回繰り返すにはループ文(for,while)を使う必要 があります。 もうちょっとヒントを書くと、whileの継続条件は条件がtrueだった場合です。 なんで、たとえば普通にwhile( sr.EndOfStream )とかかくと、ストリームが終端であ る間繰り返す、なんていう処理になってしまいますので注意。 ファイルが存在すかをチェックする方法 Fileクラスの、Existsメソッドを使用します。 ファイルが存在する場合はtrue、それ以外はfalseを返します。 パスの指定が間違っている場合もfalseを返しますから、エラーチェックも行えます。 例 hoge.txtが存在するかを確認。 if( File.Exists("hoge.txt") ) { }
https://w.atwiki.jp/0x0b/pages/37.html
ECMAscript ３版 オブジェクト Global Object Function Array String Boolean Number Math Date RegExp Error(Error, EvalError, RangeError, ReferenceError, SyntaxError, TypeError, URIError) プロパティ を保持するコンテナ 他のオブジェクト プリミティブ値 メソッド プリミティブ値を持つ組み込み 型 Undefined, Null, Boolean, Number, String 組み込み演算子セットの定義 単項演算(unary operations) 乗除演算子(multiplicative operators) 加減演算子(additive operators) ビットシフト演算子(bitwise shift operators) 関係演算子(relational operators) 等価演算子(equality operators) ビット演算子(binary bitwise operators) 論理演算子(binary logical operators) 代入演算子(assignment operators) カンマ演算子(comma operator) オブジェクトを生成するコンストラクタ コンストラクタではないオブジェクトもある prototypeプロパティにより プロトタイプベースの継承および共有プロパティの実装に使用 プロトタイプチェーン (prototype chain) クラスベースのオブジェクト指向の言語 一般に、状態(state) がインスタンスによって運ばれ、メソッドはクラスによって運ばれ、継承は構造(strucutuer) と振る舞い(behaviour) にのみ存在 ECMAScriptでは、状態およびメソッドがオブジェクトによって運ばれ、構造、振る舞い、状態がすべて継承される new String("text") オブジェクト生成にはnew式を使用 String("text") プリミティブな文字列を生成 定義 (Definitions) [訳注 この仕様では "instance" という語が散見するが、 ECMAScript はプロトタイプベース言語であり、この語はクラスベース言語における "instance" のような技術的意味を持たない。現に仕様内にこの語に関する定義は公式非公式含めて見つからず、日常語としての「実例、実体、具体的なもの」としての意味合いで用いられているとも考えられる。] 型 (Type) データ値の集合 プリミティブ値 (Primitive Value) Undefined, Null, Boolean, Number, String 型のうちの一つの構成要素 プリミティブ値は言語実装の最低レベルにおいて直接表されるデータ オブジェクト (Object) Object 型の構成要素 序列のないプロパティの集合体 それぞれのプロパティがプリミティブ値やオブジェクト、関数を含む オブジェクトのプロパティに格納された関数はメソッドと呼ばれる コンストラクタ (Constructor) オブジェクトを生成し初期化する Function オブジェクトのこと 各コンストラクタは関連する prototype オブジェクトを持ち、継承と共有プロパティの実装に用いられる プロトタイプ (Prototype) オブジェクトであり、ECMAScript 中では、構造(structure), 状態(state), 振る舞い(behaviour) の継承に用いられる。コンストラクタがオブジェクトを生成するとき、プロパティの参照を解決する目的で、そのオブジェクトは暗黙にコンストラクタに関連するプロトタイプを参照する。コンストラクタに関連するプロトタイプはプログラム式 constructor.prototype で参照され、オブジェクトのプロトタイプに追加されたプロパティは、継承を通して、そのプロトタイプを共有する全オブジェクトによって共有される ネイティブオブジェクト (Native Object) ECMAScript 実装によって提供される任意のオブジェクトで、ホスト環境に依存しない。標準 Native オブジェクトは本仕様中で定義される。Native オブジェクトの一部は Built-in(組み込み) である。他のものは ECMAScript プログラムの実行行程の間に構築されるだろう 組み込みオブジェクト (Built-in Object) ECMAScript 実装によって提供される任意のオブジェクトであり、ECMAScript プログラムの実行の開始時に存在するホスト環境に依存しない。標準 Built-in オブジェクトは本仕様中に定義され、ECMAScript 実装は他を定義してもよい。全 Built-in オブジェクトは Native オブジェクトである。 ホストオブジェクト (Host Object) Host オブジェクトは ECMAScript の実行環境を満たすためにホスト環境によって提供される任意のオブジェクトである。Native でない任意のオブジェクトは Host オブジェクトである。 undefined 値 (Undefined Value) プリミティブ値 変数に値が代入されていないときに用いられる Undefined 型 (Undefined Type) 厳密には undefined と呼ばれるひとつの値を取る null 値 (Null Value) プリミティブな値であり、ヌル、空(empty)、存在しない参照を表す Null 型 (Null Type) 厳密には null と呼ばれるひとつの値を取る 真偽値 (Boolean Value) Boolean 型の元 (member 集合を構成するもの) 一意的な二つの値、 true と false の一方である。 Boolean 型 (Boolean Type) 論理的実体を表し、厳密には二つの一意的な値で構成される。一方は true と呼ばれ、他方は false と呼ばれる。 4.3.15 Boolean オブジェクト (Boolean Object) Boolean オブジェクトは Object 型の元で、組込み Boolean オブジェクトのインスタンスである。つまり、 Boolean オブジェクトは、 new 式内で引数にブーリアンを渡した Boolean コンストラクタを用いて作成される。結果のオブジェクトはブーリアンである暗黙の(無名の)プロパティを持つ。 Boolean オブジェクトはブーリアン値に強制される。 文字列値 (String Value) String 型の元で、0 以上の 16 ビット符号なし整数値による有限の順序あるシーケンスである。 NOTE 各値は通常単一の UTF-16 テキストの 16 ビット単位をあらわすが、言語はそれらが 16 ビット符号なし整数であること以外の制限また要求を値上に設置しない。 String 型 (String Type) String 型はすべての文字列値の集合である。 String オブジェクト (String Object) Object 型の元で、組込み String オブジェクトのインスタンスである。つまり、String オブジェクトは new 式内で引数として文字列を供給する String コンストラクタを用いて生成される。結果のオブジェクトは文字列である暗黙の(無名の)プロパティを持つ。 String コンストラクタの関数としての呼び出しにより、 String オブジェクトは文字列値に強制される。 数値 (Number Value) Number 型の元で、数を直接表現する。 Number 型 (Number Type) 数を表す値の集合である。 ECMAScript において、値の集合は、特殊な "Not-a-Number" (NaN) 値、正の無限大、負の無限大を含めた倍精度64ビット形式 IEEE 754 値である。 4.3.21 Number オブジェクト (Number Object) Number オブジェクトは Object 型の元で、組込み Number オブジェクトのインスタンスである。つまり、 Number オブジェクトは new 式において Number コンストラクタに引数として数を渡して生成される。結果のオブジェクトは数字である暗黙の (無名の) プロパティを持つ。 Number オブジェクトは関数としての Number コンストラクタ呼び出し (セクション 15.7.1) によって数値に矯正できる。 Infinity プリミティブ値 正の無限大をあらわす。この値は Number 型の元である。 NaN プリミティブ値 IEEE 標準 "Not-a-Number" 値のセットあらわす この値は Number 型の元である 記述法 構文と字句の文法 (Syntactic and Lexical Grammars) 文脈自由文法 (Context-Free Grammars) 生成規則 (production)によって構成 各生成規則はその左辺に非終端記号 (nonterminal symbol) と呼ばれる抽象的記号を 右辺に 0 個以上の非終端記号と終端記号 (terminal symbol) の並びを持つ 各文法のために、終端記号は特定のアルファベットか引き出される 目標記号 (goal symbol) と呼ばれる、単一の識別される非終端記号で構成される文から始まり、与えられる文脈自由文法は言語を規定 終端記号の可能なシーケンスの (おそらく無限の) 集合で、それはシーケンス内で非終端記号を、非終端記号が左辺である生成規則の右辺で繰り返し置換することから生じる 字句と正規表現の文法 (The Lexical and RegExp Grammars) 文法は終端記号として Unicode 文字セットの文字を持つ 目標記号 InputElementDiv や InputElementRegExp から始まる生成規則のセットを定義 Unicode文字のシーケンスが入力要素のシーケンス内でどのような処理がなされるか説明する 空白類及びコメント以外の入力要素は、 ECMAScript トークン (ECMAScript tokens) と呼ばれECMAScript の構文的文法に終端記号を形成する これらのトークンは ECMAScript 言語の予約語、識別子、リテラルおよび接続子である 行終端子 (line terminator) はトークンだと考えられてはいないが、入力要素のストリームの一部になり、自動セミコロン挿入 (字句) のプロセスをガイドする 単純な空白類および一行のコメントは、廃棄されて構文的な文法用の入力要素のストリームに出現しない MultiLineComment (1 行を超えるか範囲かどうか関係ない "/*…*/" 形式のコメント) が行終端子を含まない場合、同様に単に廃棄される MultiLineComment が 1 つ以上の行終端子を含んでいる場合、それは 1 つの行終端子と置換され、それは構文的な文法用の入力要素のストリームの一部になる ECMAScript のための RegExp 文法はセクション 15.10 に与えられる。この文法は、さらにその終端記号として Unicode 文字セットの文字を持つ。それは 1 セットの生成規則を定義し、目標記号パターンから開始して、 Unicode 文字のシーケンスが正規表現パターンにどのように翻訳されるか説明する。 字句と RegExp 文法の生成規則は、区切り分離として 2 つのコロン " " を持つことで識別される。字句と RegExp 文法はいくつかの生成規則を共有する。 この文法は、さらにその終端記号として Unicode 文字セットの文字を持つ 1 セットの生成規則を定義し、目標記号パターンから開始して、 Unicode 文字のシーケンスが正規表現パターンにどのように翻訳されるか説明する 字句と RegExp 文法の生成規則は、区切り分離として 2 つのコロン " " を持つことで識別される。字句と RegExp 文法はいくつかの生成規則を共有する 数値文字の文法 (The Numeric String Grammar) 第二の文法は文字列をを数値の値に変換するのに使用される 文法は数値リテラルと関係する字句の文法の一部に似ていて、その終端記号として Unicode 文字集合の文字を持つ。 この文法は(型変換)に出現する 数値的文字文法の生成規則は、接続子として 3 つのコロン " " を用いて区別される 構文的文法 (The Syntactic Grammar) ECMAScript のための構文的文法は(式, 文, 関数定義, プログラム)で扱う 文法は ECMAScript トークンを持ち、字句文法によってその終端記号として定義 生成規則の一集合を定義し、目標記号 Program(生成規則 Program )から開始し、トークンのシーケンスがどのように構文上正しい ECMAScript プログラムを形成できるか説明する Unicode 文字のストリームが ECMAScript プログラムとして解析されることになっている場合、それは字句文法の繰り返された適用によって、最初に入力要素のストリームに変換される; この入力要素のストリームはその後、構文文法の単一のアプリケーションによって解析される 残ったトークンのない、ゴール非終端記号Program の単一の実例として入力要素のストリームのトークンを解析できない場合、プログラムは構文上誤っている 構文的文法の生成規則は、接続子として 1 つのコロン " " を用いて区別される (式, 文, 関数定義, プログラム)の中で示される構文的文法は、トークンシーケンスが正しい ECMAScript プログラムとして認められる、現実に完全な説明ではない 疑う余地のない追加トークンシーケンス、すなわち、文法によって記述され、セミコロンだけが (行終端子文字の前のような) 確実な場所内のシーケンスに加えられた場合も受理される 終端子文字が確実に "不適当な" 場所に現われる場合、文法によって記述されるあるトークンシーケンスは、受理可能であるとは考えられない 文法記法 (Grammar Notation) 字句と文字列の文法の終端記号といくつかの構文文法の終端記号は、文法の生成規則内及びこの仕様を通して、テキストがそのような終端記号を直接参照するときは 等幅フォントであらわされる。これらはプログラム中に書かれるものとして出現する。この方法で指定される非終端記号の文字は全て、 ASCII の範囲から 適当な Unicode 文字として理解されるものであり、他の Unicode 範囲の類似した文字ではない。 非終端記号は イタリック体 であらわされる。非終端記号の定義は、一つ以上のコロンの続く定義されている非終端記号の名前によって案内される。(コロンの数は生成規則がどの文法に属するかを示す。) 非終端記号の一つ以上の代替の右辺は後続行に続く。 [訳注 この HTML 版邦訳でのフォントはこの限りではないかもしれない。] 例えば、次の構文定義 WithStatement with ( Expression ) Statement は、非終端記号 WithStatement がトークン with 、左括弧トークン、 Expression 、右括弧トークン、 Statement の続きをあらわすことを明言する。 Expression 及び Statement の出現はそれ自身非終端である。別な例として、次の構文定義 ArgumentList AssignmentExpression ArgumentList , AssignmentExpression は、 ArgumentList が単一の AssignmentExpression 、または ArgumentList 、カンマ、 AssignmentExpression の続きのどちらかをあらわすかもしれないことを明言する。この ArgumentList の定義は再帰的で、つまり、自分自身の表現の中で定義される。結果として、 ArgumentList はカンマで区切られた任意の正数の引数で構成されうる。その各引数式のところは AssignmentExpression である。非終端記号のそのような再帰的定義が一般的である。 下付き文字による後置句 "opt" は、終端記号または非終端記号の後に出現でき、選択的記号を示す。代替構成の選択的記号は実際は 2 つの右辺を規定する。1 つは選択的要素を省いたもの、1 つは含めたものである。これはつまり VariableDeclaration Identifier Initialiseropt は次の略記であるということだ VariableDeclaration Identifier Identifier Initialiser そして IterationStatement for ( ExpressionNoInopt ; Expressionopt ; Expressionopt ) Statement は次の略記であり IterationStatement for ( ; Expressionopt ; Expressionopt ) Statement for ( ExpressionNoIn ; Expressionopt ; Expressionopt ) Statement 順に次の略記ということになり IterationStatement for ( ; ; Expressionopt ) Statement for ( ; Expression ; Expressionopt ) Statement for ( ExpressionNoIn ; ; Expressionopt ) Statement for ( ExpressionNoIn ; Expression ; Expressionopt ) Statement 順に次の略記ということになる IterationStatement for ( ; ; ) Statement for ( ; ; Expression ) Statement for ( ; Expression ; ) Statement for ( ; Expression ; Expression ) Statement for ( ExpressionNoIn ; ; ) Statement for ( ExpressionNoIn ; ; Expression ) Statement for ( ExpressionNoIn ; Expression ; ) Statement for ( ExpressionNoIn ; Expression ; Expression ) Statement 従って非終端記号 IterationStatement は、実際には 8 個の代替右辺を持つ。 フレーズ "[empty]" が生成規則の右辺に出現するならば、それは生成規則の右辺が終端記号も非終端記号も含まないことを示す。 フレーズ "[lookahead ∉ set]" が生成規則の右辺に出現する場合は、直後の入力終端記号が与えられた set の元ならば、生成規則が使われないことを示す。 set は { } 内に囲まれた終端記号のリストとして書くことが出来る。簡潔に言えば、 set は非終端記号として書くことも出来る。その場合、非終端記号から展開可能な終端記号の全てをあらわす。例えば、定義 DecimalDigit one of 0 1 2 3 4 5 6 7 8 9 DecimalDigits DecimalDigit DecimalDigits DecimalDigit を与えられて、定義 LookaheadExample n [lookahead ∉ {1, 3, 5, 7, 9} ] DecimalDigits DecimalDigit [lookahead ∉ DecimalDigit ] は、偶数で始まる一つ以上の数字が続く文字 n 、あるいは他の数字が続かない数字にマッチする。 フレーズ "[no LineTerminator here]" 構文的文法の生成規則の右辺に出現する場合、生成規則が 制限生成規則 (restricted production) であることを示す 入力ストリームの示された位置に LineTerminator が出現しなければ使用できない。例えば、次の生成規則 ReturnStatement return [LineTerminator 無し] Expressionopt ; プログラム内の return トークンと Expression の間に LineTerminator が出現する場合はこの生成規則は使用できない。 LineTerminator の存在が制限生成規則に隠されなければ、入力要素のストリーム内の 2 つの連続するトークン間に LineTerminator はいくつでも出現でき、プログラムの構文的受容性に影響を与えない。 文法定義内のコロンに語句 "one of" が続く場合、後続行の終端記号のそれぞれが代替定義であることを意味する。例えば、ECMAScript の字句文法は次の生成規則を含む NonZeroDigit one of 1 2 3 4 5 6 7 8 9 これは単に次の略記である NonZeroDigit one of 1 2 3 4 5 6 7 8 9 字句文法また数値文字文法の生成規則内の代替が複数文字トークンである場合、そのトークンを作る文字シーケンスをあらわす。 生成規則の右辺は、フレーズ "but not" を用いてある展開が許可されないことを規定してよく、その展開は除外される。例えば、次の生成規則 Identifier IdentifierName but not ReservedWord は、非終端記号 Identifier が IdentifierName に置換可能だが ReservedWord で置換不可能な文字シーケンスであることを意味する。 最後に、全ての代替をすべてあげるのが現実的でないいくつかの非終端記号が、ローマン体の説明的フレーズで記述される SourceCharacter any Unicode character 5.2 アルゴリズム記述について (Algorithm Conventions) 仕様はしばしば番号を振ったリストを用いて、アルゴリズム内のステップを規定する。これらのアルゴリズムは意味論を明確にするために用いられる。実際には、与えられる機能の実装に有効な、より能率的なアルゴリズムであってよい。 アルゴリズムが結果として値を生成するとき "x を返す" が用いられ、アルゴリズムの結果が x の値であり、アルゴリズムが終了すべきであることを示す。表記 Result(n) は "ステップ n の結果" の略記である。Type(x) は "x の型" の略記である。 本セクションで後に述べる加法、減法、否定、乗法、除法、数学的関数のような数学的操作は、常に、無限及び正の 0 から区別される負の 0 を含まない数学的な実数上の厳密な数学的結果を演算するものとして理解されるべきである。浮動小数点数計算を作るこの標準のアルゴリズムは、必要に応じて、無限と符号付きの 0 を操作し丸めの実行する、明示的なステップを含む。数学的操作または関数が浮動小数点数に適用される場合、その浮動小数点数\であらわされる厳密な数学的値に適用されるものとして理解されるべきである; そのような浮動小数点数は有限であるべきで、そして +0 または -0 ならば該当する数学的値は単に 0 である。 数学関数 abs(x) は x の絶対値をもたらし、 x が負(0 未満) なら -x 、そうでなければ x 自身である。 数学関数 sign(x) は、 x が正ならば 1、 x が負ならば -1 をもたらす。 x が 0 のときのための sign 関数はこの標準では用いられない。 記法 "x modulo y" (y は 0 以外の有限数) は、ある整数 q について abs(k) abs(y) かつ x - k = q * y であるような、 y (又は 0) と同じ符号の値 k を算出する。 数学関数 floor(x) は x より大きくない最大の整数 (正の無限に接近する) をもたらす。 NOTE floor(x) = x - (x modulo 1). アルゴリズムが "例外を投げる" と定義されていれば、アルゴリズムの実行は終了し、結果を何も返さない。アルゴリズム呼出しも終了し、 "例外が投げられたら…" のような用語を用いて、アルゴリズムのステップが明示的に例外を扱うに至る。一度そのようなアルゴリズムのステップに遭遇したらそれ以上例外の発生は考慮されない。 ソーステキスト 文法記法 (Grammar Notation) 字句と文字列の文法の終端記号といくつかの構文文法の終端記号は、文法の生成規則内及びこの仕様を通して、テキストがそのような終端記号を直接参照するときは 等幅フォントであらわされる。これらはプログラム中に書かれるものとして出現する。この方法で指定される非終端記号の文字は全て、 ASCII の範囲から 適当な Unicode 文字として理解されるものであり、他の Unicode 範囲の類似した文字ではない。 非終端記号は イタリック体 であらわされる。非終端記号の定義は、一つ以上のコロンの続く定義されている非終端記号の名前によって案内される。(コロンの数は生成規則がどの文法に属するかを示す。) 非終端記号の一つ以上の代替の右辺は後続行に続く。 [訳注 この HTML 版邦訳でのフォントはこの限りではないかもしれない。] 例えば、次の構文定義 WithStatement with ( Expression ) Statement は、非終端記号 WithStatement がトークン with 、左括弧トークン、 Expression 、右括弧トークン、 Statement の続きをあらわすことを明言する。 Expression 及び Statement の出現はそれ自身非終端である。別な例として、次の構文定義 ArgumentList AssignmentExpression ArgumentList , AssignmentExpression は、 ArgumentList が単一の AssignmentExpression 、または ArgumentList 、カンマ、 AssignmentExpression の続きのどちらかをあらわすかもしれないことを明言する。この ArgumentList の定義は再帰的で、つまり、自分自身の表現の中で定義される。結果として、 ArgumentList はカンマで区切られた任意の正数の引数で構成されうる。その各引数式のところは AssignmentExpression である。非終端記号のそのような再帰的定義が一般的である。 下付き文字による後置句 "opt" は、終端記号または非終端記号の後に出現でき、選択的記号を示す。代替構成の選択的記号は実際は 2 つの右辺を規定する。1 つは選択的要素を省いたもの、1 つは含めたものである。これはつまり VariableDeclaration Identifier Initialiseropt は次の略記であるということだ VariableDeclaration Identifier Identifier Initialiser そして IterationStatement for ( ExpressionNoInopt ; Expressionopt ; Expressionopt ) Statement は次の略記であり IterationStatement for ( ; Expressionopt ; Expressionopt ) Statement for ( ExpressionNoIn ; Expressionopt ; Expressionopt ) Statement 順に次の略記ということになり IterationStatement for ( ; ; Expressionopt ) Statement for ( ; Expression ; Expressionopt ) Statement for ( ExpressionNoIn ; ; Expressionopt ) Statement for ( ExpressionNoIn ; Expression ; Expressionopt ) Statement 順に次の略記ということになる IterationStatement for ( ; ; ) Statement for ( ; ; Expression ) Statement for ( ; Expression ; ) Statement for ( ; Expression ; Expression ) Statement for ( ExpressionNoIn ; ; ) Statement for ( ExpressionNoIn ; ; Expression ) Statement for ( ExpressionNoIn ; Expression ; ) Statement for ( ExpressionNoIn ; Expression ; Expression ) Statement 従って非終端記号 IterationStatement は、実際には 8 個の代替右辺を持つ。 フレーズ "[empty]" が生成規則の右辺に出現するならば、それは生成規則の右辺が終端記号も非終端記号も含まないことを示す。 フレーズ "[lookahead ∉ set]" が生成規則の右辺に出現する場合は、直後の入力終端記号が与えられた set の元ならば、生成規則が使われないことを示す。 set は { } 内に囲まれた終端記号のリストとして書くことが出来る。簡潔に言えば、 set は非終端記号として書くことも出来る。その場合、非終端記号から展開可能な終端記号の全てをあらわす。例えば、定義 DecimalDigit one of 0 1 2 3 4 5 6 7 8 9 DecimalDigits DecimalDigit DecimalDigits DecimalDigit を与えられて、定義 LookaheadExample n [lookahead ∉ {1, 3, 5, 7, 9} ] DecimalDigits DecimalDigit [lookahead ∉ DecimalDigit ] は、偶数で始まる一つ以上の数字が続く文字 n 、あるいは他の数字が続かない数字にマッチする。 フレーズ "[no LineTerminator here]" 構文的文法の生成規則の右辺に出現する場合、生成規則が 制限生成規則 (restricted production) であることを示す 入力ストリームの示された位置に LineTerminator が出現しなければ使用できない。例えば、次の生成規則 ReturnStatement return [LineTerminator 無し] Expressionopt ; プログラム内の return トークンと Expression の間に LineTerminator が出現する場合はこの生成規則は使用できない。 LineTerminator の存在が制限生成規則に隠されなければ、入力要素のストリーム内の 2 つの連続するトークン間に LineTerminator はいくつでも出現でき、プログラムの構文的受容性に影響を与えない。 文法定義内のコロンに語句 "one of" が続く場合、後続行の終端記号のそれぞれが代替定義であることを意味する。例えば、ECMAScript の字句文法は次の生成規則を含む NonZeroDigit one of 1 2 3 4 5 6 7 8 9 これは単に次の略記である NonZeroDigit one of 1 2 3 4 5 6 7 8 9 字句文法また数値文字文法の生成規則内の代替が複数文字トークンである場合、そのトークンを作る文字シーケンスをあらわす。 生成規則の右辺は、フレーズ "but not" を用いてある展開が許可されないことを規定してよく、その展開は除外される。例えば、次の生成規則 Identifier IdentifierName but not ReservedWord は、非終端記号 Identifier が IdentifierName に置換可能だが ReservedWord で置換不可能な文字シーケンスであることを意味する。 最後に、全ての代替をすべてあげるのが現実的でないいくつかの非終端記号が、ローマン体の説明的フレーズで記述される SourceCharacter any Unicode character 5.2 アルゴリズム記述について (Algorithm Conventions) 仕様はしばしば番号を振ったリストを用いて、アルゴリズム内のステップを規定する。これらのアルゴリズムは意味論を明確にするために用いられる。実際には、与えられる機能の実装に有効な、より能率的なアルゴリズムであってよい。 アルゴリズムが結果として値を生成するとき "x を返す" が用いられ、アルゴリズムの結果が x の値であり、アルゴリズムが終了すべきであることを示す。表記 Result(n) は "ステップ n の結果" の略記である。Type(x) は "x の型" の略記である。 本セクションで後に述べる加法、減法、否定、乗法、除法、数学的関数のような数学的操作は、常に、無限及び正の 0 から区別される負の 0 を含まない数学的な実数上の厳密な数学的結果を演算するものとして理解されるべきである。浮動小数点数計算を作るこの標準のアルゴリズムは、必要に応じて、無限と符号付きの 0 を操作し丸めの実行する、明示的なステップを含む。数学的操作または関数が浮動小数点数に適用される場合、その浮動小数点数\であらわされる厳密な数学的値に適用されるものとして理解されるべきである; そのような浮動小数点数は有限であるべきで、そして +0 または -0 ならば該当する数学的値は単に 0 である。 数学関数 abs(x) は x の絶対値をもたらし、 x が負(0 未満) なら -x 、そうでなければ x 自身である。 数学関数 sign(x) は、 x が正ならば 1、 x が負ならば -1 をもたらす。 x が 0 のときのための sign 関数はこの標準では用いられない。 記法 "x modulo y" (y は 0 以外の有限数) は、ある整数 q について abs(k) abs(y) かつ x - k = q * y であるような、 y (又は 0) と同じ符号の値 k を算出する。 数学関数 floor(x) は x より大きくない最大の整数 (正の無限に接近する) をもたらす。 NOTE floor(x) = x - (x modulo 1). アルゴリズムが "例外を投げる" と定義されていれば、アルゴリズムの実行は終了し、結果を何も返さない。アルゴリズム呼出しも終了し、 "例外が投げられたら…" のような用語を用いて、アルゴリズムのステップが明示的に例外を扱うに至る。一度そのようなアルゴリズムのステップに遭遇したらそれ以上例外の発生は考慮されない 字句 型 型変換 実行コンテキスト 式 文 関数定義 プログラム 重要項目なので別に移すかもしれない ネイティブECMAオブジェクト オブジェクト(Global, Object, Function, Array, String, Boolean, Number, Math, Date, RegExp, Error) 項目、総量が多いので別枠に記載 文法要約 互換性
https://w.atwiki.jp/saikyoumousou5/pages/2750.html
【妄想属性】妄想 【作品名】それゆけ！拳銃マン 【名前】フライパンナちゃん 【属性】スーパーヒロイン 【大きさ】女子小学生並み 【攻撃力】パンチ一発でフライパン（※１）の底面をブチ破れる 【防御力】成人男性にフライパンの底面で頭を思いっきりぶん殴られて無傷 【素早さ】移動速度及びパンチの速さは、地球上での終端速度（※２）に達したフライパンの落下速度並み 自分の頭上に落下してきた、地球上での終端速度に達したフライパンが自分の頭から１ｍの距離に迫ったのを目視してから反応して回避できる 【特殊能力】あらゆる全てのフライパンと、フライパンで料理をしたことがあるあらゆる全ての者に関して全知 【長所】フライパンを守り、フライパンを愛し、フライパンのために戦うヒロイン 【短所】フライパン以外の物は守らないし愛さない （※１）このテンプレ中の【攻撃力】【防御力】【素早さ】欄内のフライパンは全て、内径260mm 深さ48mm 質量1.33kg 底径185mm 板厚2.3mmの鉄製である （※２）大気中を自由落下する物体に働く空気抵抗と重力が釣り合い、それ以上加速しなくなった時の速度を終端速度という ◆考察記録--------------------------------------------------------------------------------------------------------------------------- 632 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2010/03/23(火) 22 13 49 ID oATPqYv8 フライパンナ簡易 【攻撃力】鉄板破壊 【防御力】鉄板無傷 【素早さ】終端速度フライパン級速度＋1mからの終端速度フライパン対応 【特殊能力】フライパン系全知 素早さが分かりにくいので計算してみる。 ttp //ja.wikipedia.org/wiki/%E8%87%AA%E7%94%B1%E8%90%BD%E4%B8%8Bより、 終端速度＝mg/k m＝1.33 g≒9.8 摩擦係数は恐らく下記のサイトにある情報でいいと思われる。 ttp //m-sudo.blogspot.com/2009/05/blog-post_4672.html ttp //1.bp.blogspot.com/_5p7M7rc6Dy4/SrfeqamSzKI/AAAAAAAACnI/XHbmm-DsWpk/s1600-h/%E6%9D%90%E6%96%99%E7%89%B9%E6%80%A7%EF%BC%9A%E6%91%A9%E6%93%A6%E4%BF%82%E6%95%B0.jpg k＝0.8 or 0.16？ kが定まらないのでとりあえず両方求めてみる。 (1.33 * 9.8) / 0.8 = 16.2925 (1.33 * 9.8) / 0.16 = 81.4625 よって16.3m/s～81.5m/s？の行動速度＋16.3m/s～81.5m/s？対応 素早さに幅がありすぎるので摩擦係数の情報待ちとしたいところ。 もしくは詳しい人の情報求む。 395格無しさん2018/12/22(土) 19 53 44.81ID 4MVcInqi フライパンナちゃん 抗力 D = 1/2 ρ(air) V^2 S CD (参考 https //ja.wikipedia.org/wiki/%E6%8A%97%E5%8A%9B ) 終端速度で D = 1/2 ρ(air) V^2 S CD = m g V = √{(2 m g) / (ρ(air) S CD)} g = 9.807 m/s^2 (定数) m = 1.33 kg (空気の浮力は3桁以上小さいので無視) ρ(air) = 1.222 kg/m^3 (15℃, 湿度50%) 落下は無限時間待つと凹字形の状態で安定すると考えられる。 新幹線が空気抵抗を下げるために尖った形になっているように、空気を受ける面が凸だと空気抵抗は小さくなる。 安定状態も空気を受ける面は凸になっている。 だから内径の大きさの円板よりも空気抵抗が小さい。 底面の円板よりは余分な面がある分空気抵抗が大きい。 2つの円板の終端速度の間くらいの値になる。 S(内径) = π*(130 mm+2.3 mm)^2 = 5.499*10^4 mm^2 = 5.50*10^-2 m^2 S(底径) = π*(92.5 mm+2.3 mm)^2 = 2.688*10^4 mm^2 = 2.82*10^-2 m^2 円板は CD = 1.11 (参考 http //skomo.o.oo7.jp/f28/hp28_63.htm ) V(内径) = 18.7 m/s = 67.3 km/h V(底径) = 26.1 m/s = 94.0 km/h したがってフライパンの終端速度は 67 km/h と 94 km/h の間にある。 フライパンの終端速度 80 km/h くらい 649 ◆at.uA6ZmHU 2019/03/25(月) 22 43 15.08ID sbjmi9Cx フライパンナちゃん再考察 下の考察記録にフライパンの終端速度が書いてある フライパンナ簡易 【攻撃力】鉄板破壊 【防御力】鉄板無傷 【素早さ】移動速度：80 km/h 反応速度：1mからの80 km/h対応 【特殊能力】フライパン系全知 (軍人の壁)から下がる。 ×毒島タマ 毒で負け 〇ペニスウォリアーMASAMUNE こちらの方が速い △酔川渉＆西城茉利亞 互いに決め手なし。 △Revival H2S 互いに決め手なし。 ×毒島たつひこ 毒で負け 〇肌守全裸ノ介 戦っているときに一発くらい食らうだろう 〇全選手入場！！ こちらの方が速い △鋼鉄ようかんマン 互いに決め手なし。 △鋼鉄の成人男性 互いに決め手なし。 〇石橋ゲル 戦っているときに一発くらい食らうだろう 〇勇者もこたん 戦っているときに一発くらい食らうだろう △ＨＲＰ―4Ｃ 互いに決め手なし。 ×キサマノフ 相手の方が速い。 〇光速戦士 反応はこちらの方が上 〇エペタム フライパンも壊せるし刀も壊せるだろう ×シシオの人 相手の方が速い。 ×人造人間キメラマン 噛まれて負け ×モウドクライオン 毒で負け ×ルペルペ＝ガルト 特殊能力負け 〇キメラ 攻防はこちらの方が少し上 〇マンモスハンター 10人くらいなら倒せるだろう ×ペガサス 飛べないし飛び道具もないので不利 〇巨大バッタ 飛ぶときにスキができる 〇 / . . /／. , ｨ . 攻防はこちらの方が少し上 〇周防の大蝦蟇 こちらの方が速い △結城麗香 互いに決め手なし。 これ以降は勝ち越せるだろう。 ルペルペ＝ガルト＞フライパンナちゃん＞キメラ
https://w.atwiki.jp/rai002/pages/55.html
カレントディkレクト理の取得 DWORD GetCurrentDirectory( DWORD nBufferLength, LPTSTR lpBuffer ); nBufferLength カレントディレクトリを取得するためのバッファの長さを TCHAR 単位で指定します。この長さには、終端の NULL 文字も含めてください。 lpBuffer バッファへのポインタを指定します。関数から制御が返ると、このバッファに、NULL で終わるカレントディレクトリの絶対パス名が格納されます。 戻り値 関数が成功すると、バッファに書き込まれた文字数（終端の NULL 文字を除く）が返ります。関数が失敗すると、0 が返ります。拡張エラー情報を取得するには、 関数を使います。lpBuffer が指すバッファのサイズが小さかった場合、必要なバッファのサイズ（終端の NULL 文字を含む）が返ります。
https://w.atwiki.jp/abwiki/pages/89.html
名称 |Eof 読み |エンドオブファイル 定義 |Eof(FileNum As Long) As Long 説明 |ファイルポインタがファイルの終端にあるかどうかを判断します。 戻り値 |ファイルポインタが終端部分を示しているときは、-1が返ります。それ以外は、0が返ります。 参照 |
https://w.atwiki.jp/i2p3/pages/32.html
匿名性について 終端間暗号化 I2Pネットワーク上のノード間の通信は全て終端間暗号化が施されている。そのため、送信者Aと受信者Bがいて、その間に中継するノードを挟んでいても、そのノードには通信内容がわからない。I2Pを使用したアプリケーション(I2PSnarkやI2PHiddenService)についても同様で、Destinationアドレスが各アプリケーション毎に発行されるが、送信者は受信者に正しくDestinationアドレスが伝わっている時、これを使って送信者と受信者はセキュアな終端間暗号化が可能である。 I2Pを通したBitTorrentクライアント 標準のBitTorrentプロトコルは通信の暗号化をサポートしておらず、通信相手のIPアドレスを直接知ることができる。すなわち匿名性を確立するための機構は一切用意されていない。I2Pを通したBitTorrentは、他のI2Pノードと通信するが、互いに通信先は暗号化されたアドレスが通知されるため接続元のIPアドレスを知ることはできない。また、I2Pの特性からBitTorrentに参加しないノードも中継することになるが、中継ノードは通信内容を知ることができないため何のファイルを共有しているのかを知ることもできない。さらに、I2Pを通してBitTorrentでファイル共有する場合に暗号化アドレスを使用するが、このアドレスは任意に変更することが可能であるため、同じアドレスを使い続けることによって共有しているファイルが何であるかを推測されにくい。こうした利点が伴い、高い匿名性とセキュアな通信によるファイル共有が可能である。 国内ノードのみの使用による匿名性評価 ファイル共有をするAとB、そしてAとBがそれぞれ中継するノードが存在し、これら全てのノードが国内のノードであった場合の匿名性を考える。ただし、AとBも互いの発信元が国内であることは知らないこととする。 ノードAは中継ノードを介してノードBと互いに接続する。ノードBも同様に中継ノードを介する。これによってノードAとノードBは互いの発信元を知ることはできない。 中継ノードはランダムに入れ替わり、ノードA側に最も近い中継ノードはノードAの発信元を知ることができるが、ノードAが何の通信をしているかはわからない。同様にノードBに最も近い中継ノードもノードBの通信が何であるかを知ることはできない。このことからノードAとノードBは互いに「同じファイルについてファイル共有している」ということだけを知ることができ、ノードAとノードBそれぞれの最も近い中継ノードは「ノードA／ノードBとつながっている」ことだけしかわからない。最終的にあるファイルについて共有しているという事実を知ることができるのは、ファイル共有の当事者であるノードAとノードBだけである。このようになるのは、ノードAとノードBは互いに終端間暗号化をしているので、中継ノードは一切通信内容を知ることができないためである。よって中継ノードもファイル共有の当事者も国内の発信元であっても、「ファイルXについてファイル共有している」という事実を当事者以外に知ることはできない。 ノードの追跡を考える。ノードAまたはノードBの中継ノードの末端から発信元を追跡していくことでノードAとノードBの発信元が突き止められる可能性がある。しかしI2Pでは全てのノードが持つ中継ノードがランダムに短時間で切り替わるため、現実的に追跡することは難しく、追跡によるノードAとノードBの特定は困難であると考えられる。このことから全ての国内ノードの通信が監視下にあっても、監視者にとっては「暗号化された通信をしている」ことしかわからないため、発信元の追跡は成功しないと考えられる。 悪意あるノードによる監視についてTorとI2Pの対比 Torで(HiddenServiceでない場合)使用者は出口ノードに向けてトラフィックを送信する時、3つのリレーノードを持ち、そのリレーノードはディレクトリサーバーからランダムに選ばれ、短時間でランダムに切り替わる。その時に悪意あるノードが選ばれた場合、通信内容を解読される可能性がある。これは出口ノードと終端間暗号化をせず、オニオンルーティングの特性でPoint-to-Pointの暗号化を行っているためである。I2Pではトラフィックの到達先にデータを送信する際、事前にDestinationアドレスから得られた公開鍵を使って終端間暗号化を行うため、悪意あるノードが選ばれることによる通信内容が解読される恐れはない。 政府や公安が通信の傍受を目的としたリレーノードを設置することがあるが、I2Pではそのような方法をとられても傍受には全く役に立たない。 TorHiddenServiceの場合、送信者は1つのリレーノードを中継して目的のサーバーへアクセスするが、終端間暗号化を行うため鍵配送がセキュアであると仮定した場合リレーノードが悪意を持っていても通信内容が解読されることはない。