Változók - php "megjegyzés undefined változó", "notice undefined index" és "notice undefined

előző ◈ a következő

Futtatom a PHP szkriptet, és továbbra is ilyen hibákat kapok:

Megjegyzés: A nem definiált változó: my_variable_name a C: \ wamp \ www \ mypath \ index.php fájlban a 10. sorban

Megjegyzés: Meghatározatlan index: my_index C: \ wamp \ www \ mypath \ index.php a 11. sorban

A 10. és a 11. sor így néz ki:

Mit jelentenek ezek a hibák?

Miért tűnnek hirtelen? Évek óta használom ezt a szkriptet, és soha nem volt probléma.

Mit kell tennem a javításuk érdekében?

Ez egy általános referenciális kérdés, amelyre az emberek duplikátumként hivatkoznak, ahelyett, hogy újra és újra megmagyarázzák a problémát. Azt hiszem, ez azért szükséges, mert a legtöbb igazi válasz erre a kérdésre nagyon egyedi.

Kapcsolódó meta megbeszélések:

kérte Pekka 웃 május 20'17 a 23:08

Ez csak egy értesítés, így helyesen használjátok, és ez nem hiba vagy valami ilyesmi. - Amir Surnay május 20 17-én, 11:08 órakor

Nem lehet inicializálni egy változót. Inicializál egy változót egy üzenetből, vagy kapsz vagy bármilyen tömböt? Ha igen, akkor nincsenek mezők ebben a tömbben. Ez a te hozzáférésed. - KÉRDEZZE 20 Május 20-at 23:08-kor

"Miért tűnnek hirtelen? Évek óta használom ezt a szkriptet, és soha nem volt probléma. A válasz írásakor az alábbi válaszok egyike sem foglalkozik ezzel a kérdéssel. Nagyon nagylelkű vagyok ehhez. - ChrisJJ május 20-17-én 11:08 órakor

@ ChrisJJ, Robbie válasza ezt nagyon jól magyarázza. - Leith május 20-17-én, 11:08 órakor

Mi változott a közelmúltban? Milyen verziót használ a php? Módosult a konfiguráció? Lehet néhány hibát, amelyek a hiba forrását, mivel például, és a felvétel a szükséges php fájl nem működik, mint például a rövid nyitott tag többé nem szabad megengedni, funkciók elavultak, és így D. -. Fabs május 20 '17 23:08-kor

@Fred feltételezem, hogy mindkét lehetőségre argumentumot lehet tenni. Lehetséges, hogy az újonnan érkezők bevonják a teljes sort, beleértve a "Figyelmeztetés:" kifejezést a keresési lekérdezésben, amely biztos vagyok benne, hogy ez a fő forgalomgenerátor. Ha az üzenetek teljes körűen jelen vannak, valószínűleg javítani fogja a keresőmotorok láthatóságát - Pekka 웃 május 20 '17, 23:08

@ Fred-ii- Kérdezzen egy kérdést, azonnal válaszolva, és kérje a moderátort, hogy tegyen fel kérdést a közösségi wiki munkájának. Bele szabad másolni és beilleszteni a fenti felelősségi blokkot. - Pekka 웃 május 20-17-én, 11:08 órakor

A PHP Manual hatalmas bölcsességéből

Egy nem inicializált változó alapértelmezett értéke alapján problémás, ha egy fájl egy másik, a változó nevét használó másik fájlba kerül. Ez is a legfontosabb biztonsági kockázat a register_globals engedélyezve. hiba szint E_NOTICE Nem inicializált változókkal való munka esetén, de nem abban az esetben, ha elemeket adunk hozzá egy nem inicializált tömbhöz. isset () A nyelvi konstrukció meghatározható egy változó már inicializálása. Ezenkívül az üres () megoldás ideálisabb. mert nem generál figyelmeztetést vagy hibaüzenetet, ha a változót nem inicializálták.

Ha a változó nem létezik, figyelmeztetés nem keletkezik. Ez azt jelenti, hogy üres () lényegében rövid egyenértékű. Isset ($ var) || $ var == hamis.

Ez azt jelenti, hogy csak üres () karaktert használhat. annak megállapításához, hogy van-e beállítva egy változó, és ezenkívül ellenőrzi a következő, 0, "", null változót.

A probléma megoldásának módjai:

Javasoljuk: Értesítse változóit, például amikor megpróbálja hozzáadni a karakterláncot egy nem definiált változóhoz. Vagy használja a isset () /! Üres () billentyűt. Annak ellenőrzésére, hogy a hivatkozás előtt megjelentek-e, például:

Ez sokkal tisztábbá vált a PHP 7.0-mal, most már használhatja az üres coalescence operátort

Állítsa be saját hibakeresőjét. Az E_NOTICE és az alapértelmezett kimenetre (esetleg naplófájlra) irányuló üzenetek átirányítása:

E_NOTICE letiltása a jelentésekből. Egy gyors módja annak, hogy kizárja az E_NOTICE szolgáltatást:

Tüntesse el a hibát a @ kezelővel.

Megjegyzés. Erősen ajánlott csak az 1. pont végrehajtása.

Ez az értesítés akkor jelenik meg, ha (vagy PHP) megpróbál hozzáférni egy határozatlan tömbindexhez.

A probléma megoldásának módjai:

Ellenőrizze, hogy az index létezik-e a hozzáférés előtt. Ehhez használhatod a isset () vagy array_key_exists () függvényt:

A list () nyelv kialakítása ezt akkor generálhatja, ha megpróbál hozzáférni egy tömb indexhez, amely nem létezik:

Két változót használunk a tömb két elemének eléréséhez, de a tömbnek csak egy eleme van, 0. indexe. Ezért létrehozza:

Megjegyzés: Meghatározatlan eltolás: 1

A fenti megjegyzések gyakran jelennek meg a $ _POST használatakor. $ _GET vagy $ _SESSION. $ _POST és $ _GET esetén csak ellenőrizni kell, hogy az index létezik-e vagy sem, mielőtt használná őket. $ _SESSION esetén meg kell győződnie arról, hogy a munkamenet a session_start () programmal indult, és az index is létezik.

Vegye figyelembe, hogy mind a 3 változó superglobal. Ez azt jelenti, hogy nagybetűvel kell írni.

@ dieselpower44 Néhány megfontolás: "Az üzemeltető bezárva" (@) néhány teljesítményprobléma. Ezenkívül, mivel az elhárítja az összes hibát egy adott területen belül, anélkül, hogy óvatosan használná, elfedheti azokat az üzeneteket, amelyeket szeretnél látni. - IMSoP május 20-17-én, 11:07 órakor

A problémák elrejtése NEM a problémák megoldása. Elem # 2. # 4 csak termelési kiszolgálókon használható, és nem általában. - Salman A május 20 17-én, 11: 07-kor

Lehetőség van arra, hogy letiltja az inline üzenetet (nem a kezelőben), ha egy speciális hibakezelőt is használnak? $ var = @ $ _ GET ['nonexisting']; még mindig értesítést küld. - Alph.Dev május 20-án 17: 17-kor

Miért ajánlott 1. $ value = isset ($ _ POST ['value']) használatát? $ _POST ['érték']. ''; helyett 4. $ value = @ $ _ POST ['value']; - Forsvunnet május 20 17-én 11: 07-kor

@twistedpixel Ezek a 4 mód független, ez nem egy 4 lépéses útmutató. Tehát ha úgy döntesz, hogy használja a 4. módszert, akkor azt jelenti, hogy nem hajtotta végre az első 3 módszert, így nem szüntett meg semmilyen hibát. - Aycan Yaşıt május 20 17-én, 11:07 órakor

A (z) isset () használata nem működik számomra. De az array_key_exists () és a @ works - Mugoma J. Okomba május 20'17-én 23: 07-kor

Nem javasoljuk az isset () függvényt a tömbök számára, például $ str = '111'; (Tudom, hogy tömb kell legyen) isset ($ str [0]) vissza fog térni. Jobb használni az array_key_exist () helyett isset () - Mb Rostami May 20 '17 at 23:07

És (gyakran nem ajánlott), az alternatíva a hibaelnyelési operátor @. Ez egy speciális nyelvi terv, amely lezárja a nem kívánt értesítéseket és figyelmeztetéseket, de óvatosan kell használni.

Először a microprocesszor vezérlésének büntetését veszi át az isset használatára. Ez nem mérhető a valódi alkalmazásokban, de figyelembe kell venni az adatok súlyos iterációjában. Másodszor, megakadályozhatja a hibakeresést, de ugyanakkor az elfojtott hibákat ténylegesen átadják a felhasználói hibák kezelőinek (ellentétben a kibocsátásokkal díszített kifejezésekkel).

válaszolt mario 20 május '17-én 23:07-kor

Ha kíváncsi, milyen hatást gyakorol a teljesítményre, ebben a cikkben ez jól le van írva. derickrethans.nl/. - Gajus május 20-án 17: 17-kor

Köszönöm @mario, érdekel. Most, ha valaki elég jó ahhoz, hogy összehasonlítsa a kettőt. 3v4l.org/CYVOn/perf#tabs 3v4l.org/FLp3D/perf#tabs megfelelően ezt a tesztet, úgy tűnik, hogy azonosak (megjegyezzük, hogy zoom). - Gajus május 20-án 17: 17-kor

Én teszteltem a PHP 5.4-nel, és a teljesítmény még mindig rossz. - Brynner Ferreira május 20-án 17-kor, 11:07 órakor

Általában a "rossz programozás" miatt és a hibák lehetősége miatt most vagy később.

  1. Ha ez hiba, először hajtsa végre a változó helyes hozzárendelését: $ varname = 0;
  2. Ha ez valóban csak néha meg van határozva, ellenőrizze ezt: if (isset ($ varname)). mielőtt használná
  3. Ha ez helytelen írásmód miatt van, csak javítsa ki.
  4. Lehetőség van arra is, hogy figyelmeztetéseket mutasson be PHP-ben

Erik válaszát május 20-án, 17-kor 23: 07-kor

Kérjük, ne kapcsolja ki a figyelmeztetést. A szigorúbb nyelvek gyakran azt jelenti, „lehet egy hiba, jobb, nézd ezt a sort kétszer” - azon a nyelven engedélyezett a PHP, gyakran azt jelenti, „ez a kód szar, és diktálja a hiba, azt igyekszik bizonyos értelemben, de jobb, hogy javítsa ki a lehető leghamarabb. " - delnan május 17-én, 23-kor

Bár egyetértek az első három ponttal, a 4. sz. Egyszerűen rossz. A probléma elrejtése nem fogja elengedni, és ez további problémákat okozhat a jövőben. - Valentin Flachsel május 20'17-én, 11:07 órakor

@Freek teljesen igaz, de egyes forgatókönyvek (vásárolt forgatókönyv nulla technikai tudás, meg kell futtatni a következő napra.) Az oldatot szállítószalagok - nagyon rossz, mindig hangsúlyozni kell, de a lehetőség - Pekka 웃 május 20 in '17 23:07

A csatorna jó. néha. Történelmileg a figyelmeztetéseket standard PHP-beállításokká változtatták, de a defakt paraméterek szigorúbbak lettek. Sajnálatos, sokan visszatérnek a régi beállításokhoz, hogy ne zavarják az ügyfeleket. - Erik május 20 17-én, 11:07 órakor

Válaszul a következő kérdésre: "Miért tűnnek hirtelen? Évek óta használtam ezt a szkriptet, és soha nem volt gondom.

A legtöbb webhely esetében gyakran használják az "Összes hibát, de nem" értesítést "és" elavultt "hibaüzenetet. Ezt a php.ini fájlban telepítik, és a kiszolgáló összes webhelyére alkalmazzák. Ez azt jelenti, hogy a példákban használt "értesítések" rejtve maradnak (rejtettek), míg a kritikusabbnak tekintett egyéb hibák megjelenítésre / felvételre kerülnek.

Egy másik kritikus paraméter az, hogy a hibák elrejthetők (azaz a display_errors "off" vagy "syslog" -ra van állítva).

Ebben az esetben a hibajelentés változik, hogy az értesítéseket is megjelenítse (mint a példákban) és / vagy a beállítások a képernyõn megjelenõ display_errorsekké változtak (ahelyett, hogy elnyomnák / regisztrálnák).

Miért változtak?

A nyilvánvaló / egyszerű válasz az, hogy valaki korrigálta ezeket a paramétereket a php.ini-ben, vagy egy frissített PHP-verzió már korábban használ egy másik php.ini-et. Ez az első hely a kereséshez.

Azonban lehetséges ezen paraméterek felülbírálása is

  • .htconf (a webszerver konfigurációja, beleértve a virtuális állomásokat és alkonfigurációkat) *
  • .htaccess
  • A php-kódban

És bármelyikük is megváltoztatható.

Van még egy további komplikáció, hogy a webkiszolgáló konfigurációja engedélyezheti / letilthatja a .htaccess irányelveket, ezért ha van olyan utasítások a .htaccess-ban, amelyek hirtelen elindítják / leállítják a munkát, ezt ellenőrizni kell.

(.htconf / .htaccess feltételezi, hogy apache-ként fut. Ha a parancssor fut, ez nem érvényes akkor, ha IIS-t vagy más webszervert használ, akkor ezeket a beállításokat ellenőrizni kell)

  • Ellenőrizze, hogy a php.ini php utasításai hibajelentés és display_errors php direktívái nem változtak-e meg, vagy hogy még nem használta a php.ini-t előzőleg.
  • Ellenőrizze a php direktíva error_reporting és display_errors-jét .htconf-ban (vagy vhosts stb.). Nem változott
  • Ellenőrizze, hogy a .htaccess hibakezelő és display_errors php direktívái nem módosultak-e
  • Ha van egy irányelv a .htaccess-ban, akkor ellenőrizze, hogy megengedett-e az .htconf fájlban
  • Végül ellenőrizze a kódot; Talán egy nem kapcsolódó könyvtár; Annak ellenőrzése, hogy a hibajelentés és a megjelenítési hibák beállítása a php irányelvekre van-e beállítva.

válaszolt Robbie május 20-án 17-kor 23: 07-kor

Miért történik ez a helyzet?

Idővel a PHP nyelvközpontúbbá vált. Az alapértelmezés szerint korábban letiltott beállítások alapértelmezés szerint engedélyezettek. Ennek kiváló példája E_STRICT. amely alapértelmezés szerint be volt kapcsolva, mint a PHP 5.4.0.

Ezenkívül a PHP dokumentáció szerint a defualt, az E_NOTICE le van tiltva a php.ini fájlban. A PHP-dokumentumok javasolják a hibakeresési célok beillesztését. Azonban, amikor betöltöm a PHP-t az Ubuntu tárból és a Windows BitNami veremről, látok valami mást.

Ne feledje, hogy alapértelmezés szerint a error_reporting a gyártási értékre, nem pedig az alapértelmezett értékre van állítva. Ez kissé zavaró és a php.ini-n kívül nem dokumentált, ezért más verziókon nem ellenőriztem.

A kérdés megválaszolásához azonban ez a hiba akkor jelenik meg, ha korábban nem jelent meg, mert:

Telepítette a PHP-t, és az új alapértelmezett beállítások némileg rosszul dokumentáltak, de nem zárják ki az E_NOTICE kifejezést.

Mit tehetek?

E_NOTICE letiltása. a "Alapértelmezett érték" E_ALL másolásával

Az E_NOTICE letiltása a fájl vagy a mappa szintjén. Ez előnyösebb lehet, ha van egy elavult kódja, de valami "rendben" akarsz csinálni. Ehhez konzultálnia kell az Apache2, nginx vagy bármely más tetszőleges szerverrel. Az Apache-ban a php_value-ot kell használnod .

Írja át újra a kódot, hogy tisztábbá tegye. Ha meg kell csinálni az átmenet során a termelési környezetbe, és nem akarja, hogy bárki is látni a hibákat, győződjön meg róla, kikapcsolja a kijelzőt, a hibák és csak regisztrálni a hibákat (lásd. Display_errors és log_errors php .ini, és konfigurálja a szerver) .

E_DEPRECATED. hogy megértsük, mi lehet a jövőben rosszul. Rengeteg ismeretlen hibát fog látni, de ez megakadályozza a kellemetlen problémákat, ha frissítenie kell a PHP-t a jövőben.

Mit jelent a szám?

Meghatározatlan változó: my_variable_name - Ez akkor fordul elő, ha a változó nem lett meghatározva használat előtt. Amikor a PHP parancsfájl végrehajtásra kerül, akkor a belső NULL értéket veszi fel. Azonban, melyik forgatókönyvben kell ellenőriznie a változót, mielőtt meghatározná? Végső soron ez az argumentum a "hanyag kód" számára. Mint fejlesztõ, azt mondhatom, hogy tetszik nekem, amikor egy nyílt forrású projektet látok, ahol a változók a mezõk magasak, mert meghatározhatók. Ez megkönnyíti a jövőben megjelenő változók meghatározását, és megkönnyíti a kód olvasását / tanulmányozását.

Undefined index: my_index - ez akkor történik, ha megpróbál hozzáférni egy értékhez egy tömbben, és nem létezik. A hiba megelőzéséhez végezze el a feltételes ellenőrzést.

Egy másik lehetőség az üres tömb kijelzése a funkció tetején. Ez nem mindig lehetséges.

(További tipp)

  • Amikor ezekbe és más problémákba ütköztem, használtam a NetBeans IDE-t (ingyen), és sok figyelmeztetést és értesítést adott nekem. Néhányan nagyon hasznos tanácsokat nyújtanak. Ez nem követelmény, és már nem használom az IDE-t, kivéve a nagy projekteket. Manapság több vagyok vim személy :).

válaszolt a smcjones 20 május '17-én 23:08-kor

előző ◈ a következő