HTML5.2の見出し毎の内容を雑にまとめる、2.1 Terminology (用語)

2. Common infrastructure (共通基盤) の中の 2.1 Terminology (用語) について

ここを雑に読み飛ばすと、続く文章の言葉の意味が分からなくて泣きをみますので気合を入れて読みます


内容についてはあくまで初学者の覚書ですので、正式な仕様はW3CのHTML5.2を確認してください

また、勉強のため、各仕様の邦訳文書、解説文書を読まずに自分で翻訳して覚書を書き終わってから答え合わせとして邦訳文書を参照するようにしています

このため、多くの訳語が一般的な訳と異なっていますのでご注意ください


2. Common infrastructure (共通基盤)
2.1 Terminology (用語)

共通基盤に関する用語の説明


属性と言ったとき、文脈から参照先が曖昧であれば、HTML属性とXHTML属性とIDL (インタフェース記述言語) の属性の全てを指す

JavaScriptのオブジェクトプロパティとCSS双方のプロパティも同様である

「これの機能はHTMLに適用されます (XHTMLには適用しません)」のような記述がなければ、HTML/XHTMLの片方だけに言及していてももう一方にも適用する

文書は短文からマルチメディアまでかなり広い意味で使われるが、DOMの文脈では文書 (document) はDOMの仕様に従うのでHTML文書とXML文書は区別され、バイトストリームの文脈ではHTML文書は text/html のリソースであり、XML文書はXML MIMEタイプラベルのリソースを意味し、用語「XHTML文書」は文脈によてHTML名前空間の要素を含むXML文書としての文書と、HTML名前空間の要素を含むXML MIMEタイプのバイトストリームの両方を意味する


表示される (displayed) や見える (visible) は視覚的メディアに限定されない

アルゴリズム B が別なアルゴリズム A に戻るという時、A が B を呼んだことを意味し、AはBを呼びして中断したところから実行を続けなければならない

一部の処理は並行 (in parallel) に処理され、後続処理と同時に実行されることを意味するが、この仕様は正確な並列処理実行メカニズムを定義しない

対照的に直ちに (immediately) 実行される演算は、実行中の作業に割り込んで、実行し、前の作業を再開せねばならない

透明な黒は、赤、緑、青、アルファチャンネルがすべて0のの色である

2.1.1. Resources (リソース)

リソースに関連する用語の定義

ハイパーテキスト転送プロトコル -- HTTP/1.1 の3.7 メディアタイプを併せて読むべき (だが、私は読んでいない)


この仕様ではデコードできる外部リソースはサポートされる (supported) と言う用語で表現される

HTTPの仕様で、representationと言われるものはこの仕様では resource と言う

MIME typeはインターネットメディアタイプ (Internet media type) とも呼ばれるし、CSSでもメディア指定に使う

HTMLのメディアタイプはtext/htmlである

重要な副リソース (critical subresources) は、リソースが正しい処理に利用するために必要なリソースで、どのリソースが重要かは、リソースの仕様に定義されている

2.1.2. XML compatibility (XMLとの互換性)

XHTMLへの移行を容易にするためにHTML名前空間を使うとかなんとか

XHTMLとして文書を書いたり利用する気がない人は意識しなくてもたぶんあんまり困らない

名前空間はXHTML1.xと同じ


XHTMLとして解釈する時の名前空間http://www.w3.org/1999/xhtml

XMLMIME Typeはtext/xmlapplication/xml又はサブタイプが+xmlで終わる任意のMIME type

2.1.3. DOM trees (DOM 木構造)

DOMの関連用語

プログラマにとっては大体直観的な用語の定義 (だが、読んだ方が良い)


無視 (ignored) される
他の値として扱われる
別の何かとして扱われる
要素や属性が無視される、他の値として扱われる、他の何かとして扱われると規定されている場合、DOMの内部的な処理を指し、ユーザーエージェントはそのようなDOM状況の変化させてはならない
変更 (change)

以前の値が、新しい値と異なる場合、コンテンツ属性の値のみを変更 (change) する

既に持っている値を属性に設定しても変更しない

(属性値やテキストノードが) 空 (empty)

属性値やテキストノードに対して使った場合、文字列の長さが0の事

スペース(U+0020 " " SPACE) や制御文字もない状態

ある要素の子のテキストコンテンツ (child text content)
その要素の子孫の全てのテキストノードで構成されるデータ (その他のコメントや要素は無視される)
ノードBにノードAが挿入される (node A is inserted)
挿入処置 (insertion steps) がノードAを引数として呼び出され、Aの新しい親がノードBとなる事
ノードBからノードAは除去される (node A is removed)
除去処置 (removing steps) が A を除去ノード (removedNode)の引数、B を古い親 (oldParent) の引数として呼び出された時の処理
ノードが文書に挿入される (node is inserted into a document)
挿入処置 (insertion steps) がノードを引数として呼び出され、今やドキュメントツリーの中にある時の処理
ノードが文書から除去される (node is removed from a document)
除去処置 (removing steps) がノードを引数として呼び出され、最早ドキュメントツリーに存在しない時の処理
2.1.4. Scripting (スクリプティング)

スクリプトの為の用語

恐らくはJavaScriptでDOMを通じて利用するのが標準になっており、用語はDOMに準拠している

なお、HTML5.2 (この項だけでなく全般的に) が参照しているDOMの仕様はHTML5.2勧告時点で草案のW3C DOM 4.1である


"インターフェスFooを実装するオブジェクト" の代わりに "Foo オブジェクト" と書いたりする

IDL属性の値が (例えば、著者のスクリプト (author script) によって) 検索された時、取得中 (getting) と呼ばれ、新しい値が割り当てられた時、設定中 (setting) と言われる

DOMオブジェクトが生きている (live) と言われる時、そのオブジェクトの属性やメソッドは実際の元となるデータの物で、別のある瞬間 (snapshot) のデータではない

イベントの文脈では発火 (firing)、発信 (dispatching) はDOMの仕様の定義で用いる

イベントの発火 (firing) とは、イベントの生成と発信 (dispatching) を意味し、イベントの発信 (dispatching) とは手順に従って、イベントがツリーに伝播していくことを意味する

信頼できるイベント (trusted event) と言う用語はisTrusted 属性が真に初期化されたイベントを参照する為に使われる

2.1.5. Plugins (プラグイン)

用語プラグイン (典型的な例としてはPDFビュワーなど) の解説

プラグインレンダリングには参加できるけど、DOMにノード導入したりはできないとか、ユーザーエージェントはtext/plainapplication/octet-streamプラグインと見做してはならないとかなんとか

2.1.6. Character encodings (文字エンコーディング)

文字エンコーディングの話

単にHTML文書を書きたいだけの人は余り意識しなくてもよさそうだが、文字列のコード単位の長さ (code-unit length of a string) に言及するなら読んでおいた方が良い

HTML5.2の仕様はW3CEncodingを参照しているが、もし読むならwhatwgEncodingの方が良いだろう


文字エンコーディング、または曖昧でない時の単なるエンコーディングは、Encoding仕様で定められた、バイトストリームとUnicode文字列を変換する為の定義された方法である

エンコーディングは1つのエンコーディング名と、一つ以上のエンコーディングラベルを持ち、エンコーディング仕様のエンコーディング名とラベルを参照する

UTF-16エンコーディングUTF-16BEUTF-16LEである

ASCII互換エンコーディングUTF-16エンコーディング以外の任意のエンコーディングである (このASCII互換エンコーディングとなるUTF-16エンコーディング以外の任意のエンコーディングとは、Encoding specificationにある中でUTF-16エンコーディング以外の任意のエンコーディングと言う意味で、Encoding specification にないエンコーディングは元より対象外である)

用語コード単位 (code unit) は Web IDL specificationの定義で用いられ、16bit符号なし整数のDOM Stringの不可分な最小構成要素である (これはUnicodeの定義より狭義で、コードポイント (code point) とは異なる)

用語Unicodeコードポイント (Unicode code point) は 可能であればUnicodeスカラー値を意味し、そうでなければ単独のサロゲートコードポイントである

適合要件の定義が文字かUnicodeコードポイントを条件とするとき、一対のコード単位を構成する上位サロゲートとそれに続く低サロゲートは、サロゲートペアによって表される単独のコードポイントとして扱われなければならないが、単独のサロゲートサロゲートの値の単独のコードポイントとして扱われなければならない

この仕様では、文字 (character) と言う用語は、Unicode文字と書かれていなければUnicodeコードポイントと同義である

Unicode文字 (Unicode character) とはUnicodeスカラー値である (つまり、サロゲートコードポイントではない任意のUnicodeコードポイント)

文字列のコード単位の長さ (code-unit length of a string) その文字列のコード単位 (code units) の数である

この複雑さは、Unicodeと言うよりむしろ DOM APIを 16bit (UTF-16) コード単位で定義した経緯に由来する

HTML5.2のdates and timesで先発グレゴリオ暦の紀元前1年と10000年より未来は妥当な値になるのか

W3CHTML5.2の2.4.5. Dates and timesと2.4.5.1. Monthsの内容に食い違いがあり0000-0110000-01が妥当な月の文字列かどうか良く分からないという話


追記

各仕様の内容、HTMLチェッカーによる解釈では以下の通りです

仕様またはチェッカー Month 0000-01 Month 10000-01
HTML 5.2の2.4.5. Dates and times 妥当 (*1) 妥当ではない
HTML 5.2の2.4.5.1. Months 妥当ではない 妥当
HTML Living Standard (*2) の2.3.5.1. Months 妥当ではない 妥当
Ready to check - Nu Html Checker (*3) 妥当ではない (Error: Year cannot be less than 1.) 妥当 (Warning: Year may be mistyped. (*4))
妥当 *1
between the proleptic year 0000, and the year 9999. の記述を0000年を含むと解釈した。含まなければ妥当ではない
HTML Living Standard *2
Last Updated を参照した
Ready to check - Nu Html Checker *3
時点の実装による
Warning: Year may be mistyped. *4
誤記の疑いとして警告が出ているだけで、エラーではない

HTML 5.2の2.4.5.1.、HTML Living Standard、Nu Html Checkerの判定が一致する事、HTML 5.2の2.4.5.のみ異なる判定となりNOTE内の記述であることから、2.4.5.のbetween the proleptic year 0000, and the year 9999.の記述が誤りであろうと考える

また、本記事、本追記を書くにあたり、twitterにて もんど (@momdo_) さんから色々助言をいただいた

改めて感謝を申し上げる


2.4.5. Dates and timesのNoteには以下の記述があります

This specification encodes dates and times according to a common subset of the [ISO8601] standard for dates.

(中略)

Dates are expressed in the proleptic Gregorian calendar between the proleptic year 0000, and the year 9999. Other years cannot be encoded.

Dates and timesは標準日付 [ISO 8601] の共通サブセットに従って日付と時刻をエンコードし、年は先発グレゴリオ暦で0000年から9999年の間であるとされています

紀元0年は存在しませんが、ISO 8601で0000年は先発グレゴリオ暦の紀元前1年とされているので、値としては 0000 から 9999 の間で、範囲は先発グレゴリオ暦紀元前1年から9999年の間と読めます

一方、2.4.5.1. Monthsで定義される妥当な月の文字列は以下の通りです

A string is a valid month string representing a year year and month month if it consists of the following components in the given order:

  1. Four or more ASCII digits, representing year, where year > 0
  2. A U+002D HYPHEN-MINUS character (-)
  3. Two ASCII digits, representing the month month, in the range 1 ≤ month ≤ 12

つまり、年を表す4桁以上のASCII数字で0より大きい数、ハイフン (-)、月を表す2桁のASCII数字で1以上12以下、を連続させたものが妥当な月の文字列となります

上記によればDates and timesのNOTEの記述に関わらず、0000-01は妥当な月を表す文字列ではありません (where year > 0の条件に反する)

一方で、Dates and timesのNOTEでは最大9999-12と読めますが、MonthsではFour or more ASCII digitsとあるので10000-01も妥当な月を表す文字列です

between the proleptic year 0000, and the year 9999. が 0000 と 9999 を含まないと解釈すれば0000-01は妥当でないとして双方の内容が一致しますが、9999については疑問が残ります

個人的な感想としては、Dates and timesのDates are expressed in the proleptic Gregorian calendar between the proleptic year 0000, and the year 9999. Other years cannot be encoded.の記述が単に余計で、NOTEで概要を説明しようとして他の箇所と矛盾する事を書いてしまっただけなのではないかと思うのですが、どうなのでしょうか


ちなみにHTML Living Standard — Last Updated 12 January 2018では2.3.5. Dates and timesのNOTEにbetween the proleptic year 0000, and the year 9999.の記述はないのでこの問題は生じません

その上で2.3.5.1. Monthsの妥当な月の文字列の年の部分の定義はFour or more ASCII digits, representing year, where year > 0となっており、W3CHTML5.2と同じです

2018年の抱負

この記事は自分向けの記事です

新年あけましてもう10日経ちましたが今年の抱負です

2017年の12月には決めており、前倒しで実行中ですが、blogの更新も再開したことですし表に出して宣言した方が途中で妥協したり投げ出したりしなくて良いだろう、という記事です

もうちょっと頻繁にblogを更新する

日記自体は6年くらい書いているのですが、公開しても構わない内容についてはblogとかで残した方が良いのではないかと昨年末に思って更新を再開しました

具体的な数値目標 (最低毎月1本とか) を定めて義務化すると私の性格だと長続きしないことが分かっているので更新されなくなったら「あ、やる気なくなったんだな」と思ってください

体重を60kgまで落とす

今何kgかというと74kgで、身長は165cmです

外見はそこまで肥満ではなく「そんなに太っているように見えない」とお世辞込みで言っていただけるのですが、つまり内臓脂肪と言う事です

体重計に載ると尿から糖とか蛋白とか嫌な単語が頭をよぎります

痩せろ

HTML5.2の仕様書を一通り読む

先日から始めたHTML5.2の見出し毎の内容を雑にまとめるシリーズが途中経過の成果物になります

昨年末から読み始めており、毎月1章分づつ記事が公開できれば嬉しいのですが、2018年内に終わる見込みが立っていません

兎に角一回読み終わってHTML5.3以降は変更点だけ読んで終わりにする、そんな人に私はなりたい

応用情報技術者試験に合格する

基本情報処理には合格しているのですが2001年のことで、業務で触れないし興味もないことにはとんと疎い状態が17年ほど続いております

そんな状況で身近な非プログラマーの人が昨年の秋期基本情報処理試験に合格しまして、なんの根拠もない私のプライドが危険に晒された為、応用情報処理を受験してみることにしました

まずは春期試験を受けますが、今年の抱負なので秋期試験で合格でもいいや、と年始から逃げを打っておくことにします

HTML5.2の見出し毎の内容を雑にまとめる、1. Introduction

HTML5.2の見出し毎の内容を雑にまとめる、この記事の序文と Abstract からの続き

1. Introductionから1.11. Suggested readingまで

殆どの部分がThis section is non-normative.である為、他の場所以上にざっくり斜め読み


1. Introduction (導入)
1.1 Background (背景)

This section is non-normative.

もともと学術文書のマークアップ用途だったのが、その後一般化してWebApplicationの記述までするようになったとかなんとか

1.2 Audience (この文書の仮想読者?)

This section is non-normative.

Web技術について全然知らない人はこの仕様読む前にチュートリアルとかやっとけ、特にDOMは知っとけ

1.3 Scope (範囲)

This section is non-normative.

この文書は静的または動的な文書の意味づけの仕様だよ、表現 (presentation) に関する仕様じゃないよ、オンラインの購買システム、検索システム、ゲーム、アドレス帳、コミュニケーションソフト、文書編集ソフト辺りが向いているよ

1.4 History (歴史)

This section is non-normative.

色々あって、HTML Standardの安定版をW3Cのグループが勧告するようにったよ

1.5 Design notes (設計ノート? (基本的な設計思想的な話?))

This section is non-normative.

色々あって一貫性ないし、デファクトスタンダードを取り込んだりしてきたけど、設計思想を説明するよ

1.5.1. Serializability of script execution (スクリプト実行の順次実行性? (このシリアルはパラレルの対義語で「並列処理しない」の意))

This section is non-normative.

Scriptの並列処理は複雑なのでできないようにしとくよ

1.5.2. Compliance with other specifications (他の仕様への準拠)

This section is non-normative.

他の仕様に依存しているけど競合することもあるけど、意図的な時は理由と共に意図的って書いとくよ

1.5.3. Extensibility (拡張性)

This section is non-normative.

意味づけの拡張の為にclass属性とかdata-*属性とかmeta要素とかrel属性とかscript要素とかJavaScriptを活用する方法があるよ

1.6. HTML vs XML Syntax (HTML構文 対 XML構文)

This section is non-normative.

HTML5はHTML構文とXML構文でかけるよ

1.7. Structure of this specification (この仕様の構成)

This section is non-normative.

この仕様の構成

1.7.1. How to read this specification (この仕様の読み方)

この仕様は何度も繰り返し読み返して把握すべきである

あと、HTMLの書き手側 (producers) へ要求する適合要件と、読み手側 (consumers) へ要求する処理方法は独立している

1.7.2. Typographic conventions (表記の規則)

この仕様の定義、要件、説明などのマークアップ

1.8. Privacy concerns (プライバシーへの憂慮)

This section is non-normative.

一部のHTMLの機能は、利便性を向上させる一方でユーザーのプライバシーを脅かす (ので注意が必要である)

1.9. A quick introduction to HTML (簡易なHTMLの手引き)

This section is non-normative.

HTMLの基本的な構造など

開始タグがあって、終了タグがあって、入れ子にはならなくて、みたいな話

1.9.1. Writing secure applications with HTML (HTMLで安全なアプリケーションを記述する)

This section is non-normative.

HTMLで双方向のサイト (interactive sites) を作成する場合、攻撃者がサイトやユーザーを危険に晒す脆弱性を作りこまないように気を付ける必要がある

  • Not validating user input
  • Cross-site scripting (XSS)
  • SQL injection
  • Cross-site request forgery (CSRF)
  • Clickjacking
1.9.2. Common pitfalls to avoid when using the scripting APIs (スクリプトAPIを利用する時に陥らないようにすべき、よくある穴)

This section is non-normative.

言葉で説明/理解するのが難しいので例示のコードを読むべし

凄く雑に言えば、イベントハンドラの登録タイミングによってはそのイベント完了後かもしれないので、イベントハンドラはそれを起こす要素などと一緒に追加するようにすれば安心、という話

1.9.3. How to catch mistakes when writing HTML: validators and conformance checkers (HTMLを書くときにミスを見つける方法: 検証ツールと適合性チェッカー)

This section is non-normative.

Ready to check - Nu Html Checker 使え

1.10. Conformance requirements for authors (著者に要求する適合条件)

This section is non-normative.

この仕様では妥当でない文書の処理方法についても定義する

ただし、妥当でない文書の処理方法が定義されているからと言って、妥当でない文書を書いていい訳ではない

1.10.1. Presentational markup (外見の為のマークアップ)

This section is non-normative.

以前のHTMLにあった大多数の外見の為の機能 (Presentational features) は不許可になったし、外見の為のマークアップは問題がある

唯一残っているのはstyle要素とstyle属性である

また、以下の要素は媒体から独立するよう再定義された: b, i, hr, s, small, u

1.10.2. Syntax errors (構文違反)

This section is non-normative.

HTMLの構文は様々な問題を避けるために制約が課せられているよ

具体的な内容は本文の具体例を参照すること

1.10.3. Restrictions on content models and on attribute values (コンテンツモデル (要素の内容) と属性値の制限)

This section is non-normative.

言語の構文以外にも、この仕様には要素と属性の指定にも制限が存在するよ

具体的な内容は本文の具体例を参照すること

1.11. Suggested reading (読んどくといいもの)

This section is non-normative.

  • Character Model for the World Wide Web 1.0: Fundamentals [CHARMOD]
  • Unicode Security Considerations [UNICODE-SECURITY]
  • Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG20]
  • Authoring Tool Accessibility Guidelines (ATAG) 2.0 [ATAG20]
  • User Agent Accessibility Guidelines (UAAG) 2.0 [UAAG20]
  • HTML Accessibility APIs Mappings 1.0 [html-aam-1.0]

続く

HTML5.2の見出し毎の内容を雑にまとめる、この記事の序文と Abstract

HTML4.01の頃はHTMLの仕様などを読んでいたが最近ご無沙汰でHTML5とかさっぱり分からなくなっているし、最新版以外のHTMLをすべて廃止しようという動きもある (Proposal to Republish Previous Versions of HTML and XHTML as Obsolete Recommendations (Wide Review until 2017-09-07) from Xueyuan on 2017-08-11 (public-review-announce@w3.org from August 2017) ) こともあり、改めて最新のHTMLの仕様を読んでみることにした

最新のHTMLの仕様というと、WHATWGのLiving StandardとW3CHTML5.2があるが、Living Standardは読んでいる間に内容が変わりそうなので、HTML5.2を対象と決めた

1回読んで全部理解できるものでもないので、とありえず読んだら章ごとに数行程度の要約や感想を書きつつ取り合えず頭から最後まで読んでみる事にした

この記事にはその記録である

なお、たった一行の要約でさえ多くの誤りが含まれている可能性があるが、予めご了承い頂きたい


HTML5.2 の仕様 を読むにあたり、momdo さん訳のHTML5.1の日本語訳とHTML Standerdの日本語訳を参照させていただいており、深く感謝している


Abstract (概要)

WWWの中核をなすHTMLの5.2だよ、今後ともどんどん更新していくよ

Status of this document (この文書の位置付け)

この文書はHTML5.1を廃止して取って代わるし、将来他の文書に取って代わられるから最新版は https://www.w3.org/TR/(https://www.w3.org/TR/) を見よ


HTML5.2の見出し毎の内容を雑にまとめる、1. Introduction へ続く

バッチファイルからWindows PoweShellの実行ポリシーを設定する

新しいWindows端末でPowerShellを使う場合、最初に実行ポリシィを設定する必要があります

最初に1回だけやればいい話ですが何らかの事情で頻繁に行う人にはやっぱり面倒です

そういう作業はPowerShellで自動化したい所ですが、なにせWindows PowerShellの実行ポリシーですのでWindows (DOS) コマンドのバッチをファイルの出番です

コマンドプロンプト上ではWindows PowerShellのコマンドレットはPowerShellコマンドで実行できます

PowerShell -Command "Set-ExecutionPolicy RemoteSigned -Scope CurrentUser;"

できました


これで終わりだと流石に短いのでもう少し続けます

仮に、Windows PowerShellで端末設定部分を自動化したけれど、そのps1ファイルを実行するのに実行ポリシーを変更したい、そして実行後はWindows PowerShellの実行ポリシーを元に戻したい、とします

この場合先にPowerShell Get-ExecutionPolicyで値を取得しておいて、あとから再設定することになります

ECHO OFF

REM 権限の保存
FOR /F "usebackq" %%i IN (`PowerShell -Command Get-ExecutionPolicy`) DO SET PSEP=%%i

REM 権限の設定
PowerShell -Command "Set-ExecutionPolicy RemoteSigned -Scope CurrentUser;"

REM ps1ファイルのの実行
PowerShell -File "\\nas\Set-EnvironmentInfo.ps1"

REM 権限を戻す
PowerShell -Command "Set-ExecutionPolicy %PSEP% -Scope CurrentUser;"

今回は最終的に実行したいps1ファイルを今回は\\nas\Set-EnvironmentInfo.ps1としています

また、バッチファイル化することを前提に考えているので%は二つ重ねて書いています

なお、設定をRemoteSignedにしていますが、もちろんここは用途に応じて変更してください

そんな感じで

Windows PowerShellのFunction入門 (Paramキィワード、Parameter属性編)

この記事はWindows PowerShellのFunctionのParamキィワードの基本的な説明とParameter属性の話です

値の指定 (AllowNullとか) などは出てきませんので予めご了承ください


PowerShellに名前付きで引数を設定するには、関数名の後ろに "()" で記述する方法と、関数内にParamキィワードで記述する方法の2種類ががあります

いずれの場合も宣言した変数名の$-に変えたものがパラメータ名になります

Function SampleFunction1 ($InputString) {
    Write-Host $InputString;
}

Function SampleFunction2 {
    Param(
        $InputString
    )
    Write-Host $InputString;
}

PS> SampleFunction1 -InputString "Hello";
Hello
PS> SampleFunction2 -InputString "World";
World
````

上記のどちらの書き方でも結果は同じ為、本記事では以下<code>param</code>キィワードを使う書き方で説明します

---

パラメータは変数宣言と同じように型名を付けて宣言することが出来ます

また、複数の引数を設定する場合、',' 区切りで記述します

Function SampleFunction3 { Param( [String] $InputString1, [String] $InputString2 ) Write-Host (($InputString1, $InputString2) -join ' '); }

PS> SampleFunction3 -InputString1 "Hello" -InputString2 "World"; Hello World ````


パラメータ用の特殊な型としてSwitchがあります

Switchはパラメータとして記述されると$True、なければ$falseになります

Function SampleFunction4 {
    Param(
        [Switch] $Switch1,
        [Switch] $Switch2
    )
    Write-Host (('Switch1 is', $Switch1) -join ' ');
    Write-Host (('Switch2 is', $Switch2) -join ' ');
}

PS> SampleFunction4 -Switch1;
Switch1 is True
Switch2 is False

パラメータにデフォルト値を付けたい場合、$変数名 = デフォルト値の形で記述します

Function SampleFunction5 {
    Param(
        [String] $String = 'Hello World'
    )
    Write-Host ($String);
}

PS> SampleFunction5;
Hello World


各引数には個別にParameter属性を記述することで、必須属性かどうか、パイプラインから値を受け取るかなどの設定を行う事ができます

主なParameter属性のオプションは以下の通りです

HelpMessage
パラメーターの簡単な説明文を String 型で指定。必須パラメーターの入力がない場合に使用されますが、使用方法は実装依存
Mandatory
必須かどうかを Boolean 値で指定
ParameterSetName
パラメーターのセット名を設定します。非常に長くなる為、本記事では割愛します
Position
パラメータ名がない引数の位置 (昇順) をInt型で指定。なお、関数内のすべてのパラメータがPositionを持たない場合、記述順で解釈される
ValueFromPipeline
パイプラインオブジェクトからの入力を受け入れるかどうかを Boolean 型で指定
ValueFromPipelineByPropertyName
同じ名前または同じエイリアスを持つパイプラインオブジェクトのプロパティから、その値を取得するかどうかを Boolean型で指定。ValueFromPipelineByPropertyNameが$trueの場合、ValueFromPipelineを併せて書く必要はない
ValueFromRemainingArguments
バインドされていない (パラメーター名つきなく、位置からも特定できない) 残りの引数を受け入れるかどうかを Boolean型で指定。記述がない場合は $false

以下サンプルコードです

# HelpMessage と Mandatory
Function SampleFunction6{
    Param(
        [Parameter(Mandatory=$true,HelpMessage='年齢を入力してください')]
        [String] $Age;
    )
}

PS> SampleFunction6
コマンド パイプライン位置 1 のコマンドレット SampleFunction6
次のパラメーターに値を指定してください:
(ヘルプを表示するには、「!?」と入力してください。)
Age: !?
年齢を入力してください
Age: 
# Position
Function SampleFunction7{
    Param(
        [Parameter(Position=3)]
        [Int] $C,
        [Parameter(Position=1)]
        [Int] $A,
        [Parameter(Position=2)]
        [Int] $B
    )
    Write-Host '$A is ' $A;
    Write-Host '$B is ' $B;
    Write-Host '$C is ' $C;
}

PS> SampleFunction7 1 2 3
$A is  1
$B is  2
$C is  3
# ValueFromPipeline
Function SampleFunction8{
    Param(
        [Parameter(ValueFromPipeline=$true)]
        [DateTime] $DateTime,
        [int] $AddDays = 0
    )
    $DateTime.AddDays($AddDays);
}

PS> Get-Date;
2017年12月27日 21:00:00
PS> Get-Date | SampleFunction8 -AddDate 3;
2017年12月30日 21:00:00
# ValueFromPipelineByPropertyName
Function SampleFunction9{
    Param(
        [Parameter(ValueFromPipelineByPropertyName=$true)]
        [Int] $Year,
        [Parameter(ValueFromPipelineByPropertyName=$true)]
        [Int] $Month,
        [Parameter(ValueFromPipelineByPropertyName=$true)]
        [Int] $Day
    )
    $Year;
    $Month;
    $Day;
}

Get-Date | SampleFunction9;
# ValueFromRemainingArguments
Function SampleFunction10{
    param (
        [int] $p1,
        [parameter(Position = 2)]
        [int] $p2,
        [parameter(ValueFromRemainingArguments=$true)]
        [Int[]] $others
    )
    $others;
}

PS> SampleFunction10 -p1 1 2 3 4 5
3
4
5

こんな感じで一つ