The PHP documentation says:

> 
> Of course, in order to be useful, functions that operate on text may have to make some assumptions about how the string is encoded. Unfortunately, there is much variation on this matter throughout PHP’s functions:
> 
> 
> [... a few special cases are described ...]
> 
> 
> Ultimately, this means writing correct programs using Unicode depends on carefully avoiding functions that will not work and that most likely will corrupt the data [...]
> 
> 
> 

Source: <https://www.php.net/manual/en/language.types.string.php>

So naturally my question is: Where are these specifications that allow us to identify the encoding/charset associated to string arguments, return values, constants, array keys/values, ... for built-in functions/methods/data (e.g. `array_key_exists`, `DOMDocument::getElementsByTagName`, `DateTime::format`, `$_GET[$key]`, `ini_set`, `PDO::__construct`, `json_decode`, `Exception::getMessage()` and many more)? How do composer package providers specify the encodings in which they accept/provide textual data?

I have been working roughly with the following heuristic: (1) never change the encoding of anything, (2) when forced to pick an encoding, pick UTF-8. This has been working for years but it feels very unsatisfactory.

Whenever I try to find an answer to the question, I only get search results relating to url encoding, HTML entities or explaining the interpretation of string literals (with the source file's encoding).